微服务架构，多“微”才合适？

以前的文章讨论过《互联网架构，究竟为啥要做服务化？》，随着数据量、并发量、业务复杂度的增长，互联网架构会出现以下问题：

• 代码到处拷贝
• 底层复杂性扩散
• 基础库（so/jar/dll）耦合
• SQL质量得不到保障，业务相互影响
• 数据库耦合

“服务化”是一个很好的解决上述痛点的方案。

那么问题来了，微服务架构多“微”才合适？

行业内有这样四类常见实践。

实践一：统一服务层

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

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

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

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

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

如果所有的数据访问都通过一个服务层来访问，那么一行代码