★ 微服务系列
前面我们学习了微服务的全景架构，了解到相对于传统单体架构，微服务的优势，以及系统服务化的发展趋势。
对于新启动的项目，我们在权衡之后可以大方的使用微服务架构。但其实大部分情况下，我们还要去维护一些以前研发的单体系统，这些系统可能因为访问流量的膨胀、功能的扩张而显得非常臃肿不堪，急需要向微服务架构迁移。
1 微服务迁移准备
1、需对业务充分了解，这是服务拆分，通信设计，资源整合的必要前提。
2、适应微服务架构设计原则：小版本，高速迭代。
3、快速的环境提供能力：依赖于云计算、容器技术，快速交付环境。
4、服务合理拆分：需符合团队结构或能逆向影响，能对组织架构进行微调并划分职责。（康威定律和逆康威定律）
5、基本的监控能力：包括基础的技术监控和业务监控。
6、快速的应用部署能力：需要部署管道提供快速的部署能力。
7、DevOps 自动化运维能力：需要具有良好的持续集成和持续交付能力，还需要对问题、故障的快速响应能力，开发、测试和运维能协同工作。
2 微服务颗粒的拆分策略
前面两篇文章我们学习了What & Why（什么是微服务和为什么需要做微服务架构），这一章我们就来探讨如何做微服务架构的拆分（How）。
微服务拆分没有一个绝对的标准答案，服务拆分的粒度需要根据业务场景来规划，而随着业务的发展，原先的架构方案也需要做调整。
虽然没有固定的套路，但是我们在业务实践过程中总结的一些经验，以做参考。
2.1 基于业务逻辑拆分
基于业务逻辑拆分相对好理解一点，典型的单一职责原则，我们将功能相近的业务整合到一个服务颗粒上。比如一个办公领域系统，考勤、工作流、音视频会议是是三个截然不同的业务领域，这可能就是我们拆分的一个入手点。
2.1.1 领域模型拆分
领域驱动设计DDD（Domain-Driven Design 领域驱动设计）是一个很简单的概念，表示我们对系统的划分是基于领域的，也即是基于业务方向去思考的。
举一个典型的电商业务例子。电商的业务体系庞大，涉及各方面的细节。但是我们大概能够根据业务的职能做一个拆分，比如阿里的电商中台业务，包含 用户账号子系统、商品子系统、订单子系统、客户子系统、物流子系统 等。
因为职能不同，这些领域之间包含清晰的界限，所以我们可以按照这个方向将服务于不同领域（商品域和订单域）的子系统拆成独立的服务颗粒。如下图：
2.1.2 用户群体拆分
根据用户群体做拆分，我们首先要了解自己的系统业务里的用户角色领域是否没有功能耦合，有清晰的领域界限。
比如教育信息化系统，教师的业务场景和学生的业务场景，基本比较独立，而且拆分后流量上有明显的削弱，这时候结合具体的业务分析，看是否有价值。如下图所示：