理想的互聯網服務後臺框架的九個要點

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

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

 

理想的互聯網服務後臺框架的九個要點
對於互聯網服務後臺團隊，開發框架的選擇是很是關鍵的一個問題，多年的海量服務經驗和教訓使得咱們團隊深入的認識到：

• 要儘早規範團隊的開發服務框架，避免到了後期，各類開發語言混雜、各種存儲組件充斥、重複編碼、每一個模塊形態不統1、文檔缺失、監控癱瘓、人員離職形成大量信息丟失，最後積重難返、痛苦不堪。

• 沒有框架來規範，團隊的隨意性就太大，合做效率就大打折扣，甚至於內耗、反覆的挖坑填坑，系統的成敗過於依靠人的意識和水平。

• 規範，不能靠文檔、不能靠勞動紀律、不能靠苦口婆心、不能靠人員意識、不能靠運動式的整頓，要靠技術框架上切實的限制與貼心保護。

若是有機會從0開始定義一個理想的開發框架，須要考慮哪些點？咱們以爲主要有以下9個方面：

1. 【同步編碼異步執行】兼顧運行效率和編碼效率，但願代碼寫起來是同步和順序的，而執行的時候是異步的

2. 【IDL/RPC】支持IDL（接口描述語言）和RPC，減小網絡協議相關的重複工做，協議有比較好的擴展性；遠程調用友好且高效，作到覆蓋主要的開發語言

3. 【LB】對服務間的調用選路進行統一的管理，對單機故障和網絡波動等常見狀況有自動容錯，咱們簡稱load balance(LB)

4. 【 存儲服務化】這個其實和開發框架關係不太緊密，這裏提一下，強調存儲應該有統一的組件且由專業的團隊運維，就像共有云同樣

5. 【過載保護】框架必須有成熟自帶的過載保護機制，不須要業務開發人員關注或者關注不多

6. 【基礎的監控和告警】RPC調用、機器的cpu/網絡活動、任務併發度、時延、進程監控和秒起等基礎信息，要有上報、統計和告警，不須要業務開發人員關注。

7. 【完整的業務流轉呈現】統一日誌，在一個地方可以清晰的呈現某次業務處理過程的流轉詳細狀況：通過了哪些模塊間調用，調用參數是怎樣的，每一個模塊處理的重要分支和結果是怎樣的，最好圖形化呈現。支持染色和不一樣的日誌詳細級別

8. 【中央總控】整個系統的配置和文檔等重要信息，例如每一個模塊有哪些機器，分佈在哪些機房、容量冗餘狀況、模塊間調用關係、訪問控制的配置動態管理甚至電子流，都但願能統一在一個地方web化的管理起來，而且與運營的系統是直接聯繫直接生效的

9. 【雲調度】容量的自動調度。例如要進行某個運營活動須要大量的擴容，只須要把設備放進去，就能自動的擴縮容。當某個城市機房故障，可以自動調度容量到其餘城市

基於上面的總結，咱們團隊開源了一個服務開發運營框架，叫作毫秒服務引擎。

毫秒服務引擎(msec, 取英文名Mass Service Engine in Cluster的首字母組合)是騰訊的一個開源框架，集RPC、名字發現服務、負載均衡、業務監控、灰度發佈、容量管理、日誌管理、key-value存儲於一體，目的是提升開發與運營的效率和質量。

毫秒服務引擎的創做衝動和構建經驗，來自QQ後臺團隊超過10年的運營思考。它是一整套解決方案，但也能夠拆分的來使用其中的監控、key-value存儲單品。

詳細可見官網，或在騰訊雲服務市場聯繫咱們

典型用戶羣體

使用毫秒服務引擎，用戶能夠快速擁有一套具有監控、名字發現服務、負載均衡、灰度發佈、配置管理、日誌、kv存儲等功能的系統化的開發與運營框架，特別適合互聯網初創公司。

毫秒服務引擎很是容易搭建和上手，使用它，初學者從零開始開發一個分佈式後臺demo並運行起來，只須要2個小時。基本上是一個小時完成框架搭建，一個小時完成開發上線。

功能與優點

1. 模塊間訪問採用RPC的方式，開發者不用關注網絡與報文格式，像寫單機程序同樣開發分佈式服務

2. 負載自動均衡與容錯，對於單機故障、局部網絡波動等情況自動應對，服務高可用性

3. 支持C/C++與java語言，後續還將繼續豐富；若是選擇C/C++語言，支持協程，兼具開發和運行效率

4. Web化的管理界面，在web界面完成配置、發佈、監控、日誌、Key­-value存儲集羣管理等全部操做

5. 須要複雜部署的服務器都採用docker鏡像的方式安裝，使得部署與上手很是容易

6. 相比使用其餘開源組件拼湊起來的解決方案，毫秒服務引擎更加的體系化，對團隊的規範更加到位

毫秒服務引擎也提供了微信公衆號（msec-engine），歡迎你們關注，參與討論和反饋。