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

分手后的思念是犯贱 2022-03-15 06:42 166阅读 0赞

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

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

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

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

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

**实践一：统一服务层---传统的、非分布式服务方案**

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

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

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

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

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

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

**服务层架构如何细分？**

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWhhbzExODY_size_16_color_FFFFFF_t_70 2][]

*  用户相关的子业务，访问user服务
 *  好友相关的子业务，访问friend服务
 *  群组相关的子业务，访问group服务
 *  消息相关的子业务，访问msg服务

这样的话，**一个服务出问题也不会影响其他服务，与此同时，数据层也按照业务垂直拆分开了**。

服务粒度变细之后，出现一个新的问题，业务与服务的连接关系变复杂了，有什么好的优化方案么？

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

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

**实践三：一个数据库对应一个服务**

数据访问服务最初是从DAO/ORM的数据访问需求过来的，所以有些公司也有一个数据库一个服务的玩法。

一个子业务对应一个服务的玩法如下图：

![20190302144702332.png][]

*  服务层，整个群业务是一个服务
 *  存储层，实际可能对应了群信息、群成员、群消息等多个数据表

拆分成一个数据库一个服务，则架构会变成下面的样子：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWhhbzExODY_size_16_color_FFFFFF_t_70 4][]  
群信息库，群成员库，群消息库之间也解耦开，不会相互影响。

**实践四，一个接口对应一个服务**

微服务架构中，更极端的，甚至一个接口对应一个微服务。

这样的话，架构就从：

![640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1_wx_co_1][]  
进化为：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWhhbzExODY_size_16_color_FFFFFF_t_70 5][]

*  修改群信息服务
 *  增加群信息服务
 *  获取群信息服务

多个服务操纵同一个数据库，任何接口服务出问题，都不会影响其他接口服务。使用这种方案的，一般与开发语言特性结合比较紧密，例如golang。

**上文中谈到的服务化与微服务，不同粒度的服务化各有什么优劣呢？**

总的来说，细粒度拆分的优点有：

*  服务都能够独立部署
 *  扩容和缩容方便，有利于提高资源利用率
 *  拆得越细，耦合相对会减小
 *  拆得越细，容错相对会更好，一个服务出问题不影响其他服务
 *  扩展性更好

细粒度拆分的不足也很明显：

*  拆得越细，系统越复杂
 *  系统之间的依赖关系也更复杂
 *  运维复杂度提升
 *  监控更加复杂
 *  出问题时定位问题更难

互联公司，以“子业务”作为微服务粒度是最常用，订单服务，用户服务，支付服务等等。

[Link 1]: http://mp.weixin.qq.com/s?__biz=MjM5ODYxMDA5OQ==&mid=2651961720&idx=1&sn=94d1e2b253b715368e6424ec37cd3a1a&chksm=bd2d0ca48a5a85b21d9e7a7e54d69734d8d845ed085393246f2732f9154a145b8a71b6feecac&scene=21#wechat_redirect
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWhhbzExODY_size_16_color_FFFFFF_t_70]: /images/20220315/b07bed73100e425493b2263c96b920f6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWhhbzExODY_size_16_color_FFFFFF_t_70 1]: /images/20220315/02b18bc530bb4b9e9944987afbac1366.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWhhbzExODY_size_16_color_FFFFFF_t_70 2]: /images/20220315/db2d0fb595f1450692144a1d8e1cfe59.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWhhbzExODY_size_16_color_FFFFFF_t_70 3]: /images/20220315/b0bd8dc6c1624f5c90f3b076df295959.png
[20190302144702332.png]: /images/20220315/377c10c18d4a4d34b38c3a8d90b943f8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWhhbzExODY_size_16_color_FFFFFF_t_70 4]: /images/20220315/8cc65b796a4049bba9b7c06b4d6b5fdd.png
[640_wx_fmt_png_tp_webp_wxfrom_5_wx_lazy_1_wx_co_1]: /images/20220315/4effa92856dd4d2c85f234e5217d8837.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ppYWhhbzExODY_size_16_color_FFFFFF_t_70 5]: /images/20220315/fc1787b417ea486c8c978600fbaa5ddd.png