微服务多“微”才合适？

这是最粗犷的玩法，所有基础数据，都通过一个统一的服务来进行访问。

在业务不是特别复杂的时候，这不失为一个快速分层的方案，一旦业务变得复杂，服务层会变得非常重，成为耦合焦点。

以微信场景为例，假设通过一个通用的服务层来访问基础数据。

则只有一个统一的服务层，用户信息，好友信息，群组信息，消息信息都通过这个服务层来访问。

实践二：一个子业务一个服务

如果所有的数据访问都通过一个服务层来访问，那么一行代码出故障，就将影响整个服务，所以更合理的做法是在服务层进行拆分。

服务层架构如何细分？

垂直拆分是个好的方案，将子业务分拆，那么微信的服务化架构或许会变成下面的样子：

用户相关的子业务，访问user服务
好友相关的子业务，访问friend服务
群组相关的子业务，访问group服务
消息相关的子业务，访问msg服务
这样的话，一个服务出问题也不会影响其他服务，与此同时，数据层也按照业务垂直拆分开了。 服务粒度变细之后，出现一个新的问题，业务与服务的连接关系变复杂了，有什么好的优化方案么？

常见的，加入一个高可用服务分发层（Service Mesh不就是这么干的么），并在协议设计时加入服务号，可以减少蜘蛛网状的依赖关系：

调用方依赖分发层，传入服务号 分发层依赖服务层，通过服务号参数分发