前面我已經完成了一個完整的CRUD操作，并且通過了測試。這就是面向微服務的子產品化開發模式，微服務子產品之間的耦合性低，内部的内聚性高。其餘的所有實際中的業務操作，都可以按照前面實作出來的功能，進行擴充。
要實作分布式的微服務架構，需要解決前端使用者的認證授權問題。這裡的前端使用者，不一定是人，也可能是機器或者其他東西。分布式的微服務架構不适宜用session的解決方案來實作認證授權，注意這裡我說的是不适宜，而不是不适用。是以我打算使用過濾器來橫向切入，通過JWT的解決方案來實作我這個項目的認證授權需求。這也算是借用了Java裡面的AOP的程式設計思想吧，出于實戰的目的，這裡我就不過多的解釋技術細節了，不清楚的技術細節，就自行百度吧。
其實，如果是需要實作單點登入的話，也可以把認證授權這部分，獨立出一個項目來做，單獨部署。這樣前端就可以先通過認證授權伺服器來進行認證授權操作，通過之後，再分發到後端的微服務叢集，進行業務操作。出于項目示範的簡單性原則，這裡我就把認證授權子產品內建到一個項目中來實作了。
1、JwtUtil的實作
首先，需要安裝JWT的程式包，這裡就請自行安裝吧，安裝完成後的截圖如下所示。
其次，在Utils檔案夾中建立JwtUtil.cs類檔案，代碼如下圖所示。
我就不展開源代碼了，需要源代碼的，請自行到github上下載下傳。
這裡需要解釋一下，常量字元串secret是生成Token的密鑰。我這裡是把傳入的id，認證授權的失效時間，通過secret進行加密。然後傳回加密的Token字元串給前端，前端儲存這個Token，以後需要業務操作的話，前端傳遞Token給後端，後端經過驗證，決定是否放行該業務操作。這就是Token方式的大緻描述，要想了解詳細細節的話，還請自己查找JWT的資料檢視。
2、過濾器的實作
首先，在Filters檔案夾中建立AuthFilter.cs的過濾器類檔案，代碼如下圖所示。
這裡，我隻是簡單的實作了一個靜态的驗證方法，沒有使用JWT的方式。然後，我在OnAuthorization方法中通過if語句，實作了一個簡單的業務邏輯。簡單來說，就是，隻要在controller中的action上添加了[AllowAnonymous]這個注解，那過濾器就放行該操作，而不做下面的認證授權操作。代碼如下圖所示。
這樣做的好處是，不需要認證授權的操作，比如說登入，則可以直接放行。
其次，在Startup.cs中，加入AuthFilter過濾器，代碼如下圖所示。
3、測試
對認證授權子產品進行測試，需要在controller和repository中，實作一個getToken()方法，用來在前端擷取Token進行測試。
我這個項目的認證授權的大緻流程是這樣的：前端登入系統、擷取Token、傳回前端儲存Token、通路帶有[AllowAnonymous]這個注解的服務接口（直接放行）、通路不帶[AllowAnonymous]這個注解的服務接口（驗證Token）。
這個getToken()方法，我就不傳入使用者名和密碼參數進行驗證了，這裡我直接傳回生成的Token，代碼如下圖所示。
注意這個getToken()服務接口，添加了[AllowAnonymous]這個注解。
接下來是在過濾器中修改Token驗證的業務邏輯。
我這裡用字元串1來表示驗證通過，非1表示驗證不通過。接下來是測試，先啟動項目，首先是先擷取Token，如下圖所示。
接下來通過通路getUsers服務接口來測試認證授權是否正常運作，第一步是不帶Token的通路。
可以看到，不帶Token的通路，傳回值是401，說明沒有認證和授權，被阻止了，過濾器運作測試通過。
第二步是帶有Token的通路。
可以看到，通過在Headers中加入Authorization的Token值，通路通過，可以正常擷取到資料，說明通過認證授權，測試通過。
到此為止，認證授權子產品的實作，就算是完成了，并且通過了測試。我這個項目架構的實作，也算是初步實作了，并且可以正常使用。在分布式的微服務構架模式中，通過Token的方式來實作認證授權，是現在的主流模式。并且這種方式，也不會受制于前端的技術，這就充分降低了前後端之間和認證授權子產品的耦合度。這種方式實作的認證授權子產品，完全可以獨立成一個項目，單獨部署，用來實作分布式微服務架構的單點登入。這樣在性能方面，能夠得到一個更大的提升。