第十周微服务总结



业务中台必须以微服方式落地，但是微服务的粒度应该多大呀？微服务到底应该如何拆分和设计呢？微服务的边界应该在哪里？没有官方解答，也没有精确定义，其实微服务拆分困境产生的根本原因是不知道业务或者微服务的边界到底在什么地方。换句话说，确定了业务边界和应用边界，这个困境也就迎刃而解了。微服务拆分绝不是物理形态上把原来一个单体包拆分为多个部署包，或者将原来的单体应用架构替换为一套支持微服务架构的技术框架，就算是微服务了。不合理的拆分、盲目的拆分，为了微服务而微服务，只会引入更多的复杂性而业务并没有想象那么敏捷和可复用。

业务中台建设最大的困难和挑战是，如何统筹项目制实施引入的项目墙、隔阂与业务中台倡导的平台共享、业务共享之间的矛盾。业务中台实施中同样需要组织保障、技术体系、方法论的协同推进。

DDD 核心思想是通过领域驱动设计方法定义领域模型，从业务本质出发，从而确定业务和应用边界，保证业务模型与代码模型的一致性。基于领域驱动的战略设计和战术设计，其本质是面向业务，纵向：建立与领域模型匹配的代码模型，使用微服务落地；横向：复用通用域、支撑域中的共享服务。通过纵向一体化的模型及微服务的独立性让变化更敏捷，横向复用可进一步提高组装的速度。



基于领域驱动设计DDD 来构建业务中台和指导微服落地，DDD核心思想是通过领域驱动设计方法定义领域模型，从业务本质出发，从而确定业务和应用边界，保证业务模型与代码模型的一致性。基于领域驱动的战略设计和战术设计，其本质是面向业务，纵向：建立与领域模型匹配的代码模型，使用微服务落地；横向：复用通用域、支撑域中的共享服务。通过纵向一体化的模型及微服务的独立性让变化更敏捷，横向复用可进一步提高组装的速度。

DDD 是一种处理高度复杂领域的设计思想，它试图分离技术实现的复杂性，并围绕业务概念构建领域模型来控制业务的复杂性，以解决软件难以理解，难以演进的问题。DDD 不是架构，而是一种架构设计方法论，它通过边界划分将复杂业务领域简单化，帮设计出清晰的领域和应用边界，可以很容易地实现架构演进。

DDD 包括战略设计和战术设计两部分。战略设计主要从业务视角出发，建立业务领域模型，划分领域边界，建立通用语言的限界上下文，限界上下文可以作为微服务设计的参考边界。战术设计则从技术视角出发，侧重于领域模型的技术实现，完成软件开发和落地，包括：聚合根、实体、值对象、领域服务、应用服务和资源库等代码逻辑的设计和实现。

DDD 战略设计会建立领域模型，领域模型可以用于指导微服务的设计和拆分。事件风暴是建立领域模型的主要方法，它是一个从发散到收敛的过程。它通常采用用例分析、场景分析和用户旅程分析，尽可能全面不遗漏地分解业务领域，并梳理领域对象之间的关系，这是一个发散的过程。事件风暴过程会产生很多的实体、命令、事件等领域对象，将这些领域对象从不同的维度进行聚类，形成如聚合、限界上下文等边界，建立领域模型，这就是一个收敛的过程。

在战略设计中建立了领域模型，划定了业务领域的边界，建立了通用语言和限界上下文，确定了领域模型中各个领域对象的关系。到这儿，业务端领域模型的设计工作基本就完成了，这个过程同时也基本确定了应用端的微服务边界。在从业务模型向微服务落地的过程中，也就是从战略设计向战术设计的实施过程中，会将领域模型中的领域对象与代码模型中的代码对象建立映射关系，将业务架构和系统架构进行绑定。当去响应业务变化调整业务架构和领域模型时，系统架构也会同时发生调整，并同步建立新的映射关系。



微服务技术架构

技术架构以SpringBoot+SpringCloud技术体系为开发运行平台，该平台具有天然技术中台的特性，具有强大的扩展和治理能力，技术上匹配企业构建业务中台所需的快速响应能力，是业界微服务和中台落地成熟技术方案。

下图为基于SpringBoot+SpringCloud的技术架构图，SpringBoot是Java编码框架，SpringCloud分布式服务治理框架。本架构的核心特点是，基于SpringCloud技术栈中各种组件，为业务层提供平台级服务能力，包括：服务注册发布、安全网关、负载均衡、反向代理、限流容错、系统监控、日志分析、调用链分析等能力。

相比传统技术架构，SpringCloud为业务聚合和系统集成提供了一个抽象层，把分布式环境中各节点通信协议、网络问题、服务路由、日志和监控等封装起来，为业务层屏蔽了分布式环境的复杂性。

架构分为四个层次：云基础层、平台层（技术中台）、服务层（业务中台）、开发技术层。



云基础层：微服务运行在K8S、容器技术之上，应用DevOps文化和实践。

平台层：也称为技术中台或PaaS平台，由存储、中间件、分布式服务框架组成，具体包括SpringCloud技术栈、统一工作流引擎、Nginx反向代理和负载均衡器、分布式文件服务、分布式缓存、数据集成和迁移、企业服务总线等。

服务层：分为业务服务（SaaS）、数据服务（DaaS）和UI组件（UI即服务），基于领域建模把业务拆分成服务，形成业务服务；基于数据仓库理论对数据进行聚合，并对外提供数据服务接口，形成数据服务；本技术架构使用前后端分离技术，各应用采用同一套UI，确保交互和用户体验的一致性。业务服务和数据服务相辅相成，业务服务为数据服务提供数据来源，数据服务反哺业务，为业务赋能。

开发技术：由前端技术、后端技术和组件技术组成，本系统技术选型为，前端技术：Html5、Bootstrap、Layui和jQuery等；后端技术：SpringBoot、SpringCloud技术栈、SpringMVC、JPA、Rest/Json等；组件技术包括：UI组件、报表组件、流程引擎组件等。

标准和规范：技术中台和服务中台，作为可扩展的的公共平台，第三方应用可以基于平台发布的标准和规范进行接入。主要标准和规范包括：UI规范、SpringCloud接入规范、用户中心集成规范、工作流引擎集成规范、ESB集成规范等。

分布式治理框架屏蔽了分布式环境复杂性，让开发只关注业务层面的问题。分布式治理框架分为两套技术体系：第一代，基于SpringCloud技术体系（目前江苏中烟在用该技术体系，承载了综合管理系统、安全管理系统、技术中心管理等系统的运行）和第二代，基于ServiceMesh技术体系，两套技术目前都成熟可靠，企业可以根据自身的技术标准、技术规划进行选型。下面分别介绍两套技术方案特点。