微服务分解设计四种法则

作者 |MicroStone
来源 | 今日头条

如果您在设计大型并发应用程序或者准备拆解之前的老系统时，我想你第一考虑的是微服务架构方式。

前面我们了解到微服务架构将应用程序构建为一系列松散耦合的服务，是为了通过实现持续交付和灵活部署来加速软件开发。

出于很原因，分解很重要

• 有利于分工和知识共享。使用它，具有特殊知识的多个人（或团队）可以在一个应用程序上高效地合作。
• 它描述了多个元素如何交互。
  在微服务下，有两种类型的项目

1. 待重新开发项目—国外译名：Brownfield projects，是指在现有或遗留系统的背景下开发和部署新的软件系统。因此，将单体应用程序转换为微服务是属于这种类型项目。
2. 新建项目——是指从头开始为一个全新的系统，而无需使用任何遗留代码。当您从头开始时，没有任何限制或依赖性。
   一、按业务能力模式分解
   为了创建微服务架构，一种策略是基于业务能力进行分解。作为一家企业，项目是为了创造价值。例如，在电子商务业务中，订单管理、库存管理、支付、运输等都涉及。

这种模式有以下好处业务能力比较稳定，架构依赖的业务逻辑比较稳定。

开发团队是跨职能的、自主的，并且围绕交付业务价值而非技术特性进行组织。

服务是松散耦合和内聚的。

二、按子域模式分解

领域驱动设计 (DDD) 方法是一种构建复杂软件应用程序的方法，它基于面向对象领域模型的开发。DDD 为每个子域定义了单独地域模型。每个子域都属于一个域。识别子领域与识别业务能力的过程比较相似，即分析业务和识别专业领域。最有可能的是，大多数是业务熟悉的子域。领域模型的范围在 DDD 中称为有界上下文。有界上下文包括实现模型的代码组件。

子域可以分类如下

1. 核心—业务的最大差异化因素和应用程序最有价值的部分，在一些公司经常有核心系统项目，有核心报价子系统，核心定价子系统等
2. 支持—不是差异化因素，而是与业务提供的内容相关。通常在内部或外包实施。
3. 通用—不特定于业务，最好使用现成的软件实施。

这种模式有以下好处

1. 子域职能比较稳定，架构相对也比较稳定。
2. 开发团队(通常会设计到组建虚拟团队)是跨职能的、自主的，并且专注于交付业务价值而不是技术特性。
3. 服务是松散耦合和内聚的。
   三、将单体应用程序分解为微服务时的挑战

在分解单体应用程序时，可能会出现挑战。

1. 网络延迟—在分布式系统中，网络延迟是一个持续关注的问题。您可能会发现对服务的特定分解会导致两个服务之间的大量往返。
2. 数据一致性—每个服务都有自己的数据库，因此维护跨服务的数据一致性会非常困难。
3. 神类(捂脸哭一下)—神类是控制系统中太多其他对象的对象，它超越了逻辑，成为了无所不能的类。由于其规模和复杂性，它是一个集中系统智能的类，并使用来自其他类的信息。
   四、扼杀者模式
   将遗留的单体应用程序迁移到微服务架构时，会使用 Strangler 模式。通过用新服务替换特定功能，可以使用这种模式逐步转换单体应用程序。新服务一旦准备好，旧组件就被扼杀，新服务投入使用，而旧组件退役。

单体应用最终会缩小功能，而微服务将接管整体功能。