內建.NET Core+Swagger+Consul+Polly+Ocelot+IdentityServer4+Exceptionless+Apollo的微服務開發架構
Github源代碼位址
https://github.com/PeyShine/Demo.MicroServer
Apollo配置中心
Apollo（阿波羅）是攜程架構部門研發的分布式配置中心，能夠集中化管理應用不同環境、不同叢集的配置，配置修改後能夠實時推送到應用端，并且具備規範的權限、流程治理等特性，适用于微服務配置管理場景。 由于各個項目配置都需要讀取基礎的配置資訊，這邊在内網的Centos(101)上部署了Apollo的環境，并為項目添加了一些基礎配置資訊，配置如圖
Consul
Consul是一種服務網格解決方案，提供具有服務發現，健康檢查，Key/Value存儲，多資料中心等功能。 在内網101啟動Consul服務，這裡為了測試，直接在本地将使用者服務執行個體分别在三個端口啟動起來，實際生産中這些服務可能部署在不同的機房不同的機器，他們之間組成一個服務的叢集，服務提供一個心跳檢測的方法，用于consul定時檢測服務執行個體是否健康，啟動時在consul中進行一次注冊，這個就是經常說的‘服務注冊與發現’中的服務注冊，三個服務執行個體截圖如下
注冊完成之後打開consul的ui界面可以看到，清單中存在多出一個使用者服務的叢集組名稱：Demo.MicroServer.UserService，如圖
點選Demo.MicroServer.UserService進去之後如圖，顯示三個服務執行個體的資訊
Swagger
Swagger提供了一個可視化的UI頁面展示描述檔案。接口的調用方、測試等都可以在該頁面中對相關接口進行查閱和做一些簡單的接口請求。當然Swagger的功能遠不止這些，項目中已經在服務執行個體中接入swagger，如圖
因為三個服務執行個體是同樣一份代碼，是以可以看到打開三個端口的swagger位址，看到的接口資訊完全一緻。
Ocelot 網關
Ocelot是一個.NET API網關，它提供了路由,請求聚合,服務發現、鑒權、限流熔斷、負載均衡器等一系列強大的功能，而這些功能隻需要在配置檔案中完成即可使用. 比如上面的swagger，我們在三個服務執行個體的端口打開都可以看到api相關文檔資訊，但是我們能否在api網關中直接內建呢，答案是肯定的，這依賴于ocelot強大的路由功能，如圖，簡單的幾行配置，我們便将swagger配置到了網關當中
網關内置的負載均衡器的使用，如圖我在網關中對同一個接口進行了三次調用，可以看到結果分别來自三個不同的端口中，因為我選用了負載均衡器中的輪詢政策
限流政策，當我們配置啟用限流政策，并配置機關時間内通路次數限制時，然後快速重新整理接口，超過設定的次數限制，那麼可以看到按照錯誤提示出現
Expectationless
Exceptionless 是一個開源的實時的日志收集架構，相信在微服務架構或者分布式應用應該都離不開一個統一的日志收集功能，Exceptionless就是就很好的提供了服務，相信有很多開發者都在使用ELK來完成日志的收集，這裡說下Exceptionless底層也是基于ElasticSearch， Exceptionless提供了兩種服務方式，一種是線上的，就是直接在官網注冊賬戶，建立項目，官方會給每個項目配置設定一個appid，将id配置到項目中即可使用，當然，線上使用是有限制的，對日志收集數量(3000)還有存儲時間天數(3天)都有限制，測試或者臨時使用應該都沒問題， 考慮到後面項目會在生産環境中使用，是以我在内網centos上搭建了一個本地化的Exceptionless環境來收集日志。 我這裡調用一下swagger中寫的一個異常收集測試的接口
發送完成後，到Exceptionless的ui界面來檢視收集情況
可以看到界面多出一條發送測試的資料記錄
IdentityServer4統一鑒權中心
之所有将認證授權放在最後，因為沒有這個前面的流程也是可以跑通的，測試的時候如果覺得這部分測試麻煩可以先注釋掉，流程跑通後再來內建這個，這個東西的用法還是很多的，這裡将IdentityServer4內建到api 網關當中來完成統一的認證鑒權。 在identityserver4項目中分别實作以下幾個類
分類來完全幾個東西：定義api資源，用戶端通路資源範圍，校驗賬戶密碼過程和資料傳回格式 然後在api網關中項目中統一認證，這裡需要說明下為什麼要将IdentityServer4內建到網關當中而不是在每個服務執行個體單獨去認證，想象一下，如果在一個大型項目中，不同的小組維護着不同的服務執行個體，勢必每個小組都要在各自的代碼中完成一套認證邏輯，确實沒有必要， 而Ocelot天然對IdentityServer4進行了很好的內建，我們隻需要在網關中統一添加認證代碼即可，而各個微服務執行個體隻需要關心各自的業務邏輯代碼即可。 這個也列舉一下使用過程，在用戶端沒有token時通過網關對api資源進行通路，可以看到如圖的傳回狀态碼：401
然後我們到IdentityServer4中請求一個token
拿到token後，帶着token再通過網關請求相同的api資源，可以看到正确拿到想要的資源。
特别說明
上面的所有說明，在代碼中均有展現，并開放出來，但是對于一個完整的微服務架構來說還是太簡略，隻是做了簡單的說明，後續會具體拆開來分享一下。 至于為什麼要這麼做和工具的安裝，部落格園等地方有很多這方面的對比和教程可以參考，這裡着重關注微服務架構的實作
歡迎大家提出寶貴意見，當然如果對你有幫助也歡迎star.
随時随地查閱可關注公衆号
後續更新
後續可能還會加入CAP和APM