DDD与云原生时代的微服务拆分

• 在服务拆分的时候，拆到多大最为合适？
• 以什么样的维度进行服务划分？
  带着这些问题，我们开始探索云原生时代的微服务如何进行拆分。

DDD

微服务

云原生

一、概念

在分析问题之前，我们先搞清楚，各个概念:

DDD

Domain Driven Design（领域驱动设计）,DDD整体的内容很多，它的其中一个作用是可以指导业务代码按照边界拆分。

云原生

云原生架构，能够尽可能地剥离云应用中的非业务代码，聚焦功能性业务，从而打造敏捷、智能云计算服务。本质上，云原生架构也是一种软件架构，核心特性是运行于云环境之中，对微服务进行延伸。

善用云原生技术，都能够充分发挥云计算的弹性、分布式优势，大幅提升开发效率、构建高稳定的技术系统和可弹性扩展的程序应用。代表性技术包含容器、微服务、服务网格等。

弹性扩展

• 水平扩展：通过构造机器数量，构造集群的方法，来满足容量的需求
• 垂直扩展：通过更换更强有力的机器，来获得更好的性能，或者满足容量需求

由于垂直扩展，有上限，所以现在都是采用水平扩展的方式。

微服务

微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。

二、微服务与云原生

云原生架构特点

自动恢复

服务安全

弹性扩展

快速发布

基于云原生的这些特点，做到整体的可用性、可维护性、伸缩性最好，最适用的就是微服务架构

三、DDD与微服务

微服务要如何进行拆分呢，有这样几种维度：

• 以业务边界划分：例如订单域、商品域、用户域
• 以使用者维度划分：例如淘宝有商家端、用户端
• 以成本维度划分：把什么样的服务划分在一起，能最大节省部署成本

但是微服务拆分到多大，经常是你有你的说法，我有我的说法，没法统一，DDD在这方面就给我们提供了一套指导思想：

• 微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。
• DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。

四、微服务拆分步骤

由此就可以得出了微服务的拆分步骤：

1. 通过DDD的方式（事件风暴、四色模型、领域建模等）对业务进行领域划分
2. 划分出的领域，结合云原生的特点，确定是否放在一个微服务中

例子1：比如拼多多的商家端，有一个是给用户使用的界面，还有一个给运营人员使用的配置界面，他们被划分成了两个领域。
但是运营人眼使用的后台，与商家使用的后台应该是互不影响的，这个时候最为合理的方式，是部署为两个服务
但是把给运营人员使用的内容，也单独部署一个服务，有些浪费成本，那么就有一个统一的后台，把商家端、用户端、批发商等的运营配置功能，统一在同一个微服务中，以此来节省成本

拆分前：

拆分后：

拆分后
（1）流量上不会互相影响
（2）商家运营端服务崩溃，也不会影响商家端服务不可用

小结

本篇文章，说了:

• DDD、微服务、云原生的概念
• 微服务之所以适用云原生，是因为微服务的拆分，充分利用里云原生的优点
• DDD与微服务的关系，DDD因为有一套业务、代码边界划分的理论，可以指导微服务的划分
• 最后我们说了微服务拆分步骤，就是按照DDD->微服务->云原生的分析逻辑进行。