如何做拆分服务？
如何拆分服务？
在微服务的落地中，第一步就需要进行微服务的拆分，服务的拆分很困难也很重要，本文就讲讲怎么进行服务的拆分。
技术发展到现在，还没有一个具体的、设计完善的标准方法来完成服务的拆分，服务的拆分是一门技术更是一门艺术。
对于服务的拆分，有两种情况：
- 从零开始开发新的产品，采用微服务架构，进行服务拆分。
- 将现有的单体架构的产品重构成微服务架构，进行服务拆分。
如果做的是 ToB 业务，最终在企业内部私有化部署落地，那么在大多数的场景下，微服务拆分后系统的复杂度和引发的新问题会大于带来的好处。
随着业务的发展，产品需要进行 SaaS 化改造，团队也引入多种技术栈，进行微服务的拆分应该就是势在必行了。所以下面介绍的是怎样将现有单体架构拆分成微服务。
服务的拆分不是看代码量或是工程的大小，而是看服务是否可以独立部署和扩展。每个服务都应该有清晰的边界，负责一个特定的功能。
服务拆分的原则
- 通用功能：使用共享库，比如工具类，提取成 NuGet 包或者 Maven 包，在服务中进行引用。
- 业务相关的公共部分：使用单独的服务，提供 API 的方式供其他服务调用。
每个服务都可以使用不同的架构和技术栈来实现。有一种推荐的做法就是使用六边形架构。
六边形架构
六边形架构也称为端口适配器架构，可以替代传统的三层，解决三层架构的一些弊端。端口和适配器都分为入站和出站。
- 入站适配器：通常就是对外的 RestAPI，通过调用入站端口来处理外部的请求，也可以是消息队列的消费者，进行一些事件的监听，来处理异步业务。
- 入站端口：业务服务对外暴露的公有方法。
- 出站适配器：出站适配器实现出站接口，调用外部的服务来实现一个完整的业务逻辑，出站适配器也可以是消息队列的生产者。
- 出站端口：出站端口是一组方法的接口定义，提供一种规范，供出站适配器来实现。
举个例子：在零代码平台中，表单上拖一个控件保存后，最后的效果是列表上也会有这一列了，而表单和列表属于两个独立的服务。按照六边形架构，调用关系如下图：
- 表单服务通过入站端口接收请求，处理业务逻辑，然后通过出站适配器调用列表服务的 API。
- 列表服务通过入站端口接收请求，处理业务逻辑。
六边形架构一个最大的好处就是将业务逻辑和适配器中包含的展示层和数据访问层的逻辑分离开，实现了解耦。
学习微服务，我觉得有必要同时学习领域驱动开发(DDD)，微服务是一种架构风格，DDD 是具体的架构设计方法，互相配合能够更好地落地。因为：
- DDD 中子域和限界上下文的概念可以对应到微服务中的服务。
- 微服务中一个服务可以由一个团队进行开发，DDD 的一个领域模型也是建议由一个独立的团队负责。
进行服务拆分后，之前在一个进程内就能完成的事情，现在需要在进程间进行通信了。有关进程间通信后面再继续分享。
零代码现在越来越火热，通过高度的抽象，将基础设施、重复性的工作作为平台本身的能力提供，让用户只用关注业务，这其实也是另一个层面的解耦和拆分。
