【WOT2018】沈剑：58速运架构解耦与微服务实践

原创
作者：赵立京 2018-06-14 21:47:46

云计算 2018年5月18-19日，由51CTO主办的全球软件与运维技术峰会在北京召开。在“微服务架构设计”分会场，58到家CTO沈剑带来了《58速运微服务架构解耦最佳实践》的主题分享，会后，51CTO记者根据沈剑在WOT2018全球软件与运维技术峰会的演讲内容进行了整理。

【51CTO.com原创稿件】2018年5月18-19日，由51CTO主办的全球软件与运维技术峰会在北京召开。此次峰会围绕人工智能、大数据、物联网、区块链等12大核心热点，汇聚海内外60位一线专家，是一场高端的技术盛宴，也是***IT技术人才学习和人脉拓展不容错过的平台。

在“微服务架构设计”分会场，58到家CTO沈剑带来了《58速运微服务架构解耦***实践》的主题分享，会后，51CTO记者根据沈剑在WOT2018全球软件与运维技术峰会的演讲内容进行了整理。

【讲师简介】

58沈剑，互联网架构技术专家，“架构师之路”公众号作者。曾任百度高级工程师，58同城高级架构师，58同城技术委员会主席。15年调至58到家任高级总监，技术委员会主席，负责基础架构，技术平台，运维安全，信息系统等后端技术体系搭建。17年调至58速运任CTO，负责58速运技术体系的搭建。

业务发展需要微服务架构

58速运架构包括三层结构和三块业务，如下图所示。其中，三层结构分别是PC/H***PP等端点，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)…

总的来说，沈剑老师对服务化以及微服务粒度的看法是，以“子业务系统”粒度作为微服务的单位是比较合适的：

以上内容是51CTO记者根据58到家CTO沈剑在WOT2018全球软件与运维技术峰会的采访内容整理，更多关于WOT的内容请关注IDC.NET。

【51CTO原创稿件，合作站点转载请注明原文作者和出处为51CTO.com】