微服務架構云端應用
本文作者擁有超過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：用了一部分開源。
最大的優勢是簡單和靈活：
- 減少了很多技術概念，只用管理以業務為核心的應用，使用更加簡單
- 由于架構的靈活性，除了支持微服務架構，還可以支持更加復雜的架構。
- 好雨云可以跑在任意IAAS上，理論可支持全球數據中心。
- 支持開源服務和用戶貢獻的服務，用戶選擇空間更大。 </blockquote> 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：微服務后端的數據庫是彈性伸縮的怎么做的？MySQL，mongodb
A：要支持水平伸縮，需要部署一個支持水平伸縮的數據庫中間件做為微服務。Q：伸縮的時候對業務可以做到完全透明嗎！
垂直伸縮，直接調整資源就可以了，受限于物理機的資源容量。
A：是的。我們現在的實現是對業務完全透明。Q：服務發現用到什么，Consul、Dubbo？
A：輕量級封裝 etcd。Q：每個微服務對應一個數據庫，怎么做到數據共享呢？
A：每個微服務后面的數據庫支持有狀態數據的持久化，對外整體是一個業務服務，需要根據業務關系來梳 理服務結構。如果有一致性要求比較高的場景，可以使用共享數據庫或消息服務實現。Q：垂直伸縮，調整資源就可以了，資源需求超過一臺物理機呢？拆庫？
A：三種方式：第一種，把業務拆的小，數據庫分庫。第二種，數據庫 sharding。第三種，使用CQRS模式，重新設計實現。Q：服務調用鏈的事務怎么保證的？
A： 可以通過共享數據庫，使用數據庫事務解決調用鏈事務問題。 另外，還可以使用異步的消息服務，通過保證消息可靠消費來實現。Q：CQRS 模式的 維護成本很高啊 有評估過這種改造的成本嗎？
A： 有框架重用的，比如AKKA，性能奇高，開發也很簡單。只是學習曲線比較陡Q：能分享下如何把控提供微服務的細粒度，微服務的范圍和邊界怎么控制？
A： 一定要結合實際業務場景，還要看團隊情況，我的經驗是，微服務的粒度和內部人員管理關聯。隨著業務發展，粒度也需要不斷調整的。邊界要考慮業務抽象的合理性。===========================================================
以上內容根據2015年11月24日晚微信群分享內容整理。分享人： 劉凡，好雨云創始人兼CEO。曾任澳客網 CTO和CEO職位。擁有超過12年互聯網產品開發和管理經驗，專注于互聯網技術架構設計，對產品設計、敏捷開發、安全、OKRs、大數據等領域有深入研究。推崇反應式編程，并在多個產品中成功應用。 DockOne每周都會組織定向的技術分享，歡迎感興趣的同學加微信： liyingjiesx，進群參與，您有想聽的話題可以給我們留言。
來自：http://dockone.io/article/860
本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！