命名服務主要解決微服務拆分後帶來的服務發現、路由隔離等需求，是服務治理的基石。美團命名服務（以下簡稱MNS）作爲服務治理體系OCTO的核心模塊，目前承載美團上萬項服務，日均調用達到萬億級別。爲了更好地支撐美團各項飛速發展的業務，MNS開始從1.0向2.0演進。
本文將圍繞本次演進的初衷、實現方案以及落地的效果等方面進行展開，同時本文還介紹了命名服務作爲一個技術中臺組件，對業務的重要價值以及推動業務升級的一些成果。希望本文對大家能有所幫助或啓發。
| 本文根據美團基礎架構部技術專家舒超在2019 ArchSummit（全球架構師峯會）上的演講內容整理而成。
一、MNS 1.0簡介
從架構上看，MNS 1.0 主要分爲三層：首先是嵌入業務內部的SDK，用作業務自定義調用；然後是駐守在每個機器上的SgAgent，以代理的方式將一些易變的、消耗性能的計算邏輯與業務進程分離開來，從而降低SDK對業務的侵入，減少策略變動對業務的干擾；遠端是集中式的組件，包括健康檢查模塊Scanner，鑑權緩存模塊MNSC，以及基於ZooKeeper（以下簡稱ZK）打造的一致性組件MNS-ZK，作爲通知和存儲模塊。在層級之間設立多級緩存，利用“邊緣計算”思想拆分邏輯，簡化數據，儘量將路由分配等工作均攤到端上，從而降低中心組件負載。
更多詳情大家可參考《美團大規模微服務通信框架及治理體系OCTO核心組件開源》一文中的OCTO-NS部分。
在體量方面，MNS 1.0已經接入了美團所有的在線應用，涉及上萬項服務、數十萬個節點，並覆蓋了美團所有的業務線，日均調用達萬億級別，目前我們已將其開源。
總的來講，作爲公司級核心服務治理組件，MNS 1.0在架構上帶有明顯的CP屬性，在保持架構簡潔、流程清晰的同時，還支持了業務大量迭代的需求，較好地幫助公司業務實現了服務化、標準化的目標。
二、MNS 1.0遇到的問題和挑戰
但是隨着美團業務的快速增長，公司的服務數、節點數、服務信息量、服務變動頻次等維度都在快速增長，有些服務甚至呈現出跨數量級的增長。在這樣的情況下，命名服務也面臨着一些新的問題和挑戰：
-
可用性：公司業務持續高速增長，很多都需要進行跨地域的部署。在MNS 1.0 架構下，地域之間的專線如果斷連，會發生一個地域命名服務整體不可用的情況；其次，強一致組件存在單點問題，Leader出現故障，整個集羣中斷服務；另外，在多客戶端和大數據傳輸的命名服務場景下，CP系統恢復困難，RTO達到小時級別。MNS 1.0曾經出現過後端集中式組件單機連接超過十萬且活躍鏈接數過半的情況，出現問題之後，現場恢復的負荷可想而知，這些都給命名系統的可用性帶來很大的風險。
-
擴展性：相對於需要支持的業務數量，MNS 1.0整體平行擴展能力不足。MNS-ZK的單集羣規模上限不超過300（實際只能達到250左右，這與ZooKeeper內部的myid等機制有關），否則同步性能會急劇惡化；其次，集羣寫入不可擴展，參與寫入節點越多性能越差；另外，服務信息快照在固定的時間片內持續增長，增加IO壓力的同時也延長了遷移的同步時間。而擴展性上的短板，導致MNS 1.0難以應對突發的流量洪峯，易出現“雪崩”。
-
性能：寫入操作受CP屬性限制，串行性能較低。MNS-ZK整體到7000左右的寫量就已接近上限。其次，在熱點服務場景下，數據分發較慢，這跟數據粒度較粗也有一定關係。而數據粒度粗、量大，也會在組件間傳輸消息時，導致臨時對象頻繁生成，引起GC。另外，MNS 1.0的後端集羣負載還存在均衡性問題，一是因爲原架構中缺乏集中管控服務，無法進行動態的集羣與數據拆分伸縮，二是因爲強一致屬性下，集羣節點間基於Session的遷移現場較重，很容易因一個節點掛掉而引起連鎖反應。
從可用性、擴展性、性能等三個方面，MNS 1.0暴露出很多的問題，究其根源，原來的命名服務作爲一個CP系統，爲獲得“數據一致性”而犧牲了部分情況下的可用性。其實，對於命名服務而言，一致性並沒有這麼重要，最多是調用方在一定時間內調多了或調漏了服務方而已，這個後果在不可靠網絡的大前提下，即使命名服務沒有出現問題，也可能經常會出現。藉助端的自我檢查調整機制，其影響可以說微乎其微。而另一方面，如果是一個機房或一個地域的調用方和服務方沒有問題，但是因爲這個區域和命名服務主集羣斷開了鏈接，從而導致本域內不能互調，這個就顯得不太合理了。
所以總結一下，我們認爲，命名服務的本質是建立和增強服務本身的連通性，而不是主動去破壞連通性。命名服務本質上應該是一個AP系統。
其實，業界對命名服務AP/CP模式都有相應實現和應用，很多企業使用CP模式，原因可能有以下幾點:
-
架構行爲簡單：CP系統在出現分區時行爲比較簡單，冷凍處理，粗暴但相對不容易出錯。
-
啓動門檻低：一些成熟的開源一致性組件，比如ZK、etcd都是CP系統，能夠開箱即用，在數據規模可控的情況下，基本能夠滿足企業的需求。
另外，我們瞭解到，一些公司使用特殊的方式弱化了這個問題，比如將CP系統進一步拆分到更小的域中（比如一個IDC），縮小分區的粒度，而全局有多個CP系統自治。當然，這個可能跟調用方服務方的跨度限制或者說調用配套部署有關係，但也有可能帶來更復雜的問題（比如CP系統之間的數據同步），這裏就不做詳細的討論了。
除去MNS 1.0本身的架構缺陷，我們還需要面臨另一個問題，當初在項目啓動時，雲原生尚處於起步階段，而如今，一些基於雲原生理念興起的網絡基礎設施，尤其是Service Mesh在美團快速發展，也需要MNS進行改造去適配新的流量通道和管控組件，這也是此次MNS 2.0演進的目標之一。
綜上，我們以AP化、Mesh化爲主要目標，正式開始了從MNS 1.0向MNS 2.0的演進。
三、MNS 2.0
1.整體架構
MNS 2.0的整體架構自上而下主要分爲四層：
1. 業務系統層：這一層與MNS 1.0架構類似，依然是嵌入到業務系統中的SDK或框架，但是不再感知服務列表和路由計算，從而變得更加的輕薄。
2. 代理接入層：這一層主要變化是加入了Service Mesh的Sidecar和MNS-API。前者將命名服務的部分鏈路接入Mesh；後者爲MNS增加了更豐富的HTTP調用，幫助一些沒有使用SDK或框架的業務快速接入到命名服務。整個代理接入層的改造使得MNS對接入業務更加親和。
3. 控制服務層：新增註冊中心控制服務，這也是MNS 2.0的核心。主要分爲以下三個模塊：
a. 網關管控模塊：提供集中式的鑑權、限流/熔斷、統計等SOA服務化的管控能力，同時避免海量代理組件直連存儲層。
b. 數據分發模塊：數據的通道，包括註冊數據的上傳、訂閱數據的下發，可進行精細化數據拆分和平行擴展來適配熱點服務。
c. 變更捕獲模塊：服務註冊發現的審計，包括對第三方系統進行事件通知和回調，支持多元化的服務數據營運需求。
另外，控制服務層還包括全鏈路SLA監控等新的子模塊，以及健康檢查Scanner這樣的傳統MNS組件。
4. 數據存儲層：我們進一步豐富了命名服務的存儲和分發介質，提高了數據層的整體性能。主力存儲使用K/V存儲系統（美團Cellar系統）替代MNS-ZK，有效地提高了數據的吞吐能力，支持網絡分區後的數據讀寫以及宕機災備，同時保留ZK做一些輕量級的Notify功能。新增的關係型數據庫和消息隊列（美團Mafka系統），配合控制層的變更捕獲模塊，提供更方便的數據挖掘結構和外部扇出。
5. 旁路於上面4層的是外部營運設施，主要是業務端的可視化Portal，用戶可以在上面對自身服務進行監控和操作，美團的基礎研發部門也可以在上面進行一些集中式的管控。
綜上所述，MNS 2.0整體架構在兼容1.0的前提下，重點變化是：新增了控制服務層並對底層存儲介質進行拆解。下面，我們來看一下服務註冊發現功能在MNS 2.0中的實現流程：
-
服務註冊：代理接入層透傳業務註冊請求，經過控制服務層的管控模塊（Gateway）一系列SOA和審計流程後，寫入註冊數據到存儲層。
-
數據感知：控制服務監聽數據變動，服務註冊寫入新信息後，分發模塊（Delivery）更新內存中的緩存，數據流經過捕獲模塊（CDC）將註冊信息關係化後存儲到DB。
-
服務發現：代理層請求經過控制服務的管控模塊（Gateway）效驗後，從分發模塊（Delivery）的緩存中批量獲取服務端註冊信息。Cache Miss場景時從存儲層讀取數據。
-
外部交互層：外部系統當下通過代理層接入整個MNS體系，避免直連存儲帶來的各類風險問題。未來，營運平臺可直接使用準實時DB數據，以OLAP方式進行關係化數據的分析。
接下來，我們一起來看下MNS2.0的主要演進成果。
2. 演進成果
2.1 流量洪峯&平行擴展
流量洪峯對於不同領域而言有不同的時段。對於O2O領域比如美團來說，就是每天中午的外賣高峯期，然後每天晚上也會有酒旅入住的高峯等等。當然，基於其它的業務場景，也會有不同的高峯來源。比如通過“借勢營銷”等運營手段，帶來的高峯量可能會遠超預期，進而對服務造成巨大的壓力。
MNS 1.0受制於MNS-ZK集羣數量上限和強一致性的要求，無法做到快速、平行擴展。MNS 2.0的數據存儲層重心是保證數據安全讀寫和分佈式協調，在擴展能力層面不應該對其有太多的要求。MNS 2.0的平行擴展能力主要體現在控制服務層，其具體功能包括以下兩個方面:
集羣分片：控制服務提供全量註冊數據的分片能力，解決命名服務單獨進行大集羣部署時不能進行業務線隔離的風險。MNS-Control網關模塊分爲Master和Shard等兩類角色，協作提供大集羣分片能力。
-
Master：維護服務註冊信息與各個分片集羣（Shard）的映射關係，向代理層組件提供該類Meta數據。Master接收各個Shard集羣事件，新增、清理Shard中維護的註冊信息。
-
Shard：數據分片自治向代理組件提供服務註冊/發現功能，實現按業務線隔離命名服務，同時按照Master發出的指令，調整維護的註冊信息內容。
-
Services：業務服務通過代理組件接入MNS，代理組件啓動時通過與Master的交互，獲知歸屬的Shard集羣信息以及Fallback處理措施。此後Agent只與業務線Shard進行命名數據交互，直到Shard集羣不可用，重新執行“自發現”流程。
-
Fallback措施：設置一個提供全量服務信息的默認Shard集羣，當業務線Shard異常時。一方面，Agent重啓“自發現”流程，同時將命名請求重定向到默認的Shard集羣，直到業務線Shard恢復後，流量再切回。
網絡分區可用：MNS 1.0階段，網絡分區對可用性的影響巨大，分區後MNS-ZK直接拒絕服務。新架構將存儲遷移到KV系統後，在網絡專線抖動等極端情況下，各區域依然能正常提供數據讀取功能。同時，我們與公司存儲團隊共建C++ SDK的地域就近讀寫功能。一方面，提高跨域服務註冊發現的性能，另一方面，實現了網絡分區後，各區域內命名服務可讀、可寫的目標，提高了系統的可用性，整個命名服務對網絡的敏感度降低。
目前，控制服務層在平行擴縮容時間和集羣原地恢復時間等方面，都達到了分鐘級，集羣也沒有節點上限，從而能夠有效應對突發的流量，防止服務出現“雪崩”。
2.2 推送風暴&性能提升
另一個典型的場景是推送“風暴”，在服務集中發佈、出現網絡抖動等情況下，會導致命名服務出現"一橫一縱"兩種類型的放大效應：橫向是“關注放大”，類似於社交網絡中某大V消息需要分發給衆多的粉絲，服務越核心，放大的效果越明顯。縱向是“級聯放大”，命名服務的上下游會逐級進行拷貝發送，甚至一級上下游會針對一個消息有多次的交互（Notify+Pull）。
“關注放大”和“級聯放大”本身都是無法避免的，這是由系統屬性決定，而我們能做的就是從兩方面去平滑其帶來的影響：
正面提升核心模塊性能，增強吞吐、降低延遲
-
結構化聚合註冊信息：控制服務的數據分發模塊，在內存中存儲結構化的服務註冊信息，提供批量數據的讀取能力；降低多次網絡RTT傳輸單個數據以及數據結構轉化帶來的高耗時。
-
高併發的吞吐能力：控制服務通過無鎖編程處理關鍵路徑的競爭問題，藉助應用側協程機制，提供高併發、低延遲的數據分發功能。
-
與存儲團隊共建，實現KV系統就近區域讀寫，提高命名服務的服務註冊（數據寫入）性能。
另外，包括前面提到的控制服務集羣的平行擴展能力，其實也是整體性能提升的一種方式。
側面疏通，區分冷熱數據，降低推送的數據量，提高效能
自然界中普遍存在“80/20法則”，命名服務也不例外。服務註冊信息的結構體中元素，80%的改動主要是針對20%的成員，比較典型的就是服務狀態。因此，我們將單個整塊的服務信息結構體，拆分爲多個較小的結構體分離存儲；當數據變動發生時，按需分發對應的新結構體，能夠降低推送的數據量，有效減少網絡帶寬的佔用，避免代理組件重複計算引起的CPU開銷，數據結構變小後，內存開銷也得到顯著降低。
那是否需要做到完全的“按需更新”，僅推送數據結構中變動的元素呢？我們認爲，完全的“按需更新”需要非常精細的架構設計，並會引入額外的計算存儲開銷。比如，我們需要將變動成員分開存儲以實現細粒度Watcher，或用專門服務識別變動元素然後進行推送。
同時，還要保證不同成員變動時，每次都要推送成功，否則就會出現不一致等問題。在組件計算邏輯所需的數據發生變化時，也會帶來更多的改動。在命名服務這樣的大型分佈式系統中，“複雜”、“易變”就意味着穩定性的下降和風險的上升。所以根據“80/20法則”，我們進行尺度合理的冷熱數據分離，這是在方案有效性和風險性上進行權衡後的結果。
經過改造，MNS 2.0相比MNS 1.0的吞吐能力提升8倍以上，推送成功率從96%提升到99%+，1K大小服務列表服務發現的平均耗時，從10s降低到1s，TP999從90s下降到10s，整體優化效果非常明顯。
2.3 融入Service Mesh
在MNS 2.0中，我們將代理服務SgAgent部分註冊發現功能合併到了Mesh數據面，其流程如下圖所示：
關於美團服務治理功能與Service Mesh結合的技術細節，這部分的內容，我們今年會單獨做一個專題來進行分享，感興趣的同學可以關注“美團技術團隊”微信公衆號，敬請期待。
2.4 無損遷移
除了上面說到的MNS 2.0的這些重點演進成果之外，我們還想談一下整個命名服務的遷移過程。像MNS這樣涉及多個組件、部署在公司幾十萬個機器節點上、支撐數萬業務系統的大規模分佈式系統，如何進行平滑的數據遷移而不中斷業務正常服務，甚至不讓業務感知到，是MNS 2.0設計的一個重點。圍繞業務服務無感知、具備快速回滾能力、新/老體系互備數據不丟失等要求，我們設計瞭如下圖所示的遷移流程：
MNS 2.0整體以服務爲粒度進行遷移操作，設置標誌位說明服務所處的狀態，由接入代理層組件識別該標誌做出相應的處理。標誌位包括：
-
未遷移標誌：服務註冊/發現走MNS 1.0的流程，註冊信息存儲到重構前的MNS-ZK中。
-
遷移中標誌：服務註冊並行走MNS 1.0和MNS 2.0流程，數據同時寫入新舊兩個地方，服務發現執行MNS 2.0流程。
-
已遷移標誌：服務註冊/發現全部走MNS 2.0流程，註冊信息僅存儲到MNS 2.0的數據層。該階段無法進行平滑的回滾，是項目長期驗證後最終的遷移狀態。
上述可以總結爲：聚焦單個服務，階段性遷移服務發現流量，從而達到類似系統新功能發佈時“灰度上線”的能力。當然，這個策略還涉及一些細節在其中，比如，分開存儲在雙寫時需要重點去保證異常情況下的最終一致性等等，鑑於篇幅原因，這裏就不詳細展開討論了，而且業界針對這種情況都有一些成熟的做法。
另外，我們通過優化命名服務發佈系統的發版形式，實現自動化的流量灰度策略，降低了人力成本，同時構建了自動化的遷移工具、巡檢工具，高效地進行自動化的數據遷移工作，能夠快速巡檢遷移後的鏈路風險，保障新MNS 2.0的穩定上線。
2.5 演進總結
在美團命名服務這樣的大型分佈式系統優化過程中，具體到架構和功能設計層面，我們也做了不少的權衡和取捨，前面我們也提到，放棄了增量式的精準變動信息推送方式。在考慮性能的前提下，也沒有使用數據多維度營運能力更好的MySQL作爲主要存取介質等等。取捨的核心原則是：改造目標時強調業務收益，落地過程中減少業務感知。
目前，MNS 2.0主要成果如下：
-
重構了5個已有的核心組件，研發了2個全新的系統，完成公司PaaS層數十個服務的功能的適配改造，目前已成功遷移全公司80%以上的服務，且在遷移過程中無重大事故。
-
RTO從數小時降到分鐘級，RPO爲0；全鏈路推送耗時TP999從90s降到了10s，推送成功率從96%提升到99%以上，基本完成了百萬級別服務節點治理能力的建設。
-
集羣數據按照業務線等多維度進行拆分，建立了基於分級染色的SLA指標和定期巡檢機制，同時根據公司實際場景增加了衆多的服務風控審計功能，保障了業務安全。
-
雲原生方面，支持了Service Mesh，註冊發現流程融入了Mesh底層基礎設施。
四、命名服務對業務的賦能
命名服務本身作爲基礎的技術中臺設施，在堅持“以客戶爲中心”，升級自身架構的同時，也從如下幾個方面對美團的多個業務進行賦能。
4.1 單元化&泳道
單元化（SET化）是業界比較流行的容災擴展方案，關於美團單元化的詳細內容，可參考OCTO團隊在本次ArchSummit中的另一個專題分享《SET化技術與美團點評實踐解密》。這裏主要是從命名服務對單元化支撐的角度去解答這個問題。
如上圖所示，業務多種來源的外網流量在通過網關進入內網後，會藉助命名服務提供的能力（SDK/Agent），並按照業務自定義的核心數據維度和機器屬性，給流量打上單元化標籤，然後路由到標籤匹配的下一跳，從而實現了單元間流量隔離。一個單元內部，從服務節點到各種存儲組件，都依賴於命名服務提供的單元識別和路由能力來完成隔離，所以命名服務在單元化中主要起底層支撐的作用。
目前單元化在美團的重點業務，比如外賣、配送已經建設的比較完備，通過一定的單元冗餘度，能在一個單元出現問題時，切換到另一個可用的鏡像單元，顯著提高了業務整體可用性。
接下來，我們再來看一下泳道場景。目前泳道在美團這邊主要用於業務做完代碼UT之後的線下集成測試階段，同時結合容器，實現一個即插即用的上下游調用環境去驗證邏輯。命名服務在其中起到的作用與單元化類似，根據泳道發佈平臺對機器的配置，自動編排上下游的調用關係。如下圖所示：
當下一跳存在泳道節點時，測試流量進入泳道。反之，測試流量回流到主幹。每個節點重複上述過程。
4.2 平滑發佈&彈性伸縮
命名服務另外一個重要場景是服務的平滑發佈，我們與發佈平臺配合，控制發佈流量的自動摘除與恢復，實現服務發佈操作的自動化與透明化。具體流程如下圖所示：
早期的發佈流程，存在異常調用的風險，上線過程中存在一段服務實例不可用的“時間窗口”，此時流量再進入可能導致調用失敗，然後會報錯。爲保證發佈的穩定性，需要操作人員手動進行流量排空，流程上效率低、易出錯，浪費業務團隊的時間。針對這項業務痛點，命名服務向發佈系統提供針對服務實例的流量管控能力，實現進程重啓前自動摘除並清空來源請求，升級完畢後，提供自動流量恢復的平滑發佈功能。智能地解決發版過程中的異常調用問題，提高公司的服務上線效率，降低了業務團隊的運維成本。
彈性伸縮是容器一個很大的賣點。但是在伸縮過程中有很多問題需要考慮，比如擴縮容策略，包括調用親和度配置，路由均衡等等。命名服務和容器化合作，提供業務的上下游調用關係、分組設置信息、容器下線流量無損摘除等服務，同時保障伸縮服務註冊及時、高效。如下圖所示：
4.3 服務數據
MNS服務數據對業務的賦能主要分爲兩個部分，一是將自身運行狀態以業務可理解的SLA暴露出來，方便業務評估命名服務健康狀況。對於命名服務來說，SLA指標主要有推送成功率和推送耗時兩種（其實，推送耗時也可以看做成功率的一個衡量維度，這裏暫時不做太詳細的區分）。
MNS 1.0精準量化運行狀況的困難在於，一方面MNS的發佈/訂閱機制重度依賴ZK，受限於ZK的自身實現和鏈路上衆多不同組件的異構性，及時獲取完整鏈路的推送行爲數據很困難。另一方面，由於節點數衆多，全量採集服務發現數據，對公司的監控上報系統以及採集之後的計算也是很大的負擔。
在MNS 2.0中，我們首先在架構上顯著弱化了ZK的地位，它基本上只作爲一致性通知組件。我們自研的MNS-Control可以充分DIY埋點場景，保證了主要推送行爲抓取的可控性。其次，我們採用了分級採樣計算，在全面梳理了公司現有的服務節點數比例後，將典型的服務列表數劃分爲幾個檔次，比如1000個節點的服務爲一檔，100個又爲一檔，並創建相應的非業務哨兵服務，然後在不同機房選取適量的採樣機器定期註冊+拉取來評估整體的運行情況。這樣既做到了上報量的精簡，又兼顧了上報數據的有效性。詳細操作流程，如下圖所示：
-
控制層週期性修改採樣服務中的服務數據，觸發服務發現的數據推送流程。
-
參與指標統計的機器節點，本地代理進程獲取到註冊信息推送後，上報送達時間到運維平臺並由其寫入存儲層。
-
控制層對數據庫中的數據進行聚合計算，最後上報監控系統展示指標數據。此外，通過與監控團隊合作，解決全量部署的Agent埋點監控問題。
命名服務存儲的服務信息有很高的業務價值，從中可以知道服務的部署情況、發佈頻次以及上下游拓撲信息等等。所以“賦能”的第二個部分在於，藉助這些信息，我們可以挖掘出業務服務部署運維上不合理的地方或風險點，不斷推動優化，從來避免一些不必要的損失。目前已經在推動的項目包括：
-
單進程多端口改造：業務使用這種方式去區分不同的調用端口，從而造成端口資源的浪費，而且調用下游還要感知部署信息，這種機器屬性粒度細節的暴露在雲原生時代是不太恰當的。我們協助業務將調用行爲改成單端口多接口的形式，在協議內部去區分調用邏輯。
-
大服務列表的拆分：隨着業務的發展，單個服務的節點數呈爆發式增長，甚至出現了一個服務有接近7W的節點數的情況，對發佈、監控、服務治理等底層設施產生很大的壓力。我們通過和業務的溝通，發現大列表產生的原因主要有兩點：1. 單機性能不夠，只能以實例抗；2. 服務內容不夠聚焦。換句話說，因爲服務還不夠“微”，所以導致邏輯越來越龐大，有需求的調用方和自身實例相應增加，代碼風險也在增大。因此，我們和業務一起梳理分析架構和調用，將核心共用模塊與業務邏輯羣分拆出來，減少冗餘調用，最終使一些大服務節點數量從數萬降低到數千，實現了數量級的下降。
-
上下游均衡部署：這個比較容易理解，結合調用端與服務端比例、服務方機器性能以及調用失敗率等信息，可以作爲服務業務在各機房間均衡調整機器數量的參考。另一方面，我們也在減少基於就近調用策略的粒度，目前只保留了“同IDC”和“同城”兩種，去掉了之前的“同中心策略”，減輕業務服務部署的心智負擔。後期，隨着機房數量的降低和同地域機房間延時的可控，同城路由可能是最終的方案。
在架構上，MNS 2.0依賴DB和其它一些數倉介質，進行多種維度的數據上卷和下鑽，並結合一些定製的風險策略邏輯去幫助業務發現和規避問題，目前這個事情也在進行中。
五、未來展望
未來，美團命名服務主要會朝兩個方向發展：
-
進一步收集、挖掘服務數據的價值，打造服務數據平臺，賦能業務升級。從單純實現業務註冊發現路由等需求，到通過數據反向推動業務架構流程改造升級，這也是美團核心價值觀“以客戶爲中心”的一種體現。
-
深度結合Service Mesh等雲原生基礎設施的演進。雲原生理念及相關設施架構的快速發展，必然會造成傳統服務治理組件架構上流程的變動，深度擁抱雲原生，並享受基礎功能下沉帶來的“紅利”，是命名服務一個比較確定的方向。
作者簡介
舒超，美團資深技術專家，美團OCTO服務治理團隊研發核心成員。
張翔，美團高級工程師，美團OCTO服務治理團隊研發核心成員。