一、什麼是OCTO 定義： 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高效運維。
四、總結
用服務進行設計
總是為併發進行設計
--《程式員修煉之道》
相關閱讀：
