譯者：牛小腩
在傳統的單體架構中，單個服務儲存所有的使用者資料，可以校驗使用者，並在認證成功後建立http會話。在微服務架構中，使用者是在和服務集合互動，每個服務都有可能需要知道請求的使用者是誰。一種樸素的解決方案是在微服務系統中應用與單體系統中相同的模式，但是問題就在於如何讓所有的服務訪問使用者的資料。解決這個問題大致兩個思路：若使用共享使用者資料庫時，更新資料庫表會成為乙個難題，因為所有服務必須同時公升級以便能夠對接修改後的表結構；若將相同的資料分發給所有服務時，當某個使用者已經被認證，如何讓每個服務知曉這個狀態是乙個問題。
borsos指出，單點登入（sso）方案可能看起來是乙個好主意，但這意味著每個面向使用者的服務都必須與認證服務互動，這會產生大量非常瑣碎的網路流量，同時這個方案實現起來也相當複雜 。 在其他方面，選擇sso方案安全性會很好，使用者登入狀態是不透明的，可防止攻擊者從狀態中推斷任何有用的資訊。
分布式會話方案，原理主要是將關於使用者認證的資訊儲存在共享儲存中，且通常由使用者會話作為key來實現的簡單分布式雜湊對映。 當使用者訪問微服務時，使用者資料可以從共享儲存中獲取。 該解決方案的另乙個優點是使用者登入狀態是不透明的。 當使用分布式資料庫時，它也是乙個高度可用且可擴充套件的解決方案。 這種方案的缺點在於共享儲存需要一定保護機制，因此需要通過安全鏈結來訪問，這時解決方案的實現就通常具有相當高的複雜性了。
客戶端令牌方案， 此令牌在客戶端生成，由身份驗證服務進行簽名，並且必須包含足夠的資訊，以便可以在所有微服務中建立使用者身份。 令牌會附加到每個請求上，為微服務提供使用者身份驗證。 這種解決方案的安全性相對較好，但身份驗證登出是乙個大問題， 緩解這種情況的方法可以使用短期令牌和頻繁檢查認證服務等。 對於客戶端令牌的編碼方案，borsos更喜歡使用json web tokens（jwt），它足夠簡單且庫支援程度也比較好。
客戶端令牌與api閘道器結合，這個方案意味著所有請求都通過閘道器，從而有效地隱藏了微服務。 在請求時，閘道器將原始使用者令牌轉換為內部會話id令牌。 在這種情況下，登出就不是問題，因為閘道器可以在登出時撤銷使用者的令牌。 這種方案雖然庫支援程度比較好，但實現起來還是可能很複雜。
borsos建議使用客戶端令牌（使用jwt）和api閘道器結合的方案，因為這個方案通常使用起來比較容易，且效能也不錯。 sso方案雖然能滿足需求，但他認為還是應該避免使用。若分布式會話方案所需要的相關技術已經應用在你的場景上，那麼這個方案也是比較有趣的。他同時強調在選擇解決方案時應著重考慮登出的重要性。
明年的倫敦微服務大會定於2023年11月6日-7日舉行。
微服務系統中的認證策略
在傳統的單體架構中，單個服務儲存所有的使用者資料，可以校驗使用者，並在認證成功後建立http會話。在微服務架構中，使用者是在和服務集合互動，每個服務都有可能需要知道請求的使用者是誰。一種樸素的解決方案是在微服務系統中應用與單體系統中相同的模式，但是問題就在於如何讓所有的服務訪問使用者的資料。解決這個...
微服務系統中的認證策略
在傳統的單體架構中，單個服務儲存所有的使用者資料，可以校驗使用者，並在認證成功後建立http會話。在微服務架構中，使用者是在和服務集合互動，每個服務都有可能需要知道請求的使用者是誰。一種樸素的解決方案是在微服務系統中應用與單體系統中相同的模式，但是問題就在於如何讓所有的服務訪問使用者的資料。解決這個...
彈性微服務的4種部署策略
與傳統架構相比，使用微服務構建應用程式可為開發人員提供更高的速度和敏捷性。但是，每次 更改仍會招致風險，如果未發現和解決 質量問題，則為潛在的失敗奠定了基礎。為了減輕這些風險，應用程式團隊應實施現代的雲原生路由策略，以使其更易於測試危險並確保應用程式已真正準備好在生產環境中部署。以下四種部署策略使用...