集成.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(已經支持)
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/33252.html
標籤：.NET Core