微服務架構很熱，讨論的文章非常多。但如果提到微服務架構的雲端應用，可以深入分析的還比較少。本篇來自中生代技術群（freshmantechnology）第二期，好雨雲創始人兼ceo劉凡的分享。其曾任澳客網 cto和ceo職位。擁有超過12年網際網路産品開發和管理經驗，專注于網際網路技術架構設計，對産品設計、靈活開發、安全、okrs、大資料等領域有深入研究。現推崇反應式程式設計（http://www.reactivemanifesto.org/），并在多個産品中成功應用。
下為正文：
微服務的優點：
可獨立部署、更新、替換、伸縮
自由選擇開發語言
高效利用資源
故障隔離
總結下來就是：靈活、穩定、省資源。
微服務的缺點：
服務多，帶來更多操作
管理複雜度提升
部署難度加大
總結就是：服務多，管理難度大。
僅管微服務存在着缺點，但它的優點也是非常吸引人的，目前很多企業也逐漸開始了微服務架構之旅，包括像twitter,netflix,amazon,ebay等大廠商都在使用。如下圖是twitter微服務應用部分架構圖。
傳統mvc架構，也是一體化模式。
從多個服務的結果聚合到一個聚合服務，最常見的表現是聚合服務是web服務，主要功能是頁面表現，後端的服務都是純業務功能服務，擴充業務隻需要增加一個新的後端微服務就可以啦。
聚合服務也可以是一個更高層次的組合微服務，增加業務邏輯後進一步釋出成一個新的微服務，這符合dry原則。另外，每個服務都有自己的緩存和資料庫。這個模式是最常用模式。
可實作部分業務的邏輯分離，資料共享。
用在一體化架構往微服務架構遷移過程中的過度狀态。還可用在兩個服務之前有資料一緻性要求，通過統一的資料庫事物來實作。
上面的其它模式都是同步的，會阻塞。異步消息模式适合不需要同步的場景，比如任務型服務。
主要的模式就這些，其它模式可以由這些模式演變。
每個服務都需要獨立的代碼管理、版本管理、編譯建構、部署到測試環境，部署到生産環境，代碼復原等等事情，如果要有幾十個服務要部署，人工管理幾乎不可能完成。
無狀态服務需要配置負載均衡和增加節點，有狀态服務需要擴充單個服務的資源，如果需要減少資源浪費，需要監控每個服務，還需要減少節點和資源。
每種服務的高可用政策都不一樣，無狀态服務相對簡單，管理每個有狀态服務都是難題。
任何一個服務的可用性都不是 100% 的。在分布式系統中，當我依賴的某個服務不可用的時候，我自身也将不能工作。如果是一個複雜的分布式系統，會依賴更多服務，任何一個服務不可用的時候，系統自身也将不能工作，再加上網絡不穩定的因素，系統自身的可用性将大幅度下降。
依賴配置檔案，如果寫在代碼中，需要重新部署才能生效，而配置檔案還會污染代碼。
監控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環節内容。
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萬左右的事務。
<b> </b>