有幸应掘金的邀请，参加这次ArchSummit全球架构师峰会。大会在华侨城洲际酒店举办，会场恢宏，服务专业，除了个别分会场位置不够之外，总体来说非常赞。

整齐划一的签到处

大会LOGO悬浮雕塑

大会问询台

开幕发言

由于分会场都挤爆了，上午我只好去较为务虚的主会场。

《普适智能和普适学习：智能革命和智能经济的引擎》

第一个分享嘉宾是来自新加坡南洋理工大学的黄广斌教授。

开头，教授调侃说他们那个年代，学习人工智能意味着一毕业就失业，但现在他跟学生说你们将来都会成为百万富翁。然后介绍了历史上的几波人工智能的浪潮。

机器学习的三大必要条件

人工神经网络理论介绍

人工智能与机器学习不一样。机器学习是人工只能一个子集。但机器学习将会快速地超越。

教授将几大人工智能领域列出来，分析他们的发展趋势。

然后开始总结人工智能的几大趋势。

教授说物联网的人工智能前景也很大，没必要全部押注在云端。

在未来，大公司可以开发人工智能的接口，给其它第三方使用，可以不需要扎堆去研究某一个领域。

接下来是比较深度学习、ELM和生物学习的优势劣势。

总的来说教授讲的东西偏趋势性，能够大概理解人工智能的这个领域的前景，不地这离你真的能上手人工智能还很远。

Data Outsourcing in Cloud Computing: Reliability, Security and Privacy

接下来的一位是来自WalmartLabs的工程师经历曹宁来分享。这个是讲中小企业将数据安全地、可靠地、私密地外包到云服务商那里。

首先当然是讲讲将数据外包到云计算的优势，高度灵活性，经济适用性。

尽管将数据外包到云服务有诸多优势，但客户门，尤其拥有敏感数据的客户们，如政府部门、银行等，对云计算的数据外部提出诸多要求。他们需要非常可靠的数据存储服务。

他们的担心不无道理，云服务会遇到以下的一些挑战，如，硬盘问题、外部攻击等等。

那怎么样提供更可靠的云端存储技术呢。讲师提出了两个方案。

首先是 Redundancy Technique，它下面还有几种子方案：

然后是 Fountain Codes。这里听得有点晕里雾里，感觉应该是在讲述数据的传输，还有修复的问题，上几个PPT给大家鉴别。

Exact Repair意味着数据是一模一样的，而Functional Repair则可以不一样，但使用起来一致就行。

下一步份是讲解云端数据加密的问题，提供了两种加密方式。

大疆服务网关全球化设计和实践

上午最后一个分享，听了大疆的实践。下图是在酒店现场的无人机展示。据说大疆当天去的都是HR，招聘人才之心路人皆之。

由于大疆是最球化企业，因此需要部署全球化的网关，随着管理的ip越来越多，开始需要权限管理。

以下是大疆设想中的网关架构图。

然后讲师介绍了几款开源产品的，发现各自有各自的问题，并不适用于大疆的情况。

底层基于Elastic Search。有非常清晰的调用id。

如何去计算最短路径的网关。

当前大疆在使用的全球化网关架构图。

微信 Android 模块化架构重构实践

今天的最佳分享，非微信的Android模块化架构重构实践莫属。思路清晰，从提出问题，到解决问题，让观众一目了解，受益匪浅。

开篇先回顾了微信Android的架构，让大家有一个背景的了解。

然后用图片形象地说明微信Android端是实现模块化开发的。

但随着业务增长，模块之间、模块与基础工程之间、基础工程与组件库之间耦合越来越严重。

然后列出微信错综复杂的业务关系，这使代码耦合成为大概率事件。

问题出在了几个地方，首先是基础工程代码膨胀，这是由于采用Event总线作为通信手段导致的。

主工程也膨胀了，这是由于开始设计的生命周期遗漏了程序启动导致的问题。

最后就是代码的边界模糊，模块之间没有很好的代码约束。

为了使模块化开发更好，决定重构。拆解成三大目标。

通信方式从事件总线程，改成由SDK约束。

暴露出简单的使用借口。

重新设计生命周期，补充使之完整，这也让加载的过程有所变化。

结合构建工具，提出pins工程结构，让代码粒度变小。

重构效果可人。

建一支分布式的远程团队

下午听的第二个分享是网红左耳朵耗子带来的。内容并不是很艰辛，但以比较有趣幽默的方式呈现。

开场先以戏谑的方式自嘲，说自己面临中年危机，因为价值观不正确被阿里辞退，最后作死创业的人生经历。

然后讲述了自己创业的三点原因。

讲了讲创业与普通工作的一些不同点。

但他的创业，有些不一样，他和员工的是采用远程的工作方式。

可是，远程工作也会遇到一些问题。

这个是他认为的最大问题，哈哈。

要如何提高效率呢？首先给出了效率的定义。一个公式，简单明了。

几点提高效率的方法。

对于工业社会，大都喜欢这类工厂工流水线作业的组织方式。

而现在更倾于电影工作组这种，发挥主人翁精精神的方式。

讲师将远程工作团队，比喻成一个登山团队，一个小而粗，有能力，有相同目标的团队。

采用这种远程工作协议的方式，能更有效提升工作效率。

Move Fast and Break Things: Engineering at Facebook

最后听的一场的讲师是来自Facebook性能团队的开发经理：Joel Pobar。

开场先给FB吹了下牛B，说已经有20亿人在使用Facebook及其相关产品。

一幅图来介绍闭环的反馈能够更好地优化服务。

这个反馈闭环主要从两方面讲，一个是产品开发，一个是职业发展及规划。

这个是Facebook的产品开发闭环，从决定特性，到开发，再部署上线试验，到收集数据反馈，然后再持续进行产品优化。

他们的开发环境与线上环境一样。

良好的code review习惯

部署上线前，代码都会事先作为beta版本发布到员工手机上。

产品试验中，最常用是A/B测试，基本上所有Facebook的新特性都会通过这个测试进行。

你可以选取各种维度进行测试，如性别、年龄、地区等。

上线后，会有全球的数据反馈，提供决策所需要的数据。

接下来是职业发展方面的反馈。乍一看，有自主、同事评还有经理评价，有点像腾讯内部的职业评价体系。

还有一个团队的评价，评价员工觉得当前所在的团队怎么样。

讲完之后，开始描绘Facebook引人入胜的工程师文化。首先是同理心，比如Facebook的地区研发总裁总是会时不时利用Facebook与员工沟通，回答员工的困惑。

然后讲述一些新入职员工的必答问题，他们会通过这些问题甄别面试者是否适合公司文化，他是否是一个自我驱动、学习能力强、合作能力良好的人才。

最后是目标制定。一般公司都是自上而下的，由CEO制定愿景，然后再由各经理们拆分，然后定各种KPI。而Facebook则是由CEO制定愿景，底层员工制订目标和KPI，经理负责保证员工的目标与公司一证，以及协助他们完成目标。

========================第二天==========================

Web 加速，协议先行

第二天主要关注性能方面。首先是听了我司TEG罗成介绍的HTTP2的优化

这里罗列了一些常见影响Web性能的问题，但今天主要讲的是协议。

这里粗略介绍了HTTP2的知识，HTTP2许多基本用法跟HTTP1.1保持一致。例如GET, POST，都只是在HTTP1.1的基础上进行了封装而已。横线以上的步骤，是客户端可以自己控制进行优化的地方。

这里讲解了HTTP1.1的性能问题，不外乎是请求数量受限、头部没有压缩等。

在上一个时代的HTTP1.1优化，确实是取得不少的成果。

可是，新时代随着HTTPS的普及，HTTP1.1的优化显得不合事宜。逐步被淘汰，HTTP2应运而生。

因此讲师进行了一些线下模拟测试，并且结合后台的对业务进行数据采集，准确发现当前在协议层面遇到的性能瓶颈。

Web访问速度优化方向。

TCP速度优化，可采用TFO，实际上是第二次握手的时候直接带上session, cookie，省掉了一个来回。

这个是即将从草稿成为最新标准的TLS1.3。

HSTS能使访问者直接跳到HTTPS页面，而不需要经过HTTP再302转发到HTTPS页面。

SPDY算是HTTP2的先驱，大体的优化都一致，除了没有头部压缩以外。

如果能正常使用HTTP2技术，HTTPS的访问速度是可以超越HTTP1.1的。

从以下两方面分别说明HTTP2可能是未来，又可能不是的原因。

Go Microservice 微服务架构模式

下面转场去了听微服务。是由bilibili 的技术总监毛剑介绍他们公司的服务架构。
讲师从微服务设计、高性能、可用性、一致性四方面介绍bilibili的微服务架构。

首先是将一切的后台接口都设计成服务。

性能方面，由于bilibil是视频网站，刚建站的时候遇到很慢，且很贵的情况。因此要通过以下一些加速手段进行优化。

后来还自己写了一套网关系统。

一开始是这种将各个功能拆开，部署在不同机器上，这样导致扩容困难。

后续将不同功能的合到一个机子上，维度变成，扩容会更容易。

为了达到高可用，他们采取了以下一些措施。首先是隔离，一开始是物理隔离，后来采用了docker虚拟机隔离。

服务超时也进行了处理。

不仅对单个服务，如果有一个服务依赖的链条，会对整个链条进行超时处理。

限流，用于对服务器的保护。

从客户端采取措施，减少重复请求。

容错，一旦抗不住压力，马上熔断。正常后再恢复。

降级是指一旦新服务出错，后台或客户端可采用降级的方面保证体验性。

一致性，主要是两个方面，一个是数据的一致性，另一个是服务（多节点服务）的一致性。

Mobile Performance At Scale

这次是由Facebook的人来讲。其实并没有太大新意。这里主要提几点吧。

Move Fast and Build Things, 这算是Facebook工程师的座右铭。

这是一些常见的性能指标

常见的误区1：模拟器通过不能提供到真实机器上的性能数据。这是由于机器不同，导致给出来的数据可能是错的。

误区2：减少人工测性能

因此Facebook建造了大型的测试机器中心

将所有的机器都变成了服务。

Facebook常见的A/B TEST 用于性能测试

误区3：即使有好工具，许多人不使用

由于要在整个开发生产闭环添加各种工具进行监控和测试。

Hulu基于DASH构建的高清直播系统架构及实践

接下来听了Hulu工程师讲解用DASH构建直播系统。
下面几点是新Hulu界面的一些特色。

DASH的概念

缩短分段是常用的优化延迟的手法。

YY直播基于软硬件的弱网深度优化

这里列出视频卡顿的三大原因。

弱网的软件解决方案。

如果带宽低，则优先先发送关键帧。

弱网的硬件解决方案，就是提升上行网络可用带宽。

YY造了一台小型硬件，可以插入多个电信SIM卡，可以同时采用加大上行带宽。

Facebook 的代码开发工具

又去听了一场Facebook的分享，基本将全部Facebook的分享都听完了。这次带来的是他们自己开发的代码开发工具，Nuclide。

这里讲了Nuclide的一些特色，分别是开源、远程开发、源码版本控制、构建集成、调试等。

Facebook使用Nuclide的原因。

远程开发
多语言及项目支持
开发平台
与Facebook的工作流程深度整合

后面讲解Nuclide的架构

首先要求它是跨平台的，并且可以远程开发，可以进行扩展。

Nuclide是基于文本编辑器Atom进行二次开发的，而Atom则是基于Electron。

Nuclide将语言作为一种服务，提供自动补全、上下文查看、类型检测等特性。

下面是Nuclide的一些创新，包括远程开发、快速打开、差异比较、代码审阅等。