《ArchSummit深圳2014大会》参会笔记

7月18至19日参加了为期2天的《ArchSummit深圳2014大会》。42位讲师、700多位听众，包含10个热门专题、41场精彩演讲。以下是我在聆听分享时的笔记，是我个人对内容的摘记和理解。

大会完整讲稿下载：http://pan.baidu.com/s/1gdvKbKn

 

 

构建大型云计算平台分布式技术的实践(阿里巴巴)

章博士每次演讲都干货实足，各种解决问题的思路和方法，非常值得我们深思和借鉴

1.可靠性/高性能/低成本/安全性/快速定位并解决线上问题，是云计算平台的基本需求

2.云服务器ECS是阿里云销量最大的云产品，ECS控制系统可管控3千6百台物理机，未来支持5千~2万台

3.ECS的分布式存储为确保数据高可靠，原先同步写3份，但延时大/路径长，现同步写2份，第3份异步写

4.存储优化思路：(1)SSD+SATA (2)加Cache (3)多线程事件驱动，一个线程内完成所有以避免锁和上下文切换

5.本地IO路径上的各层Cache：

   应用程序Cache(如MySQLBufferPool)->操作系统Cache(如LinuxPageCache)->存储介质Cache(如磁盘缓存)

6.由此引出写IO的4种模式：

   (1)Buffer Write (2)Direct Write (3)Write+Sync (4)O_Sync 对应的写逻辑分别是：

   (1)应用程序写Page Cache (2)直接写存储介质Cache (3)写入后调Sync刷盘 (4)写入后同步刷盘

   结论：越是试图保证写成功的写模式损耗也会越大，通常(1)+(2)是主流，适合完成97%的写操作

7.云环境中的IO，将本地IO路径中的存储介质Cache变成分布式Cache，即先写进分布式Cache再按策略刷盘

   Cache方案的好处是：(1)加速写请求 (2)降低分布式存储系统的抖动对上层应用的影响

8."写做的好，比读还快" - 正明

   “若有1%概率的请求延迟超1S，并发100请求，然后等所有请求返回，延时超1S的概率为63%” - Jeff Dean

9.SLB是负载均衡产品；RDS是数据库服务；OCS是缓存服务。各产品的特点也即分布式系统设计，见讲稿

10.全链路监控与分析系统，目前已运用在RDS和SLB上，架构上分为4层：

     数据采集：采集SQL日志、网络状态和用户行为等数据

     基础设施：将数据写入Kafka集群，再分发给数据分析层

     数据分析：接到数据后，用JStorm/Spark做实时分析，ODPS做离线分析

     数据运用：将分析出来的数据，运用于如监控系统和开放日志服务等产品

 

 

使用亚马逊Web服务(AWS)构建高可用架构(亚马逊)

来自亚马逊首席布道师Carlos Conde，这哥们英语语速太快，实在听不太完整 ，介绍了5种高可用设计模式：

1.DESIGN FOR FAILURE(面向故障设计)

   "Everything fails all the time" - Werner Vogels(CTO of Amazon)

   目标：当底层物理硬件发生故障，而需被移除或者被替换时，上层应用仍能继续提供服务

   预案：避免单点故障，承认一切失败，设计回退功能

   方法：HEALTH CHECKS(健康度检测)

2.USE MULTIPLE AVAILABILITY ZONES(使用多份可用冗余)

3.BUILD FOR SCALE( 构建可扩展系统)

   HEALTH CHECKS(健康度检测) + AUTO SCALING(自动扩展) = SELF-HEALING(自我愈合)

4.LOOSE COUPLING(设计松耦合架构)

   使用消息中间件(如Amazon Simple Queue Service)解耦，努力实现基于消息驱动的架构体系

5.AUTOMATE & TEST(自动化&测试)

 

 

运用6种有效Web编程模型构建中大型电子商务网站(携程网)

讲师总结了常见的6种应用编程模型(Application Programming Model)，分别是：

Web APM：Web编程模型，采用MVC结构分层，运用HTML/CSS/JS等技术实现

API APM：API模型，Web Service/RESTful Service

Batch APM：批处理模型，构建任务处理集群，通过ZK调度任务，实时性要求不高，偏离线场景

Email APM：电邮模型(是否用Message APM更为何适？) 通过邮件/微信/短信实现业务讯息场景

Async APM：异步模型，通过消息队列实现异步化的逻辑处理，实时要求较高，适合偏前台业务

Mobile APM：移动应用模型，分为Native(iOS+Android+WP)应用，或使用HTML5打造移动应用

嗯，的确就介绍了这些～

 

 

即时通讯架构(陌陌科技)

陌陌的通讯服务由连接集群、逻辑集群、服务化的数据集群构成：

1.连接层，允许随时重启/不允许重启断线，简单/异步原则，总连接数1200万+，单机70万连接，一般用50%

2.逻辑层，支持随时重启，职责是用户会话验证/消息存取/异步队列/消息中转等业务逻辑

通讯协议原则：安全/节流/传输高效+可靠，如XMPP/SIP协议：大量XML标签耗流大，连接不可靠，交互复杂

协议对比：

1.基于队列的消息协议：

   传统的IM协议，FIFO形式维护顺序，通讯交互次数多，服务器要维护每个状态易出错，不适合移动网络场景

2.基于版本号消息协议：

   陌陌采用的协议，基于版本号可连续发消息，接收端按版本号维护顺序，接收端回馈最后收到的消息版本号

其它通讯协议设计要求：核心长连接只传输轻量的实时数据；图片/语音等新开TCP或HTTP连接；连接可监控

 

 

唯品会技术架构面临的挑战和应对策略(唯品会)

日均4亿PV、69000个QPS，每天上午10点是全天峰值，研发团队约1200人

应对业务发展和访问攀升，针对网络/硬件/数据库/应用各层都有优化和升级(均是常见手法不赘述)

唯品会服务化平台OSP(Open Service Platform)：

基于Facebook的Thrift协议(因内部多语言)，通过IDL描述接口和模型，服务支持同步或异步处理

OSP支持动态扩容，完全分布式，支持服务注册、路由、负载均衡，支持服务治理和监控

还在研发中所以细节讲师并未透露。目测OSP的主要特性均基于Thrift本身的特性或有一定的改进

 

 

系统架构去哪儿了(去哪儿网)

去哪儿网在近10年的时间里，先后经历过3次重大的架构升级改造

前两次包括从自主研发到拥抱开源，从单机到分布式，从单一应用到按职责拆分等

而最近一次是2012年至今，基于阿里巴巴开源的Dubbo服务框架完成了服务化改造

接下来主要是：异步化、继续解偶、提升服务可运维性和可靠性等

 

 

京东应用架构设计与治理(京东商城)

架构目标：可用性(整体4个9单个5个9)、可扩展(耦合低/水平扩展)、低成本(人员/系统/服务器)，多快好省

从4个方面对质量进行要求：运行时质量、设计质量、用户质量、系统质量

京东架构设计总体原则：

1.业务平台化，基础业务下沉，可复用

2.抽象化，服务抽象化，应用集群抽象化，数据库抽象化，服务器抽象化

3.容错设计，核心服务自治，应用集群水平扩展，多机房部署

4.异步化，不同业务域之间尽量异步化，非核心业务尽量异步化，应用系统尝试SEDA方式

记得前些年，京东每搞大促活动，系统或容易宕机或响应时间变长，当时老刘刀子都掏出来了(据微博照片)

这次与京东讲师交流：近年引入大量架构资深人才，在中间件/核心系统的建设上压重兵，稳定性深入架构

比如今年618大促，前期准备包括扩容、预案、线上压测，当天主要运维方式是流量控制、监控、故障转移

京东的监控也能支持展现出应用的依赖关系，分析出应用间血缘，按运行情况实时计算相关指标并进行预测

(综上，阿里系虽仍占据技术领衔但近年来SOA均已成各大电商架构标配，且稳定性等方面经验也逐渐接近)

 

 

综上三家国内一线电商：

1.SOA均已成为各大电商的架构标配

2.成熟开源社区使中间件的差距缩小

3.稳定性等电商必备的经验逐渐平衡

我认为各电商在总的架构上区别已经不大，在相关基础设施和人员经验的差距在慢慢缩小；

技术层面比拼就是尖端技术/用户体验/敏捷开发了，谁能做好谁就能带动业务，甩开差距。

 

 

小米的大数据系统应用与实践(小米科技)

小米存储与计算团队，2012年10月成立，分成存储/计算/开放平台三个小组，目前有14人

15个集群(9个在线服务+2个离线处理+2个测试)，支持业务20+，如MiCloud/米聊/MIUI等

开源作品：

• Minos：自动化监控/部署框架

• Chronos：高可用高吞吐全局严格单调递增时间/序列生成器

• Themis：跨表、跨行事务(基于HBase)

社区贡献：147个Hadoop patches，270个HBase patches

Patches比如有：写优化(HBase-8755)/反向扫描(HBase-4811)/细粒度复制(H-8751)/跨表跨行事务(H-10999)

比如写优化：老模型中WriteHandler既Write又Sync，锁竞争激烈，优化后单独线程完成Write和Sync无锁竞争

计算平台，由Hive/MR/Impala/Spark/Storm进行前端计算或查询，后端存储为HBase和HDFS，由ZK调度各层

内部存储开放平台，由FDS(文件存储)+SDS(基于HBase结构化存储)+MR组成，对外提供RESTful API和SDK

 

 

复合创新-腾讯数据中心技术发展(腾讯)

数据中心是融合信息产业和传统产业的跨界产业，涉及电力/消防/制冷/布线/网络/监控/建筑等数十种专业

腾讯在深圳宝安、蛇口、坪山，以及天津等都建有数据中心，上海青浦的云数据中心，将于2015年交付

对高压直流240VDC电源进行拓扑改造，抑制大谐波等问题，用于数据中心配电主架构，精简了配电架构

服务器两电源分别接市电和高压直流，各一半负载，在满足可靠性下实现96%的效率，再次简化配电架构

微模块化创新，通过标准化/工业化/产品化，使基建与IT建设分离，基建完成后，IT设备便按标准灵活部署

综上方法论：从机架到园区全程模块化设计和建设， 机柜/IT模块/建筑单体/园区模块化的设计原则见讲稿

腾讯数据中心研究方向：电力系统(新能源/电池革新/busbar)，制冷系统(空气处理/置顶空调)，自动化管理

讲师观点：

1.认为数据中心缺乏一个成熟的自动化管理系统，并且认为此为百亿级市场，呼吁业界为之投入

2.能源问题，是未来数据中心关键

3.数据中心长期方案：(1)前店后厂 (2)大云西移(云指数据中心，西指向西部推进，因为光电/光热/风能等)

目前腾讯基础设施团队正式员工80人左右，再加外包员工

这实在是一个非常酷的Topic，大开眼界！

 

 

开源运维软件在小米的应用(小米科技)

从运维架构上定义了"服务树"，后续所有的运维都是基于服务树体系展开。服务树可以理解为机器TAG

服务树：基础信息(公司/部门/产品)、服务信息(服务组/服务/服务实例组/服务实例)、状态信息(机器状态)

小米"服务树"体系的提出是为了解决：机器管理混乱，能实现批量操作，多环境管理，自动化运维、监控

ANSIBLE：初始化及批量操作，优势是无需额外Agent支持/扩展性/模块化/基于目的状态管理/社区很活跃

FRIGGA：守护进程形式，职责是接收命令并触发执行。客户端管理，结合GOD，可实现双升，互相守护

THOR：部署系统，首先下载要部署包文件，按发布包内的模板生成配置，进行部署，触发God启动程序

GOD：守护进程形式，职责是启动程序，启动后并管理该程序的生命周期，比如该程序若挂掉则再启动

 

 

花瓣客户端3.0的开发模式与ReactiveCococa的使用(花瓣网)

编程现状是不断堆积判断状态的逻辑，比如实现"赞"功能，需要判断是否登录/赞过/是否点击/是否有返回响应等

“编程的本质是控制复杂度” – The Art of Unix Programming

ReactiveCocoa(RAC)是Github工程师们开发的一套FRP(函数响应式编程)框架，改变了传统的Cocoa编程模式

RAC试图解决的问题：

1.解决状态及状态之间依赖过多的问题

   引入Signal概念，来代替传统iOS开发中，对于控件状态变化检查的代理(delegate)模式以及target-action模式

   Singal是可组合(Combine)，可构造出一个新信号，支持链式(Chaining)和过滤(Filter)，也可自定义映射(Map)

2.传统MVC中Controller容易变大复杂

   RAC的MVVM(View-ViewModel-Model)模式，ViewModel与View绑定后使Controller变简单，并可提高可测性

但RAC的编程方式和传统MVC差别很大，需要较长学习时间，并且还没有开始被广泛使用，缺乏文档以及教程

 

 

实时系统架构与实践(云巴网)

针对实时内容分发/实时聊天/实时统计等业务运用场景，讲师叙述了构建实时系统时的分层模型和每层解决方案：

1.协议的选择：

   MQTT(Message Queuing Telemetry Transport)

2.负载均衡：

   负载均衡不妨从客户端做起(讲师观点)

   如TicketService：客户端请求后实现动态分配接入点，TS也可预埋目标IP，能解决DNS解析缓慢或失效等容灾

3.前端服务器设计：维持客户端长连接，同步缓存请求，异步处理请求

4.基础服务：订阅关系服务/离线消息存储/全局路由表/统计服务/高性能K/V

5.自动化运维：Ansible

 

 

手机淘宝的客户端架构探索之路(阿里巴巴)

手机淘宝为"航母级"应用平台，需在手淘上承载并整合多样的业务(即各业务的App能整合在一个大而全的App上)

2010年时手淘1.0是披着App外衣的Web，到2012年3.0时的单工程多分支的开发模式，再到2013年的插件式开发

2014年进行了手淘有史来最大规模的组件化(Bundle)重构。讲师围绕组件化特性和所达成目标关键词进行介绍：

1.归一：一个组件就是一个完整的工程，包括界面元素和业务逻辑，开发和运行阶段都基于Runtime和Bus Library

2.轻量：Runtime微内核(约150K)，含启动流程(容器初始->类加载->中间件初始->启动入口Bunlde)和组件管理等

3.透明：

   Bundle即App，容器亦OS，即开发一个Bundle与原先开发App无差异化，在容器上运行也和直接在OS运行一致

   二级容器，若是WebApp则基于WindVane，若是NativeApp则基于MicroApp Runtime，但均基于组件Runtime

   三大总线：UI总线、服务总线、消息总线，这三大总线均为OS能力的封装

4.延展：标准化(Bundle交付物AAR，构建物AWB)、灵活性(自由组装/对容器无依赖)、适应性(按需采用容器能力)

5.敏捷：AOP形式，对线上问题快速修复，对Framework代码打补丁，暂时只支持Dalvik，将适配ART以及云OS

Native App随业务发展容易变得越来越重，那么Natvite App能否将Web网站一样随时部署，即用即取，轻盈呢？

1.资源(图片)能否云端+Cache化，而现在是打包在App内，增大App的Size

2.中间件全面Bundle化，细粒度化，支持深度可复用，按需定制进App等等

3.基于依赖结构的代码(Class)实现按需加载机制(类似Require.JS)，也就是：

像打开Web网站一样，打开到哪一页，就加载哪一页的资源和执行这一页的代码逻辑，再次打开时从缓存中读取

以上是讲师针对Native App未来开发、打包和运行模式的思考

 

 

Linux内核在UCloud云平台上的实践(UCloud)

针对内核、硬件、性能三个方面，各举一个实例，讲述了UCloud在内核定制开发的实践经验

1.内核的免重启修复：

   将源码的补丁，基于ksplice生成热补丁模块，植入运行中的内核实现免重启修复

   成效：所有内核BUG均免重启修复，累计数万台次，无性能损耗，中断十毫秒级

2.内存硬件故障隔离：

   当发生内存错误时进行错误评级判断，包括可纠正/不可纠正不可恢复/不可纠正但可恢复等

   如果错误发生在可恢复的普通进程上，则隔离或杀死该进程

3.磁盘写IO模式加速：

   写IO的加速模块接管所有的IO，写IO会被顺序化至Cache盘组，Cache盘组同步至真实盘组

   (这个思路和章博士的Topic中，针对给写IO加Cache而实现提速的方法是一致的)

 

 

 

 

 

附技术大会参会指南：

已前后参加过3次类似规模的技术大会，对参会经验做了些小小的总结，适合将要参会的同学们参考

首先不要太期待能仅仅通过聆听演讲，就能获取知识和经验。所以基于此要深挖掘技术大会的价值：

1.要学会记录关键词，然后务必进行延伸学习(如网上搜索关键词的资料等)，并注重会后的动手实践

2.带上问题积极交流，是解决疑虑碰撞火花的有效方式，不要认为已完成的就是最优方案都可以拿出来再交流的

3.尽量找感兴趣的听，但并非你不感兴趣的就一定无干货，学会抽象学习，越是一线程序员/架构师分享才越有料
4.并非讲师说的就一定正确，术业有专攻，要学会对讲师分享进行提炼和验证(交流验证和动手验证)

 

第3点举例：

比如本人对iOS开发是一窍不通的

但聆听了ReactiveCococa的分享，也学到了RAC在响应式和函数式的设计思路和MVVM模式，对我是很有帮助的

 

第4点举例：

比如某场分享中，有讲师提到Erlang实现的系统遇到了CPU和内存的短板，正在计划用C替代重写掉

但我们不能持有"有问题就换语言重写"这样的态度，往往有问题的是代码本身，况且Erlang有很多写法和调优手段