Net分佈式系統之五：微服務架構

 　　因工做較忙，抽時間將框架遇到的問題和框架升級設計進行記錄。

 

1、背景&問題

　　以前框架是一個基於SOA思想設計的分佈式框架。各應用經過服務方式提供使用，服務之間通訊是RPC方式調用，具體實現基於.NET的WCF通訊平臺。框架存在以下2個問題：

　　一、高併發處理能力不足。一當高併發請求，可能出現多個服務待定處理，致使整個系統出現瓶頸。

　　二、隨着移動端普遍應用，服務不能靈活支持APP應用。

　　三、系統持續集成部署過於繁瑣，遇到問題很差定位。

　　基於以上存在問題升級框架，結合當前主流的架構思想，將系統進行服務化思惟，就是「微服務架構」。

---

  

2、微服務架構

　　微服務架構（Microservices Architecture）是將系統拆分爲多個服務，俗稱爲應用服務。應用服務實現單1、具體的業務應用功能，支持獨立部署維護，多個應用服務構建成系統。應用服務之間經過輕量級通訊框架進行，而且支持應用服務用不一樣技術或者平臺實現。微服務架構是SOA架構設計思想另外一種實現方式。微服務架構有以下特色：

　一、微服務架構好處

　　（1）橫向擴展應用服務提高系統併發處理能力

　　（2）應用服務獨立部署維護，有利於迭代開發升級持續部署

　　（3）架構靈活支持多種技術實現

　　（4）有利於應用服務實現高可用性

　二、微服務架構不足

　　（1）對系統設計有必定要求，尤爲是拆分技術應用服務接口

　　（2）致使系統實現複雜度的提升

　　（3）須要確保系統數據一致性機制

　　（4）致使系統維護要求和成本提升

　　系統是否須要採用微服務架構進行構建是由項目需求決定。採用微服務架構進行設計構建系統，對團隊成員能力比傳統要求高，尤爲是設計能力。

---

  

3、框架設計原則

　　一、可擴展：支持不修改系統功能，按需擴展服務器資源。

　　二、高可用：支持分佈式部署雙機熱備機制，知足系統高可用性的要求。

　　三、高併發：支持快捷擴張應用服務處理能力，提高系統處理能力，知足併發請求。

　　四、安全性：訪問安全經過統一認證訪問；信息安全經過加解密、簽名傳輸；網絡安全經過網絡隔離及防火牆；數據安全經過定時備份及高容錯能力。

　　五、一致性：採用數據最終一致性策略。

---

 

4、框架整體設計

　　　　

                                                                                圖1- 系統架構示意圖

　　如圖所示，系統架構基於SOA架構設計思想，而且採用微服務架構方式進行設計和構建。將系統呈現和數據進行分離。系統呈現基於網頁進行實現，支持多種前端UI框架整合及自定義開發；數據由應用服務提供，統一經過「網關API」提供使用。架構支持經過網絡層、應用層的負載均衡中間件等，實現高可用和併發處理能力。架構將一些基礎公共功能抽離構建成中間件。

　　一、網關API：應用服務經過網關API統一對外提供服務。網關API基於http協議、以restful方式提供統一服務接口，約定接口通訊協議，支持系統呈現的功能，以輕量級的通訊方式，知足不一樣客戶端。網關API實現統一數據訪問權限控制、路由應用服務、限流等功能。

　　二、消息平臺：負責應用服務之間更新同步信息，將原有系統架構分佈式事務調用更新信息的方式，調整爲經過消息異步發佈/訂閱處理，保證數據最終一致性，應用服務之間下降耦合度和強依賴關係。高併發能力下，取得緩存做用。

　　三、服務註冊監控中心：負責應用服務註冊發佈登記，同時監控應用服務接口運行狀況，支持動態控制應用服務接收請求，實現「去中心化」服務控制。組件實現服務註冊登記、監控等功能。

　　四、認證中心：負責架構訪問統一身份認證。經過用戶口令和權限進行控制訪問。結合「網關API」實現安全訪問、限流等功能，同時實現頁面管理功能。

　　五、日誌管理系統：負責記錄系統日誌，提供服務接口和組件，業務代碼經過異步方式將日誌信息傳輸到「消息平臺」，日誌管理系統訂閱「消息平臺」的日誌信息進行處理存儲。同時提供日誌管理功能

　　六、緩存中心：基於Redis分佈式內存數據庫，搭建架構統一緩存中心，提供統一緩存服務。

　　 

5、軟件架構設計

      　　

                                                                                 圖2- 軟件架構示意圖

　　如圖所示，系統架構以微服務架構方式進行開發，從切面觀察每一個應用服務進行垂直獨立開發，根據職責劃分層次，從上而下分爲四個層次，分別爲Web層、服務接口層、業務邏輯層及數據訪問層。Web層主要負責系統功能呈現表達，直接面對用戶；服務接口層主要負責提供標準化服務接口，與呈現層對接；業務邏輯層主要實現應用業務邏輯，是應用服務核心部分；數據訪問層負責數據持久化，支持業務邏輯層。各層次之間經過接口進行隔離，有利於後續維護擴展，減低依賴和影響。

　　應用服務完成開發後進行集成部署。Web層將根據約定集成到Web應用容器，其他層次構建爲應用服務進行部署，並將服務接口進行註冊登記發佈使用。

6、結語

　　基礎架構大體設計就這樣，還須要考慮實施部署，能夠考慮雲平臺彈性資源，再結合docker容器技術。

　　後續再逐步介紹相關基礎組件設計及實現原理。技術框架重於解決問題，設計依賴需求，需求來源實際業務場景。

 

 

做者:劉蔡濤
出處： http://www.cnblogs.com/Andon_liu
關於做者：專一於微軟平臺項目架構、管理。熟悉設計模式、領域驅動、架構設計、敏捷開發和項目管理。現主要從事ASP.NET MVC、WCF/Web API、SOA、MSSQL、redis方面的項目開發、架構、管理工做。 若有問題或建議，請一塊兒學習討論！
本文版權歸做者和博客園共有，歡迎轉載，但未經做者贊成必須保留此段聲明，且在文章頁面明顯位置給出原文鏈接。
若有問題，能夠郵件：568773262@qq.com 聯繫我，謝謝。

微信號：