来吧，说说你眼中的微服务

发布时间：2025-11-03 12:28:57 来源：创站工坊 作者：应用开发

 微服务划分模式

虽然服务是来吧逐步被拆分出来的，随着业务的说说演进，在某一时刻，眼中可能需要我们重新审视服务划分得是服务否合理。本节向大家推荐两种服务划分的来吧方法，首先介绍如何选择服务划分的说说方法。

基于业务复杂度选择服务划分方法

根据业务复杂度划分服务，眼中如图2-4所示。服务当业务复杂度足够高的来吧时候，应该基于领域驱动划分服务，说说而领域驱动本身足够复杂，眼中很多概念比较抽象，服务应用范围并不是来吧特别广泛，所以当业务复杂度较低时，说说可以选择基于数据驱动划分服务。眼中数据驱动更容易理解和上手。也就是说，除非业务复杂度非常高，否则应该优先以数据驱动划分服务。这里的业务复杂度专指业务逻辑，而非数据量、并发量等相关复杂度。

图2-4 根据业务复杂度划分服务

在做出选择的时候，香港云服务器还有一个参考指标是，团队以前是否已经基于领域驱动开发业务。也就是说，如果产品已经基于领域驱动开发了一段时间，团队具备了领域驱动开发的能力，那么推荐继续选择领域驱动划分服务。如果是一个全新的产品，则可以灵活选择。

选择服务划分的方法时要重点考虑如下条件。

基于数据驱动划分服务

数据驱动是一个自下而上的架构设计方法，数据驱动强调的是数据结构，也就是通过分析需求，确定整体数据结构，根据表之间的关系划分服务。

通常基于数据驱动划分服务的步骤如下。

(1)需求分析。源码下载通过领域专家(或者产品经理)确定目标，然后总结User Story，确定核心的业务流程;通过工具呈现比较粗糙的界面，进行内部讨论;不断迭代此环节，直到满意为止。

(2)抽象数据结构。根据需求总结Use Case，协助分析需求，从中抽象数据结构。

(3)划分服务。分析数据结构，识别服务——服务应该满足高内聚、低耦合、单一职责等特征。

(4)确定服务调用关系。先分析出主要流程，根据请求需要调用的服务确定服务调用关系。如果存在问题，则需要回到(1)重新开始。

(5)业务流程验证。重新回到User Story，以服务为粒度实现时序图，注意此阶段重点是验证服务划分是否合适，要关注如下问题。

(6)持续优化。

基于领域驱动划分服务

领域驱动是一个自上而下的架构设计方法，通过和领域专家建立统一的语言，不断交流，确定关键业务场景，逐步确定边界上下文。领域驱动更强调业务实现效果，认为自下而上的设计可能会导致技术人员不能更好地理解业务方向，进而偏离业务目标。

通常基于领域驱动划分服务的步骤如下。

(1)通过模型和领域专家建立统一语言。建立统一语言是为了更深入地理解需求。通用语言尽量以业务语言为主，而非技术语言;通用语言和代码一样，需要不断地重构。

(2)业务分析。确定核心的业务流程，然后逐步扩展到全部。最好通过工具呈现比较粗糙的界面，供内部讨论。

(3)寻找聚合。显式地定义领域模型的边界。最近比较热门的事件风暴，是一种基于领域驱动分析业务、划分服务的方法。

事件风暴就是把所有的关键参与者都召集到一个很宽敞的屋子里来开会，并且使用便利贴来描述系统中发生的事情，如图2-5所示。

图2-5 事件风暴

(4)确定服务调用关系。先分析出主要流程，根据一次请求需要调用的服务来确定服务调用关系。如果存在水平划分，则需要根据服务依赖原则确定关系。如果存在问题，则需要回到(1)重新开始。

(5)业务流程验证。以服务为粒度实现时序图，注意此阶段重点是要验证服务划分是否合适，主要关注如下问题。

(6)持续优化。

从已有单体架构中逐步划分服务

在大多数场景下，并非从开始阶段就采用微服务架构，而是随着业务不断发展，从最初的单体架构中逐步拆分服务。下面描述了从一个单体架构逐步拆分的步骤。

(1)所有微服务成功的故事都是从一个单体架构太大，需要被拆散开始的，如图2-6所示。我们应该从单体架构开始，当系统规模足够大、团队人数足够多时，再逐步拆分服务，通常前后端分离是拆分的第一步。

图2-6 从已有架构逐步拆分服务(一)

(2)提取公共基础服务，如单点登录。拆分可以遵循逻辑分离和物理分离两种方法。另外随着系统压力的增加，可能会用到消息中间件、分布式缓存等服务。

(3)不断地从老系统中抽象出服务，垂直划分优先，如图2-7所示。

图2-7 从已有架构逐步拆分服务(二)

(4)当业务越来越复杂的时候，API Gateway做了太多的事情，会成为一个瓶颈点，服务之间的依赖关系也会变得越来越复杂，此时，需要适当地进行水平切分，如图2-8所示。

图2-8 从已有架构逐步拆分服务(三)

微服务拆分策略

当不断从单体架构中抽象服务的时候，哪些服务优先被拆分，哪些服务不需要被拆分?以下几个策略可以帮助解决拆分中的这些问题。

如何衡量服务划分的合理性

每个产品在实施微服务架构最初的动力都不一样，目标也有所区别，所以判断是否划分合理，首先要看是否达成了目标。其次，可以参考以下几种衡量方式。每种衡量方式不能单独作为一个判断标准，需要综合考虑。

微服务划分反模式

前面我们介绍了如何划分服务，在此之上，我们希望通过微服务划分的反模式来帮助大家少走弯路。

根据代码行数划分服务

代码规模太大会导致沟通效率、交付效率低下，耦合度高，以及比较笨重。代码规模可以作为一个参考，但是不能作为一个绝对标准，微服务架构中存在一个“大服务”是很正常的。基于代码行数拆分服务很难衡量服务的完整性，容易导向更小的拆分粒度，引起不必要的复杂度。

划分粒度越小越好

服务的大小并不是特别重要，可以根据团队规模、代码规模、业务复杂度、技术领域、重要程度、成本等因素综合考虑。关于服务粒度的大小，业界并没有统一标准，也很难衡量，最接近的衡量标准是研发团队规模。粒度小意味着更高的维护成本。后端管理、辅助系统通常粒度较大。

一次性划分服务

拆分服务有如下两种方式。

第一种，先拆分业务代码再拆分数据库。如图2-9所示，数据库并没有拆分，只是从单体中抽象出部分服务。

图2-9 先拆分业务代码再拆分数据库

第二种，业务代码和数据库同步拆分。如图2-10所示，部分业务服务被拆分出来的同时，数据库也被同步拆分出来。

图2-10 业务代码和数据库同步拆分

采用第二种方式拆分服务时，根据服务将数据库彻底拆分为多个独立的数据库，每个服务独享数据库服务，服务之间只能通过接口调用。这看起来非常美好，但需要为此做大量的数据迁移。当业务处于初期，需求不是非常确定，开发人员对业务理解不是特别透彻的时候，可能拆分后发现拆分得并不合理，只能再进行合并，又要进行一次数据迁移。相对来说，业务代码拆分成本更低，而数据迁移的成本更高，频繁、大量的数据迁移并不可取。

更好的做法是把第一种方式作为过渡阶段，当业务逐步稳定后再彻底进行数据迁移。注意，处于过渡阶段时数据库并没有彻底分离，一切依赖都通过接口访问。但是这只是口头上的约定，对于业务开发人员直接在数据库中进行关联查询。需要通过Code Review的方式避免。

服务划分是一个长期的过程，需要积累大量的领域知识，以此来理解核心流程。最好是和领域专家一起组成联合团队，在理解核心问题的情况下，持续拆分服务并验证拆分合理性，随着时间的推移，还可以重新划分。可见，服务拆分是一个持续性的过程。

服务划分一旦完成，不能改变

由于业务的不断变化，以及开发人员对领域知识和其他影响因素的理解等问题，很难一次性做出一个完美的解决方案。通常在划分后会发现，某个问题是不可忍受的，例如划分后导致响应时间降低，增加了更多的成本，有可能需要重新合并服务;由于业务的变化，原本的依赖关系发生了变化，有可能面临需要重新划分服务等类似的问题。

先实施组件化，再实施微服务架构

很多技术人员试图先通过组件化逐步过渡到微服务架构，这是一种错误的思路。微服务架构划分更强调业务领域的完整性，因此垂直划分优先，而组件化往往通过抽象出稳定的部分形成组件共享，对调用次数和依赖关系并不强调。因此，组件化之后再转化到微服务架构的方式，通常是错误的。

相关文章