後臺服務標準化運營

版權聲明：本文由廖念波原創文章，轉載請註明出處: 
文章原文連接：https://www.qcloud.com/community/article/148

來源：騰雲閣 https://www.qcloud.com/community

 

爲何要服務標準化

一套互聯網後臺服務的開發和運營涉及到很是多的細節：

1. 訪問其餘服務模塊，服務端IP如何管理？網絡報文格式是怎樣的？

2. 有哪些配置文件？ 用到哪些第三方的庫？

3. 業務邏輯和基礎框架是如何分離的？

4. 對外提供怎樣的網絡接口？怎麼對外提供接口API和文檔？

5. 運營機器上的安裝目錄準備怎麼安排？ 有哪些運維腳本和工具？

6. 應該監控哪些指標？應該記錄哪些日誌？

7. 還有不少…

上面種種細節，每一個程序員實現起來都有不一樣的作法。經驗證實，若是後臺各個模塊沒有標準化和規範化，可能致使：

1. 同一個團隊開發的服務，千差萬別千奇百怪，負責運維的同事面對的多個模塊「長」的都不同，程序框架徹底不同，安裝目錄亂七八糟，沒法規模化的高效運維

2. 服務的質量徹底依賴團隊成員的技能和意識，有的成員可能會作得比較好，配置文件命名易懂、文檔及時更新與代碼保持一致、有對服務作細緻的監控上報和日誌記錄，提供了運維腳本，可是也有的成員的工做讓人抓狂

3. 每當有團隊成員離職和工做交接，交接自己就是工做量很大，交接時間長，交接質量很差，文檔缺失，不少信息在交接過程當中丟失，運營事故每每頻發

4. 經驗難以獲得傳承，一塊石頭反覆絆倒各個成員和業務模塊，運營事故雷同、頻出，團隊挫折感倍增、服務可用性低下

5. 也曾經有過作事比較規範的時候，可是這些規範一般靠耳提面命、人口相傳，靠管理者運動式的整頓，有時候管理焦點沒有持續跟進，或者隨着人員更替，團隊又把這些寶貴的經驗丟棄了，變得無序

因此服務標準化是後臺技術團隊組建開始的第一要務。

幾個誤區

誤區一：找幾個開源的組件用起來就行了唄

一般的開源的組件，只是在某一方面上規範了服務，有的是規範了網絡調用，有的是規範瞭如何監控，有的是規範瞭如何記錄遠程記錄，其實這還遠遠不夠，例如配置文件、接口定義、使用到的外部庫、安裝目錄的結構等很是多的細節，必須統一管理、有惟一出處。

誤區二：你說的我都懂，咱們團隊剛起步，業務需求多，時間緊，先野蠻生長，打破條條框框，後面再規範再改

一開始沒有標準化，後面當代碼和模塊都多起來了，且都處於運營狀態，再改再標準化，難度很是大，成本很是大，風險很是大；另外工欲善其事必先利其器，一開始就標準化好，其實可讓業務跑的更快

毫秒服務引擎(msec, 取英文名Mass Service Engine in Cluster的首字母組合)是騰訊一個開源框架，其創做衝動和構建經驗，來自QQ後臺團隊超過10年的運營思考。服務標準化是毫秒服務引擎設計的重要考量點。

毫秒引擎怎麼實現服務標準化？

首先，每一個服務的配置都web化、集中管理起來，包括：

1. 部署在哪些IP上？
   
2. 有且只有一個配置文件
   
3. Protocol buffer的接口定義文件
   
4. 引用了哪些外部庫？例如openssl
   
5. 業務邏輯和基礎框架分離，業務邏輯以插件形式提供
   
   而後，每一個業務模塊部署的目錄結構都是肯定的：
   

如上圖所示，

1. 業務部署的目錄都是/msec/一級業務名/二級業務名

2. 都包含bin etc log 等幾個目錄

3. ein裏面是啓停腳本、業務插件msec.so和外部庫（若是有）

4. etc裏面是配置文件config.ini

5. log裏面是本地的日誌文件

另外，程序員不能隨意打破上面的方式。例如臨時的另外搞一個本身配置文件什麼的，他若是這樣作，那下次發佈的時候目錄會被覆蓋，個性化的東西會被刪除掉

結語

因爲篇幅和時間的限制，這裏不能展開闡述。詳細的能夠見騰訊雲服務市場、毫秒服務引擎官網，或者微信公衆號:msec-engine