复杂系统架构设计应对之道

Posted 2021-08-06 同程艺龙技术中心

熵增定律，也叫“热力学第二定律”，揭示了事物总是向无序、混乱的方向发展。在没有干预的情况下，事物的熵（混乱、无序的状态）会不断增加，达到临界，走向消亡。而在这个过程中，混乱程度越高，熵增的进程越快。对软件系统而言，大部分系统都在经历开始、迭代、重构的过程。而架构是通过优秀的设计让有序和规则贯穿始终，从而延缓或降低熵增的进程，架构设计越合理，结构化因子越多，系统越有序，推导重来的风险越低。

复杂系统架构设计的手术刀

-抽象思维-

我们说，通过架构设计，让系统始终更有序的拓展新功能，可以有效延缓熵增的进程，那具体怎么去应对复杂的系统设计呢？

架构设计有几个比较好的系统思维方式，抽象、分层、分治，其中最重要的思维方式便是抽象思维。

《道德经》第四十二章讲：道生一，一生二，二生三，三生万物，万物归一。万物看似在变，实则不变，变得只是表象，万千变化都可以用“道”去抽象。对软件系统而言，架构设计是对现实世界的还原，如何正确的把表象抽象成模型、领域，进而优雅的拆分，进而更好的聚合和组合，勾勒出有序的世界。这是一种从具象到抽象的架构思维，把关注点从设计和实现分离。

本质上来讲，哲学和科学是对经验的抽象，架构师应该把具象思维和抽象思维进行有效的连接。首先，分析具体问题（DDD，找出问题域）；其次，将具体的问题进行提炼，抽象，形成一套架构设计和解决方案，可以适用于所有类似的具体问题（DDD，解决方案域，找出问题域的业务边界，识别限界上下文，抽象领域模型）；再次，将抽象出的架构用于解决具体的问题，根据效果来不断演进，优化原有的设计（对领域进一步抽象，流程归一，系统复用，数据共享）。

微服务与中台的碰撞

-从运行时解耦到企业级复用-

首先需要说明一下，微服务和中台，完全是两回事。

01

微服务是什么？

微服务架构将单体应用，按照业务领域拆分为多个高内聚，低耦合的小型服务，每个小服务以独立进程的方式运行，服务间采用轻量级通信机制相互访问，每个微服务可以采用不同的语言开发实现。

微服务体现去中心化、天然分布式，是中台战略有效落地的技术架构之一，用来解决企业业务快速发展与创新时面临的系统弹性可扩展、敏捷迭代、技术驱动业务创新等难题。

02

微服务解决什么问题？

传统的单体应用有很大的局限性，应用程序随着业务需求的迭代、功能的追加扩展，最终成为一个大泥球。单体应用的局限性大体包括以下几方面：

复杂性高：业务规模和团队规模发展的一定阶段，模块耦合严重，代码难以理解，质量变差，牵一发而动全身，迭代风险大。

交付效率低：构建和部署耗时长，难以定位问题，开发效率低，全量部署耗时长、影响范围广、风险大，发布频次低，回归测试工作量大。

伸缩性差：单体只能按整体横向扩展，无法分模块垂直扩展。

可靠性差：一个bug有可能引起整个应用的崩溃。

阻碍技术创新：受技术栈限制，团队成员使用同一框架和语言。

03

微服务技术架构的特点？

易于开发与维护：微服务相对小，易于理解；

独立部署：一个微服务的修改不需要协调其它服务；

伸缩性强：每个服务都可按硬件资源的需求进行独立扩容；

康威定律的实践：微服务架构可以更好将架构和组织相匹配，每个团队独立负责某些服务，获得更高的生产力；

技术异构性：使用最适合该服务的技术，降低尝试新技术的成本；

企业环境下的特殊要求：去中心化和集中管控/治理的平衡，分布式数据库和企业闭环数据模型的平衡。

 

然而，SOA之后，需要进一步解决几个问题，把单体应用进行碎片化，碎片的边界怎么划分？多个碎片如何治理？底层基础服务如何对碎片化的上层应用保持透明？

a.SpringCloud/docker/k8s的出现，加速了云原生的进度，微服务被推向了风口浪尖，哪个公司不用微服务进行项目开发，甚至会被贴上low的标签。使用SpringCloud等脚手架对应用进行日志、注册与发现、消息、统一配置、熔断降级等基础服务进行集成，屏蔽掉基础服务的实现，成功实现了对碎片化微服务的有效治理，让业务开发聚焦于业务本身，不在需要关注组件和中间件的封装和集成，通过容器化实现了运行时隔离。

b.领域驱动设计（DDD）加速微服务的落地，BC（Bounded Context）和CM（Context Mapping）支撑微服务战略设计，有效指导微服务边界的划分。

c.微服务的本质是领域化、模块化，目标是实现各领域高内聚、低耦合、服务自、运行时解耦。根据业务需求，每个微服务独立迭代，范围内通过架构设计，分而治之，让系统具有更好的延展性和拓展型，过程有序延缓熵增的进程。

1.DDD能够让我们知道如何抽象出界限上下文以及如何去分而治之，把复杂领域拆分为简单的子域。使用抽象精简问题空间，而且问题越小越容易理解。

2.DDD的界限上下文可以完美匹配微服务边界的要求，让系统设计的更加合理，最终满足高内聚低耦合的本质。

04

中台是什么？

中台是一个整体维度，他不管技术，业务，网络等的划分。它追求的是流程标准化，归一化，以平台方式实现复用，通过复用让整体的系统效能结果最大化，业务扩展灵活度最大化，实现效率最大化。中台的核心是能力复用。

05

中台和微服务有什么关系？

微服务和中台互为灵魂伴侣

    

中台架构，简单地说，就是企业级能力的复用，一个种方法论，企业治理思想。

微服务，是可独立开发、维护、部署的小型业务单元，是一种技术架构方式。

中台化的落地，需要使用微服务架构，通过微服务架构搭建中台架构所需要的领域服务。

中台强调可复用核心基础能力的建设，基础能力以原子服务的形式存在，并通过将原子服务产品化，在各业务条线进行复用和赋能，以支撑业务端各种场景的快速迭代和创新；原子服务和微服务所倡导的服务自治思想不谋而合，使得微服务成为实现原子服务的合适架构。

支撑业务场景的应用也是通过服务来实现，其生命周期随业务变化需要非常灵活的调整，这也和微服务强调的快速迭代高度一致，所以业务应用服务也适合通过微服务来实现。

中台化系统建设不是一蹴而就的，更不是设计出来的，它需要业务长期积累，技术演进，配合以微服务及领域驱动设计（DDD）在云原生架构及设计思想的推动，技术体系日渐成熟，在公司实施、落地的土壤已经具备，火车票中台建设已经出具锋芒，基于中台的创新小前台将会迎来利好。

分布式系统的架构设计原则

原则1-保守分布

分布要保守，拆分须谨慎。这项原则基于一个事实：调用不同进程上对象的方法要比调用进程内对象的方法慢数百倍；将对象移动到网络中的另一台计算机上，这种方法调用又会慢数十倍。所以，本身调用频繁或业务无法分割的场景，能不拆，就不要拆。

原则2-本地化相关内容

如果决定或被迫分布全部或部分业务逻辑层，那么应当保证经常交互的组件和功能被放置在一起。

原则3-使用Chunky接口，而不是chatty接口

Chunky是粗粒度，chatty是细粒度。粗粒度指方法中传的值用属性表示，细粒度指传的值用对象表示。

原则4-优先选用无状态对象，而不是有状态对象

无状态对象是能够在方法调用之间被安全创建和销毁的对象.如果应用程序选择销毁它,这个动作也不会影响到其他用户.这个特性不是轻易就能实现的,您必须对类进行特殊实现,这样类才不会依赖于公共方法调用之后实例字段是否继续存在.因为对实例字段没有依赖关系,所以无状态对象倾向于使用chunky接口。

通过使用智能缓存、会话管理和负载均衡的方法，可以避免或者最小化使用有状态对象所带来的问题。这就是使用无状态对象的原因，但不是必须使用。这里需要再次说明，这个原则只能应用于为在其他机器中执行的代码所提供的对象。

原则5-接口编程，而不是具体实现的编程

减少频繁的且时常出问题的部署。

小结

架构设计的本质是通过抽象、分层、分治等思维方式，让系统具有更好的拓展性和维护性，尽可能延缓熵增的进程。微观上来看，架构设计要求我们正确的把具象抽象成模型、领域，便于分层和分治。而宏观上，从单体到集群，再到分布式，再到现在的中台，驱动架构演进的正是业务本身，不同的架构是适配业务发展阶段的产物，并没有优劣之分，中台也不会是终点。而我正在探索SaaS小前台+中台在创新业务的新机会。