分享一個集成.NET Core+Swagger+Consul+Polly+Ocelot+IdentityServer4+Exceptionless+Apollo+SkyWalking的微服務開發框架

時間 2020-05-16

標籤分享一個集成 core+swagger+consul+polly+ocelot+identityserver4+exceptionless+ap core swagger consul polly ocelot identityserver exceptionless ollo+skywalking ollo skywalking 微服開發框架简体版

原文原文鏈接

集成.NET Core+Swagger+Consul+Polly+Ocelot+IdentityServer4+Exceptionless+Apollo的微服務開發框架

Github源代碼地址

https://github.com/PeyShine/Demo.MicroServergit

Apollo配置中心

Apollo（阿波羅）是攜程框架部門研發的分佈式配置中心，可以集中化管理應用不一樣環境、不一樣集羣的配置，配置修改後可以實時推送到應用端，而且具有規範的權限、流程治理等特性，適用於微服務配置管理場景。因爲各個項目配置都須要讀取基礎的配置信息，這邊在內網的Centos(101)上部署了Apollo的環境，併爲項目添加了一些基礎配置信息，配置如圖 github

Consul

Consul是一種服務網格解決方案，提供具備服務發現，健康檢查，Key/Value存儲，多數據中心等功能。在內網101啓動Consul服務，這裏爲了測試，直接在本地將用戶服務實例分別在三個端口啓動起來，實際生產中這些服務可能部署在不一樣的機房不一樣的機器，他們之間組成一個服務的集羣，服務提供一個心跳檢測的方法，用於consul定時檢測服務實例是否健康，啓動時在consul中進行一次註冊，這個就是常常說的‘服務註冊與發現’中的服務註冊，三個服務實例截圖以下 centos

註冊完成以後打開consul的ui界面能夠看到，列表中存在多出一個用戶服務的集羣組名稱：Demo.MicroServer.UserService，如圖
點擊Demo.MicroServer.UserService進去以後如圖，顯示三個服務實例的信息 api

Swagger

Swagger提供了一個可視化的UI頁面展現描述文件。接口的調用方、測試等均可以在該頁面中對相關接口進行查閱和作一些簡單的接口請求。固然Swagger的功能遠不止這些，項目中已經在服務實例中接入swagger，如圖

由於三個服務實例是一樣一份代碼，因此能夠看到打開三個端口的swagger地址，看到的接口信息徹底一致。架構

Ocelot 網關

Ocelot是一個.NET API網關，它提供了路由,請求聚合,服務發現、鑑權、限流熔斷、負載均衡器等一系列強大的功能，而這些功能只須要在配置文件中完成便可使用. 好比上面的swagger，咱們在三個服務實例的端口打開均可以看到api相關文檔信息，可是咱們可否在api網關中直接集成呢，答案是確定的，這依賴於ocelot強大的路由功能，如圖，簡單的幾行配置，咱們便將swagger配置到了網關當中app

網關內置的負載均衡器的使用，如圖我在網關中對同一個接口進行了三次調用，能夠看到結果分別來自三個不一樣的端口中，由於我選用了負載均衡器中的輪詢策略

負載均衡

限流策略，當咱們配置啓用限流策略，並配置單位時間內訪問次數限制時，而後快速刷新接口，超過設置的次數限制，那麼能夠看到按照錯誤提示出現框架

Expectationless

Exceptionless 是一個開源的實時的日誌收集框架，相信在微服務架構或者分佈式應用應該都離不開一個統一的日誌收集功能，Exceptionless就是就很好的提供了服務，相信有不少開發者都在使用ELK來完成日誌的收集，這裏說下Exceptionless底層也是基於ElasticSearch， Exceptionless提供了兩種服務方式，一種是在線的，就是直接在官網註冊帳戶，新建項目，官方會給每一個項目分配一個appid，將id配置到項目中便可使用，固然，在線使用是有限制的，對日誌收集數量(3000)還有存儲時間天數(3天)都有限制，測試或者臨時使用應該都沒問題，考慮到後面項目會在生產環境中使用，因此我在內網centos上搭建了一個本地化的Exceptionless環境來收集日誌。我這裏調用一下swagger中寫的一個異常收集測試的接口
發送完成後，到Exceptionless的ui界面來查看收集狀況
能夠看到界面多出一條發送測試的數據記錄less

IdentityServer4統一鑑權中心

之全部將認證受權放在最後，由於沒有這個前面的流程也是能夠跑通的，測試的時候若是以爲這部分測試麻煩能夠先註釋掉，流程跑通後再來集成這個，這個東西的用法仍是不少的，這裏將IdentityServer4集成到api 網關當中來完成統一的認證鑑權。在identityserver4項目中分別實現如下幾個類
分類來徹底幾個東西：定義api資源，客戶端訪問資源範圍，校驗帳戶密碼過程和數據返回格式而後在api網關中項目中統一認證，這裏須要說明下爲何要將IdentityServer4集成到網關當中而不是在每一個服務實例單獨去認證，想象一下，若是在一個大型項目中，不一樣的小組維護着不一樣的服務實例，勢必每一個小組都要在各自的代碼中完成一套認證邏輯，確實沒有必要，而Ocelot自然對IdentityServer4進行了很好的集成，咱們只須要在網關中統一添加認證代碼便可，而各個微服務實例只須要關心各自的業務邏輯代碼便可。這個也列舉一下使用過程，在客戶端沒有token時經過網關對api資源進行訪問，能夠看到如圖的返回狀態碼：401
而後咱們到IdentityServer4中請求一個token
拿到token後，帶着token再經過網關請求相同的api資源，能夠看到正確拿到想要的資源。分佈式

特別說明

上面的全部說明，在代碼中均有體現，並開放出來，可是對於一個完整的微服務架構來講仍是太簡略，只是作了簡單的說明，後續會具體拆開來分享一下。至於爲何要這麼作和工具的安裝，博客園等地方有不少這方面的對比和教程能夠參考，這裏着重關注微服務架構的實現
歡迎你們提出寶貴意見，固然若是對你有幫助也歡迎star.
隨時隨地查閱可關注公衆號