WOT2018沈剑：从58速运看微服务架构的最佳实践

“

作为技术人，一定要理解透彻一个技术方案到底解决的是什么问题，适用场景是什么，如果一味追求最新的技术，对业务的发展只会是损害。

七年一剑，华丽蜕变。自 2012 年起连续 6 年 15 场峰会，凝聚大量技术专家，博观而约取，厚积而薄发。

WOT2018 全球软件与运维技术峰会将于 2018 年 5 月 18-19 日在北京粤财 JW 万豪酒店召开，围绕 12 大核心热点，汇聚海内外 60 位一线专家，打造高端技术盛宴！是顶级 IT 技术人才学习和人脉拓展不容错过的平台。

近日，51CTO 记者对即将参加大会演讲的 58 速运 CTO 沈剑进行了专访，让我们先睹为快，探听他在微服务架构解耦方面的心得。

有利有弊，揭开微服务的真面目

近年来，微服务已经成了一个热门词汇，获得了越来越多的关注。

微服务固然有很多优点：通过分解巨大单体式应用为多个服务方法解决了复杂性问题；使每个服务都有专门开发团队来开发；独立部署；易扩展。

但微服务也不是任何业务都适用。“任何脱离业务的架构设计都是耍流氓”，沈剑老师一针见血。“如果不了解微服务解决的问题领域，不了解微服务的优缺点，带来的坑可能会高于带来的收益。”

微服务分层拆分后，能够使系统变得清晰，服务职能更加明确，并且可以向服务调用方屏蔽底层的复杂性，消除代码拷贝，提高系统整体稳定性及质量。

但是，微服务架构会使请求调用路径变长，请求耗时也会增加，系统的复杂性和运维的复杂度都会上升，定位问题的难度和周期都会加长。

所以，只有当业务和系统复杂到一定程度，数据量大到一定程度，并发量逐步上升时，使用微服务架构才更为合适。

曾经困扰58速运架构的那些痛处

沈剑老师以 58 速运为例，深入解释了微服务架构的适用场景。

58 速运在使用微服务架构之前，系统存在诸多痛点，例如：

频繁的代码拷贝。

组件库的版本兼容与耦合。

所有调用方都要关注底层系统的复杂度，例如：存储引擎，分库分表，缓存等细节，使研发效率降低。

数据库耦合。

SQL 质量底下，数据库性能降低。

微服务架构的实施，大大缓解了上述痛点。

微服务不可避免的问题：耦合

微服务架构虽好，但是如果实施不当，很可能引发系统之间的耦合。耦合，是架构中本来不相干的代码、模块、服务、系统因为某些原因联系在一起，各自独立性差，导致相互影响。如：IP 耦合、数据库耦合、服务耦合等。

当系统之间出现了耦合，就需要通过一系列的手段消除耦合。

沈剑老师简单例举了几种方式：

服务之间通过 IP 耦合在一起，可以通过配置中心解除耦合。

数据库之间耦合，可以通过数据库拆分，在数据库上游建立数据访问服务来解除耦合。

有些服务间的耦合，可以通过异步消息来解除耦合。