为什么把标题加上未雨绸缪这个成语呢，首先先来解释下这个成语的含义：
未雨绸缪出自《诗经·豳风·鸱鸮》：【迨天之未阴雨，彻彼桑土，绸缪牖户。】（绸缪：修补）意思是鸱鸮在未下雨时就啄来桑树皮，修补鸟巢。后用「未雨绸缪」比喻事先作好准备，预防意外的事情发生。
那我们在做一个项目架构时就应该做到未雨绸缪，那我们如何做准备呢，那就是在项目的架构阶段，对所有的问题做一个预警分析，那哪些问题需要我们在架构设计阶段来思考呢？在说要思考的问题前，先来看下鸟巢的例子。
1、鸟巢设计师
国家体育场鸟巢由雅克·赫尔佐格、德梅隆、艾未未以及李兴刚等设计，由北京城建集团负责施工。体育场的形态如同孕育生命的“巢”和摇篮，寄托着人类对未来的希望。
如果你是鸟巢的总设计师，你要做怎么样的思考才能把鸟巢建设的即美观又实用，同时也能为后续的文体活动提供场所。如果我要是总设计师，那我可能会考虑到下面的一些事：
● 场馆选址，场馆建在哪里，哪里有这么大的规划用地、是否需要居民搬迁、交通是否便利等
● 容座量，因为是主体育场，所以座位数不能太少，是1w,5w还是10w
● 通风&采光，虽然是室外体育场这块估计也会考虑的，风速对田径运动员的成绩还是有影响的，采光也决定了比赛的时间，阳光照射时间长，比赛时间就短了
● 排水系统，北京的天气比较多变，8月份又多雨，那排水系统肯定也需要考虑的，积水要快速排出，避免影响比赛
● 逃生通道，对于一个可以容纳8w人的体育场，如果发生自然灾害、恐怖袭击等突发事件，逃生通道也是至关重要的，要保证人民的生命和财产安全，在哪里置逃生通道，一共设置多少逃生通道都是要有考量的
● 外观设计，首先外观要独特，并且有象征意义
● 复用性设计，体育场不能只在奥运期间使用一次，要能复用；后续要能举办其它的文体活动，目前一共有8位艺人在鸟巢举行了演唱会，充分做到了复用性
当然了我不是学建筑的，对于这里面的知识不是特了解，真正的设计师肯定要考虑的更多；只有许多因素都进行设计和考虑后，才会正式开工。那为什么要事先考虑和设计这些事呢，举个简单的例子：假如场馆在投入使用后没有对逃生通道做设计，只是设计了一些通往体育场外的门，在发生突发事件后，由于通往场馆外的门比较小，只能容纳少数人通过，这样就会造成踩踏事件，伤亡会进一步增加；由于没有明确的逃生通道标识，有些人根本不知道哪里可以逃出去。看到了吧，伤害有多大。
2、软件架构师
上面介绍了一下，做为鸟巢设计师的一些设计和思考，下面回归软件的架构体系，我会从宏观层面出发，对技术架构中涉及到的一些问题进行总结和分析，不对具体细节做延伸讨论，细节问题可根据实际场景自行设计方案。
2.1、背景目标
● 明确项目背景，清晰定义需要解决的问题
● 预估收益，目标设定符合SMART
● 业务场景是什么，明确业务的价值有哪些
● 用户群体是什么？是否跟目前的产品定位符合
2.2、需求分析
● 准确分析业务需求，需求跟目标是否一致，是否是伪需求
● 区分产品需求和解决方案，饿了是需求，吃饭是解决方案
● 考虑需求覆盖的完整性，有没有遗漏的点，特别是特殊场景、边界场景
2.3、架构决策
● 行业调研，其它公司如何干的，其他部门是如何干的，方案对比需要全面，避免带着结论去对比
● 从产品和技术的角度分别调研业内先进解决方案，调研公司内部有没有现成的轮子，不要重复造轮子
● 业界是否有成熟的方案，避免偏门的解决方案，方案在本公司是否可行，付出成本怎样，未来收益如何
2.4、技术选型
● 开发成本、运维成本、社区文档完备、技术成熟度，其它部门是否使用过，踩过哪些坑
● 架构设计，支持的语言有哪些，是否可扩展
● 技术选型的列表，优缺点对比分析，最终的建议
2.5、技术架构设计
2.5.1、逻辑建模
● 逻辑建模，是一个抽象过程，提炼模型
● 梳理领域概念，核心业务模型
● 有哪些实体，实体关系：1:1 ，1:m，n:m
● 保证ER图和DB设计的一致性
2.5.2、框架服务
● 分层设计、微服务、模块化
● 高内聚、低耦合、职责单一
● 明确上下游依赖服务，这些服务的SLA如何？服务是否有单点问题（依赖组件、依赖的外部服务），单点问题的解决策略以及降级方案如何？
● 解决方案是最好的吗？是否有Plan B计划?
2.5.3、接口设计
● 接口粒度，细粒度CRUD、名字是有业务含义的API
● 接口要具有原子性、写接口要具有幂等性
● 接口是否需要分页，是否需要限制结果的返回数量
● 新接口向下兼容，避免暴露过多接口
2.5.4、存储设计
● 数据持久化选型，Mysql，Nosql，离线存储，文件存储
● 主键id生成，未来1~3年的数据量，是否有分库分表需求，是否可做数据归档
● 索引设计，冗余字段（如果需要）
● 全文检索是否由搜索引擎支持，数据如何同步到搜索引擎，增量、全量？搜索引擎何时重新构建索引
● 新数据结构兼容老结构，是否有数据清洗，是否需要双写，如何保证数据安全
2.5.5、降级兜底
● 业务是否需要降级？核心业务有损降级+合理的替代方案，非核心服务无损降级
● 接口是否有降级，降级用户是否有感知，如何做到用户无感知
● 降级策略是手动降级，还是自动降级，手动降级开关谁来控制，产品、研发、测试，是否需要领导审批？
注：如果对某个接口和某个核心业务做了降级，记得一定要验证一下，踩过大坑，不是认为配置好了，就万事大吉，切记要验证！
2.5.6、非功能设计
● 服务SLA，对外要保证几个9，通常要保证4个9
● 性能问题，QPS，响应时间（设置要合理，非常重要）
● 安全问题，数据安全，网络安全，反编译，接口安全，权限控制
● 服务治理，限流，降级，扩容（一定要问下容器云，他们是如何做数据采样的），容灾，冗余备份，多机房
● 监控报警，机器基础监控，性能监控，可用性监控，外部依赖监控，容量监控，业务监控
注：非功能设计，是指软件产品为满足用户业务需求而必须具有且除功能需求以外的特性，包括可用性、安全性、可靠性、互操作性、健壮性等
2.5.7、安全设计
● 常见的攻击手段，XSS攻击、DDOS攻击、SQL注入、CSRF
● 安全漏洞自查：敏感信息（个人信息，手机号，邮箱，银行卡，地址等）
● 有敏感信息的接口，通过id参数遍历是否会暴露数据
● 核心接口是否鉴权
● 敏感信息存储是否加密
● 敏感信息是否暴露给了前端
2.6、业务架构设计
● 业务平台化：业务平台相互独立，基础业务下沉、服务化。
● 业务线上化：所有业务线上化操作，避免线下操作（有线下操作的要进行数据回捞，如不回捞数据会丢失，无法进行统计分析等其它操作）
● 业务隔离化：核心和非核心业务隔离，核心业务精简，非核心业务多样化。
● 业务闭环化：业务尽量在一个业务内闭环，避免共用（共用的地方可以平台化），因为差异化的地方需要定制，比如国内和海外要有两套体系
● 业务平台统一化：做到同一个业务只在一个地方维护，避免多个系统同时使用，有必要的话进行合并。
2.7、实施计划
● 实施步骤，严格按照设定方案执行，临时调整要周知干系人、给出说明、并更新设计改文档
● 实施成本如何，是否有更好的实践，是否可并行
● 人力情况，设计、前端、测试、后端，支撑侧人力
● 是否可以分步实施，减少风险
● 是否有多端有一致问题（人力短缺，有更重要的项目），如何解决？
● 坚持每日站会，确认关键时间点的进度，同步风险
3、总结
软件的架构设计是一个庞大且复杂的事，三言两语不可能概括的清楚，本文通过一些简单的思考和总结，希望同学们在软件架构设计上增加一些经验和思考点。由于个人水平有限难免有不足之处，各位看官莫怪；吾自当奋发图强，弥补不足！