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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

频繁的代码拷贝。

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

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

数据库耦合。

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

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

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

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

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

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

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

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

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

  • 发表于:
  • 原文链接http://kuaibao.qq.com/s/20180315B1AGV700?refer=cp_1026
  • 腾讯「腾讯云开发者社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。
  • 如有侵权,请联系 cloudcommunity@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券