一个子业务对应一个service的玩法是：
(1)服务层，整个群业务是一个service
(2)存储层，实际可能对应了群信息、群成员、群消息等多个数据表
拆分成一个数据表一个service，则架构会变成这样：
群信息表，群成员表，群消息表等各个数据表之间也解耦开了，不会相互影响了。
【一个接口对应一个service】
微服务架构中更极端的，甚至一个接口对应一个微服务，这样的话，架构就从：
演化为：
(1)修改群信息服务
(2)增加群信息服务
(3)获取群信息服务
多个服务操纵同一个数据表，使用同一片缓存，每个接口出问题，都不会影响其他接口。
三、粒度粗细的优劣
上文中谈到的服务化与微服务，不同粒度的服务化各有什么优劣呢?
总的来说，细粒度拆分的优点有：
(1)服务都能够独立部署
(2)扩容和缩容方便，有利于提高资源利用率
(3)拆得越细，耦合相对会减小
(4)拆得越细，容错相对会更好，一个服务出问题不影响其他服务
(5)扩展性更好
(6)…
细粒度拆分的不足也很明显：
(1)拆得越细，系统越复杂
(2)系统之间的依赖关系也更复杂
(3)运维复杂度提升
(4)监控更加复杂
(5)出问题时定位问题更难
(6)…
关于微服务架构的“粒度”问题，以及各粒度的优劣，大伙有什么好的看法，欢迎补充，建设性的意见将在后续文中和大伙share。
四、结束的话
聊了许多，有网友问，笔者对待服务化以及微服务粒度的看法，个人觉得，以“子业务系统”粒度作为微服务的单位是比较合适的：
末了，讨论完微服务架构的粒度，后续文章和大家聊一聊微服务的最佳实践，需要什么样的框架、组件、技术能够将服务化在较短的时间内开展起来，下面和大伙再聊。