什么是复杂系统

我们经常提到复杂系统，那么到底什么是复杂系统。我们看下维基的定义：复杂系统（英语：complex system），又称复合系统，是指由许多可能相互作用的组成成分所组成的系统。强调了两点：

由点组成点之间有各种关联

两点的规模和复杂性直接决定了系统的复杂程度。比如就拿我们的电商系统举例，分成很多部分，商品、库存、采购、订单、物流、财务，这个只是大的分类，还有针对C端的营销、会员、购买、售后等体系，针对B端的商家入驻、管理等体系。

各个部分、体系之间有着千丝万缕的联系，可谓之复杂系统了。当然了，远远不止这些，随着业务复杂性的不断提升，整个系统的复杂性也会愈来愈复杂。

2. 什么是架构

生活中我们经常谈及“架构”，那么到底什么是“架构”，Robert C.Martin《架构整洁之道》中的定义：软件架构是指设计软件的人为软件赋予的形状，这个形状是指系统如何被划分为组件(Components)，各个组件如何排列（Arrangement），组件之间如何沟通（Communication，通讯），维基百科的定义：有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计,IEEE的定义：架构 = 组成单元的结构 + 组成单元的关系 + 原则和指南，总体来看会包括几个内容：

整体：强调部分的组成，强调合力规则：强调部分之间有关联关系，有规则，有约束通信：强调部分之间有往来，有交互

这样说来，我们人类社会本身就是一个社会架构，各种职责、分工、圈层，就我们的软件系统来说，DDD是架构，MVC也是架构，大数据设计也有大数据的架构。所以架构无处不在，好的架构能够对特定的问题，特定的领域起到规范和指导作用。

3. 架构的本质

我们知道，架构这个词是源于建筑行业的，英文原词是：Architecture，维基百科上的解释是规划、设计和建造建筑物的过程及产物。那我们就用建筑行业来理解一下。建房子对大家而言再熟悉不过了，那我们盖个小平层、盖个两层小高层、盖个5层小高层、搞个10层、盖个几百层的摩天大楼的过程、因素、风险是完全不同的。

盖摩天大楼需要付出的成本更高，过程中的不确定性更多，挑战和风险也更大，例如如何选地、选择什么样的结构，如何承重，采光如何控制，优化、如何取暖，如何上水、排水，如何通风，如何避震等等。这些东西我们考虑的越多，房子未来的质量，可控性也会越好。

所以架构本质上就是一种指导型的约束，以约定整体和部分、部分和部分之间的关系，以使整体更加稳定，更加可靠。

4. 架构分类

我们上面举的例子我们可以叫做建筑架构，实际上架构有很多种类型，比如业务架构，应用架构，技术架构，数据架构等。单个架构分类，站在不同的维度也会有不同的看法，复杂性也会有相当大的区别。

比如企业级架构能够凸显出公司的整体战略，业务涉及情况，分布情况，发力情况。而某一个单一的业务线也同样有自己的业务架构，凸显单独业务自己的业务目标、战略等。应用架构、技术架构也是同理，会有不同层面视野的架构。我们下面就以业务线内部视角对我们常见的架构分离进行下简单的说明。

4.1. 业务架构

说到业务架构，偏顶层设计了，业务的定义和划分甚至会影响到整个公司整体组织架构的设立和关系。业务架构偏向业务领域划分，模型设计，对整体业务进行语言转化，内化为领域通用语言。

4.2. 应用架构

4.3. 技术架构

5. 架构需要考虑哪些因素

5.1. 功能性需求

5.2. 非功能性需求

5.3. 可靠性

5.4. 可用性

5.5. 扩展性

5.6. 治理能力

5.7. 响应性能

6. 复杂系统如何分析

尤其是目前又被逐渐提及并广泛应用的DDD领域驱动设计方法，更加提倡领域专家的重要性。这样才能够识别现实问题的复杂性和根本痛点所在，进而能够客观合理的推导出可靠、合适的解决方案。很明显，复杂系统设计中非常重要的两个环节：需求分析、架构设计。需求分析过程中，我们需要确认需求到底要解决什么问题，面向的角色有哪些。

现在流行的分析方法要数DDD领域驱动的分析方法。使用DDD的模式分析业务需求大概会有几个步骤：

确认角色确认角色功能确认问题子域确认模型、事件、归属确认界限上下文7. 复杂系统的设计原则识别出核心问题：对于需求的承接，有些人会直接进行入开发设计阶段，尤其是对于出入职场的小伙伴。其实遇到需求我们更多的需要思考，为什么要做这个需求，这个想明白，非常有助于我们进行业务等相关的架构设计，进而掌舵整个需求。这样不会很容易的走入偏路。复杂的问题简单化，需要把复杂的问题拆解成各个小的模块，进行逐个攻破，各个模块职责会相对单一，未来的扩展性和可维护性也相对独立、简单确认使用通用的语言进行沟通，尤其是面向领域设计中，领域模型的认识大家一定要保持一致理清系统、模型的定位、关系、交互等具备未来的规划能力，包括系统、技术、方案、容量等等，以使系统能够长期更好、更稳定的提供价值服务遵循各种设计模式，最佳实践，避免从0开始，包括：SOLID设计原则，CAP理论，BASE理论

8. 复杂系统的架构特点

8.1. 重视功能拆解，模块化设计，原子化设计

8.2. 纵向 + 横向拓展能力至关重要

8.3. 架构先行

这些架构一定要清晰，明确，着眼于系统长期价值。

8.4. 分而治之

9. 典型的复杂问题解决架构

随着社会的不断进步，信息化组件发达，我们更需要信息化的方式去解决系统化的问题。早前我们更多的通过数据驱动的模式，也就是我们会先去思考会用到什么样的结构去存储相关的数据，模型之间都有什么样依赖关系，怎么样组织数据，怎么样把数据和外围交互，这些思想也是典型的MVC架构。

MVC架构迫使我们是面向视图来开发的，我们知道视图的变化最是不可控的，越是偏向于用户的东西，越是容易受到用户主观的影响。我们知道复杂系统必然存在的纷繁复杂的依赖，依赖不可能存在于视图部分，肯定会表现为接口的依赖。对于复杂系统，我们要强迫我们转换思维，强迫我们面向接口进行设计。结合着业务系统的复杂性，如果想要系统未来具有长期价值，不得不把大的系统进行拆分，用统一的业务语言进行描述，把不可识别的问题，拆分成可识别的问题域进行解决，这也就是现在又逐渐盛行起来的领域驱动设计的方法。

9.1. 领域驱动设计

领域驱动设计，强迫我们不再用数据进行驱动，而是使用领域进行驱动。遇到问题，我们先进性领域上的划分和拆解。这个问题到底属于哪个问题域，或者需要拆解到哪些问题域，然后再通过领域的组合、依赖完成最终问题的解决。

领域驱动，早在2004年Eric Evans在《Domain-Driven Design : Tackling Complexity in the Heart of Software》（领域驱动设计：软件核心复杂性应对之道）这本书中就战略和战术两个方面进行了详细的阐述。

目前来看，对于复杂系统的设计，领域驱动的模式利于系统的可持续发展。

9.2. 微服务架构

其实微服务架构就是早些时候的SOA（面向服务架构）的一种变体。其实这个词是从2014年Martin Fowler发表的一篇文章《Are Microservices the Future》开始被业界广传而火起来的。微服务架构强调去中心化管理，尽可能的保持服务的自治性和独立性。强调能力通过不同的小的服务进行整合获取。这样我们可以对服务进行有选择的纵向和横向扩展，同时也避免了单个系统的臃肿和功能的堆叠、耦合。

9.3. 云原生架构

说到原生，大家再熟悉不过了。比如我们说IOS，Android原生界面，意味着界面是他们本来就支持的。而谈到云原生，对于服务而言，我们更多强调服务先天具有云上部署、提供服务的能力。这种能力使得服务具有先天的去中心化的能力，先天的横向扩展的能力。这也是微服务重点强调的能力。

9.4. DevOps架构

DevOps之前，我们也一直在谈敏捷，业界也有战术上的落地方案。比如极限编程、Scrum等等。如果说敏捷更多是为了解决需求、产品、研发、测试之间的协同、高效，那么DevOps更多的是在解决研发、运维间的协同问题。

DevOps近年来发展的是如火如荼，这和领域驱动、微服务架构、云架构技术、虚拟化技术（尤其是Docker的发展）的发展息息相关。准确的说，是各种技术微妙组合的一种共力。DevOps的发展，是的运维不再关心应用的部署等问题，这些事情都可以交给研发来处理，运维更多的在给研发提供自动化的构建、集成、部署、监控等等相关的云基础能力。

9.5. 大数据架构

当今的是一个数字化的时代，各行各业都在忙于进行数字化的转型。对于复杂的业务系统，数据的价值尤显突出，那么自然对于海量数据的处理、价值的挖掘诉求是必然存在的。那么数据的海量存储、提取、传输、清洗、计算、挖掘等能力就需要通过大数据架构的模式进行设计。

10. 总结

现如今，系统设计的关键已经变成分布式、云化、微服务化、大数据化。架构的本质依然没有改变，只是由于社会的发展，我们的需求，需要处理的问题、依赖愈来愈复杂，我们需要用发展的眼光，时刻追随技术前沿，进而推进、优化、迭代系统的架构设计。

复杂系统的架构设计不是一蹴而就的，合适的才是正确的。希望本文能够对您在进行复杂系统设计时有一定的参考意义。

作者：张学军

来源：京东技术黑板报