为什么把标题加上未雨绸缪这个成语呢首先先来解释下这个成语的含义
未雨绸缪出自《诗经·豳风·鸱鸮》【迨天之未阴雨彻彼桑土绸缪牖户。】绸缪修补意思是鸱鸮在未下雨时就啄来桑树皮修补鸟巢。后用「未雨绸缪」比喻事先作好准备预防意外的事情发生。
 
那我们在做一个项目架构时就应该做到未雨绸缪那我们如何做准备呢那就是在项目的架构阶段对所有的问题做一个预警分析那哪些问题需要我们在架构设计阶段来思考呢在说要思考的问题前先来看下鸟巢的例子。

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:mn:m
● 保证ER图和DB设计的一致性

2.5.2、框架服务

● 分层设计、微服务、模块化
● 高内聚、低耦合、职责单一
● 明确上下游依赖服务这些服务的SLA如何服务是否有单点问题依赖组件、依赖的外部服务单点问题的解决策略以及降级方案如何
● 解决方案是最好的吗是否有Plan B计划?

2.5.3、接口设计

● 接口粒度细粒度CRUD、名字是有业务含义的API
● 接口要具有原子性、写接口要具有幂等性
● 接口是否需要分页是否需要限制结果的返回数量
● 新接口向下兼容避免暴露过多接口

2.5.4、存储设计

● 数据持久化选型MysqlNosql离线存储文件存储
● 主键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、总结

软件的架构设计是一个庞大且复杂的事三言两语不可能概括的清楚本文通过一些简单的思考和总结希望同学们在软件架构设计上增加一些经验和思考点。由于个人水平有限难免有不足之处各位看官莫怪吾自当奋发图强弥补不足