上一期蒜茴，我從計算機網(wǎng)絡(luò)層的角度談了應(yīng)對“高性能”和“高可用”的整體架構(gòu)設(shè)計胡本。今天忠荞，我將從“用戶層”和“業(yè)務(wù)層”的角度談?wù)劤Ｒ姷膽?yīng)用場景和關(guān)鍵技術(shù)殊霞。
用戶層技術(shù)
1. 用戶管理
互聯(lián)網(wǎng)業(yè)務(wù)的一個典型特征就是通過互聯(lián)網(wǎng)將眾多分散的用戶連接起來摧阅，因此用戶管理是互聯(lián)網(wǎng)業(yè)務(wù)必不可少的一部分。
稍微大一點的互聯(lián)網(wǎng)業(yè)務(wù)绷蹲，肯定會涉及多個子系統(tǒng)棒卷，這些子系統(tǒng)不可能每個都管理這么龐大的用戶，由此引申出用戶管理的第一個目標(biāo)：單點登錄（SSO）祝钢，又叫統(tǒng)一登錄比规。單點登錄的技術(shù)實現(xiàn)手段較多，例如 cookie拦英、JSONP蜒什、token 等，目前最成熟的開源單點登錄方案當(dāng)屬 CAS疤估，其架構(gòu)如下（https://apereo.github.io/cas/4.2.x/planning/Architecture.html?）
除此之外灾常，當(dāng)業(yè)務(wù)做大成為了平臺后，開放成為了促進(jìn)業(yè)務(wù)進(jìn)一步發(fā)展的手段铃拇，需要允許第三方應(yīng)用接入钞瀑，由此引申出用戶管理的第二個目標(biāo)：授權(quán)登錄。現(xiàn)在最流行的授權(quán)登錄就是 OAuth 2.0 協(xié)議慷荔，基本上已經(jīng)成為了事實上的標(biāo)準(zhǔn)雕什，如果要做開放平臺，則最好用這個協(xié)議显晶，私有協(xié)議漏洞多贷岸，第三方接入也麻煩。
用戶管理系統(tǒng)面臨的主要問題是用戶數(shù)巨大吧碾，一般至少千萬級凰盔，QQ、微信倦春、支付寶這種巨無霸應(yīng)用都是億級用戶户敬。不過也不要被這個數(shù)據(jù)給嚇倒了落剪，用戶管理雖然數(shù)據(jù)量巨大，但實現(xiàn)起來并不難尿庐，原因是什么呢忠怖？ 因為用戶數(shù)據(jù)量雖然大，但是不同用戶之間沒有太強的業(yè)務(wù)關(guān)聯(lián)抄瑟，A 用戶登錄和 B 用戶登錄基本沒有關(guān)系凡泣。因此雖然數(shù)據(jù)量巨大，但我們用一個簡單的負(fù)載均衡架構(gòu)就能輕松應(yīng)對皮假。
用戶管理的基本架構(gòu)如下：
2. 消息推送
消息推送根據(jù)不同的途徑鞋拟，分為短信、郵件惹资、站內(nèi)信贺纲、App 推送。除了 App褪测，不同的途徑基本上調(diào)用不同的 API 即可完成猴誊，技術(shù)上沒有什么難度。例如侮措，短信需要依賴運營商的短信接口懈叹，郵件需要依賴郵件服務(wù)商的郵件接口，站內(nèi)信是系統(tǒng)提供的消息通知功能分扎。
App 目前主要分為 iOS 和 Android 推送澄成，iOS 系統(tǒng)比較規(guī)范和封閉，基本上只能使用蘋果的 APNS笆包；但 Android 就不一樣了环揽，在國外，用 GCM 和 APNS 差別不大庵佣；但是在國內(nèi)歉胶，情況就復(fù)雜多了：首先是 GCM 不能用；其次是各個手機廠商都有自己的定制的 Android巴粪，消息推送實現(xiàn)也不完全一樣通今。因此 Android 的消息推送就五花八門了，大部分有實力的大廠肛根，都會自己實現(xiàn)一套消息推送機制辫塌，例如阿里云移動推送、騰訊信鴿推送派哲、百度云推送臼氨；也有第三方公司提供商業(yè)推送服務(wù)，例如友盟推送芭届、極光推送等储矩。
通常情況下感耙，對于中小公司，如果不涉及敏感數(shù)據(jù)持隧，Android 系統(tǒng)上推薦使用第三方推送服務(wù)即硼，因為畢竟是專業(yè)做推送服務(wù)的，消息到達(dá)率是有一定保證的屡拨。
如果涉及敏感數(shù)據(jù)只酥，需要自己實現(xiàn)消息推送，這時就有一定的技術(shù)挑戰(zhàn)了呀狼。消息推送主要包含 3 個功能：設(shè)備管理（唯一標(biāo)識裂允、注冊、注銷）哥艇、連接管理和消息管理叫胖，技術(shù)上面臨的主要挑戰(zhàn)有：
海量設(shè)備和用戶管理
消息推送的設(shè)備數(shù)量眾多，存儲和管理這些設(shè)備是比較復(fù)雜的她奥；同時，為了針對不同用戶進(jìn)行不同的業(yè)務(wù)推廣怎棱，還需要收集用戶的一些信息哩俭，簡單來說就是將用戶和設(shè)備關(guān)聯(lián)起來，需要提取用戶特征對用戶進(jìn)行分類或者打標(biāo)簽等拳恋。
連接狈沧剩活
要想推送消息必須有連接通道，但是應(yīng)用又不可能一直在前臺運行谬运，大部分設(shè)備為了省電省流量等原因都會限制應(yīng)用后臺運行隙赁，限制應(yīng)用后臺運行后連接通道可能就被中斷了，導(dǎo)致消息無法及時的送達(dá)梆暖。連接鄙》茫活是整個消息推送設(shè)計中細(xì)節(jié)和黑科技最多的地方，例如應(yīng)用互相拉起轰驳、找手機廠商開白名單等厚掷。
消息管理
實際業(yè)務(wù)運營過程中，并不是每個消息都需要發(fā)送給每個用戶级解，而是可能根據(jù)用戶的特征冒黑，選擇一些用戶進(jìn)行消息推送。由于用戶特征變化很大勤哗，各種排列組合都有可能抡爹，將消息推送給哪些用戶這部分的邏輯要設(shè)計得非常靈活，才能支撐花樣繁多的業(yè)務(wù)需求芒划，具體的設(shè)計方案可以采取規(guī)則引擎之類的微內(nèi)核架構(gòu)技術(shù)冬竟。
3. 存儲云欧穴、圖片云
互聯(lián)網(wǎng)業(yè)務(wù)場景中，用戶會上傳多種類型的文件數(shù)據(jù)诱咏，例如微信用戶發(fā)朋友圈時上傳圖片苔可，微博用戶發(fā)微博時上傳圖片、視頻袋狞，優(yōu)酷用戶上傳視頻焚辅，淘寶賣家上傳商品圖片等，這些文件具備幾個典型特點：
數(shù)據(jù)量大：用戶基數(shù)大苟鸯，用戶上傳行為頻繁同蜻，例如 2016 年的時候微信朋友圈每天上傳圖片就達(dá)到了 10 億張（http://mi.techweb.com.cn/tmt/2016-05-25/2338330.shtml）。
文件體積性绱Α：大部分圖片是幾百 KB 到幾 MB湾蔓，短視頻播放時間也是在幾分鐘內(nèi)。
訪問有時效性：大部分文件是剛上傳的時候訪問最多砌梆，隨著時間的推移訪問量越來越小默责。
為了滿足用戶的文件上傳和存儲需求，需要對用戶提供文件存儲和訪問功能咸包，這里就需要用到前面我在專欄第 40 期介紹“存儲層”技術(shù)時提到的“小文件存儲”技術(shù)桃序。簡單來說，存儲云和圖片云通常的實現(xiàn)都是“CDN + 小文件存儲”烂瘫，現(xiàn)在有了“云”之后媒熊，除非 BAT 級別，一般不建議自己再重復(fù)造輪子了坟比，直接買云服務(wù)可能是最快也是最經(jīng)濟的方式芦鳍。
既然存儲云和圖片云都是基于“CDN + 小文件存儲”的技術(shù)，為何不統(tǒng)一一套系統(tǒng)葛账，而將其拆分為兩個系統(tǒng)呢柠衅？這是因為“圖片”業(yè)務(wù)的復(fù)雜性導(dǎo)致的，普通的文件基本上提供存儲和訪問就夠了籍琳，而圖片涉及的業(yè)務(wù)會更多茄茁，包括裁剪、壓縮巩割、美化裙顽、審核、水印等處理宣谈，因此通常情況下圖片云會拆分為獨立的系統(tǒng)對用戶提供服務(wù)愈犹。
業(yè)務(wù)層技術(shù)
互聯(lián)網(wǎng)的業(yè)務(wù)千差萬別，不同的業(yè)務(wù)分解下來有不同的系統(tǒng)，所以業(yè)務(wù)層沒有辦法提煉一些公共的系統(tǒng)或者組件漩怎。拋開業(yè)務(wù)上的差異勋颖，各個互聯(lián)網(wǎng)業(yè)務(wù)發(fā)展最終面臨的問題都是類似的：業(yè)務(wù)復(fù)雜度越來越高。也就是說勋锤，業(yè)務(wù)層面對的主要技術(shù)挑戰(zhàn)是“復(fù)雜度”饭玲。
復(fù)雜度越來越高的一個主要原因就是系統(tǒng)越來越龐大，業(yè)務(wù)越來越多叁执。幸運的是茄厘，面對業(yè)務(wù)層的技術(shù)挑戰(zhàn)，我們有一把“屠龍寶刀”谈宛，不管什么業(yè)務(wù)難題次哈，用上“屠龍寶刀”問題都能迎刃而解。這把“屠龍寶刀”就是“拆”吆录，化整為零窑滞、分而治之，將整體復(fù)雜性分散到多個子業(yè)務(wù)或者子系統(tǒng)里面去恢筝。具體拆的方式你可以查看專欄前面可擴展架構(gòu)模式部分的分層架構(gòu)哀卫、微服務(wù)、微內(nèi)核等撬槽。
我以一個簡單的電商系統(tǒng)為例聊训，如下圖所示。
我這個模擬的電商系統(tǒng)經(jīng)歷了 3 個發(fā)展階段：
第一階段：所有功能都在 1 個系統(tǒng)里面恢氯。
第二階段：將商品和訂單拆分到 2 個子系統(tǒng)里面。
第三階段：商品子系統(tǒng)和訂單子系統(tǒng)分別拆分成了更小的 6 個子系統(tǒng)鼓寺。
上面只是個樣例勋拟，實際上隨著業(yè)務(wù)的發(fā)展，子系統(tǒng)會越來越多妈候，據(jù)說淘寶內(nèi)部大大小小的已經(jīng)有成百上千的子系統(tǒng)了敢靡。
隨著子系統(tǒng)數(shù)量越來越多，如果達(dá)到幾百上千苦银，另外一個復(fù)雜度問題又會凸顯出來：子系統(tǒng)數(shù)量太多啸胧，已經(jīng)沒有人能夠說清楚業(yè)務(wù)的調(diào)用流程了，出了問題排查也會特別復(fù)雜幔虏。此時應(yīng)該怎么處理呢纺念，總不可能又將子系統(tǒng)合成大系統(tǒng)吧？最終答案還是“合”想括，正所謂“合久必分陷谱、分久必合”，但合的方式不一樣，此時采取的“合”的方式是按照“高內(nèi)聚烟逊、低耦合”的原則渣窜，將職責(zé)關(guān)聯(lián)比較強的子系統(tǒng)合成一個虛擬業(yè)務(wù)域，然后通過網(wǎng)關(guān)對外統(tǒng)一呈現(xiàn)宪躯，類似于設(shè)計模式中的 Facade 模式乔宿。同樣以電商為樣例，采用虛擬業(yè)務(wù)域后访雪，其架構(gòu)如下：
小結(jié)
今天我為你講了互聯(lián)網(wǎng)架構(gòu)模板中的用戶層技術(shù)和業(yè)務(wù)層技術(shù)详瑞，希望對你有所幫助。
這就是今天的全部內(nèi)容冬阳，留一道思考題給你吧蛤虐，虛擬業(yè)務(wù)域劃分的粒度需要粗一些還是要細(xì)一些？你建議虛擬業(yè)務(wù)域的數(shù)量大概是多少肝陪，理由是什么驳庭？
歡迎你把答案寫到留言區(qū)，和我一起討論氯窍。相信經(jīng)過深度思考的回答饲常，也會讓你對知識的理解更加深刻。（編輯亂入：精彩的留言有機會獲得豐厚福利哦＠翘帧）
