系統服務化構建-退出功能須要 網絡支持嗎？

本文其實是一道面試題，關於登陸主題作一些探討。

對應功能常見的設計思路，表達能力，易混淆的概念，功能責任的分離，直至網絡協議的一些特色，經過這道面試題就能夠挖掘出來了。

你在網上是搜不到答案的，只有我跟面試者溝通時纔會這麼出題。

這道題會涉及如下幾個方面

用戶狀態保存邏輯/常見的軟件應用開發中如何存儲和維持用戶的狀態？

更多的應聘者會提到 Token，那麼

Token 服務端的設計策略是什麼

進而細化爲

服務端如何識別用戶

回到題目如何理解狀態，先後端分離大多采用 HTTP 協議通信，HTTP 倒是無狀態的，而咱們又要保存用戶的狀態，矛盾了吧

HTTP 是無狀態的，單純的作請求響應，而業務必須是有狀態的，不然業務沒法流轉和推動。兩者是如何關聯的

帳號體系如何設計的

這樣溝通下來是否是一連串的問題都引伸出來了？

理解狀態

狀態的理解實際上很抽象，咱們能夠 理解爲狀態就是業務的延續性，有了狀態 ，業務才能正常流轉。流轉其實是數據的流動，進而狀態就是在處理數據。

對無狀態的理解核心-獨立，【每次請求是獨立的，低耦合的】。狀態實際上最終是經過數據體現的，有狀態就表明着過多的數據依賴。

接口設計最佳實踐 文中有如下一句建議

A RESTful API should be stateless

This means that request authentication should not depend on cookies or sessions. Instead, each request should come with some sort authentication credentials.

如今 業界最流行的狀態保存維護方案就是 Token 機制。從 cookies 和 session 到 Token，就是技術的演化過程。

思考

客戶端 （特指安卓和 iOS 的原生客戶端）中有 cookies 和 session 的概念嗎？如何理解和闡述

帳號系統設計第一要點 登陸與退出

既然題目中提到了退出功能，說一說帳號系統的設計。

以前產品同事在需求評審中提出一個場景：

公衆號連接業務系統登陸，用戶在業務系統修改密碼以後，返回到微信公衆號中仍然能夠進入須要登陸受權才能夠訪問的頁面，沒有任何從新登陸的提示。

其實緣由很簡單，微信公衆號連接業務系統登陸的體系採用的 Token 保存用戶信息的兩方 OAuth 協議(注意啊這裏說的是業務系統自己的登陸邏輯，並非微信開發平臺)。

Token 有一個有效時長的生命週期，鑑於減小用戶頻繁登陸的用戶體驗效果，微信端的 Token 時長會設置的長一些，好比一個月。當在有效時長內，用戶修改密碼後，實際上微信端的 Token 是感知不到的。

爲何感知不到，從產品的完整度來講，這塊是欠缺的，從技術方面來講這要從 Token 的生成和存儲談起。

Token 生命週期由客戶端登陸場景發起，服務器端負責分配和管理。最多見的存儲方式是在 redis 數據庫中採用 key value 形式，而 key 是 token， value 是一些須要緩存的熱點數據，通常以用戶編號，用戶名等 profile 信息爲主。

帳戶系統若是設計到這一步，已經能夠知足大部分應用系統以雲端爲中心，多個客戶端正常登陸的狀況了。
這種驗證方式也是我上文提到的 寬泛的兩方 OAuth 協議的應用。以前有一篇文章單獨闡述了兩方 OAuth 系統服務化構建-兩方 OAuth

接着繼續描述，端應用拿着用戶的 Token 信息，會對應查找到緩存數據。修改密碼後，系統拿到的是用戶編號之類的惟一標識。若是在生成 Token 時，沒有作用戶惟一標識與 Token 的對應關係，那麼修改密碼後也就關聯不到用戶已生效的 Token 信息。

兩個對應關係，分別是以 Token 爲 key，和以用戶惟一標識爲 key，結合使用就能夠實現 Token 的管理

帳號系統設計的第二要點 遠程管理

咱們把接入帳號系統的系統都抽象爲應用，不論是網站，原生 APP，混合 APP，仍是微信小程序。遠程管理的用戶有兩類，一類是雲端管理人員，一類是登陸用戶。

雲端管理人員 遠程查看用戶登陸狀態，在線統計，多設備管理，踢人，都是這方面的應用場景。

登陸用戶在我的中心查看我的帳號登陸過哪些應用，剩餘時長如何，實現登陸應用退出。如圖 2 Teambition 的我的中心。

以上是開放平臺受權登陸的套路，只涉及到應用服務端和客戶端，並無達到 OAuth 三方角色的複雜度。

遠程帳號分配，保持，註銷，統計

帳號系統設計的第三要點 服務化

基於以上兩個要點設計完成以後，帳號系統已經知足了獨立於其它的系統的要求，能夠以帳號中心的身份自行運轉了，其自己就是一個通行證的協調分配中心。咱們試着列出以下 FetureList

實名驗證

1 驗證手機

實現方式 經過發送驗證碼來驗證登陸身份

2 多種登陸渠道，如手機驗證碼，用戶名密碼，微信掃碼（第三方帳號的一種），手機與密碼（用戶名登陸的一種）

應用受權管理

企業的應用分爲內部應用和外部應用

應用列表

退出應用

登陸應用

退出全部應用

操做日誌

在線人數統計

運營分析

...

安全中心

1 帳號信息常規維護，密碼修改，找回，登陸方式選擇

1 密碼修改後的登陸管理 （單點登陸，設備關聯，退出已有登陸）

2 登陸有效時長（由端應用自行控制）

退出功能與網絡支持

回到題目中，退出功能與網絡支持的產品形態是這樣的：

退出功能，請求退出登陸接口，服務端註銷登陸憑據，客戶端移除相關本地存儲。
有無網絡，退出接口是否成功，都以退出成功的交互引導用戶，至於其它的，經過技術來實現。如服務端的自動失效等。

常見的誤區是，退出只作客戶端的憑據刪除，而後跳轉登陸頁面，這樣的流程過於簡單了。

end 2019年12月 公衆號 圖南日晟

---