微服务要解决的问题：

1、可以快速迭代；

2、解决三高问题（高并发，高可用，高性能）

什么时候拆分微服务，拆分的时机是什么？

提交频繁代码冲突；

模块之间耦合严重，相互依赖，小功能修改也必须累计到大版本上线，上线还需要协调各个团队；

横向扩展流程复杂，主要业务和次要业务耦合。比如说下单业务需要扩容，但是注册业务不需要扩容。

如何决定拆分的粒度？

微服务储备：

1、业务规模要达到，按照产品生命周期来划分（导入期，成长期，成熟期，衰退期），在导入期一般采用单体架构，成长期一般采用微服务架构。

2、团队规模：结合业务复杂程度，团队规模一般达到百人。个人感觉（20人以上即可采用微服务）。

3、技术储备：领域驱动设计，注册中心，配置中心，日志系统，持续交付，监控系统，分布式定时任务，CAP理论，分布式调用链，API网关等。

4、人才储备：精通微服务落地经验的架构师和相应开发人员。

5、研发效率：研发效率大幅度下降。

微服务拆分的一些通用原则

1、高内聚低耦合。

​ 每个服务只完成自己职责内的任务，对于不是自己职责的功能交给其它服务来完成。

2、闭包原则（CCP）：

​ 微服务的闭包原则就是当我们需要改变一个微服务的时候，所有依赖都在这个微服务的组件内，不需要修改其他微服务

3、服务自治、接口隔离原则：

​ 尽量消除对其他服务的强依赖，这样可以降低沟通成本，提升服务稳定性。服务通过标准的接口隔离，隐藏内部实现细节。这使得服务可以独立开发、测试、部署、运行，以服务为单位持续交付。

4、持续演进原则：

​ 在服务拆分的初期，你其实很难确定服务究竟要拆成什么样。应逐步划分，持续演进，避免服务数量的爆炸性增长。

5、拆分的过程尽量避免影响产品的日常功能迭代：

​ 也就是说要一边做产品功能迭代，一边完成服务化拆分。比如优先剥离比较独立的边界服务（如短信服务等），从非核心的服务出发减少拆分对现有业务的影响，也给团队一个练习、试错的机会。同时当两个服务存在依赖关系时优先拆分被依赖的服务。

6、服务接口的定义要具备可扩展性：

​ 比如微服务的接口因为升级把之前的三个参数改成了四个，上线后导致调用方大量报错，推荐做法服务接口的参数类型最好是封装类，这样如果增加参数就不必变更接口的签名。

7、避免环形依赖与双向依赖：

​ 尽量不要有服务之间的环形依赖或双向依赖，原因是存在这种情况说明我们的功能边界没有化分清楚或者有通用的功能没有下沉下来。

8、阶段性合并：

​ 随着你对业务领域理解的逐渐深入或者业务本身逻辑发生了比较大的变化，亦或者之前的拆分没有考虑的很清楚，导致拆分后的服务边界变得越来越混乱，这时就要重新梳理领域边界，不断纠正拆分的合理性。

9、自动化驱动：

​ 部署和运维的成本会随着服务的增多呈指数级增长，每个服务都需要部署、监控、日志分析等运维工作，成本会显著提升。因此，在服务划分之前，应该首先构建自动化的工具及环境。开发人员应该以自动化为驱动力，简化服务在创建、开发、测试、部署、运维上的重复性工作，通过工具实现更可靠的操作，避免微服务数量增多带来的开发、管理复杂度问题。

前期设计阶段：3个人负责一个微服务较好。

后期维护阶段：每个微服务有两个人负责维护，每个人可以维护多个微服务。

功能维度拆分策略

基于业务复杂度拆分服务：

​ 业务复杂度足够高，应该基于领域驱动拆分服务。业务复杂度较低，选择基于数据驱动拆分服务

基于数据驱动拆分服务：

​ 自下而上的架构设计方法，通过分析需求，确定整体数据结构，根据表之间的关系拆分服务。

拆分步骤：

​ 1、需求分析，抽象数据结构，
​ 2、划分服务，确定调用关系和业务流程验证。

基于领域驱动拆分服务：

​ 自上而下的架构设计方法，通过和领域专家建立统一的语言，不断交流，确定关键业务场景，逐步确定边界上下文。领域驱动更强调业务实现效果，认为自下而上的设计可能会导致技术人员不能更好地理解业务方向，进而偏离业务目标。

拆分步骤：

​ 1、通过模型和领域专家建立统一语言；
​ 2、业务分析，寻找聚合，确定服务调用关系
​ 3、业务流程验证和持续

基于现有系统的拆分：

拆分步骤：

​ 前后端分离，提取公共基础服务（如单点登录），不断从老系统抽取服务，垂直划分优先，适当水平切分。

非功能维度拆分策略

扩展性、复用性、高性能、高可用、安全性、异构性

扩展性

​ 区分系统中变与不变的部分，不变的部分一般是成熟的、通用的服务功能，变的部分一般是改动比较多、满足业务迭代扩展性需要的功能，我们可以将不变的部分拆分出来，作为共用的服务，将变的部分独立出来满足个性化扩展需要。同时根据二八原则，系统中经常变动的部分大约只占 20%，而剩下的 80% 基本不变或极少变化，这样的拆分也解决了发布频率过多而影响成熟服务稳定性的问题。

复用性

​ 不同的业务里或服务里经常会出现重复的功能，比如每个服务都有鉴权、限流、安全及日志监控等功能，可以将这些通过的功能拆分出来形成独立的服务，也就是微服务里面的 API 网关。

高性能

​ 将性能要求高或者性能压力大的模块拆分出来，避免性能压力大的服务影响其它服务。常见的拆分方式和具体的性能瓶颈有关，例如电商的抢购，性能压力最大的是入口的排队功能，可以将排队功能独立为一个服务。我们也可以基于读写分离来拆分，比如电商的商品信息，在 App 端主要是商详有大量的读取操作，但是写入端商家中心访问量确很少。因此可以对流量较大或较为核心的服务做读写分离，拆分为两个服务发布，一个负责读，另外一个负责写。数据一致性是另一个基于性能维度拆分需要考虑的点，对于强一致的数据，属于强耦合，尽量放在同一个服务中（但是有时会因为各种原因需要进行拆分，那就需要有响应的机制进行保证），弱一致性通常可以拆分为不同的服务。

高可用

​ 将可靠性要求高的核心服务和可靠性要求低的非核心服务拆分开来，然后重点保证核心服务的高可用。具体拆分的时候，核心服务可以是一个也可以是多个，只要最终的服务数量满足“三个火枪手”的原则就可以。

安全性

​ 不同的服务可能对信息安全有不同的要求，因此把需要高度安全的服务拆分出来，进行区别部署，比如设置特定的 DMZ
区域对服务进行分区部署，可以更有针对性地满足信息安全的要求，也可以降低对防火墙等安全设备吞吐量、并发性等方面的要求，降低成本，提高效率。

异构性

​ 对于对开发语言种类有要求的业务场景，可以用不同的语言将其功能独立出来实现一个独立服务。