• 极客专栏正式上线!欢迎访问 https://www.jikewenku.com/topic.html
  • 极客专栏正式上线!欢迎访问 https://www.jikewenku.com/topic.html

有赞服务化架构演进

技术杂谈 勤劳的小蚂蚁 3个月前 (02-02) 99次浏览 已收录 0个评论 扫描二维码

服务化是互联网公司成长的必经之路。随着微服务的兴起,很多公司如火如荼的搞起了自己的服务化,有兴奋有无奈。那服务化该怎么做,该做什么?本文试图从有赞的发展历程来体会服务化发展。
有赞史
有赞成立于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协议,保证协议的通用性和可拓展性。
总结
如开篇所说,“服务化,只有经历过才能领悟“。作者遗憾没有完整经历过这些发展,本文主要参阅了很多历史文档,试图从过来人的角度简述有赞的服务化发展历程。本文描述的服务化主要在于服务调用问题上,而完整的服务化体系远不止如此,核心至少还包括服务注册与发现、服务监控、服务追踪、服务治理等方面,这些方面,有赞也付出了很多的努力。
现在的岁月静好,是因为有人替你负重前行。如今有赞的服务化体系已经比较完善,但也依然面临挑战。希望日后能在有赞的工作、学习、经历中更好的成长。本文不足之处,还望指出。

丨极客文库, 版权所有丨如未注明 , 均为原创丨
本网站采用知识共享署名-非商业性使用-相同方式共享 3.0 中国大陆许可协议进行授权
转载请注明原文链接:有赞服务化架构演进
喜欢 (0)
[247507792@qq.com]
分享 (0)
勤劳的小蚂蚁
关于作者:
温馨提示:本文来源于网络,转载文章皆标明了出处,如果您发现侵权文章,请及时向站长反馈删除。

您必须 登录 才能发表评论!

  • 精品技术教程
  • 编程资源分享
  • 问答交流社区
  • 极客文库知识库

客服QQ


QQ:2248886839


工作时间:09:00-23:00