您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Model Center   Code  
会员   
   
 
     
   
 订阅
  捐助
58速运架构解耦与微服务实践
 
   次浏览      
 2018-8-16 
 
编辑推荐:
本文来自于51cto,介绍了业务发展需要微服务架构,详解的微服务架构等。

业务发展需要微服务架构

58速运架构包括三层结构和三块业务,如下图所示。其中,三层结构分别是PC/H5/APP等端点,web站点应用,数据存储。三块业务分别是to C,to 2小B,to大B。

58速运架构

架构诞生了,耦合也随之而来。耦合,是架构中,本来不相干的代码、模块、服务、系统因为某些原因联系在一起,各自独立性差,影响则相互影响,变动则相互变动的一种架构状态。业务是一块一块发展起来的,而代码不是一行一行写出来的,重复代码的耦合就出现了。随着业务的增长,数据量越来越大,复杂性扩散的耦合导致了被迫联动升级。此外还有数据库耦合、服务耦合等等,如何消除?微服务是一种潜在的解决方案。

详解微服务架构

在服务化之前,互联网的高可用架构大致是这样一个架构:

(1)用户端是浏览器或APP客户端。

(2)后端入口是高可用的nginx集群,用于做反向代理。

(3)中间核心是高可用的web-server集群,研发工程师主要编码工作就是在这一层。

(4)后端存储是高可用的db集群,数据存储在这一层。

更典型的,web-server层是通过DAO/ORM等技术来访问数据库。

由此可以看到,最初的架构没有服务层,此时会出现以下痛点:代码到处拷贝;复杂性扩散;库的复用与耦合;SQL质量得不到保障,业务相互影响;疯狂的DB耦合等等。

为了解决上面的诸多问题,互联网高可用分层架构演进的过程中,引入了“服务层”。

引入服务层的好处主要有调用方便;高度复用性,防止代码拷贝;专注性屏蔽了底层复杂度;SQL质量得到了保障;数据库很方便的解耦;提供有限接口,拥有无限性能等。

“微”到什么程度才合适?

随着数据量、流量、业务复杂度的提升,微服务化架构是架构演进中的必由之路,那么,微服务架构多“微”才合适?

【粗粒度:一个服务层】

最粗犷的玩法,所有基础数据的访问,都通过一个service访问,在业务不是特别复杂的时候还好,一旦业务变复杂了,这个service层会变得非常重,成为耦合点之一,以微信场景为例,假设有一个通用的服务层来访问基础数据,这个服务层可能是这样的:

有一个统一的service层,用户信息,好友信息,群组信息,消息信息都通过这个service层来走。

细节:微信单对单消息是一个写多读少的业务,故没有缓存。

【一个子业务一个service】

如果所有的信息存储都在一个service里,那么一个地方出bug,就将影响整个业务,所以更合理的做法是在服务层进行细分,架构如何细分?垂直拆分是个好的方案,将子业务一个个拆出来,那么微信的服务化架构或许会变成这个样子:

(1)用户相关的子业务有user-service

(2)好友相关的子业务有friend-service

(3)群组相关的子业务有group-service

(4)消息相关的子业务有msg-service

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

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

常见的,加入一个高可用服务分发层集群,并在协议设计时加入服务号,可以减少蜘蛛网状的依赖关系:

(1)调用方依赖分发层,传入服务号

(2)分发层依赖服务层,通过服务号参数分发

【一个数据库对应一个service】

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

一个子业务对应一个service的玩法是:

(1)服务层,整个群业务是一个service

(2)存储层,实际可能对应了群信息、群成员、群消息等多个数据表

拆分成一个数据表一个service,则架构会变成这样:

群信息表,群成员表,群消息表等各个数据表之间也解耦开了,不会相互影响了。

【一个接口对应一个service】

微服务架构中更极端的,甚至一个接口对应一个微服务,这样的话,架构就从:

演化为:

(1)修改群信息服务

(2)增加群信息服务

(3)获取群信息服务

多个服务操纵同一个数据表,使用同一片缓存,每个接口出问题,都不会影响其他接口。

粒度粗细的优劣

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

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

(1)服务都能够独立部署

(2)扩容和缩容方便,有利于提高资源利用率

(3)拆得越细,耦合相对会减小

(4)拆得越细,容错相对会更好,一个服务出问题不影响其他服务

(5)扩展性更好

(6)…

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

(1)拆得越细,系统越复杂

(2)系统之间的依赖关系也更复杂

(3)运维复杂度提升

(4)监控更加复杂

(5)出问题时定位问题更难

(6)…

总的来说,服务化以及微服务粒度的看法是,以“子业务系统”粒度作为微服务的单位是比较合适的:

   
次浏览       
相关文章

企业架构、TOGAF与ArchiMate概览
架构师之路-如何做好业务建模?
大型网站电商网站架构案例和技术架构的示例
完整的Archimate视点指南(包括示例)
相关文档

数据中台技术架构方法论与实践
适用ArchiMate、EA 和 iSpace进行企业架构建模
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

云平台与微服务架构设计
中台战略、中台建设与数字商业
亿级用户高并发、高可用系统架构
高可用分布式架构设计与实践