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