有赞服务化架构演进

服务化是互联网公司成长的必经之路。随着微服务的兴起,很多公司如火如荼的搞起了自己的服务化,有兴奋有无奈。那服务化该怎么做,该做什么?本文试图从有赞的发展历程来体会服务化发展。

有赞史

有赞成立于2012年11月,成立初期以社群电商产品为核心,2015年实现商业化,快速发展为一家2000+人的2B Saas服务公司,以电商平台(微商城)和新零售(有赞零售、有赞美业、有赞餐饮)为主要发展方向。技术总是随着业务的繁荣不断演进,从一个差点死掉的初创公司到如今创造的电商+新零售生态,有赞经历了从单体应用到服务化较为成熟演进过程。

从时间跨度上我们可以将其发展大致分为四个阶段:单体应用时期(2013-2015)、服务化初期(2015-2016)、服务化发展(2016-2017),服务化成熟(2017-至今)。

公司创立初期,选择PHP作为核心开发语言,因为其开发速度快,试错成本低。这也是很多创业团队的选择。一旦业务成型,用户体量变大,开发团队扩张,围绕PHP开发的问题便逐渐暴露,如项目过于庞大、难以维护,发布影响面大、开发效率低等问题。

为了解决这些问题,2015年公司开始进行服务化拆分,首先是纵向拆分,将核心的功能从iron(核心的PHP应用)里面拆出来,如用户中心、店铺中心、商品中心等,服务化应用采用java开发。服务拆分后,首先需要解决的便是服务间调用问题,随着新技术语言的引入,以及有赞云业务的发展,跨语言调用的问题也日益突出。如何解决服务化的这些问题呢?下面详细分析有赞的服务化之路。

单体应用时代

为什么开始不把业务拆分好呢?可能有人会有这样的疑惑。就企业而言,追求的是快速底成本验证产品想法并占领市场,进行低成本试错;就开发而言,业务的发展是未知的,过度设计的架构可能会适得其反。有赞从一开始的月饼、代付、送礼等社交营销玩法做到Saas级电商平台,这一路的发展有不少心酸。

在早期,公司的系统架构图如下图所示,核心展示层、业务层都在强耦合在iron应用之中。谈到iron,不知曾让多少有赞人泪崩。“代码又冲突了!?”,“发布又翻车了!”,“服务又回滚!?”。没错,这就是iron。

iron是有赞的核心PHP应用,最初几乎承载着所有的核心业务。目前iron在gitlib上已经有18G+之大,当有一批新同事进来时,如果有多人全量clone(不指定depth)很容易导致gitlib服务器宕机,因此目前clone iron必须指定depth。

为什么iron发展到这么大?为什么不早点拆分呢?主要是因为有赞初期的业务快速发展导致。在拆分老应用时,要保证新功能的快速迭代,对于一个高速发展的创业型公司,在那个历史阶段没有足够的资源与时间去迁移。所以iron的庞大似乎有着历史的必然性。

随着业务的快速增长和研发团队的不断扩张,单体应用的弊端不断暴露出来。如团队协作成本增加,开发、测试、部署不同模块相互耦合,导致系统稳定性下降等。在此背景下,服务化拆分,箭在弦上。

服务化初期

Iron拆分

2015年7月,公司决心启动了“乾坤大挪移”项目。核心目标是便是拆分iron,将核心业务从PHP向Java迁移,并逐步建立完善的服务治理体系,迈向了服务化的第一步。

“乾坤大挪移”项目的启动,标志着有赞正式进入服务化阶段。服务化拆分第一个要解决的就是服务调用的问题,且一开始就遇到了跨语言调用的问题。最初的服务化调用方案如下,Java服务之间调用采用Dubbo协议,PHP与Java服务之间调用采用http协议。然而在该模式下存在不少问题,如Java服务开发者需要维护两套不同的接口,增加了额外的工作量,并不友好;PHP无法支持长链接,会有大量的时间耗费在建立链接上,并且大量的短链接对于后端服务来说也是很大的负担。

服务化初期.jpg

服务化发展

Nova兴衰

随着服务的拆分,公司需要一套跨语言调用的解决方案,于是Nova兴起。Nova是基于thrift协议而制定的有赞RPC协议。通过这个协议,解决公司跨语言交互的问题,从而形成公司的Nova框架。从狭义来讲,Nova是一种私有的通信协议;从广义来讲是有赞SOA架构。对Dubbo、Zan-PHP进行扩展,支持新的Nova协议。

nova.png

Nova似乎解决了跨语言的问题,但却存很多痛点:

第一,需要生成Thrift IDL,过程繁琐,可读性差,开发接受度不高;

第二,入侵性强,扩展性差,须深度定制;

第三,维护成本高,需要专门的团队保障;

除此之外,还有一个原因是公司Java服务化的发展使Java成为核心开发语言(Java开发人员相对来说,在市场上是最好招的)。使用Nova有一定的接入和学习成本,且开发人员水平不一,在Java盛行的时期,Nova逐渐变得累赘。

由于这些痛点,导致Nova的好景不长,一直被开发人员诟病,全面推动困难。因此在这个时期,出现了Dubbo和Nova协议共存的状态,Java内部采用Dubbo协议,跨语言采用Nova协议。回头来看,Nova似乎成为了历史性的过渡协议。

Tether萌芽

由于公司最初是已PHP为核心开发,业务系统还存在不少PHP应用,而PHP的多进程运行方式会带来许多问题。比如无法支持长链接,会有大量的时间耗费在建立链接上,解决后端服务频繁建立链接带来的损耗,并且大量的短链接对于后端服务来说也是很大的负担。未了解决这一问题,公司开始研发Tether。Tether主要实现了以下几大特性:

1.支持以长链接方式进行信令透传;

2.支持负载均衡,如轮询策略;

3.支持服务发现,与name_service对接;

4.支持多协议解析(nova、http等);

Tether作为PHP的长链接解决方案,独立部署在服务器上,与应用解耦,由运维统一部署管理,为后续的Sidecar发展奠定了基础。

服务化成熟

Sidecar

随着应用拆分的不断推进,有赞已从原来的PHP开发模式,形成了Node.js + Java的开发模式,逐步去Zan-PHP框架。并且随着电商云业务的发展,越来越多其他语言的需要接入,此过程需要解决的核心问题是:Node.js等其他语言如何调用Java服务?

有赞之前的跨语言使用的是Nova协议。然而在Nova一直遭诟病的背景下,如何更友好的解决这一问题呢?首先对比一下Nova协议与Dubbo协议:

Dubbo | Nova | | --- | --- | --- | | 开发语言 | Java | 跨语言 | | 序列化 | hessian | thrift RPC调用协议二次封装 | | 友好度 | 不需要IDL,更自然 | 需要IDL,接受度低 |

既然大家都习惯使用Dubbo,能不能在Dubbo的基础上实现跨语言交互呢?

答案是可以的。为了建立更友好的跨语言服务化方案,Tether再次升级。实现了对Dubbo原生协议的解析与转换,支持通过Http协议调用Dubbo服务。这次协议转化的能力升级,也意味着Tether正式成为Sidecar组件。

新协议设计

这种兼容性协议转换似乎解决了跨语言服务调用的问题,然而真正的跨语言需要有灵活高效的通用协议基础。最近Dubbo官方也一直在推动跨语言进程。其核心的难点便是协议。Dubbo协议是私有的,其服务接口都是通过Java Interface描述,其涉及的传输模型DTO也是Java POJO定义,要想成为跨语言的协议标准有一定难度。并且由于Dubbo的Attachment字段在尾部,Sidecar很难解析处理。而Sidecar形态需要面向多语言,协议问题首当其冲。通过Dubbo真正实现跨语言,新协议的设计是未来的关键。

dubbo协议.png

有赞的新协议设计目标如下:

1.多语言支持

电商云的客户可能使用多种语言进行开发,协议必须能够支持各种语言无痛、方便的接入。

2.便于解析的请求header

为提供丰富和完善的服务治理功能,便于Sidecar解析和添加信息的RPC请求header是必不可少的。

3.不改变内部业务的使用方式

有赞内部业务已经习惯了不编写IDL,直接开发微服务接口的开发方式。新的协议不能改变内部业务的开发方式和开发习惯,协议上的升级必须是业务完全无感知的。

4.方便的兼容和适配

推动业务升级是一个漫长的过程,新协议必须能够支持Sidecar自动进行新、旧协议的适配和转换,保证新旧版本协议长时间并存情况下的稳定性。

5.异步支持和高性能

当前dubbo使用的RPC协议通过链接内唯一的request ID实现了异步调用和consumer端的链接复用。新协议应当具备不亚于当前协议的性能,且必须具备支持异步调用和链接复用的能力。

6.使用规范通用的RPC协议

为降低框架的复杂度和学习成本,方便后续接入和使用通用的开源组件,同时保证框架处于规范的生态中,尽量借鉴和使用通用的协议和系列化方式,减少自己设计和开发带来的风险。

7.实现简单

为降低使用新协议带来的风险,新版协议应当避免复杂的实现,Java框架仅需经过简单的改造或增加拓展即可实现,减少实现复杂序列化协议带来的风险。

经过综合考虑,有赞的新rpc协议将以HTTP/2为基础,参考grpc协议。并兼容老的dubbo协议,保证协议的通用性和可拓展性。

总结

如开篇所说,“服务化,只有经历过才能领悟“。作者遗憾没有完整经历过这些发展,本文主要参阅了很多历史文档,试图从过来人的角度简述有赞的服务化发展历程。本文描述的服务化主要在于服务调用问题上,而完整的服务化体系远不止如此,核心至少还包括服务注册与发现、服务监控、服务追踪、服务治理等方面,这些方面,有赞也付出了很多的努力。

现在的岁月静好,是因为有人替你负重前行。如今有赞的服务化体系已经比较完善,但也依然面临挑战。希望日后能在有赞的工作、学习、经历中更好的成长。本文不足之处,还望指出。

原文:https://www.jianshu.com/p/162f21ef68c0

往期精彩文章

理解大型分布式架构的演进历史、技术原理、最佳实践

Oracle推出开源轻量级 Java 微服务框架 Helidon

小型系统如何“微服务”开发

如何找到完美的以太坊区块链开发者

大数据推荐系统实时架构和离线架构

ElasticSearch优化会员列表搜索

Rabbitmq延迟队列实现定时任务

软件做异常测试?必知的22个测试点总结!

Java SQL注入危害这么大,该如何来防止呢?

还没用上 JDK 11吧,JDK 12 早期访问构建版使用

Dubbo 整合 Pinpoint 做分布式服务请求跟踪

Java并发:分布式应用限流实践

原文发布于微信公众号 - 搜云库技术团队(souyunku)

原文发表时间:2018-10-17

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

扫码关注云+社区

领取腾讯云代金券