系分文档的撰写可以从WHY、WHAT、HOW三个角度来提问，并且给出解决方案。相比单调的流水账，这样写出来的系分内容更加详实。

正文

学习是需要循序渐进的，这里会提供一个系分的模板，这个模板是架构师模板的子集，可以方便的进行套用。这就好像学开车一样，一开始教练会把开车的步骤一步步交给你，等你熟练之后开车就是下意识的动作了，原来的步骤早就忘光了。系分模板就是系分的步骤，初学者一开始可以一步步来照着做，等掌握了之后就可以自由发挥了。

模板主要包含四个部分：

• 需求分析
• 需求建模
• 系统设计
• 风险防控

需求分析

刚开始最容易犯的错误就是系分的时候一下子就扎到第三步系分设计里面，直接跳过了前面两步。需求分析的目的在于理解需求的本质，搞清楚为什么要做这个需求。

需求分析主要是回答下面几个问题：

• 用户是谁？软件是工具，既然是工具就一定有使用者，了解用户是谁是理解需求的前提。
• 需求是为了解决用户的什么问题？只有把需求问题定义清楚了，才能保证最后实现的功能能够真的解决用户的问题。
• 如何才能满足用户需求？了解了用户需求之后，就要开始思考用什么方式来满足需求，具体来说就是要实现一个什么样的功能。这里可以用时序图画一个完整的业务流程，方便大家理解要做什么。
• 要实现什么样的目标？业务上有商业目标，例如支付宝的每日活跃用户数。技术上有系统目标，例如性能优化的需求要减少20%机器。
• 潜在的需求有哪些？很多时候产品提过来的是一句话需求，我们需要仔细的推敲出一句话需求背后隐含的信息。例如我们前面的“把大象放进冰箱”就是典型的一句话需求，这个时候你就要思考这个需求背后的隐含的要求：放的过程大象不能受伤、放进去之后大象不能冻死等等。如果你没有提前思考到这些潜在的需求，那么你的系分一定是不合格的。
• 要实现需求会面临哪些挑战？要考虑到功能的实现需要解决的问题。例如说产品突然给你提了一个秒杀的需求，那么你就要考虑到秒杀这个功能对系统可能带来的挑战：一致性问题、性能问题等等。

这个过程的产出物就是对上述问题的回答。

业务建模

在完成了需求分析之后，我们就可以开始进行业务建模了。业务建模就是把要实现的业务功能抽象成为模型。

什么是模型？模型是现实事物的抽象。例如地球仪是对地球的抽象，汽车模型是汽车的抽象。具体到软件开发中，我们常用的是概念模型，即把现实事物用一个概念来表示。例如我们可以把汽车抽象为下面的领域模型：

为什么要建模？抽象建模的过程中我们把事物的某些部分简化了，只专注于重要的部分，这样有利于我们抓大放小。可以说没有建模的过程，就无法进行软件开发。软件就是基于各种抽象的模型构建出来。例如你在GTA游戏里面从高到低扔一个球，会发现球在自由落体，我们知道游戏里面是没有万有引力的，那么球为什么发生自由落体？实际上，球下降的场景是软件通过力学模型来模拟实现自由落体的。

建立模型有很多种方法，常用的建模方法有ER建模、用例建模、SOA、DDD。ER建模和用例建模适用于业务复杂度较低的需求，SOA和DDD适用于业务复杂度较高的需求。我建议一开始用用例建模就可以了，因为刚开始一般也不会上手很复杂的项目。

这个过程的产出物就是领域模型，例如前面的汽车领域模型。

系统设计

前面两步还是属于业务域的分析设计，到这一步才是真正的开始了技术相关的设计。系统设计架起了业务与技术之间的桥梁，主要就是将业务建模建立的领域模型转换为开发视角的对象（类）。除了对象设计，系分设计还包含了系统模块、对象设计、系统交互、数据库表设计等等一系列跟研发密切相关的工作。

• 系统模块

一般来说刚开始做的功能只是一个小模块，整体的模块图已经有架构师设计好了，这个时候你只需要指出你新增的功能或者改动点涉及哪几个模块就行。例如下面的架构图，如果你改动的点涉及图像识别模块和数据存储模块，你就标识出来，这样评审的时候大家就知道你改动点的影响范围。

刚开始常有的疑问就是我只是接口上面新增一个字段，需要画这么大一个图吗？是不是有点小题大做了。我的观点是你可以不画，但是你就失去了一个了解全局的机会。再小的功能也是整体系统的一部分，只有了解了全局你才能具备更高的视角，慢慢成长为架构师。如果你永远只看到自己的一亩三分地，那么永远都是井底之蛙。当然一开始你肯定是画不出这么大的图的，所以你可以先找一下师兄要一下他画的架构图，然后找到自己模块所处的位置，然后照着画一个简单版本的。随着你做的需求越来越多，你就会慢慢把整个架构图吃透。

• 对象设计

将领域模型翻译成为类图。例如下面的Java列表类图。

• 系统交互

一般用时序图来表示不同组件之间的行为流程。示例如下

• 数据库表设计

这里除了考虑数据库的范式设计，还要考虑索引的设计。示例如下：

风险防控

风险防控是开发工作的底线和基本要求，即使你的技术方案做到了100分，如果风险防控没做好出了故障，那么最终分数也是0分。在蚂蚁我们主要用三板斧的方法论来解决这个问题。三板斧是蚂蚁的风险防控原则，包括可灰度、可监控、可应急。三者是分别从事前、事中、事后防范和应对风险的手段。

• 可灰度

可灰度指的是新功能上线前要保证代码要经过从小流量到大流量的验证过程，不能发布完成之后就全量生效。具体的实现方式有发布过程灰度和业务开关灰度。

发布过程灰度对于标准应用是标配，可选择发布设置为分组的，有些问题可以在发布过程中就发现。

业务开关灰度是在开发的过程中用DRM或者达尔文作为切流的开关来实现业务白名单或者按比例切流的功能。

• 可监控

可监控指的是新功能上线要保证打印了监控日志并且配置了相应的报警规则，从而保证如果出了线上问题能够及时发现。没有监控就如同在森林里面裸奔，是非常危险的事情。

• 可应急

可应急指的是在出了线上问题之后有应急手段能够短时间内就解决问题。一般线上问题分为两种：

1、业务问题：例如业务逻辑有bug，系分的时候就要考虑到出现这种问题如何应急。一般做法就是回滚代码，如果你设计的方法是不支持回滚的，那么你就违反了可应急这个原则。

2、技术问题：比如流量过大导致机器扛不住或者下游挂了，这种问题就要预先准备限流或者降级开关。

总之，系分的时候要充分考虑到新功能上线之后会出现哪些可能风险，然后做好预防、监控和应急措施。

总结

系分是一个程序员综合能力的体现，一篇文章是不可能面面俱到的。这里提供的模板只是一副地图，条条大路通罗马，还有很多其他的路线可以入门系分。