周六（2016、4、9）有幸在廣州參加了魅族發起的技術沙龍，期間有100+人參加。
可見，廣州Iter也是求知若渴的啊，同時也說明廣州，技術氛圍可能沒有北京和和深圳強，希望以后土豪們多舉辦一下類似活動。
文章內容並不完全涵蓋了沙龍所有內容，只記錄了印象深刻，或者之前沒接觸過的知識（記憶能力有限哈）。
總結的內容，不一定和演講者表達完全一致（理解能力有限哈）。寫下此文，為總結與分享知識。
這次線下沙龍總共分為4個部分：
《魅族雲同步的實踐與演進》-魅族高級架構師沈輝煌
《唯品會適變業務的架構洞察》-唯品會資深業務架構師官華
《九游平台技術演進》-微服務中心運維平台的產品負責人梁文剛
《魅族廣告業務HTTP接口的灰度方案》- 魅族高級開發工程師吳浩清
一、《魅族雲同步的實踐與演進》-魅族高級架構師沈輝煌
關於雲同步，最大的感觸是，要做一些比較復雜的軟件，要有一些基礎理論規則支撐，例如，做之前，要定好數據同步協議。
（1）同步協議
1、同步數據格式演進： Json ---> 精簡Json(變量名用1一個字母代表) ---->順序Json(直接把變量名省了掉，變量按照順序排列) + Gzip壓縮
這個變動可能很小，但是對於1天PV億級的應用來說，優化的總量也是很客觀的，傳輸數據少了，一方面節省了用戶流量，更重要的是節省了服務器帶寬，為此，我不禁感嘆，優化真是無止盡。
最終理論優化成果： 傳統Json * 50% * 60% = 30%，這就是Money。
2、傳輸協議划分。因為手機同步的數據類型、同步方式使用不同的同步協議，例如數據類型有短信、網址收藏夾這樣的小而多的數據，也有照片、視頻這樣比較大的文件；同步方式，有實時的小操作增量同步，也有換新手機，第一次初始化的全量同步。數據同步協議，需要解決的難題有可靠和安全數據傳輸、斷點續傳、數據同步沖突、減少服務器等待時間。而解決這些問題，業界有一個標准的
SyncML協議，魅族在此基礎上，進行了實現、幾種方式的應用和改進。
（2）架構設計
1、不同業務系統分為不同的Unit部署。同步大文件的服務器，消耗IO比較大，用戶可接受的等待時間比較長；同步小文件，應該是快速，高速的，不同的同步業務，用戶要求，服務器要求不一樣，所以，按照不同業務功能划分服務器，對於服務用戶、運維、調優、監控有很大的意義
2、全國多地部署，就近訪問。多地部署，一方面是提高用戶訪問速度，另外一方面也有異地容災的功能。為此，魅族自主研發了GSLB框架來實現這個功能
3、存儲方面采用了傳統RDB和HBase結合的解決方案。RDB，根據Userid水平拆分數據庫，底層架構實現了數據訪問自動路由，對於業務系統開發無感知
二、《唯品會適變業務的架構洞察》-唯品會資深業務架構師官華
關於業務架構分享，官華老師有20年的IT經驗，曾經是知微的CTO，因此分享的內容比較宏觀，侃侃而談，洋洋灑灑幾十頁PPT，在有限的時間內，講的很廣泛，不是很深入，所講的知識太多，我印象比較深，和管理問題和幾個之前從未聽說過的概念，零散總結如下：
（1）軟件開發協作，管理上面失控問題。意思就是說，從管理上面來說，管理幾個人、管理幾十人、管理幾百人，不單單有數量的區別，還有本質的區別。人多了，人員結構太扁平，會累死上面的人；如果人員結構層級太多，從上到下、從下到上溝通和執行也會有問題，容易累死下面的人。但是如何解決這個問題，沒深入討論
（2）系統重構和轉型，必須小步快跑，穩定向前，一下子顛覆性的改變，通常會失敗
（3）CQRS模式：命令與查詢分離。具體問百度君貨谷歌君
（4）微服務：把小的服務開發成單一應用的形式，每個應用運行在單一的進程中，並使用如HTTP這樣子的輕量級的API。這些服務滿足某需求，並使用自動化部署工具進行獨立發布。這些服務可以使用不同的開發語言以及不同數據存儲技術，並保持最低限制的集中式管理（網上摘錄）。 字面上面的理解，就是盡量把應用變得更小，讓應用之間相互影響變小。
三、《九游平台技術演進》-微服務中心運維平台的產品負責人梁文剛
聽梁文剛大哥的演講，感覺和題目結合得很好，把演進說的很清楚，收獲頗多。
九游系統演進過程主要分為三個階段：復雜龐大一套大系統-------->分布式系統------->服務治理（目前很多公司處於第二階段，例如博主所在公司）
一套復雜的系統------>分布式系統，這個我都有所了解（不管你知不知道），就不贅述了，關鍵總結一下，第三階段，服務治理這一塊。
大伙都知道，分布式系統架構，各個系統之間，肯定要數據互通互聯、功能共享，不管你是采用reful api\wcf還是其他調用方式，系統之前有數據流動，肯定會存在依賴。
用九游來舉例子，200+個子系統，相互調用，形成網狀結構，沒有一個人能夠完全說得清，各個系統之間相互調用邏輯！
我個人理解，服務治理，本質上就是要把這些復雜的關系管理起來。服務信息化、流程化，起到業務梳理、服務資源分配、服務質量管控、服務監控的作用。
服務治理后，你可以想象一下，這樣的美好場景：
1、系統會有一張圖，可以直觀看到幾百個系統，接口之間是怎么調用的
2、某個WebAPI接口受到攻擊，或者有故障，你可以在系統上面點點鼠標，就可以把這個API停用掉
3、某個服務調用比較頻繁，在系統點點鼠標，你就可以為這個服務分配更多系統資源
4、在系統中，可以直觀看到，哪個接口有故障，失敗率是多少、調用時長的多少
對於系統演進，個人最大的感觸就是，系統進化，總是為了解決遇到的某個問題而變化的。
四、《魅族廣告業務HTTP接口的灰度方案》- 魅族高級開發工程師吳浩清
關於灰度的話，記得之前在網上看過騰訊分享的灰度發布策略，跟這個有點類似。分享者浩清提及了很多實現的細節，收獲也蠻多的。
實現的原理，主要是在系統調用總入口開發多了一個網關層。這個網關層，根據用戶來源和灰度規則，把相應的調用請求分發到各個子系統，核心解決了不同版本的解決發布比例問題。
最后附上一張現場照片：
以上總結，如有某些知識侵犯到了相應公司權力，請及時聯系刪除。不過相信既然是開了分享沙龍，也是抱着開放的心態分享技術，促進IT行業的發展，所以我也大膽發出來了。
最后，感謝主辦方之一 msup的大力支持，我們才有可能，才會機會聚在一起學習、探討！