探索云世界
写回答
这是最粗犷的玩法，所有基础数据，都通过一个统一的服务来进行访问。
在业务不是特别复杂的时候，这不失为一个快速分层的方案，一旦业务变得复杂，服务层会变得非常重，成为耦合焦点。
以微信场景为例，假设通过一个通用的服务层来访问基础数据。
则只有一个统一的服务层，用户信息，好友信息，群组信息，消息信息都通过这个服务层来访问。
实践二：一个子业务一个服务
如果所有的数据访问都通过一个服务层来访问，那么一行代码出故障，就将影响整个服务，所以更合理的做法是在服务层进行拆分。
服务层架构如何细分？
垂直拆分是个好的方案，将子业务分拆，那么微信的服务化架构或许会变成下面的样子：
用户相关的子业务，访问user服务
好友相关的子业务，访问friend服务
群组相关的子业务，访问group服务
消息相关的子业务，访问msg服务
这样的话，一个服务出问题也不会影响其他服务，与此同时，数据层也按照业务垂直拆分开了。 服务粒度变细之后，出现一个新的问题，业务与服务的连接关系变复杂了，有什么好的优化方案么？
常见的，加入一个高可用服务分发层（Service Mesh不就是这么干的么），并在协议设计时加入服务号，可以减少蜘蛛网状的依赖关系：
调用方依赖分发层，传入服务号 分发层依赖服务层，通过服务号参数分发
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
