美團命名服務的挑戰與演進

| 本文根據美團基礎架構部技術專家舒超在2019 ArchSummit（全球架構師峯會）上的演講內容整理而成。

命名服務主要解決微服務拆分後帶來的服務發現、路由隔離等需求，是服務治理的基石。美團命名服務（如下簡稱MNS）做爲服務治理體系OCTO的核心模塊，目前承載美團上萬項服務，日均調用達到萬億級別。爲了更好地支撐美團各項飛速發展的業務，MNS開始從1.0向2.0演進。本文將圍繞本次演進的初衷、實現方案以及落地的效果等方面進行展開，同時本文還介紹了命名服務做爲一個技術中臺組件，對業務的重要價值以及推進業務升級的一些成果。但願本文對你們可以有所啓發。

1、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屬性，在保持架構簡潔、流程清晰的同時，還支持了業務大量迭代的需求，較好地幫助公司業務實現了服務化、標準化的目標。

2、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的演進。

3、MNS 2.0

1.總體架構

MNS 2.0的總體架構自上而下主要分爲四層：

• 業務系統層：這一層與MNS 1.0架構相似，依然是嵌入到業務系統中的SDK或框架，可是再也不感知服務列表和路由計算，從而變得更加的輕薄。
• 代理接入層：這一層主要變化是加入了Service Mesh的Sidecar和MNS-API。前者將命名服務的部分鏈路接入Mesh；後者爲MNS增長了更豐富的HTTP調用，幫助一些沒有使用SDK或框架的業務快速接入到命名服務。整個代理接入層的改造使得MNS對接入業務更加親和。

• 控制服務層：新增註冊中心控制服務，這也是MNS 2.0的核心。主要分爲如下三個模塊：

  • 網關管控模塊：提供集中式的鑑權、限流/熔斷、統計等SOA服務化的管控能力，同時避免海量代理組件直連存儲層。
  • 數據分發模塊：數據的通道，包括註冊數據的上傳、訂閱數據的下發，可進行精細化數據拆分和平行擴展來適配熱點服務。
  • 變動捕獲模塊：服務註冊發現的審計，包括對第三方系統進行事件通知和回調，支持多元化的服務數據營運需求。
  • 另外，控制服務層還包括全鏈路SLA監控等新的子模塊，以及健康檢查Scanner這樣的傳統MNS組件。
• 數據存儲層：咱們進一步豐富了命名服務的存儲和分發介質，提升了數據層的總體性能。主力存儲使用K/V存儲系統（美團Cellar系統）替代MNS-ZK，有效地提升了數據的吞吐能力，支持網絡分區後的數據讀寫以及宕機災備，同時保留ZK作一些輕量級的Notify功能。新增的關係型數據庫和消息隊列（美團Mafka系統），配合控制層的變動捕獲模塊，提供更方便的數據挖掘結構和外部扇出。
• 旁路於上面4層的是外部營運設施，主要是業務端的可視化Portal，用戶能夠在上面對自身服務進行監控和操做，美團的基礎研發部門也能夠在上面進行一些集中式的管控。

綜上所述，MNS 2.0總體架構在兼容1.0的前提下，重點變化是：新增了控制服務層並對底層存儲介質進行拆解。下面，咱們來看一下服務註冊發現功能在MNS 2.0中的實現流程：

1. 服務註冊：代理接入層透傳業務註冊請求，通過控制服務層的管控模塊（Gateway）一系列SOA和審計流程後，寫入註冊數據到存儲層。
2. 數據感知：控制服務監聽數據變更，服務註冊寫入新信息後，分發模塊（Delivery）更新內存中的緩存，數據流通過捕獲模塊（CDC）將註冊信息關係化後存儲到DB。
3. 服務發現：代理層請求通過控制服務的管控模塊（Gateway）效驗後，從分發模塊（Delivery）的緩存中批量獲取服務端註冊信息。Cache Miss場景時從存儲層讀取數據。
4. 外部交互層：外部系統當下經過代理層接入整個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）。

「關注放大」和「級聯放大」自己都是沒法避免的，這是由系統屬性決定，而咱們能作的就是從兩方面去平滑其帶來的影響：

正面提高核心模塊性能，加強吞吐、下降延遲

1. 結構化聚合註冊信息：控制服務的數據分發模塊，在內存中存儲結構化的服務註冊信息，提供批量數據的讀取能力；下降屢次網絡RTT傳輸單個數據以及數據結構轉化帶來的高耗時。

2.高併發的吞吐能力：控制服務經過無鎖編程處理關鍵路徑的競爭問題，藉助應用側協程機制，提供高併發、低延遲的數據分發功能。

1. 與存儲團隊共建，實現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總體以服務爲粒度進行遷移操做，設置標誌位說明服務所處的狀態，由接入代理層組件識別該標誌作出相應的處理。標誌位包括：

1. 未遷移標誌：服務註冊/發現走MNS 1.0的流程，註冊信息存儲到重構前的MNS-ZK中。
2. 遷移中標誌：服務註冊並行走MNS 1.0和MNS 2.0流程，數據同時寫入新舊兩個地方，服務發現執行MNS 2.0流程。
3. 已遷移標誌：服務註冊/發現所有走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、命名服務對業務的賦能

命名服務自己做爲基礎的技術中臺設施，在堅持「以客戶爲中心」，升級自身架構的同時，也從以下幾個方面對美團的多個業務進行賦能。

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和其它一些數倉介質，進行多種維度的數據上卷和下鑽，並結合一些定製的風險策略邏輯去幫助業務發現和規避問題，目前這個事情也在進行中。

5、將來展望

將來，美團命名服務主要會朝兩個方向發展：

• 進一步收集、挖掘服務數據的價值，打造服務數據平臺，賦能業務升級。從單純實現業務註冊發現路由等需求，到經過數據反向推進業務架構流程改造升級，這也是美團核心價值觀「以客戶爲中心」的一種體現。
• 深度結合Service Mesh等雲原生基礎設施的演進。雲原生理念及相關設施架構的快速發展，必然會形成傳統服務治理組件架構上流程的變更，深度擁抱雲原生，並享受基礎功能下沉帶來的「紅利」，是命名服務一個比較肯定的方向。

做者簡介

• 舒超，美團資深技術專家，OCTO服務治理團隊研發核心成員。
• 張翔，美團高級工程師，美團OCTO服務治理團隊研發核心成員。

招聘信息

美團OCTO服務治理團隊誠招C++/Java高級工程師、技術專家。咱們致力於研發公司級、業界領先的基礎架構組件，研發範圍涵蓋分佈式框架、命名服務、Service Mesh等技術領域。歡迎有興趣的同窗投送簡歷至tech@meituan.com（郵件備註：美團OCTO團隊）。

閱讀更多技術文章，請掃碼關注微信公衆號-美團技術團隊！