美團分散式服務通訊框架及服務治理系統 OCTO
一、什麼是OCTO
定義：
OCTO是美團的分散式服務通訊框架及服務治理系統，屬於公司級基礎設施，目前尚未開源。
目標：
為公司所有業務提供統一的服務通訊框架，使業務具備良好的服務運營能力，輕鬆實現服務註冊、服務自動發現、負載均衡、容錯、灰度釋出、呼叫資料視覺化等，持續提升服務高可用性、服務運維效率。
類比：
美團點評內部類似的框架還有pigeon（已開源，https://github.com/dianping/pigeon）。OCTO是octopus（章魚）的縮寫，pigeon是鴿子的意思，一個水裡遊，一個天上飛，目標大體一致。
業界同類產品有Dubbo。OCTO的功能因為主要內部用，功能要豐富的多。
規模：
千億級別
靜兒的老領導17年時做過一個QCon分享，叫《OCTO：千億規模下的服務治理挑戰與實踐》。裡面提到了16年OCTO日呼叫量已經超過千億，目前這個數字還在高速增長。
二、產生背景
階段1 - 垂直應用階段
這個階段大體相當於目前運用最廣泛的「分層架構」。把業務按照領域劃分（ 垂直拆分 ），將一個大應用分成幾個互不相干的小應用。
階段2 - 早期分散式階段
隨著規模的擴大，系統之間需要進一步拆分。將相同的操作抽象出來走 服務化 來實現 複用和整合 。這時候就需要使用 RPC技術 ，初期使用HTTP+JSON來實現分散式。
這個階段後期問題日益顯現：
- 規範化和標準化差：缺乏強schema約束、需要較多的編碼、呼叫方的學習和溝通成本高
- 效率低：HTTP協議頭比較重；內部要走CDN、nginx等服務才最終實現端到端的互動；資料傳輸效率低(資料傳輸格式是json，它是文字格式的，比方說一個數字用二進位制只佔1個位元組，用文字實際上存的是字串，佔3個位元組)。
- 運維成本高：缺乏 服務自動註冊發現 、依賴人工運維
階段3 - 服務治理階段
這個階段使用了基於thrift的高效能的RPC框架和基於zookeeper(zk)的服務自動註冊發現。引入這些技術帶來的問題：
- 可用性問題：強依賴zk，使用臨時節點，網路抖動會導致不穩定，正常服務被下線；zk出現大規模故障不易進行隔離。
- 未實現 全生命週期 自動化 運維：缺乏資料採集分析、監控報警等運維機制；難以推進規範化、標準化；路由策略單一
為了解決上述問題，OCTO應運而生。
三、服務治理系統設計特點
整體架構圖如下：
特點1 - 代理模式優化服務註冊發現
整體架構圖中的SG_agent（服務治理代理Service Governance Agent）是直接安放在業務（使用OCTO的服務）伺服器上的代理，也就是本地程序。實際承擔服務註冊、服務發現、動態路由解析、負載均衡、配置管理等功能及呼叫統計上報的應用代理程式。
代理模式帶來的好處：
- 標準化：用thrift IDL(介面描述語言Interface description language)提供標準介面，美團技術人人都知道的appkey（服務標識）的概念正是由此而普及。這也是美團內部統一配置中心MtConfig的基礎。
- 策略下移：將原來直接打成jar包讓業務引用的策略放到代理層來實現，可方便的進行策略熱更新，業務程式碼不再感知。
- 提升可用性：代理快取解決了zk掛業務就掛的問題。自身又採用了基於冗餘的高可用設計，整體大幅度提高了可用性。
特點2 - 狀態檢查提高可用性
資料一致性問題一直是分散式系統的要點和難點。對服務註冊發現來說，最重要的資料就是服務的狀態。是否在假死（程序還活著，但是不處理請求，比如正在fullgc）？
很多團隊是通過「keepalive探針」(心跳)來解決這個問題的。這種技術好處是準確，缺點是高消耗。因為這是業務端主動發起的探測，很多場景下keepalive的IO消耗可能比服務自身還要大。
OCTO採用的集中式的探測，早期是基於Akka Actor(用於遠端通訊的工具，特點是高效)的，通過熱備、資料分析自動水平擴充套件、Double Check、熔斷等機制，可用性和準確性都在6個9以上。
特點3 - 資料驅動
美團內部非常注重的一點就是「用資料說話」。OCTO的主要資料包括：呼叫資料、異常呼叫、呼叫鏈路資訊、全鏈路引數傳遞。資料展示形式包括：監控報警、資料報表、資料檢視。
特點4 - 全生命週期
美團內部的服務從在“媽媽肚子裡”就開始和OCTO打交道。服務註冊、機器申請的資訊都要先同步到OCTO。因為OCTO全週期性，所以可以對服務的各個階段資料提供監控和優化方案。比如在釋出部署階段，OCTO利用先禁用節點摘掉流量，讓流量打到別的機器上再下掉此節點，啟動後做服務狀態檢查，檢查通過，再接收流量來實現平滑釋出。
特點5 - 周邊生態
OCTO非常強大，強大在於它不是孤軍奮戰，是各個團隊間的跨團隊合作。這也是它被叫做“八爪魚”的原因之一。
和核心團隊，OCTO進行深度定製，比如連結複用、連結保護、原生非同步支援。和HULK(容器團隊，參見：歐陽老師的 美團點評容器平臺HULK的排程系統 )團隊的合作也是日漸緊密。靜兒就是HULK團隊的一員。合作的重要一點就是業界常提到的「流動計算架構」。解決的問題主要是提升業務可用性、資源利用率、深度devOps高效運維。
四、總結
用服務進行設計
總是為併發進行設計
--《程式設計師修煉之道》
