微博平台的RPC服务化实践

微博平台的RPC服务化实践

 

2014年第一分钟,新浪微博的发布量以808298条再次刷新记录,第一秒微博发布量相较去年提升55%。(数据来源:新浪科技 http://tech.sina.com.cn/i/2014-01-01/02409059293.shtml )这是微博平台 RPC 框架 “Motan” 上线后第一次抗峰值,整体表现平稳,基本达到最初的“应用方无感知”的目标。

 

在RPC服务化这个事情上,微博平台不是第一个吃螃蟹的:早的有亚马逊和eBay等国外先驱,近的有Twitter的finagle,淘宝的dubbo等等,网上各种公开的资料铺天盖地。另一方面,单纯的RPC调用功能实现,从技术上看其实并不复杂:client 发起调用,框架拦截调用信息,序列化,传输,server端收到调用信息,反序列化,根据调用信息发起实际调用获取结果,再原路返回。实现这些功能可能也就三五天的事情,但在一个复杂的业务环境下,稳定可靠的应用它,才是最大的挑战。

 

微博平台的 RPC 服务化拆分历程始于2013年7月。在此之前,我们花了很长的时间讨论服务化的目标,主要是项目的范围:哪些问题不属于服务化项目需要解决的问题。 实际的框架代码开发花了三个工程师(王喆@wangzhe_asdf9 陈波@fishermen 麦俊生@麦俊生)大约一个月时间,然后花了将近两个月的时间推动在第一个业务上线:调整工程师的开发模式,调整测试流程,修改上线系统,添加监控和报警,小流量测试,灰度发布,最后才是全量上线。然后又花了一个月,在微博平台主要业务中全部上线。

 

微博RPC的一些基本的数据指标:

  • Motan 框架:2w+ 行 Java 代码,1w 行 test 代码,UT行覆盖率超过 70%(当前 Motan 实现中,与微博平台内部多个系统都有功能绑定,还不具备开源条件,但开源是我们从一开始就设立好的目标之一)
  • 支持 2 种调用方式:inJVM 和 TCP远程调用。inJVM 方式类似 loopback 网卡:数据经过了协议栈流程处理,但没有流经真正的网络设备。inJVM方式主要用来支持开发调试和测试,以及在RPC服务上线初期作为Fail-Back降级使用
  • 典型业务场景下单实例 tps 极限 20k,微博平台一般采用单机双实例,即单机极限 40k
  • 典型业务场景下平均响应时间 <3 ms,框架层额外消耗 < 0.01 ms
  • 最大的单个核心业务日调用量超过 800亿次

 motan rpc 调用架构图

Motan 架构图

 

RPC服务化的目的大约有两种:将一个大一统的应用拆分成多个小的RPC服务,那么目的就是为了解耦和,提升开发效率;如果是将传统的Http或其它方式远程调用改造成高效的RPC调用,那么就是为了提升运行效率。不幸的是,微博平台的RPC框架,需要同时达到这两个目的:既要在平台内部将一个大一统的应用拆分,又要考虑到后续向开放平台的大客户们提供RPC接入的可能。因此,微博平台在技术选型和方案设计上做了很多的权衡和妥协,在实践中也获得了不少的经验和教训:

  • 首先,是选择已有开源方案,还是自己开发一个新方案?选择的依据按重要程度排序:是否满足自己的核心需求,方案成熟度,认知成本(即二次开发难度)。由于是拆分一个已有的复杂应用,微博平台的一个核心需求是:应用开发方希望尽可能的平滑迁移,最好能做到应用方无感知。我们评估的多个开源方案没有一个能满足,所以只能自己做一个了
  • 灵活性与误用的可能性:框架开发方总是有一个偏见,觉得我这个框架越灵活越好,最好每个步骤每个环节都是可以由使用方自己配置或定义。但对于一个内部强制使用的框架来说,使用方式的统一性也同样重要,换句话说,对于大部分的环节步骤,都需要保证团队内部各使用方都按同样的方式进行配置,防止误用,并降低学习和沟通成本。我们的经验是,框架开发完成后,还需要有“框架使用方”角色,将所有的灵活性限制在框架使用方的层面,避免直接暴露所有细节到最终的业务开发方
  • 序列化方式选择:微博平台从2011年引入了 PB 序列化方式,以替代 cache 和 db 中的 json 文本。但在 RPC 框架上线过程中,我们选择了对 Java 对象更为友好的 Hessian2 。因为之前的 PB 序列化需要定义 proto 文件和生成代码,平台只对必要的 model 类做了支持,而 rpc 可能涉及到更多的 wrap 类,业务逻辑类等,为所有的类提供 pb 支持的工作量太大,而且后期维护困难。当然了,Motan 框架支持各种不同的序列化方式配置。
  • 通讯协议选择:在评估了几个开源RPC框架的协议设计后,我们最终选择了在 TCP 链接基础上设计自己的 RPC 通讯协议,一个简单的二进制协议:定长 header 中包含一个 length 字段,然后就是二进制的 body payload,即序列化之后的 rpc request 或 response 。
  • 集群管理:微博平台Motan框架当前依赖于内部开发的Config Service(Code name Vintage,based on ZooKeeper)来进行服务注册,服务发现和变更通知。
  • Trace系统:微博平台Motan框架当前依赖于内部开发的类似Twitter Zipkin的Trace系统(Code name Watchman)来对RPC请求做抽样及全量trace。

 

一套新的架构在大规模的推广使用过程中总会遇到各种问题,微博平台RPC服务化也不例外。总结起来,我们遇到的问题包括:

1. 整体服务的SLA水平降低。由于前端接口依赖多个后端RPC服务,每个RPC服务风吹草动都会直接影响接口成功率。初期改造过程中,对RPC服务并没有做明确的SLA要求,加上前端有些地方对调用超时异常兼容不够,导致前端调用失败几率增加,接口成功率降低。后来我们对每一个RPC服务设立了具体的SLA要求,并优化了前端重试及失败处理机制,从而保证了整体服务的SLA。

2. 必须提供稳定的测试环境。前期改造过程中,服务调用方在进行线下测试时,由于被调用方同时也在调整,导致经常出现测试环境服务不可用的情况,严重影响了调用方的测试使用。因此快速搭建一个独立的以RPC服务为单位的测试环境,在整个服务化过程中还是十分重要的。当前微博平台以 OpenStack 为基础搭建了一套快速测试环境分配系统,支持RPC服务粒度的测试环境分配。

3. 统一的开发、测试、上线、监控流程。在初期改造中,由于涉及多个部门和开发团队,各RPC服务的开发测试上线流程都沿用原来团队的做法,不统一,导致多个互相依赖的RPC服务同时上线新版本的时候,经常出现衔接不上,无法线下集成测试,只能线上测试的情况,严重影响业务迭代速度。后来平台通过搭建一套统一的CI流程以及优化运维上线系统,初步解决了这个问题。

 

当前 Motan 框架完成了在微博平台的核心业务上线,接下来,我们的工作重点方向包括:

  • 多语言支持:RPC多语言支持很难,如果没有特别的理由,建议绕过。RPC多语言有两种不同的思路:一种是类似 Thrift/PB 定义语言无关的 proto,自动生成对应语言的代码;另一种是没有 proto 定义,只有文档规范说明,业务方自己实现,或者使用框架自带的lib实现,类似 Hessian/MsgPack 。微博平台选择的是第二种,当前已经支持 PHP client (兼容 Yar 协议),以及 C Server 。
  • RPC Service 运行时环境支持:为 Java 和 C service 提供统一的运行时环境支持。对于 Java RPC Service,目标是让业务方像写 Servlet 一样写 Service,统一打成 war 包后在 Tomcat 中运行;对于 C Service,将业务代码抽离成 so,由框架进行加载。
  • 标准化 RPC 接口改造,并推广到其它部门及开放平台使用:将当前平台内部的 Service 改造成类似微博 OpenApi 那样的标准化接口,推广给其它部门使用,并最终通过微博开放平台,开放给外部开发者使用。

 

微博平台 RPC 服务化拆分的故事,2014年依然继续。

 

撰稿:@唐福林