来自滴滴、微博、惟品会、魅族、点评关于高可用架构的实践分享

架构师小组交流会：每期选一个时下最热门的技术话题进行实践经验分享。

第二期：高可用架构。

参与嘉宾：滴滴技术负责人彭令鹏、魅族系统架构师何伟、惟品会应用架构负责人张广平、新浪微博技术专家聂永、大众点评交易平台技术负责人陈一方、七牛云首席架构师李道兵。

本文是对这次交流的整理，欢迎探讨。

 

第一轮：自由交流

滴滴彭令鹏：你们好，我是彭令鹏，目前在滴滴平台部负责整个专快车业务的稳定性和效率，以前在百度作了5年半的网页搜索部底层架构的工做。如今在滴滴主要在推四个项目，第一个项目是异地多活  ，第二个项目是全链路压测，为了尽快发现线上的一些容量风险，第三个是在推一个一键降级的平台，为了加快止损速度。第四个是服务治理，滴滴的业务也比较复杂，机器和服务规模也愈来愈大，咱们在推一个总体的服务治理工做。

 

异地多活咱们分三期，如今第一期差很少作完了。第一期主要是实现一个同城的Active /Standby。咱们的数据两个机房都有，流量主要在一个机房，另外一个机房只有少许流量，这少许流量主要是保证机房不会由于升级或其余缘由，致使它不可用。第二期才会active-active，好比说两个机房分两半各50%的流量。第三期是支付这一块，如今不考虑双活，第三期咱们会去考虑。当前第一期能够认为99%的流量跑在一个机房，1%的流量跑在另一个机房，并且另外那个1%可能随时会切回来。

 

数据同步有两大块。第一大块在数据存储这一层，好比说用了MySQL的主从复制，还有在咱们的缓存层次，为了保证命中率，咱们也作了一些双写同步复制。第二个层次，对于部分业务系统，特别是像咱们分单，它由于状态比较多，而且依赖的存储也比较多，若是在存储层作的话比较麻烦，因此咱们直接在业务层作的双写。

 

滴滴的业务模式异地多活是比较难的，主要是要求的状态比较实时，打不到车立马就有人反馈投诉，不像购物同样。异地多活，咱们一共有三大块技术，第一个是前面说的数据同步。第二个就是流量路由，前面说的99%和1%的流量的一个分配。第三大块咱们在作降级，降级包括一个最小系统，若是数据同步真出了问题，咱们会用端上面的一些数据来作补偿，反正总体仍是很难的，由于订单状态机这一块仍是比较复杂，状态比较多。

 

魅族何伟：我是魅族科技何伟，负责基础架构技术平台。魅族的互联网业务主要是用户数据同步，应用商店，音乐、视频等等，而后是push服务，push服务天天也有几个亿的推送。咱们也在作全链路压测、容量管理，后面会准备上容器这一块，如今仍是VM的。全链路压测咱们如今正在作，简单讲一下，在入口时咱们会去对流量打标记，就是着色，而后咱们就能把流量根据这个着色把它调度到某一个指定的节点，在系统的各个层级咱们均可以去作调度。咱们不是像TCPCopy那样工做。咱们的作法是把流量引到某个节点，去压某个节点的极限容量，而后咱们就能看到咱们的流量到底要多大的集群才能扛得起来。

 

七牛云李道兵：你们好，我是李道兵，负责七牛存储的技术架构。七牛是多数据中心，在全国有数个存储区域，每一个存储区域有多个核心的存储机房，这些机房的规模都比较大，用于存储客户的数据。将数据存放于一个数据中心内的风险很大，若是数据中心断电、断网，会形成数据的不可用，若是一个数据中心发生灾难性事故，还可能会形成数据丢失，因此七牛使用了双数据中心的互备技术。咱们将两个数据中心用裸光纤互联，当用户上传文件到某个数据中心时，系统异步将文件数据和相关原数据同步到与之互备的另外一数据中心，这样当一个数据中心故障时，咱们会根据故障的级别启用不一样的应急预案，将请求切换到与之互备的数据中心。

 

微博聂永：我是来自新浪微博的聂永，如今负责微博客户端IM消息下推系统基础设施的维护和优化。前段时间还参与了公司的一个性能测试系统的建设，为系统性能提供完整压测支持，举一个例子，之前作过一个聊天室项目。咱们对这个聊天室全部的功能接口都会一一的进行测试，而且会完整的模拟用户从上线到离线这个中间过程之中全部的全链路交互，而且设定每个交互的执行的次数，这个要先去梳理用户在实际操做的全部行为。好比咱们执行一次完整全链路压测，其中每一个用户至少能持续30多分钟，压测强度仍是很大的。同时，咱们在作压测的时候，其实彻底能够拿手机，和模拟的用户一同参与到压测情景中来，这样就能够以终端用户的角度，去切身体验咱们的系统的稳定性，终端操做的流畅程度等。咱们当时单机是直接的执行50万用户的压力测试，而后线上执行100万用户容量压测。

 

惟品会张广平：你们好，我是张广平，惟品会应用架构负责人。最近在作一个核心系统的重构。采购的一些商品，怎么去选购到咱们销售环节去售卖，这时候就涉及到，怎么把个人库存导进来？怎么把个人商品导到销售环节，让用户能看获得？用户去浏览商品详情页面，怎么去作收藏？还有就包括结算购物车、订单支付、促销，咱们把这些项目，做为咱们的核心系统的重构的第一阶段。这些系统重构了之后，其余的外围的系统，包括采购、物流都作一些调用。

 

惟品会这几年发展很是快，基本上每一年的量都在翻跟头，以前主要仍是靠硬件去顶，之前的应用程序主要仍是PHP。经过咱们此次的重构，此次双11效果很是好，虽然碰到了一个购物车刷单的事件，但咱们核心系统仍是比较争气，顶下来了。谈一下刷单，刷单是须要综合地去防治，咱们是从入口上判断一些请求，这些请求若是发现它是有风险的，咱们会去作限流措施。由于咱们的系统从入口的地方尚未一个总体的重构设计，因此有些流量进来，好比说流到购物车，购物车要去调用咱们目前一些商品查询，包括库存价格之类的，对后台系统压力特别大。

 

咱们当时是针对用户的请求去作一些分析，看看他的IP地址，调用咱们的风控模块之类的，可是这一次没有防得住，由于量太大。咱们系统相对来讲比较健康的，这些进来的请求应该仍是一些合理的请求，因此没有过多的限制。真要是扛不住，咱们会去作系统限流、系统降级之类的。咱们的OSP框架有一个比较有特点，咱们对访问的服务作限流，好比量达到多少之后咱们把后面的请求关闭，这样是保证咱们正常的应用能运转下去，否则会致使后面的商品查询服务、库存、价格，会瘫掉。

 

两年半之前我来惟品会的时候，清一色的PHP，只有个别团队在用尝试Java作开发，可是PHP是主流，那时候咱们面临一个PHP在扩展性方面的问题，尤为是它的框架，版本不少，用起来性能不好，基本上QPS都是在七八百左右，能上1000的都不多，基本上压到1000左右就崩掉了。咱们投入了大量的一些硬件资源，可是发现问题不断。后来组建了一个基础架构团队，从基本的服务化框架、消息框架、配置中心，还有监控模块、安全一系列都作了开发，两年多以来咱们如今基本上产品都有了。尤为是比较有特点的，是咱们的OSP框架。这个框架主要是基于thrift，滴滴的那位同窗也提到了thrift。咱们OSP的框架也是一个thrift的长链接，一个RPC的框架。咱们是做为应用架构在使用OSP。QPS从七八百，如今上万是很是轻松，比较简单的查询，能够到五六万级别。咱们每次大促都要增长好多机器，可是此次双11是省下来了，还把老的系统淘汰了下来。虽然对周边没有重合的一些系统作了扩容，整体省下来了，没有去增长新的资源。咱们这个重构仍是值得的，咱们的OSP框架扛到如今，此次双11没有出现一个问题。

 

大众点评陈一方：我是陈一方，来自大众点评。我原来是交易平台的，主要负责几个团队，优惠团队、订单团队和整个支付团队。如今负责整个点评的团购平台，这几年一直在作高并发的规模化的C端系统，B端系统也作了一些营销系统和结算系统。原来点评美团分别有个支付平台，融合之后，上海的支付也就是我负责的支付平台，会交到北京去。

 

新美大有一个支付，刚拿到牌照，原来是没牌照，可是咱们是有支付团队的，作整个支付后端的能力建设，好比说支付通道、帐户体系，还有前端统一支付的。支付后端挺复杂的，后端主要分3块，第一块就是支付资金渠道来源，资金渠道这块，好比支付宝，微信或银联或者任何支付通道，咱们叫它支付资金渠道，这块是管理资金通道的。第二块是管理用户帐户体系，由于支付会有一些资金的往来，因此你必须有明细帐户，因此会有帐户体系。第三块是面向公司类的业务汇集的，业务网关和支付网关。业务接入咱们怎么支付，他只须要接入咱们网关就能够了。网关提供能力有两种，有一种是API的模式在接入的，如今大部分是以那种组件，前端组件，好比 native 的话，咱们就直接有收银台，你只需嵌进去就行，什么都不须要作。早期咱们是Call API，由于那时候没有客服端的开发，后期的话，咱们iOS 逐渐成熟了，咱们后面API所有都上了，用那种产品化平台化的模块来接，由于这样的话自动挂了咱们切支付，或者是作支付上的营销，那时候他很是好作，产品化的一个过程。

 

第二轮：话题交流

主持人：关于全链路压测你们是怎么作的，数据是怎么处理的？生产的数据和测试的数据是放一块儿仍是隔离的？

 

滴滴彭令鹏：魅族的全链路压测是压单个节点的极限，这与咱们稍微有点不一样，其实咱们也有一个相似的作法，就是常态咱们在调度的时候，可能会在地图那种业务上面放置一个哨兵节点，这个哨兵结点的流量会比别人高一点，以便提早去发现一些问题，这点和魅族相似，可是咱们的压测不是这样的，咱们的压测是真正直接打到整个集群，就是线上集群，和正常业务是同样的。咱们的用户行为也尽量和正经常使用户一致，只是打上了特殊的标记，可是其余处理行为是彻底一致的，除了发券等那些和钱相关的。测试的是生产集群，这样作的目的是想真正去看这个生产集群的一个容量水平。这个和看单个节点的极限我以为可能有点不同。之前我在百度的时候，由于每一个模块都很大，全系统的模块没几个，因此能够经过单模块的状况直接去推导整个系统，是否是全链路容量都是够的。可是来了滴滴之后，由于滴滴的业务，每一类小的接口都独立成了服务，这就致使它的服务特别多，整个全链路下来可能有几十个，因此不直接去压一压其实仍是有不少问题是看不出来的。

 

大众点评陈一方：个人经验跟滴滴是同样的。咱们也是压测单机的容量，在线生产环境的时候不必定是按等比例放大的，因此你压一台机子它支持1000QPS，可是你10台不必定能支持1万的QPS，确实有这个问题，由于它的链路太长，没法用。好比说一个节点是10，第二个加入集群中它不是否是线性扩大 。

 

滴滴彭令鹏：咱们这边的作法，第一咱们在流量的模拟方面也是基于用户的历史数据去回放，打上特殊的标记，这个标记会从链路的最前端到最后端，所有染色上。针对标记的流量，咱们的数据有几类处理：第一数据库这块咱们是在一个proxy这样的中间件里面，直接把数据写到了一个影子表里面，至关于表级别隔离。第二个是缓存这块，由于缓存数据都会以司机的ID、用户的ID、订单的ID、坐标，做为key的组成部分，咱们全部的测试数据对这些ID作了一个偏移，好比对于坐标，咱们可能直接把这个坐标偏移到太平洋上面的一个地方，不会是真正的一个城市，这样保证咱们的缓存调用者不用改，数据就可经过key直接隔离开。第三个是消息队列，咱们会经过kafka订阅和消费消息，咱们会改造生产者，让他们将消息写到一些虚拟的topic上去。压测完了之后，咱们可能须要作数据清理，可是由于滴滴如今存储空间这一块其实并非特别瓶颈，因此清理咱们基本上不用作，当前是这样子。

 

主持人：同一个订单，用户打标是否是就是要侵入代码了？

滴滴彭令鹏：好比说作trace或者作追查，确定自上而下要传不少上下文，那咱们这样对应的一个压测标记，只是上下文里面的一个。那条路原来就是通了的，好比说对于http来说，我记得好像就是直接放在那个http的那个query string 里面，直接下去的。 

 

主持人：好比一个订单要写库，用户的ID是怎么来的？

滴滴彭令鹏：这些逻辑它是不变的，刚刚我说了，咱们采了真实的用户数据之后，会对一些ID类数据作偏移，好比说用户Passenger ID和Driver ID，正常的可认为是一些手机号，但偏移时咱们会把它的最高位，设置成特殊值，这是一类。另一类是坐标，咱们会把这个坐标，好比说北京直接平移到太平洋上面的一个经纬度，即平移到一个虚拟城市。咱们系统会将这些ID或坐标做为key去存储数据，包括缓存的key，那对应的，这些key也被咱们偏移了，因此存储的数据也就经过key隔离了。

 

大众点评陈一方：我分享下咱们当时压测的经验，咱们在压测线上服务的时候，咱们先压的读，读数据的这块压测比较容易，而压测写，其实挺难的。刚才滴滴分享他们经验，每一个团队不同。咱们的订单系统，当时压的时候就是很难就写入了。由于有一些问题，有不少数据写入咱们一次访问，后面一个集群，下面可能挂了一堆二三十台的实例数据表。遇到这样的问题怎么办呢，咱们当时是分段压测，就是先压数据层到db，就是先压db的的极限，db的极限压出来，好比说一个集群在db写的场景下支持2万，那根据这个集群服务器数量倒推，每台服务器写了多少db，而后再去测单台的服务的性能，而后再乘以集群数量，根据流量的翻量比。

 

主持人：咱们在谈压测，不少系统有第三方服务的，比方说第三方支付，对接外部的银行，没办法要求第三方服务配合你，那这个时候大家怎么办？

 

大众点评陈一方：第三方有两种作法，一种作法就是，若是它不是一个强依赖的话，你就直接把它关掉，最高峰的时候确定不够用，你就把他降级。这是第一个，第二个像支付，他强依赖的话，系统第三服务方会给你SLA，你根据它的极限值往下压就好了，若是他那个值没达到，你找他去，他达到了，你那就算了。

 

滴滴彭令鹏：咱们是这样子的，由于有一种场景，虽然支付那边会给你承诺SLA，但咱们的系统容量多是高于它的。那这个时候怎么压呢？咱们自己的压测是分为两期的。第一期，是在分单之前的压测，第二个是整个全链路。分单之前压测，是当流量到了分单系统之后，直接把它截断，从而保证这样的一些流量，不会走到下游去，对于支付也是同样的，你能够在支付模块的上游那里作一个截断。

 

主持人：作高可用有一个指标，就是要达到五个九。但最后在落地时，在多一些场景上面这些指示有实际测量吗，后面有没有一个定论去达到这个要求，或者没有达到这个要求？

 

滴滴彭令鹏：滴滴如今这边，当前是三个9多一点点。咱们将来2017年的一个目标也就是三个9一个五。作到四个9很难，对消息交易系统来讲。落实这一块第一是咱们有一个专门的第三方组织，来总体评比各个部门的稳定性指标，作得仍是比较严的。第二个是老大，包括CTO对这一块特别重视。

 

大众点评陈一方：咱们跟滴滴挺像的，咱们也是第三方的，好比运维部部或者质量部，他会给你出报表，由于它的报表是一周或者一个月的，咱们如今交易系统，要求四个9，可是咱们其实达到三个9多一点。高层管理会看这个指标，中层也会看这个指标，而后这样叠在每一个基层，他也会看这个指标，因此这样已经造成一个机制了。