唯品会RPC服务框架与容器化演进--转

原文地址：http://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=405781868&idx=1&sn=cbb10d37e25c76a1845f593a222da3c9&scene=0#wechat_redirect

编者按：本文是邱戈川在 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在一起。 今天讲的大概这么多，谢谢大家！