如何做好系统分析与设计

系统分析与设计的质量直接关系到项目需求落地的质量，这个过程也是倒逼开发者真正去弄清楚需求背景、技术细节、技术风险等，如果系统分析与设计搞得马马虎虎，那项目的最终质量就很难保障。

上图是笔者总结的系统分析与设计的脑图，罗列了需要注意的事项与结构化思考，下文将从需求分析、架构设计、领域驱动、风险管控等来分析如何做好系统分析与设计。

一、需求分析

需求分析是很多开发者容易忽视的一部分，切忌一拿到需求就埋头去干，不然很容易走进坑里而不自知，需求分析重点是要评估需求的合理性和风险：

搞清楚为什么要做这个需求，以后可能往哪个方向发展
业务指标是什么，如何衡量业务成果
目前的需求链路设计是否合理，是否能实现业务目标，如果不合理要提供技术反馈意见
需求可能会产生什么风险，比如舆情投诉风险、资损风险等等
需求的业务价值是什么，价值高低如何以及业务优先、级紧急程度等，如果是低价值需求或者不合理需求，要考虑是否可以砍掉或者把开发资源暂时让位给其他更重要的需求。

二、架构设计

完成需求分析后，如果确认需求合理就要投入到相关技术链路的架构设计中了，架构设计涉及到的面很广，每一个点拿出来单独讲都会有很多东西，这时要结合具体需求来做裁剪，不必要面面俱到，突出重点即可。

脑图中列出的架构设计事项可以作为一个技术设计时的参考模板，尤其是大型系统的设计中都是必须要考虑清楚的地方。

1.数据链路设计

选用什么样的数据库比较合适，MySQL or NOSQL，数据库的稳定性、可扩展性是否满足业务需求

数据库与表结构设计要考虑将来数据量可能有多大，是否要分库分表，如果分库分表，涉及到多维度的数据查询又该如何处理。
表结构的设计一定要细化到字段，字段类型、是否可空、字段枚举值等等都要想清楚，不然写代码时很可能因为一个字段就要返工。

2.高并发设计

如果是交易链路的高并发，要考虑超卖问题与热点问题，做好订单库存的设计。
系统上线前要评估后系统流量并做接口性能压测，要有系统限流设计，设置限流阈值
如果因为高并发导致系统问题，比如第三方接口异常、超时，要考虑设计对应的数据兜底机制与业务降级机制，不能让用户感知到系统不可用。

3.缓存设计

如果系统中用到了缓存，要考虑热点缓存、缓存击穿、缓存雪崩、缓存数据一致性等场景的处理方案
缓存不可作为数据单点使用，如果缓存出现异常，要有降级措施，比如直接走数据库查询或者有数据兜底机制。

4.数据一致性设计

如果涉及到多个数据源，要考虑采用什么样的分布式事务架构来保障数据的一致性，事务消息还是二阶段提交等等。
要建立数据巡检机制，做数据核对，及时发现数据不一致的情况并报警处理
要有必备的数据处理工具，当发现不一致时使用工具及时处理，不要直接上SQL来订正，风险很高。

5.可扩展性设计

可扩展性设计要适度超前，不能闭门造车，过度设计，不然徒增系统复杂度。
可扩展性设计最好是基于业务的发展需求来设计，不可自己去凭空设想一些可能的需求。
可扩展性的基本思想是拆分，面向流程拆分、面向服务拆分、面向功能拆分
可以结合设计模式，让代码更具备可扩展性
系统能力复用也是可扩展性的体现，可重用性设计离不开对业务的抽象，要站在业务之上看问题，横向思考，这个对开发者要求比较高。
表设计、命名、接口设计、功能实现等都要考虑是否可以给复用给其他场景来使用。

6.可维护性设计

类、接口、字段等命名是否合理，是否可以做到见名知意，如果名字比较随意，那后来人维护代码的时候也比较难以理解，代码可读性一定要高。
重视技术文档沉淀，文档是很好的技术沉淀与沟通工具，技术要详细明了，重点突出，这样其他人比较容易看懂相关的功能设计。
架构设计也一定要尽量简单，设计得越复杂，将来维护起来越麻烦，能用一个数据库解决，就不要搞两个，能不分库分表就暂时先用单表，架构设计是一个不断演化的过程，切忌过度设计。

7.高可用设计

高可用的本质是冗余

监控报警要想清楚哪些业务场景需要做监控，监控的粒度是什么，使用什么样的监控报警平台等等
开关切流设计，常见于新旧链路的切换等场景，开关设计的目的是应急回滚。
兜底机制，如果系统出现异常，如何做业务兜底设计，比如CDN页面兜底等等
灾备机制，数据库灾备、机房灾备、集群灾备等等

8.稳定性设计

服务上线三板斧：可应急、可监控、可灰度，这三条是新服务发布时的硬性指标，在设计时一定要考虑到，以防万一上线时系统有问题引发不可弥补的损失。
新服务上线前还要预估好流量大小，如果确定流量很大，必须配置相应的限流配置，并在上线前做相关系统性能的压测。
压测也是确保服务稳定性的一个重要手段，通过压测来考察系统的性能和吞吐量，对于大流量系统，新服务切不可没有压测就直接发布上线。
压测又可以分为单链路压测和全链路压测，像双11这种大流量场景，就需要多次的单链路压测和整个集团的全链路压测来衡量系统的稳定性。

9.架构设计原则

基于已有资源设计适合当前情况的架构，不可盲目照抄所谓的BAT架构，要依据实际情况灵活决策技术方案，不可生搬硬套。
大道至简，技术方案要追求把复杂的事情简单化，越是简单的架构越是方便维护，切不可追求架构的复杂性来显示个人的技术水准。
好的架构是演化出来的，不可能一步到位，注意不要过度设计，不要瞎猜业务需求。

三、风险管控

技术方案设计一定要考虑这个产品链路可能存在的风险点，包括技术风险和业务风险。

技术风险：比如新老链路的切换、接口性能超时不稳定、算法结果不符合预期等等
业务风险：有可能新功能新设计会引发用户投诉，引起舆情，涉及到资金流的场景也可能是资损风险等等
安全风险：写服务的黄赌毒内容过滤、读服务的接口防爬等

这三类型的风险结合具体需求要在设计文档中体现出来，并给出相应的解决方案，并把风险告知相关的业务方和产品经理。

风险评估是技术设计中容易被忽略的一环，但也是极其重要的，在一些金融业务场景，如果风险评估不到位，极有可能给公司带来重要资金损失，那最终自己可能也要凉凉了，不可不慎重。

四、领域驱动设计

从国内实际开发情况来看，真正去实践领域驱动的团队并不多，毕竟成本还是比较高的。但是领域驱动设计的思想要有，要有意识的运用领域驱动设计的思想去审视自己的系统设计方案。领域驱动设计是一个很好的方法论，值得学习借鉴，当然如果能实践自然更好了。

领域模型：要画出系统的领域模型，这个过程可以帮你搞清楚系统各功能模块的边界与联系，以及各模块本身的设计细节。
领域驱动的一个重要原则是把隐含的逻辑给显性化的表达出来
通过领域驱动设计来做系统模块的分层设计

五、开发排期

评估当前系统开发的可投入资源以及各个功能模块的开发人日，做成表格。
如果涉及到上下游链路的开发配合，需要去协调其他开发者的投入资源
确定测试资源，如果排期时间很紧迫，可以分模块交付与测试，做到开发与测试的并行
把排期同步给产品与业务方，沟通达成对项目交付期限的预期
对于排期要充分评估，不可盲目乐观，要留一定的冗余时间，不然一旦不能按期完成就非常被动了。
拒绝开发周期倒排，99%的倒排都没有什么意义。

更多内容欢迎关注个人微信公众号：技术进阶之路，一起成长！
如何做好系统分析与设计系统分析与设计的质量直接关系到项目需求落地的质量https://mp.weixin.qq.com/s?__biz=MzI0MDQwOTc5NQ==&mid=2247483816&idx=1&sn=f7d0652bf862ca5300f5b439c3c47f00&chksm=e91a0c04de6d85123f288b4bf665e84dc2fdce8353fe1bbb02ae4817b2b38d315c38e58aee7e&scene=132#wechat_redirect