[轉]美團.點評服務治理框架

原文地址：http://www.cnblogs.com/xiexj/p/7496347.html

美團.點評沒用服務治理時的早期RPC架構：使用的是http+json調用，編碼工做多，接口定義缺少強Scheme約束，不易規範化。http協議頭較重，應用於內網時鏈路較長，有必定可用性風險。缺少服務自動註冊發現機制，依賴人工運維。下圖是美團.點評12年的服務治理架構，那時候我還在人人，人人用的也是這套架構。美團和人人仍是有很深的淵源的。

　　

　　這種架構存在服務註冊中心強依賴zk,使用臨時節點，容易因網絡抖動致使不穩定。多語言支持帶來的服務註冊/發現需求，須要屢次實現類似邏輯，zk出現故障影響面大，不易進行隔離的問題。服務通訊框架未支持服務路由分組，機房路由，節點動態啓停等策略。框架內強耦合，過多邏輯放到客戶端，升級迭代困難，缺少服務數據採集，監控報警等機制。整體上未實現全生命週期的服務治理，運營，難以推動服務規範化，標準化。

 　　後來咱們就進入了OCTO分佈式服務通訊框架及服務治理系統。OCTO是美團.點評內部公司級基礎設施，爲公司全部業務提供統一的高性能服務通訊框架，使業務具有良好的服務運營能力，輕鬆實現服務註冊，服務自動發現，負載均衡，容錯，灰度發佈，數據可視化，監控告警等功能，提高服務開放效率，可用性及服務運維效率。

　　

• MTransport - 通訊服務框架。支持thrift, http，現包括mtthrift(java)，cthrift(C/C++)，pthrift(PHP)，Turbo thrift(Node.js)
• MNS - 命名服務。負責服務的註冊，發現等功能。
• MSGP - 服務治理管理平臺http://coto.sankuai.com 面向服務管理人員提供一站式治理功能。
• SgAgent - 本地代理，負責Region的劃分，服務分組等特性功能的實現。主要在服務註冊發現的時候採用代理模式，將註冊發現結果保存在本地，策略熱更新。避免了對zk的強依賴帶來的網絡抖動。
• HLB - 彈性負載均衡器。全部http請求/應答流量都會穿過這個系統，相似amazon elb。

 

作業務的嘛，下面從使用層面來說一下OCTO服務治理 。

　　首先定義服務：區分統一寄出組件服務，業務服務的分層，識別功能職責，邊界。明確服務的負責人，備份負責人。

　　而後註冊服務：肯定服務的惟一標識，與服務自己有關，和其角色（服務方，調用方）無關。OCTO平臺註冊服務：http://octo.sankuai.com/service/registry。建議格式爲：com.公司(內部sankuai，外部meituan).業務線.具體服務名。

 　　其實這個服務治理是從SOA演化而來的，首先有面向服務，纔有的RPC調用，調用的多，垂直切分不能知足需求，從而有了分佈式架構，微服務架構。微服務多了，怎麼保證各個模塊的健康，高效合做，纔有了服務治理。因此在小公司的區別和大公司的區別。就好像一個建一間房子，四合院，或者是一個小區，一個城鎮的區別。有了需求規模，纔有了對技術的要求。可是在大公司我可能也就是個擰螺絲的，在小公司，我須要本身建一套房子，誰也說很差哪一個技術含量更高。