复杂系统分析与设计思路

概述

 

首先，系统是什么？根据《系统架构》一书的定义，系统是由一组实体和这些实体之间的关系所构成的集合，其功能要大于这些实体各自的功能之和。对于咱们的场景，系统多是 App、Web 应用、服务、批处理程序等，也多是包括全部这些的一个大系统。

 

随着互联网和传统企业的结合愈来愈深刻，业务会愈来愈复杂。咱们该如何设计咱们的系统呢？

 

从产品到研发

 

从产品做出原型，到研发编程实现，中间有巨大的鸿沟。越复杂的业务需求，这条鸿沟就越大。通常而言，咱们至少还要有两个步骤：业务分析与架构设计。

业务分析，主要处理的是业务领域的建模。解决的问题是业务上如何实现。而后是技术与架构方面的设计，主要针对的是技术实现，解决的问题是技术上如何实现。这两个方面是会互相影响的，设计的时候每每须要来来回回的考虑这两个方面。甚至系统开发时也时常会须要调整模型或者架构，固然相应的也须要更新文档。

基本原则

 

设计与分析的过程就是不停的进行抽象和封装，而且肯定各个系统实体的细节。抽象是指将业务抽象为软件领域的元素（系统、模块或类）；封装则是指定义元素的边界，隐藏实现，开放接口。

 

相应的，分析与设计时，最基本的原则就是抽象性和封装性。固然，咱们有 SOLID、DRY、高内聚低耦合、设计模式等各类原则和方法，具体方式本文不详述了，但最终它们均可以归类到以上两点。

 

业务分析

 

分析方法

 

业务分析是针对业务领域的建模，产出就是分析模型。分析模型描述系统的逻辑设计与结构，通常会包括需求用例、实体模型以及业务场景的交互流程、状态转换等。分析模型让非技术人员可以理解系统是如何构造的，让技术人员可以以此为基础搭建系统。

 

分析的过程是不断迭代的。特别对于复杂的、涉及多个业务领域的需求，第一步每每须要在总体系统的层级进行分析，而后将模型划分到多个子系统，而后再在子系统的层级进行更细节的分析与建模。

 

另外一方面，分析过程当中须要不断的优化和调整。例如在肯定实体的行为细节时，发现两个实体的耦合很高，那么可能须要从新进行抽象，调整实体的功能范围。

 

理清业务需求

 

理清业务需求是全部分析与设计的前提：

 

• 肯定系统的利益相关者（Stakeholder）及他们的关注点。

• 肯定系统的业务需求，即「谁」使用该系统「作什么」。

• 肯定系统的功能范围，即该系统「包含什么」，不包含「什么」。

 

系统须要知足利益相关者的关注点，因此要确保全部这些关注点都有涉及到。最重要的利益相关者固然就是用户（有时还会细分为不一样类型的用户），此外还应该包括供应商、合做方、运营、销售、老板甚至政府等等，也一样包括研发测试和运维。

 

具体到系统的用户，还须要细分到角色，即便有些角色实际多是同一我的。好比对于门诊，可能有护士、顾问或系统管理员等等，能够进行不一样的操做。需求范围简单话用一个列表便可，复杂的系统能够考虑使用用例图。

 

例如，门诊预定系统的用例图能够这样画：

 

• 角色有医生、患者和门诊员工。

• 用例有设置排班、管理预定以及预定/取消医生。

创建实体模型

 

实体模型是肯定系统包含的实体以及它们之间的关联的过程：

 

• 理清业务概念，统一业务词汇。

• 抽象业务实体，包括事件、人/角色、地点和事物等。

• 识别实体关系：继承、聚合、关联等。

 

实体模型也叫 ER（Entity-Relation）模型。能够考虑使用四色法建模，通常可使用类图或组件图表示。须要注意的是必定要理清业务的概念，统一命名和定义业务相关词汇，这是进一步沟通的基础。

 

例如，预定系统的实体关系图能够这样画：

分析业务场景

 

场景分析用于肯定具体业务场景中，各个参与者的交互过程，从而进一步完善分析模型：

 

• 分析具体业务场景，肯定业务规则，梳理业务流程。

• 若是涉及复杂的状态转换，须要肯定状态转换逻辑。

• 补充和完善实体模型的内容描述。

 

对于一个业务场景，参与者可能包括人、内部模块、外部服务等，这一步须要理清楚整个业务过程和规则。须要注意的是，对于一些次要路径或者异常路径，也必定要考虑到。对于业务过程和规则，可使用普通的流程图、泳道图，也能够考虑UML的活动图，状态转换过程则能够经过UML的状态图展现。

 

对于场景分析中不太肯定的需求，或者可能会有技术难点地方，能够记录下来，后面确认和验证。

 

例如，下面是预定系统的预定状态图。

例如，下面是咱们和一家药品供应商对接的流程图。

 

架构与技术设计

 

架构方法

 

架构设计不必定要深刻到具体的实现细节，可是应该尽可能全面的考虑系统的各个方面。关键是要对项目风险有比较大的把握，这样才能避免开发过程出现不可控的问题。具体设计须要多详细，是须要设计者本身去把握度的。

 

对于暂时没法肯定的内容，应该在文档中注明，在开发过程早期进行试验和验证。若是对项目比较关键，能够考虑先行开发原型来进行验证。

 

架构设计常见的是4+1视图，即逻辑视图、开发视图、过程视图、物理视图，再加上场景。另一种我更喜欢的是视点和视角的方法，若是再加上场景的话，可能会更全面。

肯定总体架构

 

首先须要在总体上考虑系统的位置和职责：

 

• 肯定系统在整个上下文中的位置，与其余系统的关联。

• 肯定系统自身以及各个外部系统的职责。

 

总体架构对应的就是情景视图。这一步将系统看做一个黑盒，确认系统本身的范围和职责，相关的外部系统的职责，以及他们之间的关联。

 

例如，交易系统的总体架构大概是这样的：

 

设计功能模块

 

其次须要肯定系统内部的功能模块及其职责：

 

• 肯定系统的模块划分。

• 肯定每一个模块的职责以及模块间的关联。

 

功能模块对应的就是功能视图。这一步须要明确系统的内部结构。内部模块划分主要有基于业务功能的划分，以及基于实现层次的划分，稍复杂的系统可能会二者都有。也有一些系统会采用CQRS等架构，那么模块划分可能会不同。功能模块可使用UML的组件图表示。

 

明确架构关注点

 

而后须要肯定系统架构的理念：

 

• 理清架构设计须要考虑的关注点。

• 肯定系统的架构设计上的取舍。

 

这一步须要考虑各类架构视角，主要有(但不限于)如下关注点：

 

• 安全性：身份验证、权限控制和受权、操做日志、安全审计、数据一致性等。

• 性能：响应时间、吞吐量等。

• 稳定性：停机时间、故障恢复、数据一致性、数据备份等。

• 扩展性：将来可能的变动，以及如何应对变动。

• 其余：国际化、易用性、合规性等。

 

以上全部的关注点，和开发资源、时间、范围各个方面，每每很难同时知足，因此必需要明确哪些是关注的重点，哪些则能够有所妥协。例如，为了知足性能要求，可能须要下降数据的一致性；为了合规性，可能不得不花更多开发时间。

 

对于将来可能的变动，也必定要考虑到。一般状况下，咱们至少要考虑将来半年的架构，但可能只实现当前须要的版本，可是确保将来能够很容易的扩展。

 

一旦肯定了关注的重点，在设计和开发的每一个过程当中，咱们都要把这个重点放在心上。

 

例如，对于订单系统，由于涉及到钱和交易，数据的一致性和可追溯性极其重要。下单和支付的API都必须是幂等的，每一笔收入变更都必须记录日志，必须有严格的核对和对帐。为了安全，每一次API调用都必须进行权限验证。

 

例如，亚马逊有个知名的原则，全部的系统间调用都必须经过定义清楚的 API，不容许共享数据库。这也是一个架构原则。

 

设计数据库模型

 

若是分析时有了完善了实体模型，设计数据库模型就不是什么难事了。开发完成后，数据库模型应该以数据库为准，架构文档就不须要保留这一部分了。

 

须要注意的是，数据库模型是实体模型在关系数据库的实现，但不必定是严格的映射。数据库可能会有范式、冗余、一致性、同步、分表分库方面的考虑，必要时可能会使用非关系型数据库如ElasticSearch、Cassandra等。

 

有时候还会涉及到数据处理的流程。例如，一张图片提交后可能须要进行预处理，而后有运营人员进行审核和标记，最后进行发布。过程当中数据的保存形式或者状态标记多是不同的。

 

数据库设计的更多规范能够参考数据库规范。

 

设计接口

 

而后就须要肯定 API 细节了。通常咱们的服务的 API 是 JSON 格式 HTTP 形式的请求和回调。API 多是接口定义，也可能会有其余接口形式，例如消息队列等。设计阶段，API 文档能够经过 Markdown 文档、RAP 等记录，开发完成后能够独立维护，或者使用 Swagger 和代码一块儿维护。

 

接口设计须要注意几点：

 

• 接口的设计应该以系统提供的领域资源或服务为基础，同时考虑调用方的需求。

• 接口的粒度很重要，太细则调用方很不方便须要屡次调用，太粗则没法灵活的知足各类需求，须要仔细权衡。

• 接口的设计也须要从调用方的角度考虑如何进行调用。必要的话能够画流程图、时序图、状态图详细说明调用顺序即状态转换等。

• 接口的文档必定要清楚的说明调用接口的方法、前置条件，参数做用、不一样条件的处理、返回接口等。

 

场景实现

 

通常状况下，有了业务场景分析，有了数据库模型和 API，系统的实现通常是比较简单了。但可能还会有一些细节须要进一步考虑实现细节，以免风险。能够考虑更细节的活动图、时序图甚至伪代码。例如：

 

• 复杂业务场景的详细设计，或者复杂算法的实现描述。

• 离线任务的执行方式、时间和步骤。

• 非业务的一些场景，例如网络断开、缓存失效、第三方系统宕机等。

 

例如，对于支付系统的微信 Web 支付过程，涉及系统较多，交互比较复杂，能够经过时序图来定义清楚：

其余考虑

 

对于咱们的后台系统来讲，基本的技术框架都已肯定，能够解决不少基础的非业务需求。不过设计系统时，也仍是须要考虑如下等方面：

 

• 通用处理的方式，例如日志、错误处理、代码规范、单元测试等。

• 数据迁移、同步和回滚方案：对于老系统的重构，须要仔细考虑而且提早演练。

• 系统部署和发布：若是系统涉及多个子系统，须要考虑系统的部署架构。特别是同时涉及到数据迁移的，必定要仔细考虑发布的过程。

• 系统监控和告警：除了常规的监控和告警，是否有特殊的指标须要监控？

• 并发和数据量：若是系统可能面临对高并发和大数据量的问题， 须要设计对应的方案，以及相关的性能测试和压力测试。

• 缓存设计：若是须要使用缓存，除了要考虑缓存的选型、方案，并且要把缓存放到整个系统中去进行设计。

• 技术选型：涉及到新技术的引入时，则须要仔细分析备用技术的优缺点，选择最合适的方案。

 

设计方法和工具

 

• UML

• 面向对象设计（OOAP）

• 领域驱动设计（DDD）

• CQRS & Event Sourcing

 

参考

 

书

 

• 分析模式：可复用的对象模型(https://book.douban.com/subject/4832380/)

• 软件系统架构：使用视点和视角与利益相关者合做(https://book.douban.com/subject/24530471/)

• UML和模式应用(https://book.douban.com/subject/1792387/)

• 架构即将来：现代企业可扩展的Web架构、流程和组织(https://book.douban.com/subject/26765979/)

 

文章

 

• 从用例分析到方案评审，咱们是如何进行业务系统设计的(http://mp.weixin.qq.com/s/qH3vpf5CRGJ4dVaKPOFFUg)

• 互联网公司研发RD如何撰写整体设计与详细设计文档(http://www.10tiao.com/html/249/201412/201657741/1.html)

• 用UML作好系统分析(http://www.infoq.com/cn/articles/use-uml-to-do-system-analysis)

• 运用四色建模法进行领域分析(http://www.infoq.com/cn/articles/xh-four-color-modeling)

• 从“四色建模法”到“限界纸笔建模法”(http://insights.thoughtworkers.org/paper-pen-modeling/)

• 浅谈我对DDD领域驱动设计的理解(http://www.cnblogs.com/netfocus/p/5548025.html)

• 领域驱动设计参考架构详解(http://blog.csdn.net/bluishglc/article/details/6681253)

• 领域驱动设计和实践(http://www.infoq.com/cn/articles/cjq-ddd)

• 我对CQRS/EventSourcing架构的思考(http://mp.weixin.qq.com/s?__biz=MzA5Nzc4OTA1Mw==&mid=2659598125&idx=1&sn=ca39d804aede5ee46988b6d635217027)

• 架构设计基础知识整理(https://blog.dreamtobe.cn/2016/03/09/oo_architecture/)