集成.NET Core+Swagger+Consul+Polly+Ocelot+IdentityServer4+Exceptionless+Apollo的微服務開發框架 Github源代碼地址 https://github.com/PeyShine/Demo.MicroServer Apollo配置 ...
集成.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
