從本文開始，我們正式進入專案研發階段，首先我們分析下統一認證平臺應該具備哪些功能性需求和非功能性需求，在梳理完這些需求後，設計好系統採用的架構來滿足已有的需求和未來的擴充套件應用。

1 功能性需求

統一認證平臺應該具備以下基本功能，本文只是拋磚引玉，我只列出後續課程會講到的相關內容的需求，不會詳細的設計功能和需求，詳細的功能需求可在此基礎上根據專案需要自己擴充。

統一授權

可以為不同的業務系統提供一套標準、安全、可靠的授權方式，減少重複編碼工作，也可有效整合公司內部團隊使用技術架構不統一造成後期整合困難的問題。

身份認證

使用者訪問各業務系統時，提供使用者訪問的身份認證工作，校驗身份的合法性。

單點登入

使用者在認證平臺通過認證後，可直接訪問已授權的所有應用系統，實現不同應用系統的身份認證共享，從而達到多應用系統的單點登入。

掃碼登入

對於安全性要求較高的應用，可能對使用者身份進行二次認證，其中掃碼登入就是一種認證方式，後期會單獨列篇章在講解掃碼登入的實現。

2 非功能性需求

相容性

系統設計時需要考慮到相容性問題，考慮到後期接入的客戶端的不確定性，設計時應滿足採用統一標準所有客戶端均可接入。

擴充套件性

系統設計時需要考慮到系統的可擴充套件性，隨著接入應用的增多，系統也要支援橫向擴充套件來滿足高併發的需求。

安全性

系統設計時需要考慮系統應用的安全性，從資料安全到傳輸安全，保證認證平臺安全穩定執行。

3 系統初步架構

根據以上需求，形成初步的系統架構，後續的課程會圍繞此架構的基礎上進行講解，並一步一步來實現所有的功能。

通過此微服務架構，我們可以很好的對專案進行擴充套件應用，隨後我們會發現有幾個問題需要解決。

• 1、閘道器的功能及實現？

  閘道器應該具備路由、認證、鑑權、限流、熔斷、快取、監控等一系列功能，所有的請求都優先進入閘道器，他是整個應用程式的基石，所以閘道器應該滿足橫向擴充套件的需求來應對未來的請求壓力。那如何實現這個閘道器呢？大名鼎鼎的Ocelot就派上用場了，開源地址(https://github.com/ThreeMammals/Ocelot)，後續的閘道器功能實現都是基於Ocelot的基礎上進行擴充套件實現，如有不熟悉的，可以先自己檢視Ocelot相關的文件。

• 2、授權和認證的功能及如何實現？

  如何實現標準、安全、可擴充套件的認證模組，這塊就靠我們另外一個開源專案在解決我們的問題，Identity Server 4，這個元件基本能滿足我們常用的應用，基本的使用方法可參考園友們的基礎教程，後續的應用會就滿足我們業務需求需要改造的部分進行詳細介紹。

• 3、如何實現服務註冊中心？

  應用中會結合Consul叢集和.Netcore服務，實現服務的自動註冊、移除、監控、通知等一系列功能。

• 4、為什麼要搭載配置中心及如何實現？

  一旦專案使用分散式架構，面臨的最大的問題是每次釋出都要修改專案的配置資訊，想象一下如果我們有100個服務，配置資訊一致，需要修改100次，天哪。漏了百八十個忘了改也正常，這次我們就需要把配置資訊進行獨立管理，Apollo閃亮登場.

4 寫在最後

後續的文章將圍繞我們提出的4個問題來一個一個實現，下一篇我們將從閘道器這塊來講解下如何設計出跟專案需求契合的閘道器，對於當前未實現的部分如何進行改造。