海量数据系统的高可用架构设计.docx

海量数据系统的高可用架构设计挑战高可用架构建设的流量与业务复杂性何为高可用？原则有三：故障监测与排除、消除达点故障，互备和容灾。大流量网站的架构建设最重要的挑战来自“流量”与“业务复杂性”两方面：流量。高可用架构首要应对的是大流量且变动复杂场景下的可用性问题。故在建设过程中，架构需要具备高伸缩性，能实现快速扩展。读Cache也是解决大流量带来麻烦的手段。业务复杂性。于网站而言，业务复杂性比流量带来的挑战要大，因除技术性问题，还涉及人的因素。如整个业务流程没经过很好的整理，后续会带来繁多且复杂的问题。在网站建设过程中，一方面架构上要做到分布式化，业务功能域要做到服务化，这样可以保证架构的高可用、高伸缩性。另一方面业务架构与组织架构要相匹配，网站流量逐渐增大的同时组织架构与业务架构要随之变化，相互匹配。反之，如在业务发展过程中，做系统变更会带来一系列问题。如开发和发布效率会因写码风格和发布频率（假设所有业务写到同一系统）受到影响；问题排查找不到对应的负责人等。实践故障检测与排除、分布式服务化改造和大流量系统高可用迭代2011 年，淘宝 PV 处于从 1 亿到 10 亿的 PV 阶段，系统性能成为最大挑战。针对大流量系统设计高可用的静态化方案，应用在详情、购物车以及秒杀系统中；参与双11大促时，交易全链路进行优化，这些经验在滴滴也得到了应用实践。主要为以下三方面：针对故障检测，做了全平台压测针对业务快速增长情况，对系统做分布式服务化改造大流量系统高可用迭代故障检测与排除——全平台测压压测是全业务，全流程的压测。在正常情况下制造线上系统的线上流量，也就是自己来攻击自己系统，流量可自控。产生流量的线上发压平台如上图，是产生流量的线上发压平台。和淘宝浏览某个商品行为相比，滴滴流量发起较复杂，涉及时间、地理位置等多维度。平台有前台 Web 系统、后台服务系统和数据存储三层。在测压过程中，遇到一些问题。如：测试数据和线上数据如何区分开？原则上是可写在一起，但为避免带来问题，这里做了和正式表一样的影子表，同库不同表。怎样识别是在做压测？用 Trace 来传递标识，通过中间件传递，中间件不完善也可通过参数来做。由于滴滴的数据和一般数据存在差异，全平台压测数据构造要做特殊处理。发单时产生的当前位置、目的地等数据都会回传系统。这里会出现坐标问题，如用真实坐标会干扰线上某些因素。故把坐标偏移到太平洋，模拟端，把精度、纬度等也做偏移。虚拟乘客和司机，做 ID 偏移、手机号替换。如下都是在做全平台测压时，发现的问题：业务线顺风车：接口耗时增长，如列表页面：100ms = 700ms顺风车：日志搜集的上传服务夯死专快：派单访问缓存出现超时出租车：获取司机接口触发限流出租车：派单单条日志量太大影响性能基础平台NAT：2台NAT启动无用的内核模块，流量大时大量丢包LBS：位置服务写入超时，查周边接口有超时地图：路径规划服务，到达容量瓶颈?压测工具导致的其他问题专快计算超时：由于工具问题，司机和订单陡增，km算法超时，主要是日志过多导致的。分布式改造典型的分布式架构上图是典型的分布式架构。最重要的接入层和服务层要做到服务的无状态化，每个节点都需对等，因为这两层主要做读请求且请求量较大。做无状态化是便于横向扩展，当业务量大时，就可迅速部署机器来支撑流量。数据层大部分情况下都是有状态的，需解决的是冗余和备份，MySQL 要做存库，能读写分离，能做故障切换。分布式改造关键的技术点有三：分布式 RPC 框架：主要解决系统性关联问题，就是系统拆分，必须要解决系统之间的同步连接问题；分布式消息框架：主要解决系统间的数据关联性，这是异步的，与RPC同步调用互补；分布式配置框架：主要解决状态问题，实际应用中接入层和服务层也是有状态的，最好做到无状态。因为每个机器可能存在差异，故要通过中间件，把差异性放到配置框架中解决。?去年，滴滴做了服务治理相关的事。如下图，是早期的滴滴系统架构，router 接受层，到 inrouter 上层，中间有引入代码。下面是 Redis，本身是个代理。早期的滴滴系统架构这里存在的问题：上下游依赖硬编码在代码里；没有使用 inrouter/tgw 的 ip：Port；摘除和扩容需要代码重新上线，inrouter 有网络链路稳定性隐患，以及效率上的损失；没有清晰的服务目录，API 文档以及 SLA 和监控。?分布式 RPC 框架图目标是把一些服务之间的调用能够通过规范化方式串联起来。上下游通过名字服务，从上游和下游端口解耦，名字服务需要在全公司统一且名字唯一。Naming 服务就是做服务命名，服务注册和发现，到注册中心RPC通道，部署私有协议，具备可扩展性服务路由与容灾，动态路由，故障节点摘除?这里需要提醒的是，目前滴滴技术栈还不统一，所以导致中间件会复杂