读《中台架构与实现：基于DDD和微服务》有感

hzbooks

于 2021-03-15 07:00:00 发布

阅读量1.5k

点赞数

文章标签：分布式人工智能大数据编程语言 consul

本文链接：https://blog.csdn.net/hzbooks/article/details/114828008

版权

导读：我是带着问题来看这本书的，在看的过程中不断有茅塞顿开、原来如此的感觉，原来这个问题人家是这么解决的！原来这些问题大家都遇到过！

个人在IT这个行业工作有很多年了，所服务的企业都是书中所谓的传统企业，在互联网化业务转型、数字化转型呼声越来越高的当下，个人对传统企业应该如何实现技术转型一直以来都是非常感兴趣的。

个人近些年也参与过一些分布式的项目开发，对分布式也有一些了解，但感觉不管是集中式、还是分布式，其效果总是有些差强人意，哪怕上线时的代码质量再高，但伴随着维护，腐烂的气息总是会散发出来。在后期维护的时候，总是小心翼翼的，就怕牵一发而动全身；数据库的分库分表不可避免地会侵入代码逻辑，让你在开发代码的时候，总是要考虑各种约束。这跟传统的单体结构有什么区别？甚至还不如之前的单体结构呢！

我是带着问题来看这本书的，在看的过程中不断有茅塞顿开、原来如此的感觉，原来这个问题人家是这么解决的！原来这些问题大家都遇到过！

我从这本书里了解到：DDD是架构设计方法论，DDD试图分离技术、围绕业务构建领域模型（战略设计阶段），然后在领域模型中建立与技术的通用语言，实现从业务逻辑到技术逻辑/代码逻辑的映射（战术设计阶段）。个人认为DDD最关键的是：建立业务和技术的通用语言。操持着通用语言的人们就好比是建造通天塔的人类一样，如果人类操持着相同的语言，那么连上帝都会为之害怕。

微服务是一种架构体系，其精髓很简单，就是“高内聚、低耦合”。通过将应用功能构造为一组松散耦合的服务，通过REST API、事件、消息等的组合在服务之间相互通信，做到彼此独立又彼此联系。

但微服务实际上又没有那么简单。按照DDD领域驱动设计方法，在设计微服务时，需要从业务领域开始逐级细分，划分为子域、子子域、限界上下文、聚合、聚合根、实体、值对象等，这种逐级划分体现的是严格约束、分层分治的“分”能力。

聚合是微服务中的最小业务单元。围绕聚合，逐级向上，有领域服务、应用服务、facade接口服务；聚合与聚合、服务与服务之间，可以通过事件/消息来相互通信，这些服务、以及服务之间的事件/消息等体现的是聚则成形的、灵活的“合”能力。

上述的“分”与“合”，就好像“散是满天星、聚是一团火”那样。

本书还介绍了单体架构向微服务架构演进的三种策略：

1. 修缮者策略：维持原有系统整体能力不变，通过优化局部以提升系统整体能力的策略；

2. 绞杀者策略：逐步剥离业务能力，用微服务逐步代替，最终用微服务完全替代原有单体应用；

3. 另起炉灶：将原有的系统推倒重做。

个人认为这三种策略实际上是在“渐进”和“激进”之间摇摆，修缮者策略最稳妥，另起炉灶模式最激进，绞杀者策略则是“渐进”和“激进”的折中。

个人认同书中的观点，最激进的往往最不稳定，这样会导致大量未知的潜在技术风险、以及新开发模式下项目团队磨合等问题。这些不确定性因素的增多，会导致项目实施难度大大增加。但个人又想到：每个企业都有每个企业自己的特点，如果有企业愿意按照“矫枉必须过正”的说法、充分评估最激进的后果、采取最激进的做法、在振荡之后取得稳定、这应该也是可以的吧。比如说，“海尔模式”就曾历经多次振荡。

由于工作的原因，个人对书中提到的微前端、业务单元，能力聚合层、BFF（Backend For Frontends）这些都特别感兴趣。这些都是如何组织和编排离散化的服务，使之聚合成形，充分且灵活发挥业务能力的一些好做法。

个人一直在做银行IT服务，之前也参与过保险行业的互联网化业务转型规划，因此对银行/保险在数字化转型中的困境都有一些切身的体会，面对银行应用系统中的类似问题（如何组织和编排服务、使之发挥业务合力），也曾提出过自己的一些意见和建议，比如说“中台的中台”。这个“中台的中台”也可以叫“调度中心”，这个调度中心跟书中的能力聚合层、BFF这些都比较贴近，而且是一种渐进的做法。以当前的银行系统为例（这些银行实际上已经不是竖井式建设了，而是初步建立起了SOA化的平台体系结构）：将每个独立系统都做为共享中心中的一个（如：ECIF系统做为ECIF共享中心、核心系统做为核心账户共享中心，实际上这些共享中心就对应阿里中台内的各个共享中心了），然后在这些共享中心之上再加一层，起服务编排、流程调度、全局事务控制等作用，渠道/外围可以先到这个调度中心，然后这个调度中心再根据业务逻辑、业务流程，去串接不同系统（不同共享中心）内的服务，这些不同的系统只要按要求对调度中心提供服务、并保证系统内事务的一致及可回退就好了。

银行在具体建设的过程中：可以先把这个调度中心建起来；然后新增业务就走调度中心，调度中心确定各系统分别应该提供什么样的服务（对应书中的修缮者策略）；然后分业务、分模块地逐步将现有不经过调度中心的业务移入调度中心（对应书中的绞杀者策略）。银行当然也可以只采取修缮者策略，维持现有系统整体能力不变。

个人认为对于银行（特别是中小银行）来说，更换系统、更换厂商、另起炉灶等等，都不是什么好办法，这样一方面动荡磨合期太长，另一方面也会造成数据资产的遗失（在数据迁移的过程中很多有用的数据实际上就被丢弃了），如果按照上述渐进、包容的策略，在各个系统上面再包一个调度层，在这一层建立业务和技术的通用语言，由这一层的实现人员对各个系统提要求，银行完全可以渐进地、自主可控地实现能力复用、实现系统之间的数据贯通。日后这个调度中心也可以升级为撮合中心、能力中台等。

当然，银行（特别是中小银行）现在面临的困境很多，一方面是时不我待、只能借助外部厂商，另一方面对于那些无法支持高并发量数据访问的传统单体系统来说，也只能采用换系统、换厂商的做法了，这些都是不得已但又不得不为的事情。

但个人认为，不管银行如何决策，DDD和微服务的这些思想、这些方法，对于增进业务和科技的共识、对于培养业务和技术复合型人才、对于增强行内科技实力、对于提升自主可控能力等等都是有帮助的。

我个人是做银行IT服务的，我们是银行的乙方，但个人认为银行自主可控能力的提升对乙方也是好事，这会促进乙方服务转型升级，最终促进甲乙双方的共生共赢、长久合作。

DDD和微服务是思想、是方法，这些思想、这些方法同样可以应用到集中式单体应用中，实现微服务不一定非得是开放系统、非得要用JAVA，传统的主机、传统的COBOL、传统的RPG等仍然可以实现微服务，这样也可以在调度中心这个包容层的包容下，用最小的代价、最小的成本来逐步解决IT能力重复建设、系统内耦合度高等问题，并为将来的主机下移、培养DDD业务和技术复合人才、增强银行自主可控/整体统筹能力等打下基础。

如前所述，个人认为DDD最重要的是建立通用语言。我们也可以把项目类比为架构、把通用语言类比为项目这个架构中的通用语言层，用通用语言这个包容层来规范沟通术语、消除沟通障碍，用通用语言层来指导并规范项目建设、来降低项目总体难度和成本。

感谢这本书的作者给自己带来的启发和感受！再次感谢！

有关作者

丁琳，某IT服务公司架构师，拥有20多年的IT从业经验。热衷于传统行业的中台架构设计和互联网化业务转型改造。