阅读 1207

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的一些创新,包括远程开发、快速打开、差异比较、代码审阅等。
关注下面的标签,发现更多相似文章
评论