查看原文
其他

首发:唯品会RPC服务框架与容器化演进

2016-04-06 邱戈川 高可用架构

编者按:本文是邱戈川在 3 月 27 日数人云“百万并发”活动的演讲,授权「高可用架构」首发。转载请注明来自高可用架构公众号「ArchNotes」。


邱戈川,唯品会分布式架构平台产品经理,16 个年头的 IT 老兵,除了销售和老板角色,做过 IT 中的各种角色,游走于架构与产品间。关注 Docker、Mesos 等容器化技术领域的实践。主导的分布式服务框架已经广泛用于唯品会各大核心业务系统,以高性能、低延迟广受好评。现任唯品会( VIP.COM )基础架构部分布式服务框架、定时任务调度系统以及容器化管理平台产品经理。


今天要讲的题目比较热,但也比较“简单”,因为有很多公司大型系统已经在用。我的演讲内容包括两个方面:一个是分布式架构的实践,另外一个是服务体系中容器化怎么做。


分布式服务框架实践


可能大家很多都听过服务化,或者叫微服务,但是这个“微”字很难平衡,因为每个人有每个人的理解,我们的理念还是以简单实用为主,下面是唯品会 RPC 服务化框架的主要结构,proxy 层是我们特别重要的一个环节,后面会详细介绍。



在展开之前,先介绍下唯品会做服务化的原因,重要的有 5 点:


  1. 服务复杂度高。大家知道唯品会做特卖的,里面涉及到的大的系统比较多,包括库存、订单、支付等等。

  2. 团队规模大,国内的大电商企业规模都是几千人的技术规模,这是一个比较大的挑战,不像我们现在说有几十个人的创业公司。几千人的公司实际上推动一些公共技术架构比较困难。我们有专门的运维部门、业务部门等。团队越分越散,最后的结果很难协调一起开发,这是我们最大的问题。

  3. 弹性应对高并发能力,要有足够的弹性,因为我们有双十一,12.8 日店庆,接下来马上是 4.19 大促。业界竞争是我们做大促的原因,但是大促现在已经越来越烂了,包括京东、苏宁易购,包括唯品会,一周一个大促,这个不能叫大促,只能叫“周促”。大促造成的流量的并发越来越凌乱,今天可能 10 点钟很频繁了,到 11 点钟没流量了,但到了晚上 8 点流量又上来了,这种无规律的突发流量,要好支撑以及运维高性价比是很困难的一件事情。

  4. 足够的容错和自愈能力,这是我们做服务化最大的动力。整个的容错体系,不能说今天死了,找一个运维人员重新找一个机器上切换 IP。当然,现实还有一部分系统做不到服务化,旧的体系依然还存在。

  5. 降低维护成本,出错的话到底查还是不查,需要查的成本非常低。不然的话,无法把握下一次发生什么事情。做开发的,有一大部分时间都是做查错。



一般公司技术体系可以分成基础层、业务层、接入层三层的划分。基础层技术团队能做的不多,数据库、缓存及文件系统都是标准化的组件。但是服务化是在做中间层及业务聚合层,再提供 API 出来给到上面有网站及 APP 使用,服务化怎么做对整个架构以及所有技术团队都有影响。

 

经过对服务化的思考与实践,我们主要目标是做好两个事情,一个是整个体系的服务注册与发现,第二个是服务治理。


服务注册与发现


唯品会是自己构建的通信框架,基于 Thrift RPC 的方式。整个 RPC 框架分成三段:client、proxy,service。


我们的做法是把 proxy 这一层独立出来,通过 proxy 调用服务。


为什么这么做?


当服务越来越多,会发现一个问题,A 部门今天升级,B 部门不升级,就会造成业务处理很混乱,路由和容错都会很混乱。我们很难强迫业务部门说今天一定要把业务用的框架升级,业务部门会反感这种自身没有变更需求的被动升级。所以我们会把服务治理功能独立出来放在一个地方,就是这里提的 proxy 端。

 



服务发现网上已经有很多选择了,搭建不是太复杂,原理上只要把服务注册到公共的地方,即把 IP + 端口注册,然后 client 端获取对应的 IP + 端口的列表就可以了。有很多不同的技术实现服务发现。如 etcd、consul 及传统的 DNS 方式。


 

服务治理


服务治理传统大家用得多的是代理模式,使用治理功能的服务都需要流经它。考虑到这个远程代理如果有什么异常会影响整体服务质量,我们把代理放到本地,没用采用中心化的部署。


这是我们实现分布式服务总结的一个理念:尽量让所有的中心化功能都本地化,通过本地化的方式找到服务在哪里,在本地完成治理。


当我们需要升级时,只需要把本地代理升级换掉就可以了。



如上图所示,服务治理还做了很多事情,主要跟业务相关的,通用层面包括服务路由、流量控制等。


灰度流量控制


刚才另外一个朋友也讲灰度,我们叫 AB 测试,做法如下。


我们可以通过百分比的方式,在新上一个服务的时候,只放 1% 或者千分之一的流量来做灰度。


这样的话,影响客户量是最小的,不然的话,原来有 9 台机,再上一台可能有问题的机器,就有十分之一的概率出错。


治理策略


服务治理方面还做了服务之间的隔离,防火墙的部署和邻近机房路由等。


如果服务部署在异地多个机房,服务就会产生跨墙的问题,机房与机房最快也要三二十毫秒,需要充分考虑跨墙及延迟的特性。我们还做了一些熔断、限流的策略。


大家可以对比一下 Dubbo,我们没有选择它的原因就是上述服务治理方面功能的需求。


对于 proxy 高可用,实际上我们有一个灾备,把同样的 proxy 在中央找一个地方做容灾,当你发现本地不通的时候可以在远端找到。这样就可以做灾备,实现无缝升级。


另外我们做的弹性路由,在不同的 IDC 机房间配不同的 IP 段之间路由的优先级,当优先级不同的时候优先选邻近的机房的服务处理。

 

减化运维


另外一个减化运维的需求,也是跟多机房有关。




如果有很多机房,有一个机房正好做支付,现在支付的要求比较高一些,所有的服务都会被保护起来,就会有一个问题,当找到那台机器的 IP 时候,有可能发现这台机器不通。


这是由于我们从注册发现来找,有可能找到的是防火墙后面的那台机器,这样每次去申请支付的时候,就会出现一个问题,要求所有的客户端的防火墙访问策略都要被打开,然后才允许不同的客户端进来。


但最大的问题是做支付服务的那个人根本不知道有多少人在用它。怎么办?我们实际上通过判断服务是不是个特定的服务,如果是把它全部绕到一个防火墙后面的远程 Proxy,然后通过反向代理的方式进来,这样的话,避免每次都需要做配置防火墙策略,只需要给(Proxy)独立开一个对外的开放端口就可以了。


中间聚合层 


服务本身是零散化的东西,通常要接入的是中间层。实际上会在中间层做聚合,聚合层本身即可以做业务聚合,也可以做中间层的聚合,每一层的聚合都要做异步调用的设计。同时要对接口进行抽取,这样的话才能给 APP 使用。因为 APP 本身是没有服务发现的。



 

RPC 性能


使用 RPC 有很多理由, 我们这里对比一下它的整体的性能(当然性能只是一方面,是否真的需要,取决于你到底用多少性能,latency 想要多少)。


这是我们自己内部的一个简单的对比。我们会起用调用跟踪、写日志等,大概我们在 4.8 万 TPS,用 Tomcat Rest 方式压,可以到 2.4 万。


 

总结


整个服务化来说,不是纯粹引入一个 RPC 框架来做这么简单,整个服务化是一个体系,它包括很多东西,服务框架只是其中一个面。服务离散化之后,在管控服务方面,需要付出的代价也会大,大家做服务化之前一定要想清楚。



 

其他实践总结


顺带提一下我们的“黑科技”。


1、压测时候需要把 JMeter 参数调好,不然的话,很有可能不是的服务的问题,而是 JMeter 可能压不到。


2、注意 Young GC 的次数。


3、ZooKeeper


我们服务发现与治理用的 Zookeeper,Zookeeper 瓶颈非常多,如何在跨机房、大数据量情况下如果用好 ZooKeeper?


首先整个系统设计,核心做选举的三个节点一定要放在同一个数据中心部署。不然写数据会造成整个 Zookeeper 集群不稳定。另外所有的业务节点全部挂在观察者模式上,让观察者模式不要影响全局。



 

容器化演进


下面分享一下我们容器化的演进。


我们运维思路遵循简单原理,目前采用单进程部署,运维简单也是为了最大的容错。


在物理机体系上,虽然私有云我们也在做。但是要打造的体系比较大,运维难度也比较大。不少物理机 CPU 才百分之几。这是我们为什么要做容器化的原因。

 

容器化的选型,没有说哪一个对哪一个错,我们选型充分考虑了自己的特性。


我们容器化最后选择 Marathon 和 Mesos,主要原因是为了适应物理层。


Kubernetes 还没有做物理机这一层管理。我们需要方案有对整个体系后续的管理能力。K8S 里面的细节我就不说了(最大到 1000个 节点),每个人都有自己的喜好及场景来选择。




下面是整个容器平台的概貌,左边服务化体系和监控体系,最右边是原有的物理机运维体系,这两个都可以直接沿用之前的系统,不需要太多调整。


容器里面是我们主要提几个东西,包括业务的服务、Flume Agent, cAdervisor 等,我们还是遵循容器单进程的理念。




整个容器化的发布流程也比较简单,从开发一直到运维,通过 Mesos + Marathon 做调度,用 Docker 运行,再做监控分析,还有一些辅助的系统,比如网络和运维的工具等。


镜像的发布


从发布的角度,要考虑怎么简单。我们做的简易化的发布,直接用 Registry + Jenkins 实现。大家只要在 Jenkins 写好脚本就可以了,这是一个简化的流程。不需要做代码开发。



对于 Registry HA 方案,如果做一个类似于用分布式软件存储的方式,我不确定能不能做好管理。我们还是走最简单的方式,在 Jenkins 里面把它部署到多个 Registry 里。前面配置反向代理,让客户端可以访问到,这样容量就不会有问题。




网络


默认不管用 NAT 的方式还是 host 方式,它的管理始终是很麻烦。我还是希望 Marathon + Mesos 的方式不管网络,网络交给我们自己管。目前我的方式是每台机器用 Linux VLan 的方式。希望后续 libnetwork 可以支撑更好的 DHCP 的方式,目前还没考虑引入。



 

VIP DCOS


大家都很熟悉 DCOS,我们要做的事情就是基于 mesos + marathon 和  docker、cAdervisor 等组合成一个服务,包括实现我们自己的监控体系,还有策略的管理,包括弹性伸缩调度的能力,然后做一些预警,这些组件整合在一起,有一个独立的入口。


业务部门始终都是比较厌烦繁杂的东西。因此提供了一些相对友好的一些界面。

资源共享

 

当公司大了之后,不同的部门有自己的运维,不同的部门有自己的机器。他不想与别人共享,整个云化又是共享的概念,我们针对这种方式做一个限制的资源池的隔离,比如购物车和下单隔离成两组,自己的共享及弹性调度在自己的池里去做。




当然当大促的时候,我们会从公有池给它分额外的资源。将来继续演进,如果需要我们可以把它升级到公有云,把公有云机器变成 Mesos 的 slave 机器,把它挂到自己的集群里面,它就可以被调度了。


容器的“黑科技”


容器使用,我们使用了一些“黑科技”。


首先,我们在做容器化的时候调整了 Linux,在上面做一些额外的手脚。


内存策略:首先是主机 memory,一个是回收的策略的调整,一个是 swap 的调整,它是比较大的问题。默认的 memory 使用 60% 后就会使用 swap,但是最好的方式尽可能用光 memory 再用 swap。


IO 优化:两个 IO 比较关键,一个是磁盘 IO,一个是网络 IO。因为容器多了之后,实际上一个物理机能支撑 log 输出的磁盘 IO 是非常有限的。这样的话,支撑不了几个容器,所以 IO 是一个很大的影响。尽可能在物理机上配多个磁盘,把不同的 log 文件用不同的磁盘隔离开。第二个手段是应用程序本身将 IO 做一个抽样,不是所有的应用程序所有的 log 都要输出,根据情况做抽样大多可以满足需要。


磁盘 IO:再次,像我们这样的服务化体系,将 log 搜集到中心地方,log 存到本地意义不大。这样可以用一块内存磁盘方式先写进来,避免磁盘 IO。


网络 IO:建议最好用高性能万兆网卡和交换机。如果没有,则可以用多个千兆卡把它bond在一起。 今天讲的大概这么多,谢谢大家!


如果愿意加入唯品会,可以发简历到我的内推邮箱 duff.qiu@vipshop.com


对本文任何问题欢迎留言,小编会邀请讲师逐个回答。但是别留言 15,否则小编会被 Tim 老师狠狠批评。


想关注更多分布式技术,请订阅公众号获取更多文章。转载请注明来自高可用架构「ArchNotes」微信公众号及包含以下二维码。


高可用架构

改变互联网的构建方式


长按二维码 订阅「高可用架构」公众号


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存