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