架构实践论坛

航天信息系统架构师 范钢：互联网+时代下的架构转型

航天信息系统架构师 范钢带来《互联网+时代下的架构转型》主题演讲。范钢表示，好的架构源于不停地衍变。从购物（商城→双11）、订票（购票大厅→网络购票）到打车（街上叫车→打车神器），“互联网+”为我们带来了巨大的变革。但是，作为架构师，在“互联网+”之下，其实承受着诸多压力，面对着瞬时峰值和业务量增长等，架构师需要不断地进行技术升级和改造。

然而，技术升级与改造并非一帆风顺，范钢以自身的实践经验分享了架构师的“八年抗战”，详解为何技术改造会失败及其面临的风险与挑战。首先，原系统积累了大量细微而繁复的逻辑，如果新系统没能正确识别将会让用户对新系统丧失信心。而重做虽然可以快速而有效地摆脱原有系统的技术债务，却也为技术改造带来了极大的项目风险。

图：像更换零件一样更新系统

范钢建议，应采取渐进式的技术改造，让系统适于技术改造，平滑地移植代码，通过对内部结构的优化，使得业务代码逐渐与各个层次、各种技术解耦，最终像更换零件一样更新系统。

搜狗架构师 刘建：搜狗商业平台基础架构演化实践

搜狗架构师刘建基于“搜狗商业平台基础架构演化史”详解了快速迭代下基础架构的演化实践。一个好的基础架构应提供高性能、高可用、高可扩展性的业务支撑平台，支持敏捷业务开发，提升研发效率，并降低运维成本。

从初期的技术服务于业务、优先功能的快速构建、基于数据库交互、团队相对独立，选择合适/熟悉的技术到业务高速发展时期，基础架构面临着性能、可维护性、协作、成本与收益降低等挑战。刘建现场分享了搜狗基础架构探索出来的“四步走”：

1. 初始阶段——All-In-One、快速原型、基于开源/经验、团队独立；
2. 水平化——分布式会话、数据库访问框架、MongoDB访问框架；
3. 服务化——统一通讯框架、服务注册中心、服务监控管理、服务追踪框架；
4. 流式计算——实时日志发布订阅框架。

图：搜狗商业广告平台基础架构图

总结下来，在基础架构构建方面应注意以下四个方面：

1. 接口兼容性

• 基础架构演化虽是一个长期行为，但最好尽早统一；
• 接口兼容为一段时间内同类框架共存提供了基础。

2. 控制风险

• 尽量避免一刀切；
• 双路和灰度方案；
• 监控优先。

3. 易用性

• 提升开发效率，降低出错几率。

4. 开源软件

• 关注开源社区及主流开源组件；
• 基于业务需求选择和优化开源组件，关注成本和收益。

饿了么创新产品研发部副总监 程军：饿了么的整体架构

饿了么创新产品研发部副总监 程军现场分享了饿了么的整体架构。2015年，饿了么相比去年实现了10倍的增长速度，日单280万，峰值约300单/秒，在这背后，饿了么的架构发生了怎样的变化？

从单机时代的NGINX-PHP、HAProxy负载均衡到SOA、Gateway、Service等各个方面，程军详解了饿了么架构的演进，以及所采取的技术方案，按领域拆分数据库，异步消息通知，在MySQL Proxy方面连接重用、限流、读写分离、分库分表，将前后台分离。最终，饿了么的架构进化如下：

小米网研发部负责人、架构师 张涛：小米网架构变迁实践

张涛详解小米网架构如何解决秒杀、拦截黄牛、库存等用户硬需问题。第一代小米网快速、简单、能用，包括官网、订单处理、仓储物流、售后等所有系统都共同一个Database，随着系统间调用的增多形成了网状结构，耦合也越来越严重，由此演变成星状结构，到调度层、业务层、数据层的三层结构。

技术和业务膨胀为小米网的架构构建带来了双重挑战，如何管理才能达到成本最优效率最高？小米网以“业务纵切，平台横切”采用Go、MCC、Nginx、PHP、LVS开发。其通用缓存采用Twemproxy+redis构建，速度快（单节点14万QPS）、可扩展（自动分片）、稳定，异步消息服务支持大量消息通信、分钟级消息投递、自定义消息索引和协议、允许无限消息堆积。同时，通过虚拟化技术降低成本，提高计算资源利用率，同时促使业务系统设计更具伸缩性。

途牛旅游网研发总监 高建：途牛网站无线架构的变迁

途牛旅游网研发总监 高建从服务化推进、南北京机房之痛、性能提升实践、App客户端技术演进四个方面详解了途牛网站无线架构的变迁。

以价格计算服务为例，四种架构对比如下：

1. 同步——通过接口进行交互：其他系统通过调用接口通知价格中心发起运算，价格中心通过接口获取其他系统价格依赖的所有资源；
2. 异步——通过MQ交互，价格中心通过依赖数据库获取其他系统的数据，将计算价格变成两段：先算资源成本价（一个资源多供应商），再算产品最低价；
3. 并发——价库自身的数据（资源的成本价，产品团期起价）进行分库分表，根据产品的访问频度区分冷热数据的计算频率，三维（产品+团期，行程，资源）；
4. 分布式——计算过度依赖数据（检索数据量过大），变成内存数据库，使用Sharding MQ（本地访问，本地计算），Unix域通信（本地通信，提升通信效率）。

图：途牛旅游App插件式开发框架

从最初的主项目包含所有模块，同属一个仓库，代码之间耦合性较高，无公共库的抽象，不利于多个团队协同开发，到不同插件属于不同团队的独立模块，并最终都集成到主工程中，途牛App客户端经历了插件式开发的演变，并引入阿里巴巴开源的AndFix框架，解决在线热补丁修复问题。

快的资深架构师 王小雪：快的打车架构实践

快的资深架构师 王小雪详细剖析了快的从2012年上线到今年与滴滴合并前后的架构实践与演变。从V1的作坊式研发、基本功能可用，V2对核心链路进行优化，确保业务主流程正常进行，到V3阶段的体系化架构改造，在业务量快速增长的背景下，快的建立了研发流程、代码规范、故障问责机制，执行严格的Code Review，梳理链路上的单点、性能瓶颈，建立服务降级机制，并进行小规模的迭代重构，对工程架构进行了分布式改造。

以RPC选型为例，在大规模服务化之前，应用可能通过RPC工具简单暴露和引用远程服务，通过配置服务的地址进行调用，然而只是简单的RPC还不够，除了网络通信和数据序列化，大型分布式RPC还应具备服务注册与发现、降级与容量管理、资源管理等其他要素。对此，基于实际应用场景，快的引入了开源的分布式RPC框架——Dubbo，并现场分享了快的使用Dubbo踩过的一些坑：

• 链式调用的超时雪崩

client->A(timeout:3s),A->B(timeout:3s),A->C(timeout:3s)。B是非关键服务，C是关键服务。B不可用时，A傻等3s最终超时，业务不可用；B变慢，高峰时期A线程耗光，业务不可用。

• 线程优先级隔离

Provider A提供了关键服务A1，非关键服务A2，高峰时A2耗时高导致线程池满，导致A1不能提供服务。

图：Dubbo架构

• 服务不停的上线下线

Provider内存使用不当导致频繁fullgc，触发了Zookeeper的超时被下线，Provider fullgc完成后又向zk注册自己，过一会又fullgc。

• 服务无法注册

用zookeeper做注册中心，配置的注册中心地址只写ip和端口，没有配置注册中心协议，导致用默认的Dubbo协议。

• forbid consumer异常

调用某服务时出现该异常，原因是该服务的所有实例都下线了。

• Zookeeper输出大量的debug日志

配置的log4j不是debug级别，但应用大量出现debug日志，zookeeper 3.4.3的日志系统是slf4j，应用里还依赖聊logback。StaticLoggerBinder.getSingleton()加载了logback配置，默认是debug级别，log4j没有生效。

图：快的实时数据中心架构

同时，快的对数据层进行了改造，以分库分表解决了前台应用的性能问题，以数据同步解决了多库多表归一的问题。但随着时间的推移，后台单库的问题越来越严重。为此，快的基于HBase和数据同步设计了实时数据中心，支持二级索引，并设计一个SQL解析模块，减少后台应用层的改动。

58赶集集团系统架构师、技术负责人 孙玄：58同城高性能移动PUSH推送平台架构演进之路

58赶集集团系统架构师、技术负责人 孙玄以“为什么需要移动PUSH推送”、“单平台、多平台、公司级统一高性能三个阶段架构如何设计优化”等系列问题，开启了《58同城高性能移动PUSH推送平台架构演进之路》的主题分享。移动环境下的弱网络问题、App消息无法触达让PUSH成为硬需，但iOS的平台特殊性不允许Service后台常驻，统一下发APSN（Apple Push Notification Service），而Android平台方案有着开源、自主研发、第三方推送等特性，综合考量下，58同城研发出以基于第三方PUSH推送平台、自主研发高性能Provider相结合的移动PUSH推送方案。

在经过单平台、多平台的演进，移动PUSH推送第三阶段架构和协议应如何设计和优化？孙玄以58同城的移动PUSH系统架构为例进行了深度讲解，包含分层架构体系、push entry/transfer、Android/iOS Provider等。

图：58同城移动PUSH系统架构

那么，如何解决移动PUSH推送的性能问题？孙玄以Android Provider并发低为例，其原因是HTTPS线程不安全，采用每个HTTPS请求加锁，需对线上问题快速临时解决，然后对问题定位分析，找到最终解决方案，并借助libcurl HTTPS，降低锁粒度。

腾讯SNG增值产品部高级工程师、QQ会员AMS运营平台技术负责人 徐汉彬：QQ会员活动运营平台的架构设计演变

徐汉彬表示，活动运营存在上线周期短、个性化强、功能需求复杂、后端接口众多等特征，通过对不同业务活动模式的分析和抽象，绝大部分活动都可以一一组条件和动作的方式进行抽象和封装，进而形成通用的条件和动作活动组件，另外更重要的是通过平台化和框架驱动开发的方式，为通用活动组件的运行提供了高可靠、高性能，具备过载保护和水平扩展能力的框架支撑环境，活动组件只需要封装自身业务逻辑，核心功能框架自动支持，从而实现了高可靠高可用活动开发的彻底自动化。

但是，这是一个美丽的愿景，而实现这个目标就是最大的挑战。在此之下，AMS需要解决的问题就是高效活动开发模式、高可靠性和高可用性、保证活动运营业务的安全。AMS平台服务架构对外部提供不同维度的服务入口，TGW、手Q的SSO、内网通信等，AMS集群仍然属于同一入口。但做了物理隔离的集群部署，减少集群之间的相互影响。