可繫結可擴充套件的帳號系統設計原理及其實現(一)
阿新 • • 發佈：2019-02-15
轉載：http://blog.cocosdever.com/2016/03/08/The-design-principle-and-implementation-of-extensible-account-system-1/
前言
在2016年春節前兩個星期,我負責公司的新專案一元奪寶的個人中心的設計.主要的需求包括使用者註冊,登入,使用者訂單聚合,中獎資料查詢等等.裡面的使用者註冊和登入部分比較特殊,因為公司另一個產品要求奪寶專案的帳號系統能與其打通,實現另一個專案(下文簡稱B專案)的使用者可以直接登入到奪寶專案上.B專案主要是依賴手機號碼作為使用者的帳號,而奪寶專案則允許使用者通過手機號碼註冊,微信自動登入註冊,QQ自動登入註冊等等(下文統稱第三方登入).同時要求已經使用手機號碼註冊的使用者可以繫結自己的多個第三方帳號;只使用第三方帳號登入的使用者也可以隨時繫結自己的手機號,而新繫結的手機號也可以是B專案的手機號或者奪寶專案存在的帳號或者全新的號碼,如果手機號已經註冊的則將資料與手機號所在帳號合併.通過上述約束來實現所有帳號都互相打通,當然資料也要求互相打通.經過詳細探討,最終解決了這個特殊的需求.
現在春節過去了,我也在此總結分析一下這次的可擴充套件帳號系統的設計原理,而在下一篇文章中,我將介紹具體實現的技術細節.
需求場景
- 每個使用者都存在多個不同的註冊登入方式,比如微信,QQ,微博.
- 登入方式在未來可能增加或者減少.
- 使用者在使用不同的途徑註冊登入之後就成為獨立帳號,每一個獨立帳號又可以互相繫結.
- 繫結之後的帳號視為一體,但是仍然可以使用不同途徑登入.
- 相互繫結之後的帳號,可能在系統留存大量資料,不適合資料遷移.
- 使用者的主要帳號(例如手機號)可以被多次繫結到不同的第三方帳號上,擁有相同主帳號的帳號視為同一帳號,資料互通.
本文教程實現一個能滿足以上描述的帳號系統,至於大家在實際專案中可以根據自己需求,在邏輯業務中禁止或允許使用者相關行為.
難點分析
- 隨著時間推移,後期可能增加更多登入的途徑,所以系統需要使用可擴充套件的方式實現
- 假設使用者已經用手機號碼註冊過(這裡稱為老帳號),此時如果使用微信登入並且完成了相關購買等,再繫結到老帳號上,這時候需要實現使用者新舊資料合併,以確保前端展示的資料和使用者的真實查詢一致;如果再加入QQ登入並且繫結同個手機號,同樣需要把QQ操作的資料繫結到老帳號上,擁有相同老帳號的帳號資料互通.此處也為一難點,需要靈活處理.
- 使用者繫結資料之後,其實就相當於只有一個主帳號被使用了.其他第三方帳號比如微信,在微信登入的時候,仍然需要通過微信特徵(openid)進行使用者登入驗證.因此需要保留第三方帳號的關鍵資料,如果直接把這個關鍵資料所有欄位放入帳號表,則以後多增加一種方式都需要去修改一下資料表字段,這顯然是不可取.此處的設計也是一要點難點.
設計原理
難點分析一節已經描述了潛在的設計難點,接下來分別從資料庫設計,程式邏輯設計兩大部分闡述設計的原理
資料庫設計
可擴充套件帳號系統的設計
Users表設計
相信大部分同學一開始想到的就是在users表中增加第三方登入的唯一表示欄位.比如在users表的使用者名稱,密碼,基礎上增加一個wx_openid,用來表示微信唯一標識,qq_openid用來表示QQ唯一標識.然後表的主要欄位看起來就像這樣:
| id | phone(主帳號) | balance | nickname | wx_openid | qq_openid | weibo_openid | … |
|---|---|---|---|---|---|---|---|
| 6 | 10086 | 1000(幣) | 啊C | aaa | bbb | ccc | … |