《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有很多写法和调优手段

相关推荐