目录
- 一、概念
- DDD
- 云原生
- 微服务
- 二、微服务与云原生
- 三、DDD与微服务
- 四、微服务拆分步骤
- 小结
- 在服务拆分的时候，拆到多大最为合适？
- 以什么样的维度进行服务划分？
带着这些问题，我们开始探索云原生时代的微服务如何进行拆分。
DDD
微服务
云原生
一、概念
在分析问题之前，我们先搞清楚，各个概念:
DDD
Domain Driven Design（领域驱动设计）,DDD整体的内容很多，它的其中一个作用是可以指导业务代码按照边界拆分。
云原生
云原生架构，能够尽可能地剥离云应用中的非业务代码，聚焦功能性业务，从而打造敏捷、智能云计算服务。本质上，云原生架构也是一种软件架构，核心特性是运行于云环境之中，对微服务进行延伸。
善用云原生技术，都能够充分发挥云计算的弹性、分布式优势，大幅提升开发效率、构建高稳定的技术系统和可弹性扩展的程序应用。代表性技术包含容器、微服务、服务网格等。
弹性扩展
- 水平扩展：通过构造机器数量，构造集群的方法，来满足容量的需求
- 垂直扩展：通过更换更强有力的机器，来获得更好的性能，或者满足容量需求
由于垂直扩展，有上限，所以现在都是采用水平扩展的方式。
微服务
微服务是一种开发软件的架构和组织方法，其中软件由通过明确定义的 API 进行通信的小型独立服务组成。这些服务由各个小型独立团队负责。
二、微服务与云原生
云原生架构特点
自动恢复
服务安全
弹性扩展
快速发布
基于云原生的这些特点，做到整体的可用性、可维护性、伸缩性最好，最适用的就是微服务架构
三、DDD与微服务
微服务要如何进行拆分呢，有这样几种维度：
- 以业务边界划分：例如订单域、商品域、用户域
- 以使用者维度划分：例如淘宝有商家端、用户端
- 以成本维度划分：把什么样的服务划分在一起，能最大节省部署成本
但是微服务拆分到多大，经常是你有你的说法，我有我的说法，没法统一，DDD在这方面就给我们提供了一套指导思想：
- 微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。
- DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。
四、微服务拆分步骤
由此就可以得出了微服务的拆分步骤：
- 通过DDD的方式（事件风暴、四色模型、领域建模等）对业务进行领域划分
- 划分出的领域，结合云原生的特点，确定是否放在一个微服务中
例子1：比如拼多多的商家端，有一个是给用户使用的界面，还有一个给运营人员使用的配置界面，他们被划分成了两个领域。
但是运营人眼使用的后台，与商家使用的后台应该是互不影响的，这个时候最为合理的方式，是部署为两个服务
但是把给运营人员使用的内容，也单独部署一个服务，有些浪费成本，那么就有一个统一的后台，把商家端、用户端、批发商等的运营配置功能，统一在同一个微服务中，以此来节省成本
拆分前：
拆分后：
拆分后
（1）流量上不会互相影响
（2）商家运营端服务崩溃，也不会影响商家端服务不可用
小结
本篇文章，说了:
- DDD、微服务、云原生的概念
- 微服务之所以适用云原生，是因为微服务的拆分，充分利用里云原生的优点
- DDD与微服务的关系，DDD因为有一套业务、代码边界划分的理论，可以指导微服务的划分
- 最后我们说了微服务拆分步骤，就是按照DDD->微服务->云原生的分析逻辑进行。