高可用架构建设的挑战：流量与业务复杂性
何为高可用？原则有三：故障监测与排除、消除达点故障，互备和容灾。大流量网站的架构建设最重要的挑战来自流量与业务复杂性两方面。
流量。高可用架构首要应对的是大流量且变动复杂场景下的可用性问题。故在建设过程中，架构需要具备高伸缩性，能实现快速扩展。读Cache也是解决大流量带来麻烦的手段。
业务复杂性。于网站而言，业务复杂性比流量带来的挑战要大，因除技术性问题，还涉及人的因素。如整个业务流程没经过很好的整理，后续会带来繁多且复杂的问题。在网站建设过程中，一方面架构上要做到分布式化，业务功能域要做到服务化，这样可以保证架构的高可用、高伸缩性。另一方面业务架构与组织架构要相匹配，网站流量逐渐增大同时组织架构与业务架构要随之变化，相互匹配。反之，如在业务发展过程中，做系统变更会带来一系列问题：如开发和发布效率会因写码风格和发布频率（假设所有业务写到同一系统）受到影响、如问题排查找不到对应的负责人等。
实践：故障检测与排除、分布式服务化改造和大流量系统高可用迭代
2011年，淘宝PV处于从1亿到10亿的PV阶段，系统性能成为最大挑战，针对大流量系统设计高可用的静态化方案，应用在详情、购物车以及秒杀系统中；参与双11大促时，交易全链路进行优化，这些历史积累在滴滴得到应用实践。滴滴在过去近一年时间做了三方面实践：
一、 针对故障检测，做了全平台压测
二、 针对业务快速增长情况，对系统做分布式服务化改造
三、 大流量系统高可用迭代
故障检测与排除——全平台测压。 压测是全业务，全流程的压测。在正常情况下制造线上系统的线上流量，也就是自己来攻击自己系统，流量可自控。
产生流量的线上发压平台
如上图，是产生流量的线上发压平台。和淘宝浏览某个商品行为相比，滴滴流量发起较复杂，涉及时间、地理位置等多维度。平台有前台Web系统、后台服务系统和数据存储三层。在测压过程中，遇到一些问题。如测试数据和线上数据如何区分开？原则上是可写在一起，但为避免带来问题，这里做了和正式表一样的影子表，同库不同表。如怎样识别是在做压测？用Trace来传递标识，通过中间件传递，中间件不完善也可通过参数来做。
由于滴滴的数据和一般数据存在差异，全平台压测数据构造要做特殊处理。发单时产生的当前位置、目的地等数据都会回传系统。这里会出现坐标问题，如用真实坐标会干扰线上某些因素。故把坐标偏移到太平洋，模拟端，把精度、纬度等也做偏移。虚拟乘客和司机，做ID偏移、手机号替换。
如下，这些都是在做全平台测压时，发现的问题：
业务线
基础平台
压测工具导致的其他问题
典型的分布式架构
分布式改造。 如上图，是典型的分布式架构。最重要的接入层和服务层要做到服务的无状态化，每个节点都需对等，因为这两层主要做读请求且请求量较大。做无状态化是便于横向扩展，当业务量大时，就可迅速部署机器来支撑流量。数据层大部分情况下都是有状态的，需解决的是冗余和备份，MySQL要做存库，能读写分离，能做故障切换。
分布式改造关键的技术点有三：分布式RPC框架、分布式消息框架和分布式配置框架。分布式RPC框架主要解决系统性关联问题，就是系统拆分，必须要解决系统之间的同步连接问题 。分布式消息框架是解决系统间的数据关联性，这是异步的，与RPC同步调用互补。分布式配置框架是解决 
状态问题，实际应用中接入层和服务层也是有状态的，最好做到无状态。配置因为每个机器可能存在差异，故要通过中间件，把差异性放到配置框架中解决。
早期的滴滴系统架构
去年，滴滴做了服务治理相关的事。如上图，是早期的滴滴系统架构，router接受层，到inrouter上层，中间有引入代码。下面是Redis，本身是个代理。这里存在的问题：上下游依赖硬编码在代码里；没有使用inrouter/tgw的ip：Port；摘除和扩容需要代码重新上线，inrouter有网络链路稳定性隐患，以及效率上的损失；没有清晰的服务目录，API文档以及SLA和监控。
分布式RPC框架图
如上是分布式RPC框架图，目标是把一些服务之间的调用能够通过规范化方式串联起来。上下游通过名字服务，从上游和下游端口解耦，名字服务需要在全公司统一且名字唯一。Naming服务就是做服务命名，服务注册和发现，到注册中心。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、或者在数据库层单独做一个热点库等。
大流量系统的高可用迭代这里需要注意的点有热点隔离、先做数据的动静分离、将99%的数据缓存在客户端浏览器、将动态请求的读数据cache在web端、对读数据不做强一致性校验、对写数据进行基于时间的合理分片、实时热点发现、对写请求做限流保护、对写数据进行强一致性校验等。
高可用架构建设的经验：体系化、积累和沉淀
通过多年的高可用架构建设，这里有一些经验值得分享。最大的体会就是需要做稳定性体系化建设，包括建立规范和责任体系。其次就是工具要完善和体系化，以及需要配套的组织保障。
建议在责任体系的建设方面，公司一定每年都要制定高可用指标（KPI）、故障等级也要明晰，影响多少客户都要做描述、责任和荣耀体系也同等重要，这是个长期且苦逼的事。 工具方面，要完善且体系化，做规范，做KPI，最终要做到工具化，通过工具化把流程、规范能固定。工具要体系化，像全机压测，单机压测等等都可做工具。
一个高可用架构的建设，不是一朝一夕，需要各方面积累和沉淀，一定要注意以下三方面的处理流程：
关于变更：在变更之前必须制定回滚方案，涉及到对变更内容设置开关，出现问题可快速通过开关关闭新功能；接口变更、数据结构变更、回滚要考虑第三方依赖，在变更之中出现问题，第一时间回滚。
指导原则：将故障清晰描述和暴露出来，获取第一手资料，找到问题反馈源头，解决问题，消除故障同时找到对应系统和业务的直接负责人。
处理流程：问题发现后第一时间上报到“消防群、组建应急处理小组、跨团队合作，通知到对方系统的负责人，P1故障要通知到客服与公关接口人，尽量做到集中办公，问题处理完毕，立即总结和制定改进方案、系统TL负责，改进方案的执行情况。
本文作者:许令波 来源:51cto
CIO之家 www.ciozj.com 微信公众号:imciow