因工作較忙,抽時間將框架遇到的問題和框架升級設計進行記錄。 一、背景&問題 之前框架是一個基於SOA思想設計的分散式框架。各應用通過服務方式提供使用,服務之間通信是RPC方式調用,具體實現基於.NET的WCF通信平臺。框架存在如下2個問題: 1、高併發處理能力不足。一當高併發請求,可能出現多個服務待 ...
因工作較忙,抽時間將框架遇到的問題和框架升級設計進行記錄。
一、背景&問題
之前框架是一個基於SOA思想設計的分散式框架。各應用通過服務方式提供使用,服務之間通信是RPC方式調用,具體實現基於.NET的WCF通信平臺。框架存在如下2個問題:
1、高併發處理能力不足。一當高併發請求,可能出現多個服務待定處理,導致整個系統出現瓶頸。
2、隨著移動端廣泛應用,服務不能靈活支持APP應用。
3、系統持續集成部署過於繁瑣,遇到問題不好定位。
基於以上存在問題升級框架,結合當前主流的架構思想,將系統進行服務化思維,就是“微服務架構”。
二、微服務架構
微服務架構(Microservices Architecture)是將系統拆分為多個服務,俗稱為應用服務。應用服務實現單一、具體的業務應用功能,支持獨立部署維護,多個應用服務構建成系統。應用服務之間通過輕量級通信框架進行,並且支持應用服務用不同技術或者平臺實現。微服務架構是SOA架構設計思想另一種實現方式。微服務架構有如下特點:
1、微服務架構好處
(1)橫向擴展應用服務提升系統併發處理能力
(2)應用服務獨立部署維護,有利於迭代開發升級持續部署
(3)架構靈活支持多種技術實現
(4)有利於應用服務實現高可用性
2、微服務架構不足
(1)對系統設計有一定要求,尤其是拆分技術應用服務介面
(2)導致系統實現複雜度的提高
(3)需要確保系統數據一致性機制
(4)導致系統維護要求和成本提高
系統是否需要採用微服務架構進行構建是由項目需求決定。採用微服務架構進行設計構建系統,對團隊成員能力比傳統要求高,尤其是設計能力。
三、框架設計原則
1、可擴展:支持不修改系統功能,按需擴展伺服器資源。
2、高可用:支持分散式部署雙機熱備機制,滿足系統高可用性的要求。
3、高併發:支持快捷擴張應用服務處理能力,提升系統處理能力,滿足併發請求。
4、安全性:訪問安全通過統一認證訪問;信息安全通過加解密、簽名傳輸;網路安全通過網路隔離及防火牆;數據安全通過定時備份及高容錯能力。
5、一致性:採用數據最終一致性策略。
四、框架總體設計
圖1- 系統架構示意圖
如圖所示,系統架構基於SOA架構設計思想,並且採用微服務架構方式進行設計和構建。將系統呈現和數據進行分離。系統呈現基於網頁進行實現,支持多種前端UI框架整合及自定義開發;數據由應用服務提供,統一通過“網關API”提供使用。架構支持通過網路層、應用層的負載均衡中間件等,實現高可用和併發處理能力。架構將一些基礎公共功能抽離構建成中間件。
1、網關API:應用服務通過網關API統一對外提供服務。網關API基於http協議、以restful方式提供統一服務介面,約定介面通信協議,支持系統呈現的功能,以輕量級的通信方式,滿足不同客戶端。網關API實現統一數據訪問許可權控制、路由應用服務、限流等功能。
2、消息平臺:負責應用服務之間更新同步信息,將原有系統架構分散式事務調用更新信息的方式,調整為通過消息非同步發佈/訂閱處理,保證數據最終一致性,應用服務之間降低耦合度和強依賴關係。高併發能力下,取得緩存作用。
3、服務註冊監控中心:負責應用服務註冊發佈登記,同時監控應用服務介面運行情況,支持動態控制應用服務接收請求,實現“去中心化”服務控制。組件實現服務註冊登記、監控等功能。
4、認證中心:負責架構訪問統一身份認證。通過用戶口令和許可權進行控制訪問。結合“網關API”實現安全訪問、限流等功能,同時實現頁面管理功能。
5、日誌管理系統:負責記錄系統日誌,提供服務介面和組件,業務代碼通過非同步方式將日誌信息傳輸到“消息平臺”,日誌管理系統訂閱“消息平臺”的日誌信息進行處理存儲。同時提供日誌管理功能
6、緩存中心:基於Redis分散式記憶體資料庫,搭建架構統一緩存中心,提供統一緩存服務。
五、軟體架構設計
圖2- 軟體架構示意圖
如圖所示,系統架構以微服務架構方式進行開發,從切麵觀察每個應用服務進行垂直獨立開發,根據職責劃分層次,從上而下分為四個層次,分別為Web層、服務介面層、業務邏輯層及數據訪問層。Web層主要負責系統功能呈現表達,直接面對用戶;服務介面層主要負責提供標準化服務介面,與呈現層對接;業務邏輯層主要實現應用業務邏輯,是應用服務核心部分;數據訪問層負責數據持久化,支持業務邏輯層。各層次之間通過介面進行隔離,有利於後續維護擴展,減低依賴和影響。
應用服務完成開發後進行集成部署。Web層將根據約定集成到Web應用容器,其餘層次構建為應用服務進行部署,並將服務介面進行註冊登記發佈使用。
六、結語
基礎架構大致設計就這樣,還需要考慮實施部署,可以考慮雲平臺彈性資源,再結合docker容器技術。
後續再逐步介紹相關基礎組件設計及實現原理。技術框架重於解決問題,設計依賴需求,需求來源實際業務場景。
作者:劉蔡濤
出處:http://www.cnblogs.com/Andon_liu
關於作者:專註於微軟平臺項目架構、管理。熟悉設計模式、領域驅動、架構設計、敏捷開發和項目管理。現主要從事ASP.NET MVC、WCF/Web API、SOA、MSSQL、redis方面的項目開發、架構、管理工作。 如有問題或建議,請一起學習討論!
本文版權歸作者和博客園共有,歡迎轉載,但未經作者同意必須保留此段聲明,且在文章頁面明顯位置給出原文連接。
如有問題,可以郵件:[email protected] 聯繫我,謝謝。