2016年史稱直播元年，一年當(dāng)中數(shù)以百計(jì)的直播應(yīng)用如雨后春筍般出現(xiàn)在市場上，AppStore、Android市場上充斥著秀場直播、事件直播、移動直播、直播交友等形形色色的應(yīng)用，占據(jù)著越來越多用戶的閑暇時光。

在萬眾創(chuàng)業(yè)的大背景下，創(chuàng)業(yè)者們紛紛撲向這個號稱數(shù)百億的新興市場，在這場運(yùn)動中，風(fēng)投、基金也攜著大把的鈔票為大家提供著燒錢的原料。一時間，程序猿、運(yùn)營貓和產(chǎn)品狗們摩拳擦掌，CXO和金融巨子們也揮斥方遒。

隨著直播、短視頻的火爆，內(nèi)容創(chuàng)業(yè)的激情被點(diǎn)燃，主播經(jīng)濟(jì)也迅速崛起，我們希望發(fā)揮技術(shù)成本優(yōu)勢，扶持有內(nèi)容、有資質(zhì)、有想法但無技術(shù)的創(chuàng)業(yè)者，和我們共同營造視頻互娛的長尾生態(tài)。經(jīng)過綜合考慮，啟動了直播SaaS項(xiàng)目。

這一年多我們經(jīng)歷了如下有意思的事情：

從無到有組織團(tuán)隊(duì)，

從無到有構(gòu)建應(yīng)用，

從無到有設(shè)計(jì)流程，

從脆弱到高并發(fā)、高可用的洗禮，

運(yùn)營平臺的構(gòu)建，

攻擊和安全，

微服務(wù)、DevOps的探索，

政策風(fēng)暴的打擊黑暗的摸索。

團(tuán)隊(duì)組織

從五月開始項(xiàng)目時，我們環(huán)顧四周，可用之人惟五六耳，要快速完成兩月上線可用直播SaaS軟件之目標(biāo)可謂通天之難。

外援（內(nèi)部拆借和人員外包）我們想到的第一步，這當(dāng)中涉及到公司HR制度、外包單位降標(biāo)供人等困難。從頭到尾用了10多位外包同學(xué)，除了兩位客戶端和前端同學(xué)順利轉(zhuǎn)正外，被淘汰、被回收占了絕大多數(shù)。

當(dāng)然，招聘是同時進(jìn)行的工作，拜給力HR所賜，我們需要的幾個人員在一月之內(nèi)迅速到崗，同時努力勸說其他部門想離職的同學(xué)加入我們，迅速補(bǔ)強(qiáng)了研發(fā)隊(duì)伍。

前端缺乏Leader，只能讓外包同學(xué)擔(dān)綱，甚至讓優(yōu)秀外包同學(xué)去面試同學(xué)（嘆氣），最終，跌跌撞撞堅(jiān)持至第一版本發(fā)布，才迎來了前端的Leader。從這件事情上我們看出，一個團(tuán)隊(duì)的初期架子尤其重要，當(dāng)缺乏某個角色的Leader時，就應(yīng)該最高優(yōu)先級去招攬過來。當(dāng)然這個是一個隨緣分的事情，比如，一個角色的Leader不盡人意，希望替換掉時，招聘時日漫長，拖了近三月入職，見到效果已經(jīng)是四月之后。

經(jīng)過一年多的摸爬滾打，我們團(tuán)隊(duì)規(guī)模穩(wěn)步向前，團(tuán)隊(duì)技術(shù)氛圍逐步加強(qiáng)，給大家營造成了相對輕松、融洽、利于成長的大環(huán)境。

總結(jié)起來：借調(diào)人員早期可用，但應(yīng)早日收編或替換；外包人員早期慎用；堅(jiān)持讓優(yōu)秀的人去面試，一流的人招一流的人，二流的人只能招到三流的人；人力問題要早發(fā)現(xiàn)早解決，持續(xù)招聘，保證糧草充足。

應(yīng)用構(gòu)建（2016）

如何構(gòu)建一個App后端，與我而言絕對算是一個挑戰(zhàn)。我之前的經(jīng)歷大多是一些平臺的搭建和多媒體相關(guān)技術(shù)探索，諸如云轉(zhuǎn)碼系統(tǒng)、RTMP推流SDK、Push廣告之類，他們都是純后臺應(yīng)用。在做天天項(xiàng)目之前，我對Web的理解可以說停留在RestAPI階段。

長短連接

我們首先在長短連接之間進(jìn)行了一些抉擇，當(dāng)時的想法是對某些場景如用戶心跳使用長連接，鑒于連接層的建設(shè)需要投入額外的精力，我們選擇了短連接上行加IM（云廠商提供）下行的思路，這樣，既能保證CS端消息請求及時觸達(dá)，保證用戶體驗(yàn)。

JSON還是PB

在服務(wù)協(xié)議抉擇上，JSON是客戶端喜歡的類型，而后端同學(xué)希望使用PB，考慮到前端WEB環(huán)境使用PB的困難，我們使用了前端JSON接入，后端PBRPC的架構(gòu)。

PB RPC

因?yàn)橹绑w會過PB封裝的RPC帶來的好處，首先PB的編寫可以取代接口文檔的編寫，工程師不必干重復(fù)的事情；其次，PB的轉(zhuǎn)換過程中的檢查可以節(jié)省一些參數(shù)檢查的邏輯；其他諸如節(jié)省帶寬之類的，現(xiàn)在看來倒沒有那么重要。

因此，后端堅(jiān)定不移的選擇了PB，后續(xù)我們基于Beego實(shí)現(xiàn)了一套簡單的RPC框架，利用template實(shí)現(xiàn)了client、controller、router等代碼生成；形成了RPC接口編寫規(guī)范，這套規(guī)范與grpc的規(guī)范比較接近，是grpc規(guī)范的子集。

而后，我們基于正則分析將PB文件轉(zhuǎn)成了客戶端工程師更愿意閱讀的markdown文檔，利用toc將markdown文檔轉(zhuǎn)換成帶邊欄目錄的html文檔，系統(tǒng)的文檔按模塊、接口、Message的層次進(jìn)行目錄組織，通過錨點(diǎn)超鏈實(shí)現(xiàn)快速跳轉(zhuǎn)，再結(jié)合瀏覽器的文本搜索功能，工程師利用文檔的效率大幅提升。

業(yè)務(wù)劃分

框架不成熟，業(yè)務(wù)緊張使我們面臨的大敵，所以前期我們選擇了全家桶開發(fā)模式，當(dāng)時的考慮是：

如果分服務(wù)，不成熟的框架修改會造成諸多服務(wù)的連帶修改；

當(dāng)時的設(shè)想是service層除了個別基礎(chǔ)service復(fù)用，對其他模塊的調(diào)用一律使用client來耦合；

通過全家桶+模塊相互調(diào)用限制的策略，實(shí)現(xiàn)了起步和將來轉(zhuǎn)到分服務(wù)的可能性。更近一步，我們的全家桶可以通過Client配置，實(shí)現(xiàn)按模塊部署。

回頭來看，全家桶模式有利有弊，但是適合起步階段。優(yōu)勢：

1） 不必花太多時間在業(yè)務(wù)劃分上，實(shí)現(xiàn)了業(yè)務(wù)快速起步；

2） 避免了過早的業(yè)務(wù)拆分導(dǎo)致的返工；半年后，隨著對業(yè)務(wù)的深入理解，我們拆分了Passport、消息中心、主播、用戶、房間、增值系統(tǒng)（訂單、支付、游戲、禮物、紅包、VIP等）、數(shù)值系統(tǒng)（計(jì)數(shù)器、數(shù)值、榜單）等諸多邊界清晰的服務(wù)。

缺點(diǎn):

1） 模塊相互調(diào)用限制規(guī)則在具體執(zhí)行過程中，由于新入職工程師的疏忽以及某些工程師的不理解而被打破；這里面暴露了流程和團(tuán)隊(duì)溝通方面的諸多問題，這里暫且不表。

2） 隨著限制規(guī)則全家桶底層代碼修改后，需要對所有的獨(dú)立部署模塊進(jìn)行升級，否則可能導(dǎo)致依賴的service發(fā)生變化，但上層模塊并未更新的線上問題。

3）全家桶代碼量越來越大，編譯越來越慢，IDE的響應(yīng)也越來越慢。

4）隨著后續(xù)業(yè)務(wù)的開展，基礎(chǔ)服務(wù)（如Passport模塊），需要支撐其他業(yè)務(wù)線，對穩(wěn)定性的要求更高；而Passport的每次上線，因?yàn)槭侨彝袄锩娴囊粋€模塊，裹挾著其他業(yè)務(wù)模塊的修改一起上線，帶來了更多的風(fēng)險。

IM消息和客戶端版本

IM消息由服務(wù)端通過RestAPI的方式進(jìn)行，但是隨著客戶端版本的更新，新老版本需要的消息類型不一樣，造成了一些實(shí)際困難：

1） 客戶端接收到不識別的消息類型，信令消息和房間消息丟棄，顯示消息提示不支持；

2）消息只能增加字段，不能減少字段；

3）產(chǎn)品需求發(fā)生變化，發(fā)送消息需要區(qū)別新老版本，因?yàn)槲覀儾荒茏龅桨纯蛻舳酥鹨话l(fā)送房間消息和廣播消息，因此我們設(shè)計(jì)了消息冗余發(fā)送的技術(shù)：高版本客戶端忽略原消息，低版本丟棄不識別的新消息。

流程

敏捷開發(fā)團(tuán)隊(duì)遵循敏捷流程，但敏捷也不是沒有成本的，有的團(tuán)隊(duì)設(shè)置了敏捷教練，但如果敏捷教練和TeamLeader各自為政，會造成效率降低，不能迅速為團(tuán)隊(duì)找到最佳實(shí)踐。相反雙方應(yīng)該深入合作，敏捷教練最好向TeamLeader / CTO匯報，合理設(shè)計(jì)好敏捷流程。

經(jīng)過摸索，我們整理了一套流程，并對其中一些流程制定了規(guī)范：研發(fā)接口文檔規(guī)范、研發(fā)Git使用規(guī)范、提測上線郵件規(guī)范、事故CaseStudy規(guī)范，以下是流程一些要點(diǎn)：

需求分析和設(shè)計(jì)：按要求出設(shè)計(jì)并評審，復(fù)雜Story設(shè)置Owner

開發(fā)和測試：代碼提交需要Review、開發(fā)需要維護(hù)接口自動化測試Case、提測需要發(fā)提測郵件、測試階段，應(yīng)提醒PM驗(yàn)收、維護(hù)兩套測試環(huán)境

上線和運(yùn)維：重要的上線需要發(fā)上線預(yù)告郵件，上線需要發(fā)上線通報，上線使用預(yù)覽環(huán)境，必要情況選需要發(fā)數(shù)據(jù)分析和上線收益郵件，周末節(jié)假日值班，事故發(fā)生后需要CaseStudy并發(fā)送事故報告

就像注釋是代碼的補(bǔ)丁一樣，流程是對自動化框架的補(bǔ)丁，流程最好能自動化實(shí)現(xiàn)，否則會造成很大的心智負(fù)擔(dān)，逐步退化。舉個例子：提測郵件以前均是由RD自行發(fā)出，為了方便Leader和QA同學(xué)查閱，我們對內(nèi)容和標(biāo)題做了規(guī)定，但是實(shí)踐過程中貫徹難度較大，對于簡單規(guī)則的遵守，人往往不如機(jī)器。后來QA團(tuán)隊(duì)開發(fā)了teamcat測試平臺，對提測流程實(shí)現(xiàn)了自動化，研發(fā)同學(xué)只需要與WebUI交互，將更多精力放到填寫提測內(nèi)容和測試要點(diǎn)上面。測試同學(xué)和領(lǐng)導(dǎo)也可以一目了然的看到當(dāng)前的當(dāng)前的項(xiàng)目狀態(tài)。

代碼review的貫徹難度最大，我們經(jīng)歷了好幾個階段：

1）最先是由Leader自行Review，但是Leader個人精力有限，往往不能做到全覆蓋；

2）由值周同學(xué)負(fù)責(zé)，這個也很難推廣，同學(xué)水平參差不齊，骨干同學(xué)太忙，無法長期堅(jiān)持；

3）自動化的工具如SonarQube、GoLint等工具可以幫助Leader快速掌握某位同學(xué)提交代碼的質(zhì)量大致情況。

測試

敏捷開發(fā)中強(qiáng)調(diào)測試，甚至提倡TDD來促進(jìn)開發(fā)，我們經(jīng)過了長期的摸索，經(jīng)過了以下幾個階段：

快速擼碼，野蠻生長

在這個階段，老板意志表現(xiàn)比較強(qiáng)烈，要求兩個月發(fā)布第一版可用產(chǎn)品，因此我們在設(shè)計(jì)上和代碼上的要求無暇顧及太多，但是我們從頭開始建立了自動化Case，和人工手動測試兩個驗(yàn)證手段。后續(xù)我們發(fā)現(xiàn)在線下單獨(dú)的單測環(huán)境中跑這些Case不能幫忙避免其他環(huán)境中出現(xiàn)的客戶配置問題，我們便在開發(fā)環(huán)境中運(yùn)行自動化Case，收到的效果是第一時間發(fā)現(xiàn)問題。

問題不斷，迭代緩慢

測試過程中發(fā)現(xiàn)的BUG數(shù)量巨大，且不易收斂，每次發(fā)版曠日持久，系統(tǒng)脆弱，經(jīng)常牽骨連筋，顧此失彼。我們開始強(qiáng)調(diào)研發(fā)自己維護(hù)Case，但收效其實(shí)不大，因?yàn)楹芏嗤瑢W(xué)往往只是冒煙即可，不考慮邊界，不考慮復(fù)用。往往出現(xiàn)大片的Case不過，測試Case腐敗退化，因?yàn)榕牌诰o任務(wù)重而更加腐敗退化。

加強(qiáng)單測

后來隨著開始微服務(wù)建設(shè)，我們重新考慮了測試的分工，研發(fā)同學(xué)注重自己單元的質(zhì)量驗(yàn)收，通過單元測試來驗(yàn)證自己的代碼的正確性，驗(yàn)證設(shè)計(jì)的可測、可擴(kuò)展等合理性。要求新的微服務(wù)和新的業(yè)務(wù)模塊都必須單測，前期代碼覆蓋率保證在60%以上，每次提交前要求單測全部通過。在經(jīng)過一段時間實(shí)踐后，我們又開始強(qiáng)調(diào)單測的整潔性和可讀性，經(jīng)過一系列努力，測試驅(qū)動和講求設(shè)計(jì)的技術(shù)氛圍也逐漸加強(qiáng)。業(yè)務(wù)架構(gòu)上，會圍繞著業(yè)務(wù)拆分與服務(wù)重用進(jìn)行討論，代碼實(shí)現(xiàn)上，會圍繞著設(shè)計(jì)模式和代碼整潔而努力。

VSCode在Go開發(fā)方面的優(yōu)勢明顯：圖形化的Debug過程，按工程區(qū)分的環(huán)境變量，一鍵生成測試代碼，測試覆蓋評估等。選用它讓我們在效率方面受益匪淺。

自動化Case

QA同學(xué)也開始了專人負(fù)責(zé)的自動化Case維護(hù)，這次，他們找到了竅門：

1）通過準(zhǔn)備數(shù)據(jù)集等方式，保證測試的可重復(fù)運(yùn)行；

2）針對不同使用方對微服務(wù)的一些限制，他們增加了不同的Case；

3）發(fā)生報警后，測試同學(xué)先定位問題，迅速找到相關(guān)研發(fā)同學(xué)進(jìn)行解決。

雖然我們還沒有做到傳說中的代碼提交后直接過測試并上線的全自動化模式，但是我們通過小米加步槍的方式，自己參照經(jīng)典，結(jié)合摸索找到一條適合自己的測試自動化之路。

環(huán)境和部署

開發(fā)環(huán)境

開發(fā)階段，我們將環(huán)境分了local和dev兩個環(huán)境，

dev環(huán)境原則是上給客戶端和前端同學(xué)開發(fā)使用的，后端同學(xué)不能隨意修改開發(fā)環(huán)境，只能自測通過后才能Push代碼，再由Jenkins任務(wù)自動更新到dev環(huán)境。

local環(huán)境用于本地開發(fā)，因?yàn)間o開發(fā)本身跨平臺，在Mac、Windows和Linux上均可運(yùn)行，因此我們鼓勵工程師在本地開發(fā)。local環(huán)境與dev環(huán)境使用相同的數(shù)據(jù)層，如果服務(wù)A需要依賴服務(wù)B，則A的local環(huán)境依賴B的dev環(huán)境即可。

測試環(huán)境

直播SaaS環(huán)境比一般AppServer的環(huán)境多一些，測試的內(nèi)容也多一些，我們的線下測試環(huán)境分了以下幾種：

test，用于新版本測試；

app_release: 用于新應(yīng)用測試；

sandbox: 用于研發(fā)復(fù)現(xiàn)和驗(yàn)證特定版本的問題；

我們的進(jìn)程分為以下三類：1）RPC Server，2）Msg Queue Consumer，3）Timer。這幾個環(huán)境使用相同的數(shù)據(jù)層，通過不同環(huán)境使用不同隊(duì)列實(shí)現(xiàn)MQConsumer的獨(dú)立，最后幾大環(huán)境只是共享了Timer，因此我們把Timer做得很薄，Timer只包含Timer的驅(qū)動，具體的業(yè)務(wù)通過調(diào)用RPC接口實(shí)現(xiàn)。通過區(qū)分幾大環(huán)境，做到專有環(huán)境專有用途，多件事情并行進(jìn)行。

預(yù)覽環(huán)境

預(yù)覽環(huán)境和線上環(huán)境使用相同的數(shù)據(jù)層，他的隊(duì)列也和線上分開，除了Timer外，其他邏輯均能在線上環(huán)境做到小規(guī)模的測試。

生產(chǎn)環(huán)境

SaaS的灰度比較特殊，他有一個實(shí)驗(yàn)性質(zhì)的App，線上它的新版本，我們不必部署獨(dú)立的灰度環(huán)境，也能完成灰度。

高并發(fā)

高并發(fā)的核心永遠(yuǎn)是水平擴(kuò)展以及緩存，水平擴(kuò)展的核心是系統(tǒng)節(jié)點(diǎn)無狀態(tài)，不存在單點(diǎn)瓶頸。這點(diǎn)而言，Web服務(wù)的可擴(kuò)展能力還是不錯的，數(shù)據(jù)層Mysql存在此類問題，但是隨著微服務(wù)的拆分，我們可以將數(shù)據(jù)遷移到不同的數(shù)據(jù)庫實(shí)例上實(shí)現(xiàn)業(yè)務(wù)拆分，而針對同一張表出現(xiàn)的性能問題，還能使用水平分庫分表的策略進(jìn)行優(yōu)化，當(dāng)然，隨著TIBD等分布式RDS出現(xiàn)，也為此類問題提供了更簡單的方案。

緩存問題是出現(xiàn)了以后能迅速加上，并且要注意加緩存正確姿勢；以及具體場景的適用性，比如：用戶針對自己的查詢請求，為了保證數(shù)據(jù)一致性，可以不過緩存。

長連接：加強(qiáng)對系統(tǒng)資源的復(fù)用

水平擴(kuò)展：必要時可以加機(jī)器解決的問題都不是問題

讀寫分離：讀寫分離，降低主庫的壓力

緩存：保護(hù)數(shù)據(jù)庫

異步調(diào)用：削峰填谷

網(wǎng)關(guān)限流：保護(hù)后續(xù)服務(wù)

高可用

運(yùn)維層面

預(yù)覽環(huán)境做線上驗(yàn)證，大小上線都經(jīng)過預(yù)覽驗(yàn)證

基礎(chǔ)框架完成事件收集，方便監(jiān)控報警

利用業(yè)務(wù)日志分析完成業(yè)務(wù)層面的報警

多環(huán)境一視同仁，堅(jiān)持相同標(biāo)準(zhǔn)建設(shè)監(jiān)控系統(tǒng)?

設(shè)計(jì)層面

優(yōu)先考慮無狀態(tài)服務(wù)（基于負(fù)載均衡） ，其次考慮主從備份，再次考慮單機(jī)冷備

重視：限流、隔離、熔斷?

重視：緩沖解耦（通過業(yè)務(wù)異步實(shí)現(xiàn)削峰填谷）?

重視：供應(yīng)商的多備份和監(jiān)控?

重視：數(shù)據(jù)層方案的梳理和監(jiān)控?

接口分級和校本化的降級方案（譬如第三方Token的緩存）?

重視安全、攻擊和接入層保護(hù)

代碼流程層面

重視單測和自動化Case建設(shè)?

SonarQube自動化檢查?

CaseStudy，同一錯誤不犯兩變

運(yùn)營和統(tǒng)計(jì)

服務(wù)的運(yùn)營平臺是個B端應(yīng)用，我們最先在做模塊設(shè)計(jì)時雜糅了業(yè)務(wù)和服務(wù)，我們的模塊是有C端業(yè)務(wù)、B端業(yè)務(wù)、服務(wù)等。運(yùn)營平臺最先開始是一個MVC的典型前后端一體的后臺Web服務(wù)，隨著業(yè)務(wù)發(fā)展，設(shè)計(jì)和PM對產(chǎn)品不滿意，前端介入了進(jìn)來，所有的請求均通過運(yùn)營平臺做了一層翻譯，我對此深感不滿，因?yàn)槿魏我淮胃膭佣夹枰?jīng)過前端、OP、業(yè)務(wù)模塊至少三個開發(fā)同學(xué)的參與。交互流程長，消息出偏差后極易導(dǎo)致效率下降，因此我們啟動了運(yùn)營平臺架構(gòu)的改造。首先，前后端分離不可避免，業(yè)務(wù)模塊也不可能一成不變，因此唯一能固定住不變的只有運(yùn)營平臺，我們通過實(shí)現(xiàn)自動化鑒權(quán)并透傳請求的方法實(shí)現(xiàn)了自動化的OPGateway，針對90%需求，它實(shí)現(xiàn)了前端和后端模塊同學(xué)直接對接。而剩余10%（跨模塊的查詢聚合、修改聚合），運(yùn)營平臺單獨(dú)開發(fā)自己的接口即可。

統(tǒng)計(jì)的實(shí)現(xiàn)我們采用了Spring Framework、MyBatis的Web程序，它將按天的業(yè)務(wù)統(tǒng)計(jì)計(jì)算出來，存儲到結(jié)果數(shù)據(jù)庫中，結(jié)果數(shù)據(jù)庫可供運(yùn)營平臺查詢。

驅(qū)動方式

Web接口，實(shí)現(xiàn)數(shù)據(jù)重新計(jì)算、結(jié)果查詢等功能。

定時任務(wù)，按配置自動運(yùn)行，

查詢數(shù)據(jù)源

Mysql：數(shù)據(jù)的最大來源

Hive：后續(xù)我們考慮將ES和Mongo都導(dǎo)入到Hive體系中，方便跨庫查詢。

ES、Mongo、S3

結(jié)果數(shù)據(jù)庫

Mysql

Mongo：文檔型數(shù)據(jù)庫，結(jié)果字段可自由擴(kuò)展

數(shù)據(jù)倉庫

隨著微服務(wù)的建設(shè)，與傳統(tǒng)的分層架構(gòu)不同，數(shù)據(jù)庫屬于微服務(wù)的組成部分。

1）數(shù)據(jù)庫被隔離的情況會越來越多，數(shù)據(jù)按服務(wù)的不同，分布在不同的數(shù)據(jù)庫或不同的Mysql實(shí)例中。

2）數(shù)據(jù)庫的選型更加靈活，很多Nosql數(shù)據(jù)庫（如Mongo、Redis、ES等）會成為微服務(wù)數(shù)據(jù)層的首選。

由于以上的變化，數(shù)據(jù)統(tǒng)計(jì)變得更加困難。因此有必要創(chuàng)建數(shù)據(jù)倉庫，將后端的業(yè)務(wù)數(shù)據(jù)歸集到數(shù)據(jù)倉庫中，方便數(shù)據(jù)分析。

我們實(shí)踐了Sqoop+Hive的數(shù)據(jù)倉庫建設(shè)的方法，通過Sqoop將RDS數(shù)據(jù)同步到Hive中，通過通過Mongo、ES的插件將數(shù)據(jù)也導(dǎo)入到Hive中。通過Hive查詢實(shí)現(xiàn)業(yè)務(wù)的統(tǒng)計(jì)

報表系統(tǒng)

簡單起見，我們選用了ReDash作為數(shù)據(jù)報表系統(tǒng)，同時我們開發(fā)了腳本，將結(jié)果定期發(fā)送給相關(guān)同學(xué)。做到數(shù)據(jù)及時可觸達(dá)。

微服務(wù)（2017）

微服務(wù)是最近幾年很火的一個詞匯，我們從16年就希望進(jìn)行微服務(wù)改造，但是限于人力與能力，遲遲沒有動手，直至17年我們才開始積極探索。

業(yè)務(wù)的拆分是微服務(wù)比較關(guān)鍵的部分，但是微服務(wù)難點(diǎn)在于底層，框架和實(shí)現(xiàn)和自動化運(yùn)維的投入和摸索。

重視Beego，我們發(fā)現(xiàn)他在微服務(wù)需要的負(fù)載均衡、Tracing、RPC規(guī)約、熔斷等技術(shù)范疇的考慮太少，相反，grpc為大家提供了不錯的選項(xiàng)，他基于中間件的AOP思路也可以方便的擴(kuò)展框架能力。

因此，我們的架構(gòu)師基于GRPC，結(jié)合我們的最佳實(shí)踐，實(shí)現(xiàn)了一套名為Doraemon的微服務(wù)框架以及名為dolly的腳手架工具。殊途同歸，與Beego、Bee不謀而合。

Doraemon提供一整套微服務(wù)開發(fā)，部署，監(jiān)控的解決方案，具有如下特點(diǎn)：

1）基于GRPC框架對外輸出RPC和RESTful接口；

2）支持多應(yīng)用開發(fā)，最大程度保證服務(wù)自治;

3）提供攔截器，可以完成面向切面(AOP)編程；

4）集成基于Consul的服務(wù)治理，并提供可視化服務(wù)監(jiān)控，鏈路跟蹤；

5）集成Promethues，采集基礎(chǔ)數(shù)據(jù)，打點(diǎn)監(jiān)控業(yè)務(wù)情況；

框架解決了開發(fā)和部分運(yùn)維的問題，但是自動化的運(yùn)維仍需要投入，我們的DevOPS同學(xué)完成了如下壯舉：

1）基于ELK的實(shí)時日志收集和展示體系

2）基于ES的業(yè)務(wù)報警服務(wù)，采用了Watcher和Alert雙引擎

3）基于Promethues、Graphana基礎(chǔ)報警體系

4）基于KMR的數(shù)據(jù)倉庫體系

5）自研Atlas服務(wù)樹服務(wù)

6）基于Jenkins+ansible的自動化部署體系

這些投入，從底層上為服務(wù)提供了強(qiáng)有力可自動擴(kuò)展的運(yùn)維保證，將我們之前預(yù)留的空白填寫完成。

基于直播場景，我們抽離了如下服務(wù)的系統(tǒng)：

1）基礎(chǔ)服務(wù)體系（Passport、關(guān)系服務(wù)、消息中心、配置服務(wù)、Video服務(wù)...）

2）業(yè)務(wù)服務(wù)（個人秀、房間、主播...）

3）增值系統(tǒng)（訂單中心、第三方支付中心、游戲、禮物、紅包、VIP、分賬...）

4）數(shù)值系統(tǒng)（計(jì)數(shù)器、數(shù)值、榜單）等諸多邊界清晰的服務(wù)、

原來的全家桶服務(wù)逐步演變?yōu)槲⒎?wù)的Gateway角色，他實(shí)現(xiàn)了服務(wù)的耦合，應(yīng)對業(yè)務(wù)的細(xì)微變化。

服務(wù)分層沉淀除了更多的穩(wěn)定的服務(wù)，他們專人負(fù)責(zé)，靈活升級，重復(fù)利用，為后續(xù)的業(yè)務(wù)發(fā)展奠定了不錯的基礎(chǔ)。

安全、攻擊和黑產(chǎn)

網(wǎng)絡(luò)攻擊是中小平臺繞不開的東西，他就像躲在暗處的忍者，在你最不情愿的時候，給你最傷的打擊。

我們的客戶前后經(jīng)歷過三四次打擊，前面我們的服務(wù)一打就掛，陸續(xù)試過了運(yùn)營商流量清洗、高防IP、始終沒有擺脫他們的糾纏，每天付出數(shù)萬的費(fèi)用，頗有些破敵一百，自損三千的悲壯，偶然機(jī)會，我們想到了某商高防，接入之后，攻擊立馬停止。

攻擊方的肉雞在16年實(shí)現(xiàn)了成本大降，隨之而來的是隨意的興風(fēng)作浪，記得阿里在之前的世界紀(jì)錄是400GBPS，而今年攻擊我們的流量動輒超過600GBPS。據(jù)說某司建立了儲備帶寬數(shù)T的扛打機(jī)房，財大氣粗，溢于言表。

打不過自然要考慮躲，我們后續(xù)設(shè)計(jì)了多域名和直播盾方案，利用了狡兔三窟以及分級降級的思想。

安全意識在云服務(wù)廠商內(nèi)部還是很高的，定期安全掃描，接口全HTTPS，密碼存儲加鹽加密，金融數(shù)據(jù)庫特殊密級都是具體措施。這些問題平時不會是什么大問題，一旦出問題，技術(shù)負(fù)責(zé)人也差不多要收拾東西走人了。

網(wǎng)絡(luò)黑產(chǎn)在我們平臺上更加猖獗，尤以賣小片，拉主播為主。

我們后來接入了一些第三方的臟字和作弊服務(wù)，但也只解決了部分問題，舉幾個例子說明有多黑產(chǎn)人員多么有才。

有的用戶，將自己的昵稱改成廣告語，然后瘋狂加關(guān)注，我曾經(jīng)看過一個用戶他關(guān)注的人數(shù)達(dá)到了好幾萬。這里面只要轉(zhuǎn)化率達(dá)到百分之一，那么他的收入就會超過萬元。

總之，以上所講的東西都是做社區(qū)、做直播等產(chǎn)品必須要面臨的，而且要長期戰(zhàn)斗的領(lǐng)域。