隨筆筆記1
1.1 什么是分布式系統(tǒng)
隨著軟件環(huán)境和需求的變化 ，軟件的架構由單體結構演變?yōu)榉植际郊軜?，具有分布式架構的系統(tǒng)叫分布式系統(tǒng)，分 布式系統(tǒng)的運行通常依賴網絡，它將單體結構的系統(tǒng)分為若干服務，服務之間通過網絡交互來完成用戶的業(yè)務處 理，當前流行的微服務架構就是分布式系統(tǒng)架構，如下圖:
分布式系統(tǒng)具體如下基本特點: 1、分布性:每個部分都可以獨立部署，服務之間交互通過網絡進行通信，比如:訂單服務、商品服務。 2、伸縮性:每個部分都可以集群方式部署，并可針對部分結點進行硬件及軟件擴容，具有一定的伸縮能力。 3、共享性:每個部分都可以作為共享資源對外提供服務，多個部分可能有操作共享資源的情況。 4、開放性:每個部分根據(jù)需求都可以對外發(fā)布共享資源的訪問接口，并可允許第三方系統(tǒng)訪問。
1.2 分布式認證需求
分布式系統(tǒng)的每個服務都會有認證、授權的需求，如果每個服務都實現(xiàn)一套認證授權邏輯會非常冗余，考慮分布式 系統(tǒng)共享性的特點，需要由獨立的認證服務處理系統(tǒng)認證授權的請求;考慮分布式系統(tǒng)開放性的特點，不僅對系統(tǒng) 內部服務提供認證，對第三方系統(tǒng)也要提供認證。分布式認證的需求總結如下:
統(tǒng)一認證授權 提供獨立的認證服務，統(tǒng)一處理認證授權。
無論是不同類型的用戶，還是不同種類的客戶端(web端，H5、APP)，均采用一致的認證、權限、會話機制，實現(xiàn) 統(tǒng)一認證授權。
要實現(xiàn)統(tǒng)一則認證方式必須可擴展，支持各種認證需求，比如:用戶名密碼認證、短信驗證碼、二維碼、人臉識別等認證方式，并可以非常靈活的切換。 應用接入認證應提供擴展和開放能力，提供安全的系統(tǒng)對接機制，并可開放部分API給接入第三方使用，一方應用(內部 系統(tǒng)服 務)和三方應用(第三方應用)均采用統(tǒng)一機制接入。
1.3 分布式認證方案
1.3.1 選型分析
1、基于session的認證方式 在分布式的環(huán)境下，基于session的認證會出現(xiàn)一個問題，每個應用服務都需要在session中存儲用戶身份信息，通過負載均衡將本地的請求分配到另一個應用服務需要將session信息帶過去，否則會重新認證。
這個時候，通常的做法有下面幾種: Session復制:多臺應用服務器之間同步session，使session保持一致，對外透明。 Session黏貼:當用戶訪問集群中某臺服務器后，強制指定后續(xù)所有請求均落到此機器上。 Session集中存儲:將Session存入分布式緩存中，所有服務器應用實例統(tǒng)一從分布式緩存中存取Session。
總體來講，基于session認證的認證方式，可以更好的在服務端對會話進行控制，且安全性較高。但是，session機 制方式基于cookie，在復雜多樣的移動客戶端上不能有效的使用，并且無法跨域，另外隨著系統(tǒng)的擴展需提高 session的復制、黏貼及存儲的容錯性。
2、基于token的認證方式
基于token的認證方式，服務端不用存儲認證數(shù)據(jù)，易維護擴展性強， 客戶端可以把token 存在任意地方，并且可 以實現(xiàn)web和app統(tǒng)一認證機制。其缺點也很明顯，token由于自包含信息，因此一般數(shù)據(jù)量較大，而且每次請求 都需要傳遞，因此比較占帶寬。另外，token的簽名驗簽操作也會給cpu帶來額外的處理負擔。
1.3.2 技術方案
根據(jù) 選型的分析，決定采用基于token的認證方式，它的優(yōu)點是:
1、適合統(tǒng)一認證的機制，客戶端、一方應用、三方應用都遵循一致的認證機制。 2、token認證方式對第三方應用接入更適合，因為它更開放，可使用當前有流行的開放協(xié)議Oauth2.0、JWT等。 3、一般情況服務端無需存儲會話信息，減輕了服務端的壓力。
分布式系統(tǒng)認證技術方案見下圖:
流程描述:
(1)用戶通過接入方(應用)登錄，接入方采取OAuth2.0方式在統(tǒng)一認證服務(UAA)中認證。
(2)認證服務(UAA)調用驗證該用戶的身份是否合法，并獲取用戶權限信息。
(3)認證服務(UAA)獲取接入方權限信息，并驗證接入方是否合法。
(4)若登錄用戶以及接入方都合法，認證服務生成jwt令牌返回給接入方，其中jwt中包含了用戶權限及接入方權 限。
(5)后續(xù)，接入方攜帶jwt令牌對API網關內的微服務資源進行訪問。 (6)API網關對令牌解析、并驗證接入方的權限是否能夠訪問本次請求的微服務。
(7)如果接入方的權限沒問題，API網關將原請求header中附加解析后的明文Token，并將請求轉發(fā)至微服務。
(8)微服務收到請求，明文token中包含登錄用戶的身份和權限信息。因此后續(xù)微服務自己可以干兩件事:
1，用 戶授權攔截(看當前用戶是否有權訪問該資源)
2，將用戶信息存儲進當前線程上下文(有利于后續(xù)業(yè)務邏輯隨時 獲取當前用戶信息)
流程所涉及到UAA服務、API網關這三個組件職責如下:
1)統(tǒng)一認證服務(UAA) 它承載了OAuth2.0接入方認證、登入用戶的認證、授權以及生成令牌的職責，完成實際的用戶認證、授權功能。
2)API網關
作為系統(tǒng)的唯一入口，API網關為接入方提供定制的API集合，它可能還具有其它職責，如身份驗證、監(jiān)控、負載均 衡、緩存等。API網關方式的核心要點是，所有的接入方和消費端都通過統(tǒng)一的網關接入微服務，在網關層處理所 有的非業(yè)務功能。
補充：
什么是會話：
用戶認證通過后，為了避免用戶的每次操作都進行認證可將用戶的信息保證在會話中。會話就是系統(tǒng)為了保持當前
用戶的登錄狀態(tài)所提供的機制，常見的有基于session方式、基于token方式等。
基于session方式的交互流程是，用戶認證成功后，在服務端生成用戶相關的數(shù)據(jù)保存在session(當前會話)中，發(fā)給客戶端的 sesssion_id 存放到 cookie 中，這樣用戶客戶端請求時帶上 session_id 就可以驗證服務器端是否存在 session 數(shù) 據(jù)，以此完成用戶的合法校驗，當用戶退出系統(tǒng)或session過期銷毀時,客戶端的session_id也就無效了。
基于token方式的交互流程是，用戶認證成功后，服務端生成一個token發(fā)給客戶端，客戶端可以放到 cookie 或 localStorage等存儲中，每次請求時帶上 token，服務端收到token通過驗證后即可確認用戶身份。
基于session的認證方式由Servlet規(guī)范定制，服務端要存儲session信息需要占用內存資源，客戶端需要支持 cookie; 基于token的方式則一般不需要服務端存儲token，并且不限制客戶端的存儲方式。如今移動互聯(lián)網時代 更多類型的客戶端需要接入系統(tǒng)，系統(tǒng)多是采用前后端分離的架構進行實現(xiàn)，所以基于token的方式更適合。什么是授權
拿微信來舉例子，微信登錄成功后用戶即可使用微信的功能，比如，發(fā)紅包、發(fā)朋友圈、添加好友等，沒有綁定 銀行卡的用戶是無法發(fā)送紅包的，綁定銀行卡的用戶才可以發(fā)紅包，發(fā)紅包功能、發(fā)朋友圈功能都是微信的資源即 功能資源，用戶擁有發(fā)紅包功能的權限才可以正常使用發(fā)送紅包功能，擁有發(fā)朋友圈功能的權限才可以使用發(fā)朋友 圈功能，這個根據(jù)用戶的權限來控制用戶使用資源的過程就是授權。
為什么要授權?
認證是為了保證用戶身份的合法性，授權則是為了更細粒度的對隱私數(shù)據(jù)進行劃分，授權是在認證通過后發(fā)生的， 控制不同的用戶能夠訪問不同的資源。
授權: 授權是用戶認證通過根據(jù)用戶的權限來控制用戶訪問資源的過程，擁有資源的訪問權限則正常訪問，沒有權限則拒絕訪問。授權的數(shù)據(jù)模型
主體、資源、權限相關的數(shù)據(jù)模型如下:
主體(用戶id、賬號、密碼、...)
資源(資源id、資源名稱、訪問地址、...)
權限(權限id、權限標識、權限名稱、資源id、...)
角色(角色id、角色名稱、...)
角色和權限關系(角色id、權限id、...)
主體(用戶)和角色關系(用戶id、角色id、...)
通常企業(yè)開發(fā)中將資源和權限表合并為一張權限表，如下
資源(資源id、資源名稱、訪問地址、...)
權限(權限id、權限標識、權限名稱、資源id、...)
合并為: 權限(權限id、權限標識、權限名稱、資源名稱、資源訪問地址、...)
一些資料筆記，記錄一下。
公司saas平臺基于session的認證方式，客戶端以session_id與服務端保持會話。
