服务如何拆分
本文内容
前言
上一篇文章中讲解了什么是微服务，微服务的演进。那么我们应该 在什么时候进行服务的拆分，如何拆分？拆分后会到来哪些问题，如何解决？这些都是微服务需要考虑的问题。
1. 什么时候应该拆分服务？
虽然现在微服务、容器化非常火爆，但并不意味着我们的每个项目都直接无脑使用微服务架构，需要根据项目实际的体量来选择。
在项目刚起步的时候，一般都是快速开发，展现产品，看看产品思路是否可行，所以架构不宜过度设计，使用常规的快速开发、迭代的方式就好。当产品的可行性得到验证后，就可以一步步增加新特性、新功能了。
比如一个社交 App，初期可以只开发首页信息流、评论等基础功能。产品上线后，用户量逐渐增多，觉得产品的可行性比较好的时候，就可以增加更多的玩法，比如附近好友、随机匹配等。
当项目的规模变大后，所需的开发人员也会随之扩张，以支持多个功能的开发。如果此时还采用单体架构，将会面临如下问题：
- 多个功能模块混合在一起开发、测试、部署，就会导致不同模块之间互相影响，降低了开发效率。
- 多个模块耦合在一起，线上服务的稳定性和可靠性都得不到很好的保证。当用户量激增时，单体架构的系统性能也跟不上。
此时就需要对单体架构进行服务拆分了，让不同小团队负责不同的功能模块，模块之间独立开发、测试、部署，大大降低了复杂度，不同的服务部署到不同的机器上，也增加了系统的性能和可靠性。
2. 如何拆分服务？
当意识到要拆分服务后，如何拆分才是真正的一大难题，因为拆分不能一概而论，需要根据实际项目的情况而定。
在业界有两种服务拆分的思路，分别是 纵向拆分（业务维度）和 横向拆分（公共独立的功能维度）。
纵向拆分（业务维度）
纵向拆分 是按照 业务的关联程度 来进行拆分：
- 关联比较紧密的业务 适合拆分为一个微服务；
- 如果 一个业务比较独立，那么可以将其单独拆分为一个微服务。
例如在上面的社交 App 中，首页信息流是一个服务、评论是一个服务、消息通知是一个服务、附近好友是一个服务......
横向拆分（公共独立的功能维度）
横向拆分 是按照 该服务是否会被多个其他服务调用，且该功能依赖的资源独立，不与其他的业务耦合，此时拆分出来的该服务就能被复用。
例如在上面的社交 App 中，位置服务就可以独立运行，不与其他业务耦合，这就是一个公共独立的服务。在附近好友、共享实时位置的服务中，都可以调用位置服务。
还有一些常见的公共微服务，例如用户的认证授权服务、图片和视频处理服务等等。
3. 微服务会带来什么问题？
从单体架构演进来微服务架构后，架构复杂度无疑肯定是增加了不少的，那么新架构会带来什么问题呢？
在微服务结构中，常见的几个问题如下：
- 服务如何定义：
- 单体架构中，不同功能模块之间通常是以类库的方式进行使用；
- 微服务架构中，服务是跨进程的，怎么定义服务给外界使用呢？答案是 接口，无论是使用 HTTP 还是 RPC，服务之间都是通过接口来描述一个服务，包括接口名、接口参数和接口返回值。
- 服务如何发布和订阅：
- 单体架构中，服务都是在进程内调用，使用一个服务直接调用方法即可；
- 微服务架构中，服务提供者如何对外暴露自己的地址，服务调用者又如何查询到服务的地址呢？答案是 注册中心，这里会记录所有服务提供者的地址，以供服务调用者查询。
- 服务如何监控：我们需要清楚的知道每一个微服务的 健康状态、性能、可用性 等，当服务出现问题时要及时报警通知。
- 服务如何治理：当服务的数量变多后，服务的依赖关系、调用链也会变得更加复杂。如果一个服务出问题，那我们要保证全局服务不会受影响，因此就需要一些服务治理的手段了，包括 服务熔断、服务降级 等。
- 故障如何跟踪：服务都部署到不同的机器上，当调用链出现问题时，就需要快速排查问题出现在哪个服务上，这就需要一个 链路跟踪系统。
当然，在具体的微服务架构中可能还会出现其他各种各样的问题，这些都是微服务拆分后需要考虑的，在有了可行的解决方案后，才能真正开始系统的微服务化。