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的一些創新，包括遠程開發、快速打開、差別比較、代碼審閱等。