DockOne技術分享（三十五）：微服務架構雲端應用

這是一個建立於 的文章，其中的資訊可能已經有所發展或是發生改變。
【編者的話】本文作者擁有超過12年互連網產品開發和管理經驗，專註於互連網技術架構設計，對產品設計、敏捷開發、安全、OKRs、大資料等領域有深入研究。本文介紹微服務架構和優缺點，並講解常見微服務架構模式和適用情境。最後結合實踐，選擇合適的雲平台，講解如何部署、管理、遷移和服務伸縮，最後講解實際運營中的問題及解決方案。

總結優點就是 ：靈活、穩定、省資源

總結缺點就是：服務多，管理難度大

這是以前大家常用的MVC模式，講究模組化設計和設計模式。

從多個服務的結果彙總到一個彙總服務，最常見的彙總服務是web服務，主要功能是頁面表現，後端的服務都是純業務功能服務，擴充業務只需要增加一個新的後端微服務就可以啦，這個模式是最常用模式。

代理模式是一種特殊的彙總模式，對外是一個統一的封裝，一般做內部介面的代理，對外統一一個介面。

可實現部分業務的邏輯分離，資料共用。
用在一體化架構往微服務架構遷移過程中的過度模式。
還可用在兩個服務之前有資料一致性要求，通過統一的資料庫事務來實現。

適合不需要同步任務返回的服務，比如任務型服務。
這種模式容錯性好，效能高。
當然，這是非同步本身的優點 比較複雜的業務情境大家可以研究下 CQRS ，核心也是非同步。

服務部署的挑戰
每個服務都需要 獨立的代碼管理、版本管理、編譯構建、部署到測試環境，部署到生產環境，代碼復原等等事情，如果要有幾十個服務要部署，人工管理幾乎不可能完成。
服務伸縮的挑戰
無狀態服務 需要配置負載平衡和增加節點，具狀態服務需要擴充單個服務的資源，如果需要減少資源浪費，需要監控每個服務，還需要減少節點和資源。
服務高可用的挑戰
每種服務的高可用策略都不一樣，無狀態服務相對簡單，管理每個具狀態服務都是難題。
服務容錯的挑戰
任何一個服務的可用性都不是 100% 的。在分布式系統中，當我依賴的某個服務停用時候，我自身也將不能工作 。如果是一個複雜的分布式系統，會依賴更多服務，任何一個服務停用時候，系統自身也將不能工作，再加上網路不穩定的因素，系統自身的可用性將大幅度下降。
依賴關係的挑戰
依賴設定檔，如果寫在代碼中，需要重新部署才會生效，而設定檔還會汙染代碼。
服務監控的挑戰
監控cpu？負載？磁碟IO? 大量微服務如何同時監控？什麼方式監控更加有效？

好雨雲（www.goodrain.com）

一定要讓使用者簡單
內部封裝：不用管理計算資源和網路資源，並把某些複雜特性封裝在內部。
整體對外：服務做為一個整體管理。
以業務為核心，去除技術多餘技術概念。

我們支援 java，php，python，node.js，ruby，golang等開發語言。
如果需要更加靈活的方式 就需要用 dockfile了
原始碼支援 github 和 私人代碼倉庫


以敏捷為主，關鍵性的服務，可以定製開發部署流程，增加許可權限制，符合內審制度。

水平伸縮 用於 無狀態的 server 和 worker 類的服務。
垂直伸縮 用於 有狀態的服務。

一般通過LB和訊息佇列支援無狀態服務高可用
具狀態服務的高可用比較困難，我們通過統一的架構支援。

有點類似spring的依賴注入

類似保險絲，當服務B變慢，達到斷路器的閥值，服務B，將自動下線，不至於影響其他服務，當延遲變小，服務逐步恢複。
容錯還有一種方式是使用非同步。

業務指標：平均回應時間，吞吐率 ，線上人數
在實際情境中，使用業務監控可以替代技術監控，而且更加簡單容易理解。

Q&A

Q：請問你是基於Docker和Mesos嗎?

A：用了Docker。

Q：是混合雲架構嗎?

A：是的，也可用在私人雲端。

Q：微服務是誰發布哪？

A：只要有代碼就發行就緒微服務，一般由微服務的開發人員發布。

Q：業務系統日誌是如何處理的？


A：統一輸出到標準輸出和錯誤輸出，按租戶儲存，即時顯示到頁面，可以按天下載。

Q：請問你們的容器管理系統是基於開源平台還是自己開發的？有何優勢？


A：用了一部分開源。
最大的優勢是簡單和靈活：
1. 減少了很多技術概念，只用管理以業務為核心的應用，使用更加簡單
2. 由於架構的靈活性，除了支援微服務架構，還可以支援更加複雜的架構。
3. 好雨雲可以跑在任意IAAS上，理論可支援全球資料中心。
4. 支援開源服務和使用者貢獻的服務，使用者選擇空間更大。

Q：請問你們的服務「水平伸縮」和「垂直伸縮」分別面對哪類情境？如何?？


A：「垂直伸縮」對於所有情境都是可以使用的。「水平伸縮」用到無狀態服務的情境，而且可以和「垂直伸縮」疊加使用的，具狀態服務不支援水平伸縮。針對不同微服務類型，在管理後台配置就可以實現。

Q：微服務跨平台如何解決網路延遲問題呢？

> A：在網路不穩定的情境，服務之前的調用一定要用斷路器，另外只有最佳化物理網路鏈路了。

Q：微服務怎麼解決後端資料庫的部署和依賴問題
？

A：在好雨雲，資料庫也算特殊一類微服務，同樣有其他微服務的特性，一樣可以通過微服務的特性部署和配置依賴關係。

Q：介紹下服務間通訊是如何?的？

A：在服務使用端實現了一個透明的代理，它根據服務註冊的Endpoint，找到要使用的服務，如果是多個服務，自動實現負載平衡。

Q：支援的語言有沒有c語言？


A：可以通過dockfile支援的。

Q：請問一下docker選用的是哪個版本？有特殊原因嗎？


A：我們比較保守，用的是比較穩定的，除非有個大特性吸引我們

Q：請問代理模式是指類似於 API GATEWAY 嗎？具體用什麼實現的？


A：是的。有很多種實現方式，可以自己寫代碼實現，也可以部署一個 Nginx。

Q：從前面架構圖看每個微服務的資料庫是獨立的，這是必須的嗎？

A：這樣有很多優點，比如業務隔離，獨立團隊維護，業務分區，等等，不是必須，共用模式就是特例。

Q：能否理解解決「服務伸縮」問題的重點是「服務發現」和「狀態共用」？


A：這塊的核心依賴程式實現，如果程式實現的好，就可以做到非常好的水平伸縮，我們自己的具狀態服務也是可以水平伸縮的。

Q: 請問當每個服務都可能同時存在多個線上版本時，如何做ab testing？如何控制業務路由？

A：ab testing 我們當前沒有實現，下一步會引入這個特性。我們的設計思路是實現一個控制使用者訪問路由的微服務，同時支援ab testing。

Q： 哪種服務模式用的最多？非同步訊息模式嗎？


A：用的最多的是彙總模式和非同步訊息模式。

Q：微服務後端的資料庫是Auto Scaling的怎麼做的？MySQL，mongodb

A：要支援水平伸縮，需要部署一個支援水平伸縮的資料庫中介軟體做為微服務。
垂直伸縮，直接調整資源就可以了，受限於物理機的資源容量。

Q：伸縮的時候對業務可以做到完全透明嗎！


A：是的。我們現在的實現是對業務完全透明。

Q：服務發現用到什麼，Consul、Dubbo？


A：輕量級封裝 etcd。

Q：每個微服務對應一個資料庫，怎麼做到資料共用呢？


A：每個微服務後面的資料庫支援有狀態資料的持久化，對外整體是一個商務服務，需要根據業務關係來梳 理服務結構。如果有一致性要求比較高的情境，可以使用共用資料庫或Message Service實現。

Q：垂直伸縮，調整資源就可以了，資源需求超過一台物理機呢？拆庫？


A：三種方式：第一種，把業務拆的小，資料庫分庫。第二種，資料庫 sharding。第三種，使用CQRS模式，重新設計實現。

Q：服務調用鏈的事務怎麼保證的？

A：
可以通過共用資料庫，使用資料庫事務解決調用鏈事務問題。
另外，還可以使用非同步Message Service，通過保證訊息可靠消費來實現。

Q：CQRS 模式的 維護成本很高啊 有評估過這種改造的成本嗎？

A：
有架構重用的，比如AKKA，效能奇高，開發也很簡單。只是學習曲線比較陡

Q：能分享下如何把控提供微服務的細粒度，微服務的範圍和邊界怎麼控制？

A：
一定要結合實際業務情境，還要看團隊情況，我的經驗是，微服務的粒度和內部人員管理關聯。隨著業務發展，粒度也需要不斷調整的。邊界要考慮業務抽象的合理性。

===========================================================
以上內容根據2015年11月24日晚群分享內容整理。分享人： 劉凡，好雨雲創始人兼CEO。曾任澳客網 CTO和CEO職位。擁有超過12年互連網產品開發和管理經驗，專註於互連網技術架構設計，對產品設計、敏捷開發、安全、OKRs、大資料等領域有深入研究。推崇反應式編程，並在多個產品中成功應用。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加： liyingjiesx，進群參與，您有想聽的話題可以給我們留言。