轉載聲明：本文為中生代技術群聯合好雨雲創始人兼CEO原創文章，轉載必須連同本訂閱號二維碼全文轉載，並註明作者名字及來源：中生代技術群（FreshmanTechnology）。
話題：微服務架構雲端應用
講師：劉凡
職位：好雨雲創始人兼CEO
簡介：曾任澳客網 CTO和CEO職位。擁有超過12年網際網路產品開發和管理經驗，專注於網際網路技術架構設計，對產品設計、敏捷開發、安全、OKRs、大數據等領域有深入研究。現推崇反應式編程（http://www.reactivemanifesto.org/），並在多個產品中成功應用。
劉總在這次分享中主要為大家介紹了什麼是徽服務，實現微服務有哪些架構模式以及微服務在實際中的應用情況。
微服務架構(Microservices Architecture)是一種架構風格和設計模式，提供將應用分割成一系列細小的服務，每個服務專注於單一業務功能，運行於獨立的進程中，服務之間邊界清晰，採用輕量級通信機制相互溝通、配合來實現完整的應用，滿足業務和用戶的需求。（引用自http://www.csdn.net/article/2015-07-20/2825258）
微服務的優點：
可獨立部署、升級、替換、伸縮
自由選擇開發語言
高效利用資源
故障隔離
總結下來就是：靈活、穩定、省資源。
微服務的缺點：
服務多，帶來更多操作
管理複雜度提升
部署難度加大
總結就是：服務多，管理難度大。
僅管微服務存在著缺點，但它的優點也是非常吸引人的，目前很多企業也逐漸開始了微服務架構之旅，包括像Twitter,Netflix,Amazon,eBay等大廠商都在使用。如下圖是Twitter微服務應用部分架構圖。
微服務的架構模式
1. 一體化架構模式
傳統mvc架構，也是一體化模式。
2. 聚合模式
從多個服務的結果聚合到一個聚合服務，最常見的表現是聚合服務是Web服務，主要功能是頁面表現，後端的服務都是純業務功能服務，擴展業務只需要增加一個新的後端微服務就可以啦。
聚合服務也可以是一個更高層次的組合微服務，增加業務邏輯後進一步發布成一個新的微服務，這符合DRY原則。另外，每個服務都有自己的緩存和資料庫。這個模式是最常用模式。
3. 代理模式
4. 資源共享模式
可實現部分業務的邏輯分離，數據共享。
用在一體化架構往微服務架構遷移過程中的過度狀態。還可用在兩個服務之前有數據一致性要求，通過統一的資料庫事物來實現。
5. 異步消息模式
上面的其它模式都是同步的，會阻塞。異步消息模式適合不需要同步的場景，比如任務型服務。
主要的模式就這些，其它模式可以由這些模式演變。
大量微服務帶來的挑戰
1. 服務部署的挑戰
每個服務都需要獨立的代碼管理、版本管理、編譯構建、部署到測試環境，部署到生產環境，代碼回滾等等事情，如果要有幾十個服務要部署，人工管理幾乎不可能完成。
2. 服務紳縮的挑戰
無狀態服務需要配置負載均衡和增加節點，有狀態服務需要擴充單個服務的資源，如果需要減少資源浪費，需要監控每個服務，還需要減少節點和資源。
3. 服務高可用的挑戰
每種服務的高可用策略都不一樣，無狀態服務相對簡單，管理每個有狀態服務都是難題。
4. 服務容錯的挑戰
任何一個服務的可用性都不是 100% 的。在分布式系統中，當我依賴的某個服務不可用的時候，我自身也將不能工作。如果是一個複雜的分布式系統，會依賴更多服務，任何一個服務不可用的時候，系統自身也將不能工作，再加上網絡不穩定的因素，系統自身的可用性將大幅度下降。
5. 依賴關係的挑戰
依賴配置文件，如果寫在代碼中，需要重新部署才能生效，而配置文件還會汙染代碼。
6. 服務監控的挑戰
監控cpu？負載？大量微服務如何同時監控？
微服務在好雨雲的解決方案
底層是通過docker實現的，只是用戶感受不到docker。
內部封裝,不用管理計算資源和網絡資源，並把某些複雜特性包裝在內部。整體對外，服務做為一個整體管理。
開發語言支持Java、Python、PHP、Ruby、Golang,Node.JS等，代碼支持Github，好雨託管倉庫。
水平伸縮用於無狀態的 Server和Worker 類的服務。
垂直伸縮用於有狀態的服務。
部分有狀態服務支持水平分區（ sharding），用戶只需要調整節點個數就可以了。
一般通過LB支持無狀態服務高可用，支持有狀態服務高可用。
類似Spring，參數通過環境變量實現。
實現微服務之間的連接和編排，以上微服務模式都可以通過這種方式動態配置實現。
類似保險絲，當服務B變慢，達到斷路器的閥值，服務B，將自動下線，不至於影響其他服務，當延遲變小，服務逐步恢復。容錯還有一種方式是使用異步，可以參考CQRS模式。
業務指標：平均響應時間，吞吐率 ，在線人數。
在實際場景中，使用業務監控可以替代技術監控，而且更加簡單容易理解。
單個REST服務的實時性能分析，資料庫性能分析，最慢的Sql語句不一定是對資料庫影響最大的。實時性能分析通過CEP＋log實現，以前工作一直使用，沒有APM炫，但解決了很多實際問題。還在實現了Mongodb ，Redis等數據存儲的實時性能分析。
至此，相信你也對微服務，微服務的構架模式以及微服務在現實場景中的應用有了一個大概的認識了。如果你還想要了解得更多，請繼續查看下面的Q&A環節內容。
Q&A
Q1 99.95%的SLA是如何測量的，現在都有那些初始客戶?
劉總: 我們自己實現了負載均衡組件，監控每個租戶的服務可用性，後端服務不可用和錯誤返回碼都會算到不可以用時間。我們現在的用戶有工行，天津濱海新區管委會，章魚網，51talk，學霸君，好貸寶等。
Q2 依賴調整配置就生效嗎，背後是如何做到的？
劉總: 我們的服務發現是通過etcd實現的，之前實現了完全實時修改實時生效的方案，但是太複雜了，現在的實現方式是通過環境變量實現的，修改配置之後需要重啟，無狀態服務用戶感知不到。
Q3 SOA的時候重點談到了美好的編排，不同粒度的層次，逐層編排，其實最考驗設計能力和抽象能力，編排本身的美好得不到很好的利用，如何破？
劉總: 這只能考驗一個公司的技術架構師和業務架構師了，我以前身兼這兩職，我沒遇到過這些問題。我也沒有其它思路。
Q4 監控部分對於內存洩漏，堆棧分析有沒有好的支持？
劉總: 這個沒有，但是如果由於內存洩漏導致服務死掉，我們平臺會自動重啟。
Q5 你們雲平臺本身有沒有異地容災的能力？
劉總: 我們能實現geo－master，現在設計如何對用戶開放這類服務。
Q6 微服務這塊在移動端有沒有好的案例，一般像Android和 iOS這類移動應用上如何使用和借鑑微服務模式呢?
劉總: 剛才分享的代理模式特別適合用戶移動開發場景，微服務都是API。代理模式是一種特殊的聚合模式，對外是一個統一的包裝，一般做內部接口的代理，對外統一一個接口，內部可以用多個微服務實現。
Q7 服務之間有沒有調用鏈的設計，方便跟蹤跨服務的問題，可以分享一下嗎？
劉總: 細化的跟蹤沒有，通過服務拓撲可以實現粗力度的。
Q8 工行上的是那些業務，好雨雲擅長是高性能高PV的業務，還是對事務一致性要求都有很高要求的業務？
劉總: 高PV場景我們特別適合，因為我們非常容易伸縮。事務一致性我們有兩種方式，一種大家可以選擇自己喜歡的存儲服務，各類數據有存儲自己的方式。第二種，我們通過akka實現一套高一致性，高性能的解決方案，單機能做到每秒100萬的事務。
Q9 劉總，你提到了類似在線人數之類的業務監控，對於產品可以增強鏈路監控功能否，比A9如用戶是在操作鏈路上那個環節流失得比較嚴重，做統計以便產品改進，這些監控本身需要調用平臺API嗎？
劉總: 不太理解鏈路是什麼意思，是指用戶行為數據嗎？現在我們沒有，我們不擅長這塊。
Q10 服務拓撲就是服務級依賴關係吧？
劉總: 是的，每個微服務有自己的響應時間和吞吐率，表現在拓撲圖裡，可以粗力度分析出問題。
Q11 我們通過akka實現一套高一致性，高性能的解決方案，單機能做到每秒100萬的事務，這塊能不能具體說一下，比如一個第三方支付簡單的A用戶到B用戶的轉帳場景，A和B在不同的sharding單元。
劉總: akka的模式是使用CQRS模式，也就是事件溯源的方式，以前資料庫的那些事務問題在這都不存在。
Q12 Akka的話是不走資料庫直接在內存裡做事務嗎？
劉總: 是的，通過事件溯源保證數據一致性。理論上它不是事務，但能實現事務的效果。
Q13 隊列技術如何支持的呢？
劉總: 我們平臺支持任何開源的隊列服務。
Q14 微服務之間如何通信，協議和數據格式是怎樣的？
劉總: 微服務會有多個節點，但我們會內置LB，對外統一一個服務接口，支持任意協議和格式。
Q15 工行，天津濱海新區管委會，章魚網，51talk，學霸君，好貸寶主要應用場景，高PV支持，高事務支持，大數據分析，爬蟲，devops，通過微服務架構把業務能拆分更小，便於重用和維護。 akka的方案就是聯機交易。這些客戶具體的應用場景是哪些呢？可以選擇1－2個典型case介紹下微服務所產生的價值，如果有聯機交易的Case更佳。
劉總: 介紹下微服務所產生的價值，如果有聯機交易的Case更佳主要應用場景，高PV支持，高事務支持，大數據分析，爬蟲，devops，通過微服務架構把業務能拆分更小，便於重用和維護。 akka的方案就是聯機交易。
Q16 實時性能分析用的是cep +log, 不是很理解cep？
劉總: 複雜事件處理，實時流處理，通過strom也可以實現。
Q17 如何應對微服務的毛剌現象（某個服務瞬間出現較大延遲的現象，可能會導致某批請求超時等情況）？
劉總: 不好意思，我沒遇到過這種情況，我覺得應該跟實現方式有關。
Q18 akka的方案就是聯機交易，akka原先架構體系是什麼？遇到了什麼樣的瓶頸？微服務之後改進的是什麼？聯機交易規模怎樣？
劉總: 原先就是用傳統資料庫，交易的事務性能低下，做了sharding會引入新的問題，而且聯機分析也有問題，用akka改造後能處理高峰業務每秒10萬左右的事務。
下期分享預告
分享講師：陳顯銘（花名：山丘）
公司崗位：螞蟻金服-技術專家
個人經歷：從事研發工作7年，資深程式設計師，愛思考，愛黑人。
分享話題：性能優化二三事
話題簡介：主要從性能優化常見模式，壓測常見模型，全鏈路壓測技術分解三個方面講解。
分享時間：2016年1月14日
關於中生代技術群
友直,友諒,友多聞；群好、群真、群多妹子。架構、開發、運維、DBA、前端一網打盡，做中國最好的中生代！
我們不叫架構師群的原因是現在架構師群已經不少了，我們不僅僅討論高大上的概念，我們還會討論類似於[開發應該懂多少運維，開發應該掌握DBA基礎7日譚等基礎性話題]，特別高大的群，有些問題憋著不敢問，怕被認為是low到爆呢，我們這裡有專家、也有對於新領域而言的菜鳥，讓我們重溫老夫子的訓誡[三人行，必有我師焉]，更多精彩請持續關注freshmanTechnology微信訂閱號！
掃碼關注
中生代技術群
連接技術大咖的橋梁，促進科技技術的交流