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

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

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

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

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

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

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

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

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

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

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

查詢慢

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

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

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

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

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

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

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

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

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

引入搜索引擎，專職前端&客戶端的查詢請求

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

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

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

分而治之

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

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

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

追求架構(gòu)簡單

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

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