上篇文章讨论《互联网架构，究竟为啥要做服务化?》，随着数据量、并发、业务复杂度的增加，互联网架构会出现以下问题：代码到处拷贝底层复杂扩散基础库（so/jar/dll)耦合SQL的质量无法保证，业务交互和数据库耦合“服务”很好地解决了上述痛点。那么问题来了，微服务架构到底有多“微”才合适呢？业内有四种常见做法。做法一：统一服务层这是最粗暴的玩法。所有基础数??据都通过统一的服务访问。当业务不是特别复杂的时候，这是一种快速的分层方案。一旦业务变得复杂，服务层就会变得很重，成为耦合的重点。以微信场景为例，假设基础数据通过公共服务层接入。那么只有一个统一的服务层，用户信息、好友信息、群组信息、消息信息都是通过这个服务层来访问的。做法二：一个子业务一个服务如果所有的数据访问都是通过一个服务层来访问，那么一行代码失败就会影响到整个服务，所以在服务层进行拆分比较合理。如何细分服务层架构？垂直拆分是一个很好的解决方案。如果拆分子业务，微信的服务化架构可能是这样的：用户相关的子业务，访问用户-服务好友相关的子业务，访问好友服务群相关的子服务，访问群服务消息相关的子服务，访问msg服务。这样，一个服务出现问题就不会影响到其他服务。同时，数据层也按照业务垂直拆分。.服务粒度变细后，新的问题又出现了。业务与服务的连接关系变得更加复杂。有什么好的优化方案吗？常见的是加一个高可用的服务分布层（ServiceMesh不就是这么干的吗），在协议设计中加入服务号，可以减少蜘蛛网依赖：调用者依赖分布层，传入的服务号分配层依赖于服务层，服务号参数分配做法三：一个数据库对应一个服务数据访问服务原本来自于DAO/ORM的数据访问需求，所以有些公司也有一个数据库-一个-服务方式。一个服务对应一个子业务的玩法如下：服务层，整个群业务是一个服务存储层，实际上可能对应多个数据表，如群信息、群成员、群消息等。变成一个数据库和一个服务，那么架构会是这样的：群信息库、群成员库、群消息库也是解耦的，不会互相影响。实践4、一个接口对应一个服务在微服务架构中，更极端一点，一个接口对应一个微服务。在这种情况下，架构演变为：修改群组信息服务添加群组信息服务获取群组信息服务多个服务操作同一个数据库，任何接口服务故障不会影响其他接口服务。使用这种方案的一般都是跟开发语言特性紧密结合的，比如golang。上面提到的服务化和微服务的优缺点是什么？总的来说，细粒度拆分的优点是：服务可以独立部署进行扩容和缩容，有利于提高资源利用率越细，耦合越小。拆分得越细，容错性就越好。一项服务出现问题不会影响其他服务。可扩展性更好。细粒度拆分的缺点也很明显：，系统越复杂，系统之间的依赖关系越复杂，运维复杂度越高，监控越复杂，定位越难有问题时的问题。互联网公司以“分业务”为微服务粒度是最常用的，订单服务、用户服务、支付服务等等。【本文为专栏作者《58神剑》原创稿件，转载请联系原作者】点此阅读更多该作者好文
