【SDCC 2016】微博、58赶集、百度外卖、腾讯微信、阿里巴巴的高可用架构实践...

【CSDN现场报道】2016年11月18日-20日，由CSDN重磅打造的年终技术盛会 —— “2016中国软件开发者大会”（Software Developer Conference China 2016，简称SDCC 2016）在北京京都信苑饭店隆重举行。本届大会云集了100多位国内外顶尖专家和技术大牛，共设新趋势和新实践2大主题会场，14个技术专题。面向国内外的中高端技术人员，聚焦最前沿技术及一线的实践经验，助力企业的技术升级和改造、全面提升技术人员的综合实力。

今年的 SDCC 高可用架构专场汇聚了来自微博、到家、百度外卖、腾讯微信、腾讯云、58赶集、阿里巴巴的资深技术专家，围绕着高可用主题各自分享了其团队的探索实践。而诸多观众更是早早地就来到了现场，下午13：30，本次会议在百度外卖基础架构部架构师陈霖的主持下正式开始，陈霖首先对所有的主题讲师与内容进行了扼要介绍并向所有观众表示欢迎。

新浪微博产品部技术专家聂永：性能驱动模式推动海量系统健康发展

新浪微博产品部技术专家聂永带来“性能驱动正确打开姿势”主题演讲，另辟蹊径，结合项目实践从性能角度展开架构分析。分享以幽默互动开场，成功调动起大家的参与热情。阐述在一个需要支持千万量级用户的在线聊天室项目中，通过完整实施性能测试驱动模式，如何在研发力量方面只配有一个初级工程师和一个中级工程师的情况下，最终实现并超出性能考核指标，顺利完成开发任务的。

在这个过程中无疑遇到了巨大的挑战，为此在实践过程中做了以下尝试：

1. 设立性能考核标准；
2. 挑选工具，在这一环节最终选择了Tsung，分享中也就其优势和不足做了详细的介绍；
3. 设计测试会话内容；
4. 把握测试前中后的关注点；
5. 全链路压测。

到家平台架构部高级工程师周千威：RPC框架高可用实践

到家平台架构部高级工程师周千威为现场观众带来了《RPC框架高可用实践》的主题演讲，他有着丰富的架构经验，曾主导58同城会员商业产品-优先刷新的设计、研发工作，目前负责到家自研服务架构 DSF(Daojia Service Framework)、DSF服务治理、短网址服务、通用消息平台等基础框架和通用平台。

本次演讲主要包括高可用含义、RPC 框架高可用的具体实施、服务治理三个部分。对于“高可用”这个概念相信大家并不陌生，各个领域都存在高可用：数据库、缓存、应用服务等。周千威表示：作为业务系统，我们的高可用不仅仅是简单的追求数字指标，而是满足不断变化的业务系统需求。而“高可用”就是尽量避免出现“不可用”，一旦出现局部不可用时，使其影响降到最低，或则能够及时给予及时报警，能让负责人及时解决，或则能够自主解决。而 RPC 框架的高可用，就是客户端和服务端的高可用，只有两者都高可用，总体上才是高可用的。在接下来的分享中，周千威具体分享了其与团队为达到 RPC 框架的高可用性，服务端和客户端都可以采取哪些策略方法：

一、服务端：

1. 基本问题：当遇到服务Crash 时，可采取集群部署的直接方式，集群必须支持动态横向扩展，添加服务节点动态生效；
2. 高可用实践：对服务集群节点进行分组，或为核心上游业务单独建立组节点，以避免因某个上游服务问题，导致整个服务集群能力的影响以及对其他核心上游服务的不可用；
3. 如何控制访问间干扰？限流！需要注意的是，限流是有一个有效期的，到家架构团队采纳的是一分钟；
4. 黑白名单：服务自我保护的常见方式；
5. 队列独享模式：任一线程阻塞都会丢弃任务，不存在队列竞争，可对任务分类处理。

二、客户端：

服务端集群方式部署，客户端产生路由，RPC 的高可用性除了能保障服务正常，客户端可正常向服务端发起请求外，还需满足“业务能用性”：

1. 基于接口路由，客户端调用某个接口方法的请求只会固定的落到某些指定的服务节点上处理；
2. 基于业务规则路由：基于用户自定义的路由规则路由，系统提供了基于方法参数hash值的路由规则，基本上可以满足大部分的业务场景。

最后，周千威对服务治理进行了介绍与实例展示，当 RPC 框架引入服务治理时，客户端与服务店之间都会有一个 TCP 链接，主要用于服务分发，以实现服务注册（节点自动发现、快速扩容）、监控告警（阈值、波动、异常）、数据统计与展示（服务维度与调用）等。

百度外卖架构师陈霖：百度外卖交易系统高可用实践

随着百度外卖业务的逐步发展，对技术架构也提出了更高的要求，而交易系统作为外卖业务最核心的系统，承担着极其重要的责任，因此确保交易系统高可用无疑是最核心的目标。

陈霖在分享中介绍了实践中的高可用接入层、部分异地多活、Cache服务，以及分布式数据库手段。系统分析结束之后进入重点内容——队列。由于诸多系统都要用到订单，因此必须要考虑多系统订单一致性问题，这就要用到分布式队列。这里的数据统一提交到主备数据库，做到双机房备份。还有队列+数据对账实现最终一致性，首先是重试与接口幂等，再者就是乐观锁机制。

此外，要做到尽量无单点，因为在微服务细分程度很高的情况下，会形成网状结构，这在生产环境中是很可怕的，任何一个节点的问题都会导致全盘崩坏，故而要避免产生环状结构。同时，他还指出数据库也要做过载保护。在讨论超时问题时，分述了全局超时和精细化超时。针对前者做出了全局超时控制的优化：可用超时层层向下透传，全局+动态超时可以保护后面操作不再做无用功。最后他还为大家补充介绍了华佗系统。

腾讯微信后台开发高级工程师陈俊超：PhxSQL 的设计与实现

腾讯微信后台开发高级工程师陈俊超在现场分背景、思路、实现、效果四个部分详细分享了微信开源项目—— MySQL 集群 PhxSQL 的设计与实现，具体讲解 PhxSQL 是如何做到高可用、强一致性。陈俊超表示，原生 MySQL 存在容灾缺陷，为了实现高可用强一致，MySQL 提供了包括使用异步复制和半同步复制在内的复制方案，其中前者无法保证主备数据一致。在一个典型的一主两备系统中，Master 重启会导致在切换至新 Master 后，旧 Master 可能会多出一些数据，由此造成了数据的不一致，更有幻读、调用端分裂等问题。经诸多实践与分析，可总结得出缺乏自动选主机制的 MySQL 无法同时满足高可用和强一致，而这也正是其团队研发 PhxSQL 的由来。

基于以上，PhxSQL 主要通过可靠日志存储和请求透传来解决 MySQL 所面临的诸多问题，构建起以“可靠日志存储”为中心的架构，Master 用类似半同步的协议，将 binlog 同步到 BinlogSvr，同时，Slave 不直接从 Master 拉取 binlog，而是从 BinlogSvr 拉取，并校准重启过程，确定 pendingbinlog 是否要 commit。

腾讯云IaaS技术负责人邹辉：腾讯云架构设计之道

邹辉在演讲中详细探讨了如何衡量一个系统可用性，如何构建一个高可用系统等问题，具体如下：

一、影响可用性的因素

“有人，就有意外（bug），有意外（bug）就有故障。”我们在衡量可用性的环节引入了两个指标：MTBF（平均无故障工作时间）MTTR（平均故障恢复时间）。软件、硬件、IDC、网络，乃至人为因素都可能引发故障，从而影响可用性。然而没有故障就没有架构师这个职业，架构师首先要让系统少出故障自动恢复，若故障已经发生，就需要快速发现并定位，继而快速解决。同时他还指出，可用性不是过度设计。

二、提高可用性的具体策略

高可用不等于完美或过度设计，软件系统属于应用科学，任何架构师首先都要考虑业务场景。在如何提升可靠性的问题上，不得不提到节日小彩灯的例子，旧有的串联模式下，一个彩灯故障就会导致一堆故障。后转向并联，性能明显有所提升，但这还远远不够，后又引入“金属丝绝缘层”，一旦灯丝有问题，绝缘层熔就会断开始导电。

三、并联部署：上线的基本要求

1. 机房内：多实例容灾
2. 公共服务：多机房、多地域容灾
3. 后端系统：多地分开部署，分开服务

并联在接入层+逻辑层的应用为无状态和CLB（负载均衡）。CLB本身的并联设计为：地区之间，TIX设备正常会记录一系列路由，出现异常TIX设备会及时发现改变机房权重，从而达到秒级跨机房容灾；地区内部，上曾出错直接向下传递，CLB连接同步，即使挂掉两台也互不影响。

四、经验分享

1. 缓存要多，数据库要主备
2. 核心数据 要多级容灾
3. 除了架构上的并联，还可以：过载保护，让故障得到控制；接口级别的柔性可用：绕过故障的非关键接口。

最后强调的一点就是：架构师的职责是取得产品与架构的平衡。

阿里巴巴大数据计算平台首席架构师林伟：高可用的大数据计算平台如何持续发布和演进

阿里巴巴大数据计算平台首席架构师林伟发表《高可用的大数据计算平台如何持续发布和演进》主题演讲，具体分享支持完全托管的 PB/EB 级数据仓库解决方案 —— 阿里 MaxCompute 计算平台在保障数据安全的同时，是如何快速解决用户海量数据计算问题，支撑起每日百万级作业规模的。

那么，如何保证新功能不会造成线上故障？如何处理可测性和安全性之间的矛盾？林伟从编译器 Playback 工具、Flighting 工具等方面进行了深度的技术实现讲解：

1. 编译器：基于 AST 的编译器模型，采用 Pluggable 设计，IDE IntelliSense，Warning 支持；
2. Playback SQL Script 自我验证：利用灵活的数据处理语言来构造分析人物，以超大规模计算能力来并行分析海量用户任务等；
3. Playback 进行新版本验证，精确制导找到触发新的优化规则 Query，验证其查询优化是否符合预期；
4. Flighting 工具：保证 MaxCompute 优化器和运行器正确运行；
5. 资源隔离：CPU/内存上增强 cgroup，磁盘上进行统一的存储管理，网络方面确保 Scalable Traffic Control，通过以上手段实现在保障线上核心业务需求情况下进行 Flighting 测试；
6. 数据安全：无需人工干预进行数据脱敏，Flighting 任务结果直接对接分析任务产生测试报告。

58赶集集团转转事业部资深数据研发工程师李军：转转二手交易平台大数据体系化与高可用实践

李军在演讲中重点阐述转转二手交易平台在二手业务的高速发展下，数据如何体系化、平台化、高可用。纵观数据采集——数据传输——建模存储——统计挖掘——可视化这一发展全程，每个环节都有其难点需要一一突破。为了应对系统可用性差、维护成本高、体验不统一以及业务增长和数据运营的矛盾等问题，团队展开数据体系化操作，包括数据仓库化和数据平台化。

在数据仓库化的介绍中，涉及数据的结构化、低耦合、主体化、模型化、ETL，以及高可用。论及数据平台化则关注全局架构、数据架构以及BI平台等。在BI平台方面，团队只做了两项工作，包括业务需求抽象分类和多样性解决方案。而此处实时多维统计对监控的意义就在于保证数据的时效性，通过服务降级和水平扩展实现高可用。同时，所谓“一图胜千言”，还要实现数据可视化。

更多精彩内容，请关注图文直播专题：SDCC 2016中国软件开发者大会，微博：@CSDN研发频道，订阅CSDN官方微信公众号（ID：CSDNnews），即时获取大会动态。