騰訊QQ團(tuán)隊(duì)將于12月4日開(kāi)源一個(gè)服務(wù)開(kāi)發(fā)運(yùn)營(yíng)框架，叫做毫秒服務(wù)引擎（Mass Service Engine in Cluster，MSEC），它集RPC、名字發(fā)現(xiàn)服務(wù)、負(fù)載均衡、業(yè)務(wù)監(jiān)控、灰度發(fā)布、容量管理、日志管理、Key-Value存儲(chǔ)于一體，目的是提高開(kāi)發(fā)與運(yùn)營(yíng)的效率和質(zhì)量。

毫秒服務(wù)引擎的創(chuàng)作沖動(dòng)和構(gòu)建經(jīng)驗(yàn)，來(lái)自QQ后臺(tái)團(tuán)隊(duì)超過(guò)10年的運(yùn)營(yíng)思考。它是一整套解決方案，但也可以拆分來(lái)使用其中的監(jiān)控、Key-Value存儲(chǔ)單品。

典型用戶(hù)群體

毫秒服務(wù)引擎非常容易搭建和上手，使用它，初學(xué)者從零開(kāi)始開(kāi)發(fā)一個(gè)分布式后臺(tái)demo并運(yùn)行起來(lái)，只需要2個(gè)小時(shí)。基本上是一個(gè)小時(shí)完成框架搭建，一個(gè)小時(shí)完成開(kāi)發(fā)上線(xiàn)，特別適合互聯(lián)網(wǎng)初創(chuàng)公司。

功能與優(yōu)勢(shì)

模塊間訪問(wèn)采用RPC的方式，開(kāi)發(fā)者不用關(guān)注網(wǎng)絡(luò)與報(bào)文格式，像寫(xiě)單機(jī)程序一樣開(kāi)發(fā)分布式服務(wù)。

負(fù)載自動(dòng)均衡與容錯(cuò)，對(duì)于單機(jī)故障、局部網(wǎng)絡(luò)波動(dòng)等狀況自動(dòng)應(yīng)對(duì)，服務(wù)高可用性。

支持C/C++、Java、PHP語(yǔ)言，馬上還會(huì)推出支持Python語(yǔ)言；如果選擇C/C++語(yǔ)言，支持協(xié)程，兼具開(kāi)發(fā)和運(yùn)行效率。

Web化的管理界面，在Web界面完成配置、發(fā)布、監(jiān)控、日志、Key-Value存儲(chǔ)集群管理等所有操作。

需要復(fù)雜部署的服務(wù)器都采用Docker鏡像的方式安裝，使得部署與上手非常容易。

相比使用其他開(kāi)源組件拼湊起來(lái)的解決方案，毫秒服務(wù)引擎更加的體系化，對(duì)團(tuán)隊(duì)的規(guī)范更加到位。

毫秒服務(wù)引擎設(shè)計(jì)背景

對(duì)于互聯(lián)網(wǎng)服務(wù)后臺(tái)團(tuán)隊(duì)，開(kāi)發(fā)框架的選擇是非常關(guān)鍵的問(wèn)題，10年的海量服務(wù)經(jīng)驗(yàn)和教訓(xùn)使得我們團(tuán)隊(duì)深刻認(rèn)識(shí)到：

要盡早規(guī)范團(tuán)隊(duì)的開(kāi)發(fā)服務(wù)框架，避免到了后期，各種開(kāi)發(fā)語(yǔ)言混雜、各類(lèi)存儲(chǔ)組件充斥、重復(fù)編碼、每個(gè)模塊形態(tài)不統(tǒng)一、文檔缺失、監(jiān)控癱瘓、人員離職造成大量信息丟失，最后積重難返、痛苦不堪；

沒(méi)有框架來(lái)規(guī)范，團(tuán)隊(duì)的隨意性就太大，合作效率就大打折扣，甚至于內(nèi)耗、反復(fù)的挖坑填坑，系統(tǒng)的成敗過(guò)于依靠人的意識(shí)和水平；

規(guī)范，不能靠文檔、不能靠勞動(dòng)紀(jì)律、不能靠苦口婆心、不能靠人員意識(shí)、不能靠運(yùn)動(dòng)式的整頓，要靠技術(shù)框架上切實(shí)的限制與貼心保護(hù)。

如果有機(jī)會(huì)從零開(kāi)始定義一個(gè)理想的開(kāi)發(fā)框架，我們覺(jué)得需要考慮下面9點(diǎn)。

同步編碼異步執(zhí)行。兼顧運(yùn)行效率和編碼效率，希望代碼寫(xiě)起來(lái)是同步和順序的，而執(zhí)行的時(shí)候是異步的。

IDL/RPC。支持IDL（接口描述語(yǔ)言）和RPC，減少網(wǎng)絡(luò)協(xié)議相關(guān)的重復(fù)工作，協(xié)議有比較好的擴(kuò)展性；遠(yuǎn)程調(diào)用友好且高效，做到覆蓋主要的開(kāi)發(fā)語(yǔ)言。

LB。對(duì)服務(wù)間的調(diào)用選路進(jìn)行統(tǒng)一的管理，對(duì)單機(jī)故障和網(wǎng)絡(luò)波動(dòng)等常見(jiàn)情況有自動(dòng)容錯(cuò)，我們簡(jiǎn)稱(chēng)load balance（LB）。

存儲(chǔ)服務(wù)化。這個(gè)其實(shí)和開(kāi)發(fā)框架關(guān)系不太緊密，這里提一下，強(qiáng)調(diào)存儲(chǔ)應(yīng)該有統(tǒng)一的組件且由專(zhuān)業(yè)的團(tuán)隊(duì)運(yùn)維，就像共有云一樣。

過(guò)載保護(hù)。框架必須有成熟自帶的過(guò)載保護(hù)機(jī)制，不需要業(yè)務(wù)開(kāi)發(fā)人員關(guān)注或者關(guān)注很少。

基礎(chǔ)的監(jiān)控和告警。RPC調(diào)用、機(jī)器的CPU/網(wǎng)絡(luò)活動(dòng)、任務(wù)并發(fā)度、時(shí)延、進(jìn)程監(jiān)控和秒起等基礎(chǔ)信息，要有上報(bào)、統(tǒng)計(jì)和告警，不需要業(yè)務(wù)開(kāi)發(fā)人員關(guān)注。

完整的業(yè)務(wù)流轉(zhuǎn)呈現(xiàn)。統(tǒng)一日志，在一個(gè)地方能夠清晰的呈現(xiàn)某次業(yè)務(wù)處理過(guò)程的流轉(zhuǎn)詳細(xì)情況：經(jīng)過(guò)了哪些模塊間調(diào)用，調(diào)用參數(shù)是怎樣的，每個(gè)模塊處理的重要分支和結(jié)果是怎樣的，最好圖形化呈現(xiàn)。支持染色和不同的日志詳細(xì)級(jí)別。

中央總控。整個(gè)系統(tǒng)的配置和文檔等重要信息，例如每個(gè)模塊有哪些機(jī)器，分布在哪些機(jī)房、容量冗余情況、模塊間調(diào)用關(guān)系、訪問(wèn)控制的配置動(dòng)態(tài)管理甚至電子流，都希望能統(tǒng)一在一個(gè)地方Web化的管理起來(lái)，并且與運(yùn)營(yíng)的系統(tǒng)是直接聯(lián)系直接生效的。

云調(diào)度。容量的自動(dòng)調(diào)度。例如要進(jìn)行某個(gè)運(yùn)營(yíng)活動(dòng)需要大量的擴(kuò)容，只需要把設(shè)備放進(jìn)去，就能自動(dòng)的擴(kuò)縮容。當(dāng)某個(gè)城市機(jī)房故障，能夠自動(dòng)調(diào)度容量到其他城市。

毫秒服務(wù)引擎架構(gòu)

整個(gè)系統(tǒng)由下面幾部分組成，如圖所示。

**Web Console：**整個(gè)系統(tǒng)的運(yùn)營(yíng)管理中心，包括：

• Tomcat提供Web管理界面，管理的數(shù)據(jù)保存在MySQL里。

• LB是名字發(fā)現(xiàn)服務(wù)和負(fù)載均衡，remote_shell是遠(yuǎn)程文件傳輸與遠(yuǎn)程命令執(zhí)行服務(wù)。

**Log服務(wù)器：**提供業(yè)務(wù)Log的存儲(chǔ)和查詢(xún)服務(wù)。Log存儲(chǔ)在MySQL表里。

**Monitor服務(wù)器：**提供業(yè)務(wù)上報(bào)信息的存儲(chǔ)和查詢(xún)服務(wù)。業(yè)務(wù)上報(bào)信息存儲(chǔ)在內(nèi)存里，推薦內(nèi)存8G~16G。定時(shí)dump到磁盤(pán)的方式防止數(shù)據(jù)掉電丟失。

**業(yè)務(wù)運(yùn)營(yíng)服務(wù)器：**部署開(kāi)發(fā)框架和業(yè)務(wù)邏輯代碼，處理業(yè)務(wù)請(qǐng)求。

**key-value存儲(chǔ)服務(wù)：**相對(duì)整個(gè)框架比較獨(dú)立，按需選用。

服務(wù)標(biāo)準(zhǔn)化運(yùn)營(yíng)

一套互聯(lián)網(wǎng)后臺(tái)服務(wù)的開(kāi)發(fā)和運(yùn)營(yíng)涉及非常多的細(xì)節(jié)。

訪問(wèn)其他服務(wù)模塊，服務(wù)端IP如何管理？網(wǎng)絡(luò)報(bào)文格式是怎樣的？

有哪些配置文件？ 用到哪些第三方的庫(kù)？

業(yè)務(wù)邏輯和基礎(chǔ)框架是如何分離的？

對(duì)外提供怎樣的網(wǎng)絡(luò)接口？怎么對(duì)外提供接口API和文檔？

運(yùn)營(yíng)機(jī)器上的安裝目錄準(zhǔn)備怎么安排？ 有哪些運(yùn)維腳本和工具？

應(yīng)該監(jiān)控哪些指標(biāo)？應(yīng)該記錄哪些日志？

還有很多…

上面種種細(xì)節(jié)，每個(gè)程序員實(shí)現(xiàn)起來(lái)都有不同的做法。經(jīng)驗(yàn)證明，如果后臺(tái)各個(gè)模塊沒(méi)有標(biāo)準(zhǔn)化和規(guī)范化，可能導(dǎo)致：同一個(gè)團(tuán)隊(duì)開(kāi)發(fā)的服務(wù)，千差萬(wàn)別千奇百怪，負(fù)責(zé)運(yùn)維的同事面對(duì)的多個(gè)模塊“長(zhǎng)”的都不一樣，程序框架完全不一樣，安裝目錄亂七八糟，無(wú)法規(guī)模化的高效運(yùn)維。

服務(wù)的質(zhì)量完全依賴(lài)團(tuán)隊(duì)成員的技能和意識(shí)，有的成員可能會(huì)做得比較好，配置文件命名易懂、文檔及時(shí)更新與代碼保持一致、有對(duì)服務(wù)做細(xì)致的監(jiān)控上報(bào)和日志記錄，提供了運(yùn)維腳本，但是也有的成員的工作讓人抓狂。

每當(dāng)有團(tuán)隊(duì)成員離職和工作交接，交接本身就是工作量很大，交接時(shí)間長(zhǎng)，交接質(zhì)量不好，文檔缺失，很多信息在交接過(guò)程中丟失，運(yùn)營(yíng)事故往往頻發(fā)。

經(jīng)驗(yàn)難以得到傳承，一塊石頭反復(fù)絆倒各個(gè)成員和業(yè)務(wù)模塊，運(yùn)營(yíng)事故雷同、頻出，團(tuán)隊(duì)挫折感倍增、服務(wù)可用性低下。

也曾經(jīng)有過(guò)做事比較規(guī)范的時(shí)候，但是這些規(guī)范通常靠耳提面命、人口相傳，靠管理者運(yùn)動(dòng)式的整頓，有時(shí)候管理焦點(diǎn)沒(méi)有持續(xù)跟進(jìn)，或者隨著人員更替，團(tuán)隊(duì)又把這些寶貴的經(jīng)驗(yàn)丟棄了，變得無(wú)序。

所以服務(wù)標(biāo)準(zhǔn)化是后臺(tái)技術(shù)團(tuán)隊(duì)組建開(kāi)始的第一要?jiǎng)?wù)。

兩個(gè)誤區(qū)

**誤區(qū)一：**找?guī)讉€(gè)開(kāi)源的組件用起來(lái)就好了唄。

• 通常的開(kāi)源的組件，只是在某一方面上規(guī)范了服務(wù)，有的是規(guī)范了網(wǎng)絡(luò)調(diào)用，有的是規(guī)范了如何監(jiān)控，有的是規(guī)范了如何記錄遠(yuǎn)程記錄，其實(shí)這還遠(yuǎn)遠(yuǎn)不夠，例如配置文件、接口定義、使用到的外部庫(kù)、安裝目錄的結(jié)構(gòu)等非常多的細(xì)節(jié)，必須統(tǒng)一管理、有唯一出處。

**誤區(qū)二：**你說(shuō)的我都懂，我們團(tuán)隊(duì)剛起步，業(yè)務(wù)需求多，時(shí)間緊，先野蠻生長(zhǎng)，打破條條框框，后面再規(guī)范再改。

• 一開(kāi)始沒(méi)有標(biāo)準(zhǔn)化，后面當(dāng)代碼和模塊都多起來(lái)了，且都處于運(yùn)營(yíng)狀態(tài)，再改再標(biāo)準(zhǔn)化，難度非常大，成本非常大，風(fēng)險(xiǎn)非常大；另外工欲善其事必先利其器，一開(kāi)始就標(biāo)準(zhǔn)化好，其實(shí)可以讓業(yè)務(wù)跑的更快。

如何實(shí)現(xiàn)服務(wù)標(biāo)準(zhǔn)化？

首先，每個(gè)服務(wù)的配置都Web化、集中管理起來(lái)。

部署在哪些IP上？

有且只有一個(gè)配置文件。 Protocol buffer的接口定義文件。 引用了哪些外部庫(kù)？例如openssl。 業(yè)務(wù)邏輯和基礎(chǔ)框架分離，業(yè)務(wù)邏輯以插件形式提供。 然后，每個(gè)業(yè)務(wù)模塊部署的目錄結(jié)構(gòu)都是確定的。 如上圖所示：

• 業(yè)務(wù)部署的目錄都是/msec/一級(jí)業(yè)務(wù)名/二級(jí)業(yè)務(wù)名；

• 都包含bin etc log 等幾個(gè)目錄；

• bin里面是啟停腳本、業(yè)務(wù)插件msec.so和外部庫(kù)（如果有）；

• etc里面是配置文件config.ini；

• Log里面是本地的日志文件。

另外，程序員不能隨意打破上面的方式。例如臨時(shí)的另外搞一個(gè)自己配置文件什么的，他如果這樣做，那下次發(fā)布的時(shí)候目錄會(huì)被覆蓋，個(gè)性化的東西會(huì)被刪除掉。

后臺(tái)服務(wù)的RPC和路由管理

互聯(lián)網(wǎng)服務(wù)的后臺(tái)，硬件通常是由大量的廉價(jià)機(jī)器組成；軟件架構(gòu)通常采取大系統(tǒng)小做、分而治之的思想。這就決定了業(yè)務(wù)邏輯涉及到大量的網(wǎng)路IO，同時(shí)單機(jī)故障、網(wǎng)絡(luò)局部故障是運(yùn)營(yíng)的常態(tài)。那么，RPC和路由管理就顯得尤其重要了。毫秒服務(wù)引擎為此提供了一個(gè)完整的解決方案。

• RPC的概念其實(shí)出現(xiàn)已經(jīng)很久了，記得筆者讀大學(xué)的時(shí)候，接觸到RPC的概念，總覺(jué)得不重要，多此一舉。 我掌握好Socket通信這個(gè)利器和TCP/IP協(xié)議族原理，什么功能不能實(shí)現(xiàn)？

• RPC就跟本地函數(shù)調(diào)用一樣寫(xiě)代碼，確實(shí)開(kāi)發(fā)效率比較高；我自己把Socket相關(guān)函數(shù)好好封裝一下，讓代碼復(fù)用起來(lái)，開(kāi)發(fā)效率也很高。

• 不懂或者不關(guān)注網(wǎng)絡(luò)通信底層原理，光會(huì)函數(shù)調(diào)來(lái)調(diào)去，這樣的程序員太沒(méi)有出息了！

后來(lái)，筆者開(kāi)始帶團(tuán)隊(duì)，親身經(jīng)歷了一些團(tuán)隊(duì)協(xié)作和IT服務(wù)運(yùn)營(yíng)過(guò)程中的故事，才發(fā)現(xiàn)RPC非常關(guān)鍵。如果沒(méi)有很好的實(shí)現(xiàn)RPC和路由管理，IT系統(tǒng)服務(wù)質(zhì)量會(huì)過(guò)度的依賴(lài)人的意識(shí)，而這個(gè)通常成本非常高、效果也不好。

毫秒服務(wù)引擎是怎么做的？

首先，毫秒服務(wù)引擎將每個(gè)服務(wù)部署在哪些IP上這些信息集中管理起來(lái)，即使是調(diào)用外部的非標(biāo)準(zhǔn)服務(wù)（我們叫異構(gòu)服務(wù)），也需要將該外部服務(wù)的接口IP配置到毫秒服務(wù)引擎管理系統(tǒng)里。這樣涉及到的IP信息就不會(huì)散落在代碼和各種配置文件里了。

服務(wù)之間的調(diào)用，統(tǒng)一采用CallMethod()函數(shù)的方式，避免代碼千奇百怪；按服務(wù)名字調(diào)用和接口名調(diào)用。 RPC背后的路由算法對(duì)于單機(jī)故障、網(wǎng)絡(luò)局部波動(dòng)等異常，自動(dòng)容錯(cuò)。簡(jiǎn)單的說(shuō)，路由算法按一定的規(guī)則輪轉(zhuǎn)的選擇被調(diào)用模塊的接口機(jī)，并統(tǒng)計(jì)過(guò)去一段時(shí)間的調(diào)用成功率、時(shí)延信息，根據(jù)這些信息調(diào)整該接口機(jī)被選擇到的比例。如果某個(gè)接口機(jī)故障了，那么就不會(huì)發(fā)送請(qǐng)求給它，從而實(shí)現(xiàn)自動(dòng)容錯(cuò)。

毫秒服務(wù)引擎框架本身，在RPC執(zhí)行的時(shí)候，就上報(bào)了很多基礎(chǔ)屬性和日志，這樣保證了服務(wù)監(jiān)控和告警等運(yùn)營(yíng)措施不依賴(lài)與人的意識(shí)。下圖是叫做getMP3List這樣一個(gè)RPC調(diào)用的請(qǐng)求數(shù)和成功數(shù)，這些是不需要業(yè)務(wù)開(kāi)發(fā)者工作就自動(dòng)上報(bào)。

每個(gè)請(qǐng)求有唯一ID來(lái)標(biāo)識(shí)，通過(guò)該ID，毫秒服務(wù)引擎可以在框圖中直觀的呈現(xiàn)該請(qǐng)求經(jīng)過(guò)的模塊、模塊間的RPC名字等信息，這個(gè)同樣不需要業(yè)務(wù)開(kāi)發(fā)者的工作就自動(dòng)實(shí)現(xiàn)。

后臺(tái)服務(wù)的灰度發(fā)布與監(jiān)控

灰度發(fā)布和監(jiān)控是互聯(lián)網(wǎng)海量服務(wù)必備的兩大利器，能夠極大提高后臺(tái)服務(wù)可用性和運(yùn)營(yíng)水平，背后的哲學(xué)是持續(xù)交付、用戶(hù)測(cè)試和盡在掌控。

在騰訊，有一個(gè)課程系列，叫做《海量服務(wù)之道》，包含十多門(mén)課程和方法論，是技術(shù)同事必修和必知必會(huì)的，其中兩門(mén)課程就是《灰度發(fā)布》和《全方位監(jiān)控》。

筆者在加入騰訊QQ后臺(tái)團(tuán)隊(duì)之前，曾經(jīng)在電信行業(yè)、金融行業(yè)做過(guò)幾年開(kāi)發(fā)工作。剛進(jìn)入騰訊時(shí)，覺(jué)得技術(shù)上很多地方讓人耳目一新。

• 后臺(tái)系統(tǒng)都是部署在非常多的廉價(jià)服務(wù)器上，每個(gè)人都會(huì)管理非常多的機(jī)器，讓人覺(jué)得很有成就感很富有。

• 有比較精確的設(shè)備預(yù)算計(jì)算模型，每個(gè)服務(wù)器的性能在考慮容災(zāi)冗余的前提下，通常被壓榨到剛剛好，負(fù)責(zé)人會(huì)深入的洞悉整個(gè)系統(tǒng)的性能、容災(zāi)、柔性等方方面面。能負(fù)責(zé)一個(gè)海量的系統(tǒng)是很榮耀的一件事情。

• 沒(méi)有專(zhuān)職的測(cè)試人員，經(jīng)過(guò)開(kāi)發(fā)者自測(cè)后，灰度發(fā)布加詳細(xì)的監(jiān)控，主要的系統(tǒng)幾乎每?jī)芍芏紩?huì)被發(fā)布一輪，作為后臺(tái)技術(shù)人員，自己的工作直接影響數(shù)以?xún)|計(jì)的用戶(hù)，有點(diǎn)手握核彈處于上帝視角的感覺(jué)。

• 監(jiān)控系統(tǒng)（我們內(nèi)部一個(gè)叫monitor的系統(tǒng)）真的是太方便了，一條條曲線(xiàn)直觀的展示整個(gè)系統(tǒng)運(yùn)作的各種指標(biāo)，如果有異常短信和電話(huà)就會(huì)響起來(lái)，讓人覺(jué)得一切盡在掌控，有一種面對(duì)著大量?jī)x表盤(pán)操控著航母游弋或者是戰(zhàn)斗機(jī)掛著核彈翱翔的感覺(jué)。

好了，趕緊結(jié)束程序員意淫的美好感覺(jué)，我想說(shuō)的重點(diǎn)是：灰度發(fā)布和監(jiān)控真的是互聯(lián)網(wǎng)海量服務(wù)必備的兩大利器，能夠極大的提高后臺(tái)服務(wù)可用性和運(yùn)營(yíng)水平。

當(dāng)然，灰度發(fā)布不只是一部分一部分的發(fā)布新代碼，監(jiān)控也不只是繪制曲線(xiàn)和告警短信那么簡(jiǎn)單，這里面深究下去會(huì)有很多東西，背后的哲學(xué)是持續(xù)交付、用戶(hù)測(cè)試和盡在掌控。

毫秒服務(wù)引擎是怎么做的？

#####灰度發(fā)布 在服務(wù)配置管理頁(yè)點(diǎn)擊“制定發(fā)布計(jì)劃”。

選擇這一次灰度要發(fā)布的目標(biāo)機(jī)器和發(fā)布類(lèi)型。 在接下來(lái)的向?qū)е羞x擇正確版本的配置文件、外部庫(kù)、業(yè)務(wù)插件等，這樣就完成了發(fā)布計(jì)劃的制作。 接著，點(diǎn)擊菜單 “運(yùn)維->發(fā)布”，可以查詢(xún)所有發(fā)布計(jì)劃，對(duì)于已經(jīng)發(fā)布的計(jì)劃，可以做回滾操作。點(diǎn)擊詳情可以查看發(fā)布計(jì)劃更詳細(xì)信息，并執(zhí)行發(fā)布。

監(jiān)控

關(guān)于監(jiān)控，在“RPC和路由管理”那里講得已經(jīng)比較詳細(xì)了，這里不贅述。只說(shuō)明一下：除了RPC和框架本身自動(dòng)上報(bào)的一些信息，還支持業(yè)務(wù)自定義上報(bào)信息（例如我想上報(bào)第28級(jí)VIP用戶(hù)登錄的次數(shù)），且支持對(duì)于關(guān)鍵指標(biāo)的波動(dòng)、最大值、最小值設(shè)置告警。

KV存儲(chǔ)集群的設(shè)計(jì)要點(diǎn)

Key-Value存儲(chǔ)系統(tǒng)，是非常普遍的需求，幾乎每個(gè)在線(xiàn)的互聯(lián)網(wǎng)后臺(tái)服務(wù)都需要KV存儲(chǔ)，我們團(tuán)隊(duì)在KV存儲(chǔ)方面，經(jīng)歷過(guò)幾個(gè)時(shí)期，我自己深感要做好不容易。

第一個(gè)時(shí)期，很早期的時(shí)候，我們的數(shù)據(jù)存儲(chǔ)在MySQL表里，按照用戶(hù)賬號(hào)簡(jiǎn)單的分庫(kù)分表，為了保證訪問(wèn)高并發(fā)，利用每個(gè)MySQL服務(wù)器的內(nèi)存做數(shù)據(jù)緩存；主備兩套分布在不同IDC，業(yè)務(wù)邏輯自己做副本同步。當(dāng)時(shí)主要的問(wèn)題是：內(nèi)存的數(shù)據(jù)結(jié)構(gòu)擴(kuò)展困難、運(yùn)維工作瑣碎、數(shù)據(jù)同步機(jī)制本身的缺陷導(dǎo)致不能做異地IDC部署，這些缺點(diǎn)對(duì)于業(yè)務(wù)飛速發(fā)展、一地機(jī)房已經(jīng)不夠用的局面非常被動(dòng)。

第二個(gè)時(shí)期，我們?cè)O(shè)計(jì)了新的KV存儲(chǔ)系統(tǒng)，其用戶(hù)數(shù)據(jù)結(jié)構(gòu)容易擴(kuò)展、具備可以多地部署的數(shù)據(jù)同步機(jī)制，很好的應(yīng)對(duì)了新時(shí)期業(yè)務(wù)發(fā)展的需要。為了設(shè)備成本考慮，我們把數(shù)據(jù)做冷熱分離，訪問(wèn)頻繁的數(shù)據(jù)會(huì)加載到專(zhuān)門(mén)的Cache層，且對(duì)于不同的訪問(wèn)模型，掛載不同架構(gòu)的Cache，另外一個(gè)File層專(zhuān)門(mén)做數(shù)據(jù)持久化。這樣的設(shè)計(jì)，使得架構(gòu)太復(fù)雜，bug收斂速度慢，運(yùn)維工作相比以前甚至更復(fù)雜了。

第三個(gè)時(shí)期，為了應(yīng)對(duì)普遍的KV存儲(chǔ)需求，我們以公共組件的形式重新設(shè)計(jì)了KV存儲(chǔ)，作為團(tuán)隊(duì)標(biāo)準(zhǔn)的組件之一，得到了大規(guī)模的應(yīng)用。結(jié)合同期抽象出來(lái)的邏輯層框架、路由管理等其他組件，團(tuán)隊(duì)的公共基礎(chǔ)組件和運(yùn)維設(shè)施建設(shè)的比較完備了，整個(gè)業(yè)務(wù)的開(kāi)發(fā)和運(yùn)維實(shí)現(xiàn)了標(biāo)準(zhǔn)化。但這個(gè)階段就用了我們團(tuán)隊(duì)足足2年多時(shí)間。

不同于無(wú)數(shù)據(jù)的邏輯層框架，KV存儲(chǔ)系統(tǒng)的架構(gòu)設(shè)計(jì)會(huì)更復(fù)雜、運(yùn)維工作更繁瑣、運(yùn)營(yíng)過(guò)程中可能出現(xiàn)的狀況更多、bug收斂時(shí)間會(huì)更長(zhǎng)。一句話(huà)：團(tuán)隊(duì)自己做一個(gè)KV存儲(chǔ)系統(tǒng)是成本很高的，而且也有比較高的技術(shù)門(mén)檻。

設(shè)計(jì)一個(gè)KV存儲(chǔ)，需要考慮至少這些方面。

如何組織機(jī)器的存儲(chǔ)介質(zhì)，通常是內(nèi)存、磁盤(pán)文件；例如用hash的方式組織內(nèi)存。

如何設(shè)計(jì)用戶(hù)的數(shù)據(jù)結(jié)構(gòu)，使得通用、易于擴(kuò)展、存儲(chǔ)利用率高；例如PB序列化、Json、XML方式。

友好的訪問(wèn)接口，而不只是get/set一整個(gè)value。

如何做集群分布、如何sharding、如何做到方便的擴(kuò)縮容；例如一致性hash算法。

如何做數(shù)據(jù)冗余、副本間如何同步、一致性問(wèn)題；副本間如何選舉master。

備份與恢復(fù)、數(shù)據(jù)校驗(yàn)與容錯(cuò)。

讀寫(xiě)性能。

其他可能的特殊需求：例如我們?cè)O(shè)計(jì)過(guò)一個(gè)KV存儲(chǔ)，用于存儲(chǔ)一些公眾號(hào)的個(gè)數(shù)不受限粉絲列表。

上面8點(diǎn)，業(yè)內(nèi)的KV存儲(chǔ)組件一般都會(huì)考慮到，或者各有特色，各自?xún)?yōu)勢(shì)在伯仲之間。但是綜合過(guò)去的經(jīng)驗(yàn)教訓(xùn)，我們覺(jué)得有一點(diǎn)很容易被忽視：可運(yùn)維性、運(yùn)維自動(dòng)化、黑盒化運(yùn)維。

舉一個(gè)例子，前面提到的我們第二個(gè)時(shí)期的KV存儲(chǔ)系統(tǒng)，剛開(kāi)始應(yīng)用的時(shí)候，一次擴(kuò)容過(guò)程會(huì)有10多步的運(yùn)維操作，包括load數(shù)據(jù)、做增量同步、多次修改機(jī)器狀態(tài)、數(shù)據(jù)比對(duì)等等，需要運(yùn)維同事以高度的責(zé)任心來(lái)完成。另外就是運(yùn)維同事必須如該KV存儲(chǔ)架構(gòu)設(shè)計(jì)者一樣深刻理解系統(tǒng)背后的原理和細(xì)節(jié)，否則就不能很好的執(zhí)行運(yùn)維操作，這個(gè)要求也非常高，新老交接周期長(zhǎng)，還容易出運(yùn)維事故。

基于上面的考慮，同事為了讓用戶(hù)更容易學(xué)習(xí)和接受，毫秒服務(wù)引擎在Redis Cluster的基礎(chǔ)上，實(shí)現(xiàn)了運(yùn)維Web化，并加上了集群的監(jiān)控。

通過(guò)Web界面方便進(jìn)行

集群概要狀態(tài)查看。

可以在Web上方便的完成日常的運(yùn)維操作：新搭集群、擴(kuò)縮容、故障機(jī)器的恢復(fù)。 請(qǐng)求量、內(nèi)存使用、CPU等各種狀態(tài)信息可直觀監(jiān)控，也可以按IP粒度查看。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的腾讯QQ团队开源分布式后台毫秒服务引擎全解析：引擎架构、RPC、灰度……的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。