从业务到技术：微服务建模的四大切入点

随着互联网技术的飞速发展，微服务架构作为一种灵活、高效的系统设计模式，已经成为许多企业构建可扩展、高可用应用的首选方案。然而，微服务架构的成功不仅依赖于技术的选择，更依赖于如何科学地进行服务建模。如何将复杂的业务需求抽象成一系列高内聚、低耦合的服务？如何确保服务间的协作和数据的一致性？这些问题往往成为微服务架构设计中的瓶颈。

本篇文章将带您深入探索微服务架构中的服务建模切入点。从服务分类到服务模型，从服务边界的识别到数据去中心化，我们将通过一系列具体的切入点，帮助您在设计微服务架构时，能够更好地理解和把握服务的内在关系。无论您是初次接触微服务架构的开发者，还是已有一定经验的架构师，都能从中获得启发与实践指导，进一步优化您的微服务设计。

让我们一起走进微服务的世界，解锁架构设计的秘密。

一、服务建模切入点一：服务分类

（一）、服务的基本类别：工具服务+实体服务+任务服务

工具服务

代表可重用服务，区别业务模型，特点是业务领域无关，本质是面向技术、具备高可用性的底层处理服务，根据其用途也可以做进一步细分，一般包括以下表现形式：

公共工具服务：面向多种应用程序，如安全性、记录和审核，通常设计成基于WEB的服务，并开放通用、松散类型接口。
资源工具服务：用于封装物理系统资源，如数据存储/消息资源，通常用于底层，使用服务门户暴露入口。
微服务工具服务：服务细粒度、高度特性化，如XML加密服务，通常用于本地调用，需要考虑性能、无状态性和线程安全，可以作为JAR包进行直接引用。
包装器工具服务：面向遗留系统，建立标准化服务契约，需要明确所支持的数据和消息模型。

实体服务

建立一种一致的方法访问和处理业务数据，对应基于业务的功能上下文，侧重于以数据为中心。同样可重用，一般被更高级的任务服务使用，具体包括领域实体和消息实体，领域实体是服务中规范化的业务数据模型，消息实体特定于实体服务契约的数据模型，具体分析如下图：

实体服务的层次讲解：

领域实体和消息实体示例讲解：

任务服务

关注实现业务相关逻辑，很大程度上有组合逻辑组成，通常需要维护状态，体现为一种组合结构。

总结下：工具服务因为不涉及业务，识别和提取相较另外两种服务而言比较简单。实体服务关注于数据，任务服务关注于业务组合，都需要根据业务本身抽象化。

（二）、从业务维度对服务做层次分类：基础服务+通用服务+定制服务+其他服务

基础服务：基础服务往往和技术整合在一起，比较典型的基础服务包括消息服务、路由服务等。
通用服务：与基础服务的区别是其完全面向业务，通用性非常高。取决于对业务的抽象程度，包含的内容可以很多，如账号服务、登录服务、通知服务等对于任何一个系统而言都可以认为是一种通用服务。
定制服务：定制服务相对而言不应该太多，主要面向外部、面向系统集成类的表现形式。常见的定制服务包括插件服务、外部账号和接口类服务。
其他服务：除以上三种类型的服务统称其他服务。

注：通用服务与基础服务区分上可能存在一定难度，可以做一个简单判断：如果一个服务依赖的层次和数量非常多，那么可能更偏向于基础服务，反而更偏向于通用服务。

以下列举一个架构服务示例：（移动医疗系统服务架构图）

二、服务建模切入点二：服务模型

（一）、服务的概念模型维度：服务标准+服务级别

服务标准

服务无状态：服务应当不需要管理状态信息，因此能够维持送耦合性。服务应该被尽可能设计成无状态，即便意味着要将状态管理移至他处。
服务可重用：不管是否存在即时复用的机会，服务均被设计为支持潜在的可复用。
服务可发现：服务发布上线后，允许被其他消费者自动发现；当服务提供者下线后，允许消费者接收服务下线通知。
服务自治：逻辑由服务所控制，并位于一个清晰的边界内，服务已经在边界内被控制，不依赖其他服务。
服务松耦合：服务被设计为功能相对独立，尽量不依赖其他服务的独立功能提供者。
服务共享一个标准契约：为了与服务提供者交互，消费者需要导入服务提供者的服务契约。
服务是底层逻辑的抽象：只有经服务契约所暴露的服务队外部世界可见，契约之外底层的实现逻辑是不可见的。

服务级别

一级服务：具备完善的容错降级机制以及对低级别服务的熔断措施、定期检测、配置高级别的监控告警流程等。
二级服务：多采用异步方式进行系统交互，容忍暂时数据不一致性。
三级服务:可随时降级整个服务。

（二）、服务统一表现形式：服务契约化+文档服务

1.服务契约化：要求至少对服务的基本方面作出说明包括API、能力、约束、版本四个方面，减少多余及可能反复的口头沟通，降低协助成本。

2.文档服务：Swagger或HAL等文档服务要日常化规范化。

三、服务建模切入点三：服务边界

（一）、识别业务领域及边界：通用语言+子域+聚合

我们可以简单认为，我们所要设计的每一个特定的业务系统就是一个领域。在领域驱动设计中，有两个主要设计维度，即设计的策略维度和设计的技术维度，策略维度偏重于业务架构的梳理以及考虑如何把业务架构和技术架构相结合的问题，设计维度包含集合、领域事件等组件，有助于组织服务内部以及服务与服务之间进行交互的方式。

通用语言

思路是面向领域和业务，促进后续代码模型中的命名等使用领域词汇而不是技术词汇，能够将客户、体验设计师、业务分析师、技术人员集结在一起对业务需求进行沟通，随后对其进行领域划分，这是服务有效识别的前提。

子域

系统拆分的切入点，其来源往往取决于系统的特征和拆分的需求，如核心功能、辅助性功能、第三方功能等，业界将各个子域分成核心子域、支撑子域和通用子域三种：

核心业务属于核心子域；
专注于业务某一方面的子域属于支撑子域；
作为基础设施的功能属于通用子域。

聚合

一个子域包含若干聚合。聚合的核心思想在于将关联降至最少有助于简化对象之间的遍历，使用一个抽象来封装模型中的引用，主要由两部分组成：根实体和边界，只有根对象之间才能直接交互，其他对象只能与该聚合中的根对象进行直接交互，如下图分析：将 $2^{8}-1$ 次交互降为 $2^{3}-1$ 次交互。（聚合示意图）

（二）、界限上下文：领域与界限上下文+界限上下文集成策略

领域与界限上下文

界限指的是每个模型概念、属性和操作，在特定边界之内具有特定的含义，这些含义只限定在该界限内，界限的划分能在很大程度上影响系统的设计和实现，也为确定服务边界提供了合理性依据。具体举例如下：

子域、聚合和界限上下文三者之间的关系如下，划分方法如图讲解：（子域、聚合和界限上下文关系及业务流程划分）

界限上下文集成策略

站在高层次的架构分析角度，任何一个系统都可以处在其他系统的上游，也可以处在其他系统的下游。系统集成实际上就是将上游系统和下游系统进行整合，共同完成某一业务的流程。

上下文集成的基本思路在于解耦和统一，具体要关注防腐层与统一协议+领域事件两个重要思想，具体问题具体分析：

（三）、服务边界划分的四大原则

服务关联度原则：该服务变化时是否导致其他服务的变化。
业务能力职责单一原则：边界内的业务能力职责应单一，不是完成同一业务能力的服务不应该放在同一个上下文中。
读写分离原则：数据读取类型服务应尽量放在单独子域，且该子域不应该为核心子域。
组织关系原则：设计团队组织和独特业务价值。

四、服务建模切入点四：服务数据

绝大多数服务都会依赖数据，而很多数据可能也会被一批服务所依赖。微服务架构中数据管理的基本思想就是数据去中心化。

（一）、数据去中心化的三大场景

主要设计对数据拆分需求的表现形式：

跨表查询场景解决

在数据层去掉各种连接操作，将连接查询转变为简单的单表查询，然后对各种表查询的结果在内存中进行动态组装，从而实现业务所需要的数据。注意：如果考虑到未来服务拆分或重构的需要，从一开始就保持数据单表查询是最佳实践。

跨库查询场景解决

针对一些修改频率不高、相对静态的数据而言，可以采用数据复制的方式达到同一份数据在两个数据库中同时存在的效果，从而将跨库查询转变为同一库中表查询。

对于实时性要求比较高的数据，则可以开放接口的方式实现两个数据库之间的数据集成效果。

技术耦合场景及解决

技术耦合表现在使用了特定某种数据存储容器相关的技术体系，对于关系型数据库而言，存储过程、触发器就是典型的数据库工具级别的特有技术。

由于每种数据存储容器对这些技术的实现和支持都有所不同，所以在原则上，我们的业务功能都不应该使用这些技术进行数据处理。如果有，需坚决去掉。

（二）、数据去中心化流程

主要包含四大步骤，但涉及复杂的数据迁移工作，人力和时间成本都很大，也是目前微服务架构数据库去中心化的难度所在。

步骤1：代码分离

必须代码拆分，通过物理上代码拆分，即把原本单块系统中的代码拆分成几个组成部分就能实现。

步骤2：重复数据库模式：代码拆分后，对数据访问会形成两种模式

一种是数据能够随着代码完成拆分，即这些数据不存在多个系统共用情况，简单把数据迁移出去供单个系统访问即可。

二是由于代码中包含了跨表查询、跨库查询和技术耦合场景，不能简单进行数据拆分，所以需要一个过渡环节，把几个系统共用的数据进行冗余处理，就是将同一份数据库模式和相应的数据同时保存在不同的数据库中。

步骤3：迁移数据读写操作

将针对数据库写入和读取操作做单独抽离。

数据写入操作比较容易抽离，因为针对某个业务数据写入的源头通常只有一个，只要明确这个数据源就可以。

数去读取操作因为在没有进行专门的数据拆分之前，同一份数据可能通过各种方式被多业务共享，出现大量跨表查询、跨库查询和技术耦合场景，这是需要采用前文所述的各种解决方案进行读操作分离，这是最为复杂和最难的一步。

步骤4：抽离服务化接口

完成迁移数据读写操作迁移、去除数据定时同步机制以后，我们需要对代码进行拆分，从而实现服务化，抽离服务化接口是完成数据去中心化的最后一个环节。

五、总结思考

在微服务架构的设计与实施过程中，服务建模的思路和方法至关重要。从服务的分类到服务边界的识别，再到数据管理的去中心化，本文展示了如何通过科学的架构方法来应对复杂系统中的各种挑战。然而，尽管我们可以从理论上明确服务的拆分、设计和数据管理的最佳实践，实际应用过程中仍然会遇到诸多问题和困难：

服务拆分的灵活性与适应性
微服务架构的优势在于它能够有效应对系统的扩展性和维护性问题，但服务拆分的过程并非一蹴而就。在服务拆分时，如何在保证系统整体一致性的前提下，合理拆分并定义每个服务的边界，往往依赖于业务需求的变化和系统的演化。因此，在设计服务架构时，灵活性和适应性应成为关键考虑因素。例如，服务边界的划分不仅仅依赖于领域模型，还需要结合实际业务场景和技术环境的动态变化。
服务数据的去中心化与一致性挑战
数据去中心化是微服务架构的重要组成部分，然而，如何在保持数据一致性、减少数据冗余的同时，确保各个服务之间的高效交互和低耦合，是微服务架构中的一大挑战。文章提到的数据拆分和迁移流程，虽然提供了很好的理论框架，但在具体实现中，特别是在涉及到跨表查询、跨库查询等场景时，往往会出现性能瓶颈或数据一致性问题。因此，如何通过技术手段和设计模式解决分布式数据一致性问题，仍然是微服务架构实践中的一个亟待攻克的难题。
服务与团队的协作关系
服务边界的划分并不仅仅是技术问题，还与团队的协作结构密切相关。文章中提到的“组织关系原则”强调了设计团队与业务价值的匹配问题。在实际操作中，团队结构的调整往往需要与服务划分相结合，确保每个服务的开发和维护能够与团队的工作流程相适应。如何通过组织结构的优化来提升微服务架构的效率和灵活性，是一个需要进一步思考的问题。
服务的演化与技术债务管理
微服务架构在初期能带来高效的开发和运维优势，但随着系统的复杂度增加，技术债务也可能逐步积累。如何在长期维护中避免微服务架构的“腐化”，通过持续的技术优化和服务重构，保持系统的高效性和可维护性，是一个不可忽视的问题。对于开发团队而言，如何设计出一个可以不断适应业务变化且具备较强演化能力的架构，仍然是微服务架构成功应用的关键。
微服务架构的成本与收益
尽管微服务架构有许多优势，但它也带来了一些不可忽视的成本，例如服务拆分的复杂性、跨服务的通信开销以及运维的难度。在设计微服务架构时，必须权衡这些成本与收益，确保架构的可行性和高效性。在未来的实践中，如何在不牺牲可扩展性和高可用性的前提下，尽量减少微服务架构的运维成本，将是微服务设计的一个重要方向。

微服务架构的服务建模不仅仅是一个理论框架的应用，它需要结合具体的业务需求和技术背景，灵活调整和优化。在实际实施过程中，技术和业务的紧密结合，团队协作的高效配合，以及对于架构演化的持续关注，都将决定微服务架构的成功与否。通过对这些问题的深入思考和持续改进，我们能够逐步解决微服务架构中遇到的各种挑战，从而实现更为高效、可扩展和易维护的系统架构设计。

参考书籍及文献：

【1】郑天民. 微服务设计原理与架构. 北京：人民邮电出版社，2018.

【2】Eric Evans. 领域驱动设计：软件核心复杂性应对之道. 赵莉，盛海燕，刘霞译. 北京：机械工业出版社，2018.

今天的文章从业务到技术：微服务建模的四大切入点分享到此就结束了，感谢您的阅读。