标签:alt 有一个 实践 end 也有 拆分 就是 代码 Golan
以前的文章讨论过《互联网架构,究竟为啥要做服务化?》,随着数据量、并发量、业务复杂度的增长,互联网架构会出现以下问题:那么问题来了,微服务架构多“微”才合适?
行业内有这样四类常见实践。
这是最粗犷的玩法,所有基础数据,都通过一个统一的服务来进行访问。
在业务不是特别复杂的时候,这不失为一个快速分层的方案,一旦业务变得复杂,服务层会变得非常重,成为耦合焦点。
以微信场景为例,假设通过一个通用的服务层来访问基础数据。
则只有一个统一的服务层,用户信息,好友信息,群组信息,消息信息都通过这个服务层来访问。
如果所有的数据访问都通过一个服务层来访问,那么一行代码出故障,就将影响整个服务,所以更合理的做法是在服务层进行拆分。
服务层架构如何细分?
垂直拆分是个好的方案,将子业务分拆,那么微信的服务化架构或许会变成下面的样子:
服务粒度变细之后,出现一个新的问题,业务与服务的连接关系变复杂了,有什么好的优化方案么?
常见的,加入一个高可用服务分发层(Service Mesh不就是这么干的么),并在协议设计时加入服务号,可以减少蜘蛛网状的依赖关系:
数据访问服务最初是从DAO/ORM的数据访问需求过来的,所以有些公司也有一个数据库一个服务的玩法。
一个子业务对应一个服务的玩法如下图:
拆分成一个数据库一个服务,则架构会变成下面的样子:
群信息库,群成员库,群消息库之间也解耦开,不会相互影响。
微服务架构中,更极端的,甚至一个接口对应一个微服务。
这样的话,架构就从:
进化为:
总的来说,细粒度拆分的优点有:
细粒度拆分的不足也很明显:
互联公司,以“子业务”作为微服务粒度是最常用,订单服务,用户服务,支付服务等等。
架构师之路-分享技术思路
推荐阅读:
《“缓存架构,一篇搞定”-年终总结(五)》
《“技术人如何带团队”-年终总结(六)》
《“MySQL必知必会”-年终总结(七)》
《“算法与数据结构”-年终总结(八)》
《过完年跳槽,要考虑哪些要素?》
你们公司有订单服务,用户服务,支付服务么?
标签:alt 有一个 实践 end 也有 拆分 就是 代码 Golan
原文地址:https://blog.51cto.com/jyjstack/2548846