在當前項目中微服務如火如荼，已經是開發和架構主流，對於服務架構更是五花八門。今天根據個人對於微服務的理解特意整理自己理解的微服務架構圖例，在繪製此圖事考慮過很多，目的在於不想後期每個項目都單獨的畫一個圖例進行結構說明，希望有一個通用的架構，其他各系統都直接遵照執行即可，在概要設計章節可以覆蓋更廣闊的業務系統。如下:
原圖連接地址: https://www.processon.com/view/5d70cc60e4b08987f5514e15?fromnew=1，可以直接在線克隆，根據自己的需求進行改動。
架構說明:
1. 服務管理(4箇中心)
圖例中主要提出4箇中心: 註冊、配置、認證、監控，主要是對整個微服務集羣正常運行起到支撐作用同時也至關重要。
內部服務統一都註冊到註冊中心，對其他服務進行接口暴露；統一通過配置中心對服務本身的參數進行更新維護，所有的外部訪問統一都會通過網關進行認證授權；所有服務的運行統一彙總到監控中心，可以直接查看到各個服務的健康度。
2. 統一網關
如上所示，系統不限於採用什麼分佈式框架和技術，對外統一通過網關提供API接口或其他形態如WebSockt，MQTT等形式；網關中心主要負責接收外部請求，通過授權中心提供的數據對請求進行訪問認證，以及接口限流策略控制，最後當各種規則都通過的請求，才被路由到後端的實際微服務集羣。
3. 業務微服務
每個業務微服務，根據實際業務領域進行拆分(此處建議參考領域建模思想DDD)，每個微服務可以有自己獨立的DB，對外或是依賴其他的服務接口統一都通過REST API形式進行對外暴露或依賴。
4.內部交互
微服務的內部交互通過兩種方式：一種通過接口直連的方式進行，進行同步調用，這種方式在一定程度上是可以爲後期業務的鏈路監控提供便捷，同時也可滿足絕大部分業務需要。另一種通過消息中間件實現內部服務之間的異步調用,如果需要和第一種一樣需要實現鏈路監控，就需要在消息協議體中加入請求ID並進行跟蹤監控，通過採用消息的異步調用，需要根據業務自身特點進行選擇。
5.對外異構系統集成
圖中Open API 主要是對外開放接口，從而異構系統之間的集成，對外提供的接口同樣需要經過內部認證中心的授權，否則是不能調用。對外接口存在形態可以是多種，比如:http,mq,websocket等，可以根據實際業務選擇性調用
6. DevOps
開發運維部署方面， 所有服務的開發實現和部署都基於DevOps，從服務虛擬化，容器化，代碼靜態掃描，自動測試，自動構建和自動發佈等，均有集成的DevOps工具和環境完成。
7.監控維護
系統正式運行由統一的監控運營平臺進行監控，通過專業的日誌分析平臺提供日誌監控和分析，通過專業的安全策略實現安全防護，同時由任何服務監控或是異常統一都有告警系統進行告警。此處建議採用PAAS層服務進行實現，比如阿里雲、微軟雲和AWS等均有提供對應的服務。此處更多是基於硬件，虛擬機，網絡以及安全攻擊等方面的監控，服務的監控中心區別不一樣。
總結
綜上所述，按這樣的思路考慮架構，其思路上基本上可以容納很多概念，在描述架構的同時不侷限於具體技術實現，架構的設計其實可以提出對於技術選型的參考，因爲架構中多少都透露出對於技術的需求，而不是對於某一個技術組件的強依賴。