上篇说到了整体架构的模型。
API网关+BFF数据组装+服务层
那么服务层如何划分呢？
按什么划分
比如客户部门、物流部门、财务部门这样。但是这样划分的很少。
还有一种按业务分：
不同的服务解决不同业务问题。
比如稿件组、视频组、漫画组、评论组、弹幕组。
一般一个服务稳定了就可以交给底下的人维护了，主力就继续开发下一个服务。
分多细
细的好处：
- （1）服务都能够独立部署
- （2）扩容和缩容方便，有利于提高资源利用率
- （3）拆得越细，耦合相对会减小
- （4）拆得越细，容错相对会更好，一个服务出问题不影响其他服务
- （5）扩展性更好
细的坏处：
- （1）拆得越细，系统越复杂
- （2）系统之间的依赖关系也更复杂
- （3）运维复杂度提升
- （4）监控更加复杂
- （5）出问题时定位问题更难
微的粒度还关乎着库的分离。
我的建议是：
一步步来
其实架构真的是分久必合、合久必分。
- 当你觉得两个代码没有什么业务耦合的时候，就可以分离了。
- 当你觉得一个数据要调用多个服务的，就要合并了。
举例：
- 账号服务，开始是一个服务，只有昵称、头像、性别等。
- 后面加入了VIP、装备系统、背包等等。
- 于是把这些都拆成了一个个服务，毕竟是没有耦合关系的。
- 后来发现取一个用户的数据，需要调用七八个子服务，好麻烦，代码合并又很难受。
怎么办？
架构就是一层加一层。
在加个账号BFF层，用来组装数据，需要账号所有信息的就调用它就好了。
对外聚合，对内拆分。
总结
架构是慢慢演进出来的，要根据业务和实际环境来选择架构和演进架构。
持续迭代，持续重构。
