有幸應掘金的邀請，參加這次ArchSummit全球架構師峰會。大會在華僑城洲際酒店舉辦，會場恢巨集，服務專業，除了個別分會場位置不夠之外，總體來說非常贊。
由於分會場都擠爆了，上午我只好去較為務虛的主會場。
《普適智慧和普適學習：智慧革命和智慧經濟的引擎》
第一個分享嘉賓是來自新加坡南洋理工大學的黃廣斌教授。
開頭，教授調侃說他們那個年代，學習人工智慧意味著一畢業就失業，但現在他跟學生說你們將來都會成為百萬富翁。然後介紹了歷史上的幾波人工智慧的浪潮。
機器學習的三大必要條件
人工神經網路理論介紹
人工智慧與機器學習不一樣。機器學習是人工只能一個子集。但機器學習將會快速地超越。
教授將幾大人工智慧領域列出來，分析他們的發展趨勢。
然後開始總結人工智慧的幾大趨勢。
接下來是比較深度學習、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的一些創新，包括遠端開發、快速開啟、差異比較、程式碼審閱等。