定義：
octo是美團的分布式服務通訊框架及服務治理系統，屬於公司級基礎設施(octo已經開源，下面：octo-rpc, octo-portal，octo-ns 都是octo的一部分)。
目標：
為公司所有業務提供統一的服務通訊框架，使業務具備良好的服務運營能力，輕鬆實現服務註冊、服務自動發現、負載均衡、容錯、灰度發布、呼叫資料視覺化等，持續提公升服務高可用性、服務運維效率。
模擬：
美團點評內部類似的框架還有pigeon（已開源，是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的服務）伺服器上的**，也就是本地程序。實際承擔服務註冊、服務發現、動態路由解析、負載均衡、配置管理等功能及呼叫統計上報的應用**程式。
**模式帶來的好處：
- 策略下移：將原來直接打成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高效運維。
四、總結
用服務進行設計
美團分布式服務通訊框架及服務治理系統OCTO
定義 octo是美團的分布式服務通訊框架及服務治理系統，屬於公司級基礎設施 octo已經開源，octo rpc,octo portal，octo ns 都是octo的一部分 目標 為公司所有業務提供統一的服務通訊框架，使業務具備良好的服務運營能力，輕鬆實現服務註冊 服務自動發現 負載均衡 容錯 灰度...
微服務 分布式服務框架
spring cloud rest與rpc比較 dubbo 和 spring cloud 對比 通訊協議 傳輸的格式都屬於協議 服務路由 分布式服務上線時都是集群組網部署，集群中會存在某個服務的多例項，消費者如何從服務列表中選擇合適的服務提供者進行呼叫，這就涉及到服務路由。分布式服務框架需要能夠滿足...
分布式服務框架 Zookeeper
createmode persistent 建立後只要不刪就永久存在 ephemeral 會話結束年結點自動被刪除，ephemeral結點不允許有子節點 sequential 節點名末尾會自動追加乙個10位數的單調遞增的序號，同乙個節點的所有子節點序號是單調遞增的 persistent sequen...