系列文章是博主对沈剑的《架构师训练营》分享内容的个人笔记总结，原内容公众号“成为架构师”。
统一服务层
最开始，也是最简单的，仅是抽象出一个服务层，所有的服务都是在一起的，全局只有一个服务的概念，这一服务满足上游的所有调用，并对下游进行操作
子业务服务
统一的服务层不利于扩展部署和维护，按照业务的垂直拆分，进行服务划分，一个业务一个服务，下图就是表现了用户服务、朋友服务、群组服务、消息服务
上游的业务可能会调用多个服务，形成了网状关系，复杂性增大，引入网关进行统一转发可以解决这个问题
调用方通过服务号访问网关，网关通过服务号对调用进行分发
一个数据库一个服务
一个服务可能会对应多个数据库，如下图的群组服务，就是群组信息、群组成员、群组消息三个库，但由一个统一的群组服务进行访问
一个数据库一个服务就是划分为三种服务：
这在按照业务划分服务的粒度上变得更细了
一个接口一个服务
除一个数据库一个服务外，还有更细的粒度，就是按照接口来划分服务，一个接口一个服务：
群组服务包含，更新、添加、获取等接口，按照这些接口再划分为不同的服务
这一粒度太细了，细到依赖于特定的编程语言，如进程轻量级的Go
常用的最佳实践
越细的粒度服务化通常会有以下的优点：
- 易于扩容缩容、独立部署
- 耦合度小，容错性好
缺点也是显而易见的，那就是复杂：
- 系统复杂、依赖关系复杂
- 运维也更复杂
- 配套设施也更为复杂
真正投入生产实践的，是一个权衡的过程，通常，基于业务作为微服务的划分粒度是最佳实践
上一篇回顾：【成为架构师3-1】服务化：微服务架构，究竟解决什么问题
下一篇更精彩：持续更新中…