ArchSummit干货之旅（完结）

有幸应掘金的邀请，参加此次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的一些创新，包括远程开发、快速打开、差别比较、代码审阅等。