服务拆分理论和原理及方法

                                   服务拆分理论和原理及方法

谈到微服务，议论的最多，吵架的最多的就是服务拆分问题，服务拆分是否合理直接影响到微服务架构的复杂性、稳定性以及可扩展性。然而并没有任何一本书籍或者规范来介绍如何拆分服务，那么如何正确的做服务的拆分? 目前各家做法也都是根据架构师经验以及业务形态和用户规模等因素综合考虑。在工作中曾经遇到以下二种服务拆分的模式：

一个方法一个服务：视业务规模和业务场景而定；

基于代码行数的划分：简单粗暴，不推荐；

有人说按方法拆分服务太过于细致，应该要按业务功能来拆。其实当业务达到一定规模的时候，按方法拆分是一种非常有效的做法，以用户服务举例，在初始阶段的时候，用户服务具备了用户的增删改查功能，当用户规模上升之后需要对增删改查功能做优先级划分。大家都知道在互联网中流量获客是最贵的，运营团队通过互联网投放广告获客，用户在广告页上填写手机号码执行注册过程，如果此时注册失败或者注册过程响应时间过长，那么这个客户就可能流失了，但是广告的点击费用产生了，无形中形成了资源的浪费。所以此时需要按方法维度来拆分服务，把用户服务拆分为用户注册服务（只有注册功能），用户基础服务（修改、查询用户信息）。

在做服务拆分的时候，每个服务的团队人数规模也是非常重要的，人数过多可能会变成单体应用，沟通决策会缓慢，人数太少工作效率又会降低，一般来说会遵循 2 个披萨原则和康威定律：

2 个披萨原则：两个披萨原则最早是由亚马逊 CEO 贝索斯提出的，他认为如果两个披萨不足以喂饱一个项目团队，那么这个团队可能就显得太大了，所以一个服务的人数划分为 5-7 人比较合适。因为人数过多的项目将不利于决策的形成，而让一个小团队在一起做项目、开会讨论，则更有利于达成共识，并能够有效促进企业内部的创新。

康威定律：你想要架构成为什么样，就将团队分成怎样的结构。比如前后端分离的团队，架构就是基于前后端分离。在基于微服务设计的团队里，一个很好的理念是自管理，团队内部对于自己所负责的模块高度负责，进行端对端的开发以及运维。

整个单体应用有那么多的功能，到底哪些业务功能需要拆分，哪些业务功能又不需要拆分呢？可以遵循服务拆分的方法论：当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过 2 个或以上的其他服务或客户端提供数据，应该被拆分成一个独立的服务模，而且拆分的服务要具备高内聚低耦合。

关于服务拆分模式，使用比较多的是业务功能分解模式和数据库模式，因为容易理解而且使用起来比较简单，效果也很好。

业务功能分解模式：判断一个服务拆分的好坏，就看微服务拆分完成后是否具备服务的自治原则，如果把复杂单体应用改造成一个一个松耦合式微服务，那么按照业务功能进行分解是最简单的，只需把业务功能相似的模块聚集在一起。比如：

 

用户管理：管理用户相关的信息，例如注册、修改、注销或查询、统计等。

商品管理：管理商品的相关信息。

数据库模式：在微服务架构中，每个服务分配一套单独的数据库是非常理想方案，这样就缓解了单个数据库的压力，也不会因为某个数据库的问题而导致整个系统出现问题。

微服务初始阶段服务拆分不需要太细，等到业务发展起来后可以再根据子域方式来拆分，把独立的服务再拆分成更小的服务，最后到接口级别服务。如果服务拆分的过小会导致调用链过长，以及引发没有必要的分布式事务，此时阶段性的合并非常重要。做为架构师不仅要学会拆分服务，也需要学会合并服务，需要周期性的去把拆分过小或者拆分不合理的服务要及时合并。

总得来说，在服务拆分的时候需要抓住以下重点：

高内聚的拆分模式
以业务为模块拆分
以迭代频率和改动范围拆分
阶段性合并
定期复盘总结