关于架构:浅谈复杂业务系统的架构设计-京东云技术团队

作者：京东科技 皮亮

1. 什么是简单零碎

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

1. 由点组成
2. 点之间有各种关联

两点的规模和复杂性间接决定了零碎的复杂程度。比方就拿咱们的电商零碎举例，分成很多局部，商品、库存、洽购、订单、物流、财务，这个只是大的分类，还有针对 C 端的营销、会员、购买、售后等体系，针对 B 端的商家入驻、治理等体系。各个局部、体系之间有着千头万绪的分割，堪称之简单零碎了。当然了，远远不止这些，随着业务复杂性的一直晋升，整个零碎的复杂性也会愈来愈简单。

2. 什么是架构

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

1. 整体：强调局部的组成，强调合力
2. 规定：强调局部之间有关联关系，有规定，有束缚
3. 通信：强调局部之间有往来，有交互

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

3. 架构的实质

咱们晓得，架构这个词是源于建筑行业的，英文原词是：Architecture，维基百科上的解释是布局、设计和建造建筑物的过程及产物。那咱们就用建筑行业来了解一下。建房子对大家而言再相熟不过了，那咱们盖个小平层、盖个两层小高层、盖个 5 层小高层、搞个 10 层、盖个几百层的摩天大楼的过程、因素、危险是齐全不同的。盖摩天大楼须要付出的老本更高，过程中的不确定性更多，挑战和危险也更大，例如如何选地、抉择什么样的构造，如何承重，采光如何管制，优化、如何取暖，如何上水、排水，如何通风，如何避震等等。这些货色咱们思考的越多，房子将来的品质，可控性也会越好。

所以架构实质上就是一种领导型的束缚，以约定整体和局部、局部和局部之间的关系，以使整体更加稳固，更加牢靠。

4. 架构分类

咱们下面举的例子咱们能够叫做修建架构，实际上架构有很多种类型，比方业务架构，利用架构，技术架构，数据架构等。单个架构分类，站在不同的维度也会有不同的认识，复杂性也会有相当大的区别。比方企业级架构可能凸显出公司的整体策略，业务波及状况，散布状况，发力状况。而某一个繁多的业务线也同样有本人的业务架构，凸显独自业务本人的业务指标、策略等。利用架构、技术架构也是同理，会有不同层面视线的架构。咱们上面就以业务线外部视角对咱们常见的架构拆散进行下简略的阐明。

4.1. 业务架构

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

4.2. 利用架构

体现利用外部的构造关系。利用如何进行设计，包含模块如何划分，性能如何实现，技术如何撑持，数据如何展现，流程如何定义，逻辑如何实现，数据如何存储等等，都是利用架构的领域。咱们常常说到的 MVC、分层架构、CQRS、DDD 传统洋葱圈架构、DDD 六边形架构都能够归结为利用架构的领域。

4.3. 技术架构

技术架构不肯定局限于单个利用外部，尤其是以后微服务架构时代，服务之间如何交互，服务如何治理，数据如何存储，缓存如何构建等等，都是技术架构的领域。技术架构给利用和业务架构提供了一个技术根底，以使业务更好的倒退，更强壮的迭代，倒退。

5. 架构须要思考哪些因素

5.1. 功能性需要

无论是什么架构，咱们第一工夫思考的肯定是须要满足咱们理论的业务述求的。没有需要的架构就是相当于海市蜃楼，中看不中用，不切实际。这并不是真正的架构。一般来说，性能需要会间接决定业务架构，对利用和技术架构影响不大。咱们的架构必须可能正确、残缺地对功能性需要起到撑持作用。

5.2. 非功能性需要

架构满足功能性需要是第一要务，同时咱们须要思考可能稳固、牢靠的反对性能，也就是咱们同时须要满足一些非性能行需要，比方性能、可靠性、扩展性、兼容性等等。

5.3. 可靠性

为了更好的服务于性能，咱们须要确保架构可能稳固、高效的运行。不会时不时的呈现服务解体或者不可用的状况。

5.4. 可用性

同样的，服务对外要始终处于可用的状态，即便单个服务实例呈现问题，咱们仍然能够失常的对外提供服务。

5.5. 扩展性

功能性需要不是一层不变的，尤其在当今流行麻利的时代，需要不是一次性提出的。咱们须要对系统、服务的整体能力有全面的定位和把控。这就须要咱们的架构在新的需要呈现的时候，能够不便的进行扩大反对。

5.6. 治理能力

好的架构肯定是不便经营、治理和监控的。甚至宏观到工程治理，代码肯定是易于保护、扩大、协同的。

5.7. 响应性能

个别的，功能性需要都会对性能有肯定的预期。这个业务要咱们在架构上做很多工作，比方读写拆散、缓存、异步等等的染指，以满足整体架构的响应能力。

6. 简单零碎如何剖析

有的同学会有误区，一想到相似这样的零碎就感觉会有很大的复杂性，就会思考急流勇退。然而你所认为的难不肯定是难。咱们都晓得一句熟语：“难者不会，会者不难”，往往会因为大家教训的不同，看待同一问题的想法和思路就都会不一样。这也就是为什么咱们会在零碎设计的时候，强调专家的重要性。尤其是目前又被逐步提及并广泛应用的 DDD 畛域驱动设计办法，更加提倡领域专家的重要性。这样才可能辨认事实问题的复杂性和基本痛点所在，进而可能主观正当的推导出牢靠、适合的解决方案。很显著，简单零碎设计中十分重要的两个环节：需要剖析、架构设计。需要剖析过程中，咱们须要确认需要到底要解决什么问题，面向的角色有哪些。当初风行的分析方法要数 DDD 畛域驱动的分析方法。应用 DDD 的模式分析业务需要大略会有几个步骤：

1. 确认角色
2. 确认角色性能
3. 确认问题子域
4. 确认模型、事件、归属
5. 确认界线上下文

7. 简单零碎的设计准则

1. 辨认出外围问题：对于需要的承接，有些人会间接进行入开发设计阶段，尤其是对于出入职场的小伙伴。其实遇到需要咱们更多的须要思考，为什么要做这个需要，这个想明确，十分有助于咱们进行业务等相干的架构设计，进而掌舵整个需要。这样不会很容易的走入偏路。
2. 简单的问题简单化，须要把简单的问题拆解成各个小的模块，进行一一攻破，各个模块职责会绝对繁多，将来的扩展性和可维护性也绝对独立、简略
3. 确认应用通用的语言进行沟通，尤其是面向畛域设计中，畛域模型的意识大家肯定要保持一致
4. 理清零碎、模型的定位、关系、交互等
5. 具备将来的布局能力，包含零碎、技术、计划、容量等等，以使零碎可能长期更好、更稳固的提供价值服务
6. 遵循各种设计模式，最佳实际，防止从 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. 总结

现如今，零碎设计的要害曾经变成分布式、云化、微服务化、大数据化。架构的实质仍然没有扭转，只是因为社会的倒退，咱们的需要，须要解决的问题、依赖愈来愈简单，咱们须要用倒退的眼光，时刻追寻技术前沿，进而推动、优化、迭代零碎的架构设计。

简单零碎的架构设计不是欲速不达的，适合的才是正确的。心愿本文可能对您在进行简单零碎设计时有肯定的参考意义。