|
|
51CTO旗下网站
|
|
移动端

微服务架构,多“微”才合适?

“服务化”是一个很好的解决上述痛点的方案。那么问题来了,微服务架构多“微”才合适?行业内有这样四类常见实践。

作者:程序员界的彭于晏来源:今日头条|2020-05-28 22:41

 

随着数据量、并发量、业务复杂度的增长,互联网架构会出现以下问题:

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

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

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

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

实践一:统一服务层

「转」微服务架构,多“微”才合适?

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

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

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

「转」微服务架构,多“微”才合适?

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

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

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

服务层架构如何细分?

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

「转」微服务架构,多“微”才合适?
  • 用户相关的子业务,访问user服务
  • 好友相关的子业务,访问friend服务
  • 群组相关的子业务,访问group服务
  • 消息相关的子业务,访问msg服务

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

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

「转」微服务架构,多“微”才合适?

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

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

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

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

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

「转」微服务架构,多“微”才合适?
  • 服务层,整个群业务是一个服务
  • 存储层,实际可能对应了群信息、群成员、群消息等多个数据表

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

「转」微服务架构,多“微”才合适?

群信息库,群成员库,群消息库之间也解耦开,不会相互影响。

实践四,一个接口对应一个服务

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

这样的话,架构就从:

「转」微服务架构,多“微”才合适?

进化为:

「转」微服务架构,多“微”才合适?
  • 修改群信息服务
  • 增加群信息服务
  • 获取群信息服务

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

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

总的来说,细粒度拆分的优点有:

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

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

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

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

【编辑推荐】

  1. 如何提升微服务的幸福感
  2. 微服务项目搭建,到底要不要聚合工程?
  3. 微服务分布式架构中,如何实现日志链路跟踪?
  4. 企业从单体架构向微服务架构转型的 9 个难点
  5. 微软开源 Tye 项目,可简化微服务开发
【责任编辑:武晓燕 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

实操案例:Jenkins持续交付和持续部署

实操案例:Jenkins持续交付和持续部署

微服务架构下的自动化部署
共18章 | freshman411

105人订阅学习

思科交换网络安全指南

思科交换网络安全指南

安全才能无忧
共5章 | 思科小牛

87人订阅学习

云计算从入门到上瘾

云计算从入门到上瘾

传统IT工程师的转型
共26章 | 51CTO阿森

249人订阅学习

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO官微