作者介绍许令波,花名君山,现任滴滴出行技术研究员,从事容器化和资源调度方面的技术建设。曾在淘宝工作七余载,经历了淘宝网 PV 从 1 到 50 亿的增长历程。其中涉及端与管道、应用层代码级、应用架构和端到端等全链路的优化,架构方面从单个应用到分布式、无线多端、中台以及国际化的演进。这些积累的经验同时也在滴滴得到应用实践。 高可用架构建设的挑战:流量与业务复杂性何为高可用?原则有三:故障监测与排除、消除达点故障,互备和容灾。大流量网站的架构建设最重要的挑战来自“流量”与“业务复杂性”两方面:
在网站建设过程中,一方面架构上要做到分布式化,业务功能域要做到服务化,这样可以保证架构的高可用、高伸缩性。另一方面业务架构与组织架构要相匹配,网站流量逐渐增大的同时组织架构与业务架构要随之变化,相互匹配。 反之,如在业务发展过程中,做系统变更会带来一系列问题。如开发和发布效率会因写码风格和发布频率(假设所有业务写到同一系统)受到影响;问题排查找不到对应的负责人等。 实践:故障检测与排除、分布式服务化改造和大流量系统高可用迭代2011 年,淘宝 PV 处于从 1 亿到 10 亿的 PV 阶段,系统性能成为最大挑战。针对大流量系统设计高可用的静态化方案,应用在详情、购物车以及秒杀系统中;参与双11大促时,交易全链路进行优化,这些经验在滴滴也得到了应用实践。主要为以下三方面:
故障检测与排除——全平台测压 压测是全业务,全流程的压测。在正常情况下制造线上系统的线上流量,也就是自己来攻击自己系统,流量可自控。 产生流量的线上发压平台 如上图,是产生流量的线上发压平台。和淘宝浏览某个商品行为相比,滴滴流量发起较复杂,涉及时间、地理位置等多维度。 平台有前台 Web 系统、后台服务系统和数据存储三层。在测压过程中,遇到一些问题。如:
由于滴滴的数据和一般数据存在差异,全平台压测数据构造要做特殊处理。发单时产生的当前位置、目的地等数据都会回传系统。这里会出现坐标问题,如用真实坐标会干扰线上某些因素。 故把坐标偏移到太平洋,模拟端,把精度、纬度等也做偏移。虚拟乘客和司机,做 ID 偏移、手机号替换。 如下都是在做全平台测压时,发现的问题: 业务线
基础平台
压测工具导致的其他问题
分布式改造 典型的分布式架构 上图是典型的分布式架构。最重要的接入层和服务层要做到服务的无状态化,每个节点都需对等,因为这两层主要做读请求且请求量较大。做无状态化是便于横向扩展,当业务量大时,就可迅速部署机器来支撑流量。 数据层大部分情况下都是有状态的,需解决的是冗余和备份,MySQL 要做存库,能读写分离,能做故障切换。 分布式改造关键的技术点有三:
去年,滴滴做了服务治理相关的事。如下图,是早期的滴滴系统架构,router 接受层,到 inrouter 上层,中间有引入代码。下面是 Redis,本身是个代理。 早期的滴滴系统架构 这里存在的问题:
分布式 RPC 框架图 目标是把一些服务之间的调用能够通过规范化方式串联起来。上下游通过名字服务,从上游和下游端口解耦,名字服务需要在全公司统一且名字唯一。
这里需要提醒的是,目前滴滴技术栈还不统一,所以导致中间件会复杂一些,应该最早期把技术栈统一,选择 Java 或者 Go 等,可以避免后续的问题。 服务命名要规范,服务名自描述,要构建统一服务树。为了效率和规范性,协议建议选择私有 RPC 协议。公有如 http 协议,测试方便,带来方便性的同时也带来的其他问题,就是容易被滥用。 服务路由建议是全局摘除,像机器一旦不可用就通知上游,及时摘掉,但也有一定的风险。如网络闪断,下面机器全挂,会导致所有服务都不可用。所以需在全员镇守情况下做全局确认,不要拖着整个服务,要从上游做决策,再换个IP,重新做一次。 分布式服务化改造的大团队协作,从单业务系统做分布式改造的一个出发点就是解决大团队分工和协作问题。代码的分支拆分,减少代码冲突,使得系统独立,打包和发布效率都会提高;部署独立,线上故障排查和责任认定会更加明确。 同时,带来的问题是依赖的不确定性增加,性能上的一些损耗。像一次请求,如果一下调来七八个请求,这也会带来一些问题,所以这个过程要有一定的合理性,就是公司现在处于什么阶段,现在需不需要拆分。所以系统、效率等方面要做一个平衡。 大流量系统的高可用迭代 大流量系统的架构实现高可用的策略部署,带有分组功能的一致性 Hash 的 Cache、静态内容前置到 CDN 和热点侦测等。 系统 APS 和服务层有五层代码 如上图,一个系统 APS 和服务层有五层代码,通过水平扩展加机器也解决不了问题。在业务层,没办法做水平扩展,必须做有状态的变化,部署带有分组功能的一致性 Hash 的 Cache。 为了具备更大的伸缩性需要把静态内容前置到CDN。 静态内容前置到 CDN 在服务端即使做扩展,量还是有限,读的请求,读的数据往前推,最终推到 CDN 上。CDN 体系比较多且有地域性,可抗百万级别的流量,但要解决冗余带来的时效性、一致性的问题。这样做带来的好处,除提高伸缩性,还节省带宽,节点分散,可用性更高。这里提醒下,CDN 可用性需要做评估,如不是自建,需要让提供 CDN 的供应商给出可用性指标,避免后续维系困难。 热点侦测 热点侦测流程图 前台系统到后台系统,整个请求是有链路的,一个请求从发起最终到服务端,到数据库层中间需经历多层,过程中存在时间差。特定情况下,会有 1-2 秒延时。利用这一点,当前端请求自导到接受层时,做实时热点侦测,当发现接收层发生变化,可及时通过认证等手段对这个请求做标记,把热点数据记录下来。 之后,把热点数据的信息通知下一个系统,这样就可起到从上游系统发现问题,保护下游的目的。当发现某个请求特别热时,提前对它做拦截。热点数据通过实时发现,日志采集过来,做统计,然后把这个热点数据再导到写数据系统的后端系统 cache 中,这样可保护后端的部分热点系统。 1% 的热点会影响 99% 的用户,这种情况在电商是特别明显的,如某个商品特别热卖,商品请求流量占全网流量很大部分。且上屏容易产生单点,查数据库时将定在同一机器。这样很容易导致某个商品会影响整个网站的所有商品。所以要在数据库做保护,如在本地做 cache、服务层做本地 cache、或者在数据库层单独做一个热点库等。 大流量系统的高可用迭代,需要注意的点有:
经验:高可用架构建设的体系化、积累和沉淀通过多年的高可用架构建设,这里有一些经验值得分享。最大的体会就是需要做稳定性体系化建设,包括建立规范和责任体系;其次就是工具要完善和体系化,以及需要配套的组织保障。 建议在责任体系的建设方面,公司一定每年都要制定高可用指标(KPI)、故障等级也要明晰,影响多少客户都要做描述、责任和荣耀体系也同等重要,这是个长期且苦逼的事。 工具方面,要完善且体系化,做规范,做 KPI,最终要做到工具化,通过工具化把流程、规范能固定。工具要体系化,像全机压测,单机压测等等都可做工具。 一个高可用架构的建设,不是一朝一夕,需要各方面积累和沉淀,一定要注意三方面的处理流程。
|
|