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