億級(jí)用戶中心的設(shè)計(jì)與實(shí)踐

用戶中心，顧名思義就是管理用戶的地方，幾乎是所有互聯(lián)網(wǎng)公司最為核心的子系統(tǒng)之一。它的核心功能是登錄與注冊(cè)，主要功能是修改密碼、換綁手機(jī)號(hào)碼、獲取用戶信息、修改用戶信息和一些延伸服務(wù)，同時(shí)還有登錄之后生成Token以及校驗(yàn)Token的功能。下面我們從幾個(gè)維度來拆解用戶中心。

用戶中心既需要為用戶提供服務(wù)，也會(huì)承擔(dān)其他業(yè)務(wù)的頻繁調(diào)用；既然需要為用戶提供服務(wù)，它就會(huì)自帶一些業(yè)務(wù)邏輯，比如用戶在登錄過程中需要風(fēng)控或短信的校驗(yàn)，那么就會(huì)存在不可用的風(fēng)險(xiǎn)。而比如獲取用戶信息的接口，則沒有那么多的依賴，可能只需要調(diào)用數(shù)據(jù)庫或者緩存就可以。獲取用戶信息接口要求穩(wěn)定，而核心的登錄注冊(cè)接口也需要穩(wěn)定，但是當(dāng)我們?cè)诮涌趯用婕右恍┎呗曰蛘咝薷牡臅r(shí)候，不希望因?yàn)樯暇€問題導(dǎo)致整個(gè)服務(wù)不可用，而且上線后，需要對(duì)整個(gè)服務(wù)功能做全量的回歸，導(dǎo)致資源嚴(yán)重浪費(fèi)。

因此，基于業(yè)務(wù)特性，我們可以將用戶中心拆成3個(gè)獨(dú)立的微服務(wù): 網(wǎng)關(guān)服務(wù)，核心服務(wù)，異步消費(fèi)者服務(wù)。網(wǎng)關(guān)服務(wù)，提供http服務(wù)，聚合了各種業(yè)務(wù)邏輯和服務(wù)調(diào)用，比如登錄時(shí)候需要校驗(yàn)的風(fēng)控或者短信；核心服務(wù)，處理簡(jiǎn)單的業(yè)務(wù)邏輯以及數(shù)據(jù)存儲(chǔ)，核心服務(wù)處在調(diào)用鏈路的終端，幾乎不依賴調(diào)用其他服務(wù)，比如校驗(yàn)Token或者獲取用戶信息，他們就只依賴于redis或者數(shù)據(jù)庫；而異步消費(fèi)者服務(wù)，則處理并消費(fèi)異步消息。下文會(huì)詳細(xì)介紹。

這樣的設(shè)計(jì)之后，當(dāng)有新功能上線時(shí)，核心服務(wù)和異步消費(fèi)服務(wù)幾乎不需要重新發(fā)布，只需要發(fā)布網(wǎng)關(guān)服務(wù)，依賴我們核心服務(wù)的第三方非常放心，層級(jí)也非常的清晰。當(dāng)然，這樣做的代價(jià)就是服務(wù)的調(diào)用鏈路變長了。由于涉及到網(wǎng)關(guān)和核心服務(wù)，就需要發(fā)布兩個(gè)服務(wù)，而且要做兼容性測(cè)試。

用戶中心的接口涉及到用戶的核心信息，安全性要求高；同時(shí)，承接了較多第三方的調(diào)用，可用性要求也高。因此，對(duì)用戶中心的接口做以下設(shè)計(jì)：

首先，接口可以拆分為面向Web和面向App的接口。Web接口需要做到跨域情況下的單點(diǎn)登錄，加密、驗(yàn)簽和token校驗(yàn)的方式也同App端的不一樣。

其次，對(duì)核心接口做特殊處理。比如登錄接口，在邏輯和鏈路上做了一些優(yōu)化。為什么要對(duì)這些接口做特殊處理呢？假如用戶不能登錄，用戶會(huì)非常恐慌，客訴量會(huì)立馬上來。

那怎么做呢？一方面，我們將用戶核心信息表做簡(jiǎn)單。用戶的信息當(dāng)中會(huì)包含userId、手機(jī)號(hào)碼、密碼、頭像、昵稱等字段，假如把用戶的這些所有信息都保存在一張表中，那么這張表將會(huì)異常龐大，變更字段變得異常困難。因此，需要將用戶表拆分，將核心的信息保存在用戶表中，比如userId、username、手機(jī)號(hào)碼、密碼、鹽值（隨機(jī)生成）等；而一些如性別，頭像，昵稱等信息保存在用戶資料表中。

另一方面，我們需要將登錄的核心鏈路做短，短到只依賴于讀庫。一般情況下，用戶登錄后，需要記錄用戶登錄信息，調(diào)用風(fēng)控或者短信等服務(wù)。對(duì)于登錄鏈路來說，任何一個(gè)環(huán)節(jié)出現(xiàn)問題都有可能導(dǎo)致用戶無法登錄，那么怎么樣才能做到最短的鏈路呢？方法就是依賴的服務(wù)可自動(dòng)降級(jí)。比如說反欺詐校驗(yàn)出問題了，那么它自動(dòng)降級(jí)后使用它的默認(rèn)策略，極端情況下只做密碼校驗(yàn)，主庫掛了之后還能到從庫讀取用戶信息。

最后就是接口的安全性校驗(yàn)。對(duì)App接口我們需要做防重放和驗(yàn)簽。驗(yàn)簽可能大家比較熟悉，但是對(duì)防重放這個(gè)概念可能相對(duì)陌生。防重放，顧名思義就是防止請(qǐng)求重復(fù)發(fā)送。用戶請(qǐng)求在特定時(shí)間段內(nèi)只能請(qǐng)求一次。即使用戶請(qǐng)求被攻擊者挾持，在一段時(shí)間內(nèi)也無法重復(fù)請(qǐng)求。如果攻擊者想要篡改用戶請(qǐng)求再發(fā)送，對(duì)不起，請(qǐng)求不會(huì)通過。得益于大數(shù)據(jù)的支持，結(jié)合終端，我們還可以把每個(gè)用戶行為畫像存儲(chǔ)在系統(tǒng)中（或者調(diào)用第三方服務(wù)）。用戶發(fā)起請(qǐng)求后，我們的接口會(huì)根據(jù)用戶畫像對(duì)用戶進(jìn)行諸如手機(jī)號(hào)碼校驗(yàn)、實(shí)名認(rèn)證、人臉或者活體校驗(yàn)。

隨著用戶的增長，數(shù)據(jù)超過了1億，怎么辦？常見的辦法就是分庫分表。我們來分析一下用戶中心常見的一些表結(jié)構(gòu)：用戶信息表，第三方登錄關(guān)聯(lián)表，用戶事件表。從上述表中可以看出來，用戶相關(guān)的數(shù)據(jù)表增長相對(duì)緩慢，因?yàn)橛脩粼鲩L是有天花板的。用戶事件表的增長是呈指數(shù)級(jí)增長，因?yàn)槊總€(gè)用戶登錄、變更等密碼及變更手機(jī)號(hào)碼等操作是不限次數(shù)。

因此，首先我們可以先把用戶信息表垂直切分。正如上面說的，將用戶ID、密碼、手機(jī)號(hào)、鹽值等常見字段從用戶信息表中拆分，其他用戶相關(guān)的信息用單獨(dú)一張表。另外，把用戶事件表遷移至其他庫中。相比于水平切分，垂直切分的代價(jià)相對(duì)較少，操作起來相對(duì)簡(jiǎn)單。用戶核心信息表由于數(shù)據(jù)量相對(duì)較少，即使是億級(jí)別的數(shù)據(jù)，利用數(shù)據(jù)庫緩存的機(jī)制，也能夠解決性能問題。

其次，我們可以利用前后臺(tái)業(yè)務(wù)的特性采用不同的方式來區(qū)別對(duì)待。對(duì)于用戶側(cè)前臺(tái)訪問：用戶通過username/mobile登錄或者通過uid來查詢用戶信息。用戶側(cè)信息的訪問通常是單條數(shù)據(jù)的查詢，我們可以通過索引多次查詢來解決一致性和高可用問題。對(duì)于運(yùn)營側(cè)后臺(tái)訪問：根據(jù)年齡、性別、登錄時(shí)間段、注冊(cè)時(shí)間段等來進(jìn)行查詢，基本上都是批量分頁查詢。但是由于是內(nèi)部系統(tǒng)，查詢量低，對(duì)一致性要求低。如果用戶側(cè)和運(yùn)營側(cè)的查詢采用同一個(gè)數(shù)據(jù)庫，那么運(yùn)營側(cè)的排序查詢會(huì)導(dǎo)致整個(gè)庫的CPU上升，查詢效率下降，影響到用戶側(cè)。因此，運(yùn)營側(cè)使用的數(shù)據(jù)庫可以是和用戶側(cè)同樣的MySQL離線庫，如果想要增加運(yùn)營側(cè)的查詢效率，可以采用ES非關(guān)系型數(shù)據(jù)庫。ES支持分片與復(fù)制，方便水平分割和擴(kuò)展，復(fù)制保證了ES的高可用與高吞吐，同時(shí)能夠滿足運(yùn)營側(cè)的查詢需求。

最后，如果還是要水平切分來保證系統(tǒng)的性能，那么我們采取什么樣的切分方式呢？常見的方法有索引表法和基因法。索引表法的思路主要是UID能夠直接定位到庫，但是手機(jī)號(hào)碼或者username是無法直接定位到庫的，需要建立一個(gè)索引表來記錄mobile與UID或者username與UID的映射關(guān)系的方式來解決這個(gè)問題。通常這類數(shù)據(jù)比較少，可以不用分庫分表，但是相比直接查詢，多了一次數(shù)據(jù)庫查詢的同時(shí)，在新增數(shù)據(jù)的時(shí)候還多了一次映射關(guān)系的插入，事務(wù)變大。基因法的思路是我們將username或者mobile融入到UID中。具體做法如下：

1. 用戶注冊(cè)時(shí)，根據(jù)用戶的手機(jī)號(hào)碼，利用函數(shù)生成N bit的基因mobile_gen，使得mobile_gen=f(mobile);

2. 生成M bit全局唯一的id，作為用戶標(biāo)識(shí)；

3. 拼接M和N，作為UID賦給用戶；

4. 根據(jù)N bit來取余來插入到特定數(shù)據(jù)庫；

5. 查找用戶數(shù)據(jù)的時(shí)候，將用戶UID的后N bit取余來落到最終的庫中。

從上述過程中看，基因法只適用于某類經(jīng)常查詢的場(chǎng)景，比如用手機(jī)號(hào)碼登錄，如果用戶使用username登錄就比較麻煩了。因此大家也可以根據(jù)自己的業(yè)務(wù)場(chǎng)景來選擇不同的方式水平切分。

用戶登錄之后，另一個(gè)重要的事情就是Token的生成與校驗(yàn)。用戶的Token分為兩類， 一類是web端登陸生成的Token， 這個(gè)Token可以和Cookie結(jié)合， 達(dá)到單點(diǎn)登陸的效果，在此不細(xì)說了。另外一類就是APP端登錄生成的Token。用戶在我們的APP輸入用戶名密碼之后，服務(wù)端會(huì)對(duì)用戶的用戶名密碼進(jìn)行校驗(yàn)，成功之后從系統(tǒng)配置中心獲取加密算法的版本以及秘鑰，并按照一定的格式排列用戶ID，手機(jī)號(hào)、隨機(jī)碼以及過期時(shí)間，經(jīng)過一系列的加密之后，生成了Token之后并將其存入Redis緩存。而Token的校驗(yàn)就是把用戶ID和Token組合并校驗(yàn)是否在Redis中存在。那么假如Redis不可用了怎么辦呢？這里有一個(gè)高可用和自動(dòng)降級(jí)的設(shè)計(jì)。當(dāng)Redis不可用的時(shí)候， 服務(wù)端會(huì)生成一個(gè)特殊格式的Token。當(dāng)校驗(yàn)Token的時(shí)候，會(huì)對(duì)Token的格式進(jìn)行一個(gè)判斷。

假如判斷為Redis不可用時(shí)生成的Token，那么服務(wù)端會(huì)對(duì)Token進(jìn)行解密，而Token的生成是由用戶ID，手機(jī)號(hào)、隨機(jī)碼和過期時(shí)間等數(shù)據(jù)按照特定順序排列并加密而來的， 那么解密出來的數(shù)據(jù)中也包含了ID，手機(jī)號(hào)碼，隨機(jī)碼和過期時(shí)間。服務(wù)端會(huì)根據(jù)獲取到的數(shù)據(jù)查詢數(shù)據(jù)庫， 比對(duì)之后告訴用戶是否登錄成功。由于內(nèi)存緩存redis和數(shù)據(jù)庫緩存性能的差距，在redis不可用的情況下，降級(jí)有可能會(huì)導(dǎo)致數(shù)據(jù)庫無法及時(shí)響應(yīng)，因此需要在降級(jí)的方法上加入限流。

數(shù)據(jù)安全對(duì)用戶中心來說非常重要。敏感數(shù)據(jù)需要脫敏處理，對(duì)密碼更是要做多重的加密處理。應(yīng)用雖然有自己的安全策略，但如果把黑客限制在登錄之前，那應(yīng)用的安全性將得到大幅度的提升。互聯(lián)網(wǎng)上用戶明文數(shù)據(jù)遭到泄露的案件屢屢發(fā)生，因此各大企業(yè)對(duì)數(shù)據(jù)安全的認(rèn)識(shí)也提到了前所未有的高度。而即使使用了MD5和salt的加密方式，依然可以使用彩虹表的方式來破解。那么用戶中心對(duì)用戶信息是怎么保存的呢？

首先，正如上文中提到的用戶密碼、手機(jī)號(hào)等登錄信息和其他的信息分離，而且在不同的數(shù)據(jù)庫中。其次，對(duì)用戶設(shè)置的密碼進(jìn)行了黑名單校驗(yàn)，只要符合條件的弱密碼，都會(huì)拒絕提交，因?yàn)椴还苁褂昧耸裁醇用芊绞降娜趺艽a，都極其容易破解。為什么呢？因?yàn)槿说挠浶院懿睿蟛糠秩丝偸亲顑A向于選擇生日，單詞等來當(dāng)密碼。6位純數(shù)字可以生成100萬個(gè)不同的密碼，8位小寫字母和數(shù)字的組合大概可以生成2.8萬億個(gè)不同的密碼。一個(gè)規(guī)模為7.8萬億的密碼庫足以覆蓋大部分用戶的密碼，對(duì)于不同的加密算法都可以擁有這樣一個(gè)密碼庫，這也就是為什么大部分網(wǎng)站都建議用戶使用8位以上數(shù)字加字母密碼的原因。當(dāng)然，如果一方面加了鹽值，另一方面對(duì)密鑰分開保管，破解難度會(huì)指數(shù)級(jí)增加。

最后，可以用bcrypt/scrypt的方式來加密。bcrypt算法是基于Blowfish塊密鑰算法來實(shí)現(xiàn)的，bcrypt內(nèi)部實(shí)現(xiàn)了隨機(jī)加鹽處理，使用bcrypt之后每次加密后的密文都不一樣，同時(shí)還會(huì)使用內(nèi)存初始化hash過程。由于使用內(nèi)存，雖然在CPU上運(yùn)行很快，但是在GPU上并行運(yùn)算并不快。隨著新的FPGA集成了大型RAM，解決了內(nèi)存密集IO的問題，但是破解難度依然不小。而scrypt算法彌補(bǔ)了bcrypt算法的不足，它將CPU計(jì)算與內(nèi)存使用開銷都指數(shù)級(jí)提升了。bcrypt和scrypt算法能夠有效抵御彩虹表，但是安全性的提升帶來了用戶登錄性能的下降。用戶登錄注冊(cè)并不是一個(gè)高并發(fā)的接口，所以影響并不會(huì)特別大。因此在安全和性能方面需要依據(jù)業(yè)務(wù)類型和大小來做平衡，并不是所有的應(yīng)用都需要使用這種加密方式來保護(hù)用戶密碼。

此處的異步消費(fèi)，就是上文提到的異步消費(fèi)服務(wù)。用戶在做完登錄注冊(cè)等操作后，需要記錄用戶的操作日志。同時(shí)，用戶注冊(cè)登錄完畢后，下游業(yè)務(wù)需要對(duì)用戶增加積分，贈(zèng)送禮券等獎(jiǎng)勵(lì)操作。這些系統(tǒng)如果都同步依賴于用戶中心，那么整個(gè)用戶中心將異常龐大，鏈路非常冗長，也不符合業(yè)內(nèi)的“大系統(tǒng)做小“的原則。依賴的服務(wù)不可用之后將會(huì)造成用戶無法登錄注冊(cè)。因此，用戶中心在用戶操作完之后，將用戶事件入庫后發(fā)送至MQ，第三方業(yè)務(wù)監(jiān)聽用戶事件。用戶中心和下游業(yè)務(wù)解耦，同時(shí)用戶操作事件入庫后，在MQ不可用或者消息丟失的時(shí)候可做補(bǔ)償處理。用戶的畫像數(shù)據(jù)也在很大程度上來源于此處的數(shù)據(jù)。

用戶中心涉及到用戶的登錄注冊(cè)更改密碼等核心功能，能否及時(shí)發(fā)現(xiàn)系統(tǒng)的問題成為關(guān)鍵指標(biāo)，因此對(duì)業(yè)務(wù)的監(jiān)控顯得尤為重要。需要對(duì)用戶中心重要接口的QPS、機(jī)器的內(nèi)存使用量、垃圾回收的時(shí)間、服務(wù)的調(diào)用時(shí)間等做詳細(xì)的監(jiān)控。當(dāng)某個(gè)接口的調(diào)用量下降的時(shí)候，監(jiān)控會(huì)及時(shí)發(fā)出報(bào)警。除了這些監(jiān)控之外，還有對(duì)數(shù)據(jù)庫Binlog的寫入，前端組件，以及基于ZipKin全鏈路調(diào)用時(shí)間的監(jiān)控，實(shí)現(xiàn)從用戶發(fā)起端到結(jié)束端的全面監(jiān)控，哪怕出現(xiàn)一點(diǎn)問題，監(jiān)控隨時(shí)會(huì)告訴你哪里出問題了。比如運(yùn)營互動(dòng)推廣注冊(cè)量下降的時(shí)候，用戶中心就會(huì)發(fā)出報(bào)警，可以及時(shí)通知業(yè)務(wù)方改正問題，挽回?fù)p失。

本文從服務(wù)架構(gòu)設(shè)計(jì)，接口設(shè)計(jì)，token降級(jí)，數(shù)據(jù)安全和監(jiān)控等方面介紹了億級(jí)用戶中心的設(shè)計(jì)，當(dāng)然用戶中心的設(shè)計(jì)遠(yuǎn)不止這些，還會(huì)包含用戶數(shù)據(jù)的分庫分表，熔斷限流，第三方登錄等，在本文中就不一一贅述。盡管本文中設(shè)計(jì)的用戶中心能夠滿足大部分公司的需求，但是還存在一些比較大的挑戰(zhàn)：在鑒權(quán)服務(wù)增長的情況下，如何平滑的從用戶中心剝離；監(jiān)控的侵入性以及監(jiān)控的粒度的完善；另外服務(wù)的安全性、可用性、性能的提升永遠(yuǎn)都沒有盡頭，也是我們孜孜追求的目標(biāo)。在未來的日子里，希望能夠通過大家的努力，使用戶中心的技術(shù)體系更上一層樓。