摘要：包括服務(wù)的自動(dòng)化部署，以及鏈路監(jiān)控等并未細(xì)說(shuō)提及。結(jié)語(yǔ)誠(chéng)然，整個(gè)服務(wù)架構(gòu)可以輕松應(yīng)對(duì)千萬(wàn)級(jí)并發(fā)。期望，整個(gè)服務(wù)架構(gòu)能伴隨公司繼續(xù)成長(zhǎng)壯大。

ShareSDK，顧名思義，分享的SDK組件，公司基于互聯(lián)網(wǎng)，早期主要以ShareSDK起家。今日思來(lái)，很幸運(yùn)，能陪著ShareSDK一起成長(zhǎng)。

如圖
經(jīng)典的單體應(yīng)用架構(gòu), 和很多初創(chuàng)企業(yè)一樣，當(dāng)時(shí)采用這種架構(gòu)。用redis等緩存擋住并發(fā)，用MySQL來(lái)存儲(chǔ)數(shù)據(jù)。
前端的報(bào)表分析直接操作MySQL即可。
我并不反對(duì)單體架構(gòu)，反而我覺得很合適，由于初創(chuàng)企業(yè)業(yè)務(wù)形態(tài)并不穩(wěn)定，單體架構(gòu)其實(shí)很容易調(diào)整，殺雞焉用牛刀。

公司是國(guó)內(nèi)第一家做移動(dòng)端分享SDK的企業(yè)，隨著業(yè)務(wù)發(fā)展，由于幾乎每個(gè)APP都會(huì)有分享功能的需求，業(yè)務(wù)發(fā)展飛快。
我記得當(dāng)時(shí)一個(gè)“魔漫相機(jī)”App就占據(jù)了我們半壁帶寬。

在業(yè)務(wù)請(qǐng)求的入口并未根據(jù)業(yè)務(wù)做輕重之分，導(dǎo)致數(shù)據(jù)交互類的接口以及日志數(shù)據(jù)上報(bào)的接口共享網(wǎng)關(guān)。

業(yè)務(wù)高峰，請(qǐng)求擁堵，核心數(shù)據(jù)交互的接口失敗導(dǎo)致用戶體驗(yàn)極差

服務(wù)降級(jí)無(wú)法實(shí)施，相對(duì)而言，日志上報(bào)接口并不屬于核心業(yè)務(wù)流程

無(wú)法做線路區(qū)分，只能統(tǒng)一使用BGP，帶寬等成本高

早期數(shù)據(jù)直接落地MySQL，通過(guò)MySQL做統(tǒng)計(jì)分析。

數(shù)據(jù)插入并發(fā)數(shù)受限，性能堪憂

存儲(chǔ)集群未拆分，不能根據(jù)業(yè)務(wù)特點(diǎn)分而治之

查詢慢

由于整個(gè)架構(gòu)比較簡(jiǎn)單，對(duì)于復(fù)雜的業(yè)務(wù)以及大數(shù)據(jù)分析支持基本上談不上

基于單體應(yīng)用，我們基本上看不到未來(lái)，這除了單體應(yīng)用本身的局限性之外，在架構(gòu)上本身也跑不動(dòng)。這樣就造就了成本以及資源的重度浪費(fèi)。

通過(guò)業(yè)務(wù)域名拆分以及智能DNS，實(shí)現(xiàn)不同地域國(guó)家省市&不同業(yè)務(wù)落入不同網(wǎng)關(guān)(不同機(jī)房)，不同帶寬線路

業(yè)務(wù)拆分、微服務(wù)化，不同業(yè)務(wù)區(qū)別對(duì)待，資源上也是分而治之

服務(wù)拆分： 公共服務(wù) & 具體業(yè)務(wù)服務(wù)

梳理后的整個(gè)服務(wù)架構(gòu)，從請(qǐng)求端到網(wǎng)關(guān)API再到具體的業(yè)務(wù)處理，流量上可以隨意切割以及合并，很方便的做擴(kuò)容以及縮容操作。

數(shù)據(jù)分為基礎(chǔ)數(shù)據(jù)以及統(tǒng)計(jì)分析數(shù)據(jù)。
將核心關(guān)鍵的基礎(chǔ)數(shù)據(jù)，比如配置信息等提取出來(lái)，分庫(kù)存儲(chǔ)，將所有的統(tǒng)計(jì)分析數(shù)據(jù)以及可異步存儲(chǔ)數(shù)據(jù)落地本地磁盤，再由flume實(shí)時(shí)拉走。這樣帶來(lái)的好處有很多：

基礎(chǔ)數(shù)據(jù)可以選用高性能存儲(chǔ)，極大加速部分核心業(yè)務(wù)響應(yīng)

采用模hash、一致性hash、日期等算法分隔不同的數(shù)據(jù)，分實(shí)例存儲(chǔ)，方便擴(kuò)容

引入搜索引擎，專職前端&客戶端的查詢請(qǐng)求

引入Flume、Kafka，采用落地日志 + Flume + Kafka實(shí)現(xiàn)數(shù)據(jù)流分發(fā)，即使Flume掛了，由于日志先落地，所以待Flume修復(fù)后，仍然可以保證數(shù)據(jù)無(wú)丟失無(wú)斷層繼續(xù)傳輸，而在Flume上面，我們采用了Kafka Channel，而不是普通的FileChannel、MemoryChannel等，使之即使在流量高峰，也不至于導(dǎo)致FlumeServer掛起

不同數(shù)據(jù)分析需求（如APM、業(yè)務(wù)統(tǒng)計(jì)等等）接入FlumeServer 或者 Kafka 按需獲取數(shù)據(jù)處理

上述簡(jiǎn)單講到了服務(wù)架構(gòu)以及數(shù)據(jù)架構(gòu)的演化，但是細(xì)致各個(gè)環(huán)節(jié)可以有很多道道。包括服務(wù)的自動(dòng)化部署，DI/DC以及鏈路監(jiān)控等并未細(xì)說(shuō)提及。
對(duì)于個(gè)人，最深刻的理解有兩點(diǎn)：

分而治之

充分理解各個(gè)軟件工具本身適合的領(lǐng)域，讓專業(yè)的軟件工具對(duì)付它們擅長(zhǎng)的業(yè)務(wù)，而不是一招拍死

充分理解業(yè)務(wù)

架構(gòu)基于業(yè)務(wù)，好不好的架構(gòu)要看什么樣的業(yè)務(wù)，如果換成公司的IMSDK，顯然這個(gè)架構(gòu)完全不合適。

追求架構(gòu)簡(jiǎn)單

數(shù)據(jù)每一次流動(dòng)，都可能伴隨一定的異常。那么架構(gòu)簡(jiǎn)單如何體現(xiàn)？
能用一兩層服務(wù)解決的事情絕對(duì)不使用三層服務(wù)，方便數(shù)據(jù)追蹤跟進(jìn)以及業(yè)務(wù)排錯(cuò)。
其次，服務(wù)業(yè)務(wù)盡可能簡(jiǎn)單，ShareSDK的配置服務(wù)以及社交信息服務(wù)等都是各自獨(dú)立，這在團(tuán)隊(duì)分工優(yōu)化上也顯得簡(jiǎn)單。

誠(chéng)然，整個(gè)服務(wù)架構(gòu)可以輕松應(yīng)對(duì)千萬(wàn)級(jí)并發(fā)。但是，我認(rèn)為可以優(yōu)化的空間還有很多。期望，整個(gè)ShareSDK服務(wù)架構(gòu)能伴隨公司繼續(xù)成長(zhǎng)壯大。