作者：來自 vivo 網際網路中介軟體團隊

本文根據羅亮老師在“2023 vivo開發者大會"現場演講內容整理而成。公眾號回覆【2023 VDC】獲取網際網路技術分會場議題相關資料。

vivo微服務平臺為全球5億+使用者背後的全網十萬級機器、萬級微服務提供服務，在高效實踐過程中，vivo中介軟體平臺團隊輸出了一套業務適用的微服務架構最jia實踐--架構能力矩陣、高效的開源中介軟體元件全生命週期管理策略，走出了一條從開源到開源+自研的技術演進路徑，透過微服務引擎升級和統一平臺建設較好解決了面臨的問題與挑戰。

一、vivo 從 0 到 1 的微服務架構工程實踐

1.1 為什麼需要微服務及落地挑戰

伴隨業務的高速發展，業務的複雜度越來越高，使用者規模和訪問量也越來越大；專案的迭代速度越來越快，交付效率要求也越來越高。與此同時，服務的叢集規模越來越大，部署架構越來越複雜，故障範圍也越來越不可控。此外，突增的業務流量時刻考驗著服務的水平擴容能力，創新業務的快速孵化也對服務的可擴充套件性提出了更高的要求。想要解決以上問題，業務架構會朝著微服務架構方向演進。

正是在這樣的背景下，vivo於2015年開始微服務架構改造，在落地過程中碰到了以下問題：

一是：服務數量多，配置修改生效、服務釋出等變更場景效率低下；

二是：業務鏈路長，高可用保障難，問題與故障定位耗時長，服務的維護成本高；

三是：大量的跨服務通訊，效能和訪問體驗最佳化提升難度大；

四是：一個業務鏈路涉及大量的上下游團隊，對接溝通的協作成本高；

為了解決以上落地過程中的開發、運維、團隊協作等難題，我們需要建設配套的微服務架構技術體系。

1.2 vivo 微服務架構最jia實踐-架構能力矩陣

建設一套微服務架構技術體系，助力業務又快又好地構建微服務工程，需要哪些技術能力？我們對微服務架構的主要業務場景進行了分析，在業務實踐過程中，微服務主要會涉及同步、非同步、定時任務三大核心業務場景。

在 同步呼叫場景：涉及的技術能力主要是RPC框架、註冊中心、服務治理；

在 非同步呼叫場景：涉及的技術能力主要是訊息中介軟體；

在 定時任務場景：涉及的技術能力主要是分散式任務排程。

除了上面介紹的框架和系統，業務在微服務架構改造過程中，需要的能力全貌是怎樣的？

在深度參與業務微服務架構改造過程中，我們對最jia實踐能力項進行了抽象，從而形成了vivo內部的微服務架構最jia實踐總結-架構能力矩陣，總計近30項能力。為了更直觀的呈現這些能力，我們從接入層、服務層、資料層的三層架構分層，開發、運維等DevOps的關鍵環節對架構能力進行了梳理，如下圖所示。

在開發環節：

在開發介面時，我們要實現內外網介面分離，保障介面的安全性，為此我們要接入閘道器來隔離內外網介面；在接入層和服務層，我們可以透過治理平臺來實現限流、熔斷、降級等能力，保障業務的高可用。
在構建內部服務時，我們要儘可能實現服務無狀態，透過RPC框架實現內部介面的RPC相互呼叫，具備異常重試能力，提升服務的魯棒性；在編碼過程中，我們透過接入配置中心實現程式碼與配置分離，具備執行時動態調整配置的能力，提高服務的變更效率。
在非同步呼叫場景，我們可以透過接入訊息中介軟體實現業務間的相互解耦、流量削峰；在定時任務場景，我們可以透過分散式任務排程系統，實現失敗任務的自動轉移能力。
此外，我們可以透過落地儲存與計算分離能力，實現服務層和資料層的解耦，便於分層擴容，具備面向未來更大規模業務的擴充套件能力。
在資料層，透過落地讀寫分離、冷熱分離等能力，提升系統效能，節省儲存成本；同時將這些能力透過研發框架進行封裝，便於業務側複用。

在運維環節：

我們可以藉助CDN實現網站的動靜分離訪問，減小系統的請求壓力；在日常運維過程中，我們要實現服務的可灰度、可回滾；服務節點無單點；同時藉助容器技術快速實現彈性伸縮能力；提升系統的故障恢復速度。
在部署時，透過部署與釋出分離，可以較好規避釋出變更時產生的問題，即服務部署成功，並且健康檢查透過後再發布到生產環境，減小故障的影響範圍。
在遇到嚴重的系統故障時，需要具備使用備份資料從零恢復的能力，同時對所有已知的故障場景要有對應的預案，提升系統的故障應對能力。
在資料運維上，我們要確保資料屬主唯yi，避免多個業務對同一個資料庫進行訪問；同時也要實現業務資料和大資料的儲存隔離，避免相互影響。

除了以上能力之外，我們還要實現業務的安全合規，建設覆蓋Metric、Trace、Log的可觀測能力體系，便於對故障問題的定位排查；在多機房層面，需要具備同城雙活、異地多活等跨機房容災能力。

1.3 vivo 微服務平臺能力

為了更好落地以上最jia實踐，我們構建了一套從接入層、服務層、訊息層、框架層到儲存層的平臺能力，完整的平臺能力地圖如下圖所示：

在 接入層，我們提供了四層流量閘道器和七層微服務API閘道器；在服務層提供了服務/流量治理平臺、配置中心、註冊中心、介面管理平臺、分散式任務排程等系統。

在 訊息層提供了訊息中介軟體；在框架層提供了腳手架，可快速整合日誌、配置、限流/熔斷、MySQL/Redis等SDK，以及RPC框架。

在 儲存層提供了DaaS平臺，包含MySQL、Redis、ElasticSearch、MongoDB、檔案服務等系統能力。

為了更好排查故障問題，我們在可觀測領域構建了監控中心、日誌中心、呼叫鏈等系統；此外，還有更好支撐服務構建、變更釋出的CICD系統和IT基礎設施的配置管理系統CMDB。

截止2019年，vivo基本完成了從0到1的微服務平臺能力煙囪式建設。

快速構建這些能力的過程，離不開開源元件的賦能。例如微服務API閘道器背後的zuul，註冊中心背後的ZooKeeper和etcd，RPC框架的Dubbo和bRPC；配置中心的Apollo和Nacos，流量治理的hystrix和sentinel，訊息中介軟體的RabbitMQ和RocketMQ，任務排程的xxl-job；如下圖所示。

在此，我們也透過VDC(vivo 開發者大會)平臺，感謝開源社群的賦能，助力vivo微服務架構技術體系從0到1的快速構建。

1.4 vivo 微服務現狀

截止當前，vivo的微服務平臺為全球分佈在60+個國家/地區的5億+使用者提供服務；其中vivo現有萬級的微服務，覆蓋全網機器規模十萬級，每天處理高達8000億次的RPC呼叫次數，流量的峰值QPS達到千萬級以上。

在支撐如此規模的微服務過程中，特別是在2020年以後，我們碰到了較多的問題與挑戰，為了解決這些問題，我們使用了微服務引擎升級和統一平臺建設的解決方案；下面來一起看看我們碰到了哪些問題與挑戰？

二、微服務引擎升級與統一平臺建設

2.1 面臨的問題與挑戰

我們知道，註冊中心和配置中心是微服務架構領域的技術基石；下面給大家說明下我們在這兩個基石系統實踐過程中遇到的 問題與挑戰：

首先是註冊中心，眾所周知，ZK是CP特性，在註冊中心場景有較多不可用的問題，此外還有跨機房多活能力缺失，叢集故障半徑大等問題；寫效能無法水平擴充套件，在大規模Dubbo服務場景中，介面級註冊模型註冊的資料量大，在業務高頻變更期間網路卡的頻寬峰值會超過1000Gbps。此外還有業務易混用，功能缺失；內部的多個技術棧使用不同的註冊中心，跨技術棧呼叫的研發運維成本高等問題。

在配置中心場景，存在應用、元件配置的變更通道不統一，故障場景配置回滾慢，變更審計日誌分散，業務恢復耗時長等問題；配置變更下發的時效不滿足業務要求，內部存在多套配置中心，都需要和業務研發流程打通，存在審批、審計、回滾等功能沒有對齊的問題；此外在功能和安全上，還需要實現內部的配置定時生效，配置加解密等需求，配置訪問通道符合公司的安全要求。

從以上的問題與挑戰中可以看出，基於開源元件快速構建的微服務底層引擎在vivo的內部業務場景中存在較多的可用性、效能&容量、研發運維、功能&安全問題與挑戰。

2.2 註冊中心引擎升級

為了解決以上的問題與挑戰，我們需要進行技術升級，首先給大家介紹的是註冊中心的 解決方案：

針對Dubbo介面級服務發現導致ZK註冊中心流量過大的問題，業界同行都在往應用級服務發現遷移來構建解決方案；透過Dubbo開源社群官網的介紹，我們可以看到，應用級服務發現是適應雲原生，支援更大規模的服務發現模型；

將Dubbo介面級服務發現模型升級為應用級，可降低單機50%的記憶體消耗，降低註冊中心叢集90%的儲存與推送壓力，從架構上支援百萬例項叢集規模；

因此我們需要將Dubbo框架服務發現模型從介面級升級為應用級，徹底解決註冊資料量大，對註冊中心請求壓力大的問題，同時具備面向雲原生微服務架構的擴充套件能力。

此外，針對註冊中心的可用性、效能&容量、研發運維等問題，我們需要建設滿足AP特性、支援跨機房多活的統一註冊中心，使用Session+Data分離架構，Data層持久化資料，Session層處理和客戶端的長連線，無狀態Session層能較好收斂客戶端請求，實現讀寫流量隔離，具備較好的橫向擴充套件能力，真正解決註冊中心的效能、容量和擴充套件性問題。

綜上，我們需要構建Dubbo應用級服務發現能力，構建Session+Data分離的統一註冊中心，內部的專案代號為vns。

從上面的技術方案分析中，我們可以看到，透過應用級註冊可以徹底解決註冊中心的流量突刺問題；透過Session+Data雙層分離架構可以實現業務無感知的多叢集拆分，有效縮小故障半徑，那如何來落地呢？

我們首先想到的就是上圖左側的技術方案，透過構建暴露gRPC協議、支援應用級註冊的vns系統，海量的Dubbo服務透過雙註冊來實現遷移；但是在經過詳細的技術分析之後，我們發現該方案存在明顯的 耦合問題：

首先是Dubbo應用級註冊升級的進展依賴vns系統的建設進度，Dubbo框架依賴穩定的vns SDK，Dubbo框架和vns系統之間存在進度依賴問題；

其次還存在回滾依賴問題，當vns系統因灰度異常回滾時，Dubbo應用級註冊升級進度也會同步回滾；

同理當Dubbo流量切換異常回滾時，vns的業務接入進度也會回退。

此外，部分不迭代的業務可能需要繼續使用介面級註冊，無法實現ZK註冊中心的完全下線。

為了解決以上問題，我們對技術方案進行了升級，改用透過vns系統暴露和支援ZK協議，實現Dubbo應用級註冊升級和vns系統的能力建設解耦；當vns系統的能力建設進展還未達到生產環境要求時，我們可以透過引入一套新的ZK叢集來支援Dubbo的應用級註冊模型升級；當vns的能力成熟度達到生產環境的要求後，可以對引入的ZK叢集進行替代，整個過程可以根據系統建設進展和可用性保障要求，進行可控的灰度放量和回滾操作，控制變更風險；最終，vns透過暴露ZK+gRPC雙協議滿足業務的接入訴求。

在整個技術方案落地過程中，我們始終堅持業務導向原則，實現業務升級和遷移的零|低成本；採用穩妥、完善的升級遷移方案，確保過程可灰度、可回滾、可觀測；大家可以看到，我們透過相容ZK協議，最大限度的保障Dubbo業務的平滑升級，切換方案做到了可灰度可回滾可觀測，在減少升級成本的同時，降低專案落地風險，最終實現ZK註冊中心的完全下線。

2.3 配置中心引擎升級

介紹完註冊中心，我們再來看看配置中心的解決方案，配置中心主要解決的是配置通道不統一，效能不達標，無法滿足內部的業務需求等問題。

上圖左側是我們最新的配置中心技術架構圖，右側是統一配置通道的示意圖，我們透過支援應用配置與元件配置的統一配置通道，實現了配置管理能力的收斂統一，在此基礎上，建設一鍵審批/審計/回滾等能力，實現了和內部業務研發流程的打通，減少人力運維投入；此外，在新版配置中心上，我們也實現了較多的高可用、效能、安全、可觀測能力增強等業務訴求；在配置中心升級過程中，我們追求業務的無感知升級，透過相容原有配置中心對外開放的介面，實現了新系統的平滑升級，原有系統優雅下線。

大家可以看到，和註冊中心的升級方案類似，在配置中心的技術方案設計中，我們也較好的遵循了業務導向原則。

2.4 統一微服務平臺建設

介紹完註冊中心和配置中心等微服務引擎的技術升級方案，我們再來看下從0到1快速構建的煙囪式微服務平臺會面臨哪些問題和挑戰？

從上圖左側示意圖中可以看到，我們快速構建的微服務平臺存在10個以上的模組，每個模組都有獨立的入口，使用者使用平臺的易用性很低；此外，這些模組在建設過程中，還需要重複對接雲平臺、單點登入、許可權、工單、監控、CMDB等公共服務系統；系統審計日誌分散，不便於快速定位因變更引起的問題；綜上，煙囪式微服務平臺存在多入口，功能重複對接，運維、研發成本高，故障排查與恢復效率低，易用性不足等問題。

要解決煙囪式微服務平臺的問題，需要構建更合理的產品方案，我們對使用者的使用現狀進行了分析：

透過系統埋點資料發現，煙囪式微服務平臺中使用者使用頻率最高的兩個系統分別是配置中心、服務治理。

透過上圖左側的PV/UV餅狀圖資料，大家可以發現：

配置中心的使用者訪問主要集中在配置的【查詢與變更】、【變更記錄與審批】和配置變更相關的2個頁面上，服務治理的使用者訪問主要集中在【服務概覽】、【服務查詢】和服務相關的2個頁面上。

基於埋點資料，我們可以看到使用者的訪問集中在少數的幾個功能上，透過整合各個系統模組高頻使用的功能，建設統一的平臺入口，實現系統間聯動，這也給我們如何建設統一平臺提供了較好的思路。

此外，在對各個模組的技術架構進行分析時，我們識別到了位於zui底層、技術依賴程度最高的兩個系統：配置中心、註冊中心，這兩個系統非常適合作為統一平臺建設的技術底座。

區別於煙囪式微服務平臺的多個系統模組獨立對接CICD等研發平臺，在統一微服務平臺建設中，我們升級為統一平臺對接CICD等研發平臺；我們的建設思路是，以配置中心/註冊中心為底座來建設統一微服務平臺：

一是：基於統一的配置通道與CICD等研發平臺系統進行聯動，建設一鍵審批、回滾能力，整合研發流程，降低對接成本；

二是：透過統一平臺的建設，實現平臺間聯動，建設高階的自動化水平，支撐業務進一步提升持續服務能力。

2.5 引擎升級&統一平臺建設總結

接下來，對我們前面講到的內容做一個總結：在大規模、海量業務的微服務架構實踐過程中，我們透過引擎升級和統一平臺能力建設較好的解決了碰到的問題與挑戰。

在升級和建設過程中，我們需要保證現有業務的連續性，保障不發生因底層引擎升級和平臺建設導致的可用性問題。因此，引擎升級和統一平臺建設的工作需要建立在高可用保障的基礎上；換句話來說，可用性是我們所有工作的底座。

在這個基礎上，我們實現註冊中心和配置中心的引擎升級，完成應用級註冊模型升級；在這個過程中，解決底層引擎的擴充套件性、容量、效能、可維護性和安全性等問題；最後，我們要建設統一的微服務平臺能力，實現平臺間聯動，構建自動/自助化使用能力；賦能業務。

大家可以看到，透過完整的方案介紹，在上圖右側我們呈現了微服務架構實踐過程中的價值分層邏輯，即在可用性的基礎上，提升系統的擴充套件性、容量、效能、可維護、安全性等能力；然後再在此基礎上，交付更高的研發效率，更好的使用者使用體驗。

三、微服務架構升級的總結與展望

介紹完我們的解決方案後，最後來說明下我們對微服務架構升級的總結與思考，以及對未來的展望。

3.1 擁抱開源的實用主義

在構建微服務架構技術體系的過程中，我們始終堅持擁抱開源，迭代業務適用的技術平臺；結合內部業務的實際情況，我們走出了一條從開源到開源+自研的研發路徑。

在從0到1的平臺能力建設過程中，我們引入開源元件進行能力快速構建，快速交付滿足業務的需求；始終堅持業務適用原則，不過度設計，支撐業務的快速迭代；以上階段，我們稱之為“拿來主義”。

在面向更大規模、海量業務實踐過程中，為了解決碰到的問題與挑戰，我們在開源的基礎上進行增強，自研部分能力來解決億級使用者規模下內部業務的功能，效能，容量，研發流程打通等需求；這個階段，我們稱之為“實用主義”。

在技術平臺迭代過程中，我們始終堅持2個原則，一是簡單有效原則，堅持用最簡單的解決方案來解決問題；二是迭代和演進原則，堅持平臺持續迭代和演進的原則；前期基於開源元件快速搭建能力，再基於實際的業務需求和痛點來落地自研架構；在這個過程中，始終堅持業務適用，不為了技術而技術，避免大而全的技術架構。

此外，也要說明一個常見的誤區，我們為什麼不完全自研？vivo的微服務平臺建設從開源社群獲益良多，堅持不閉門造車，站在巨人肩膀上，持續引入優秀特性來支撐業務的快速發展，同時也會考慮將部分行業適用的通用優秀特性反饋給社群，和社群共同成長。

3.2 中介軟體元件全生命週期管理

大家可以看到，vivo的微服務架構技術體系引入了較多的開源元件，在實踐過程中，我們摸索出了一套完整的中介軟體元件全生命週期管理策略。

我們先來看看業務的訴求和底層技術的特點：

首先是業務的訴求：

業務期望更高的迭代交付效率；
快速引入新技術，使用新技術助力業務創新，但很多時候新技術往往意味著成熟度不足，可能存在較多問題；
業務的不斷創新與發展，對元件的效能、容量要求越來越高；

對業務來說，高效迭代交付需求是第一位的。

然而，底層技術有它自己的特點：

技術的發展有它的客觀規律，需要經歷萌芽期 → 膨脹期 → 低谷期→ 復甦期→ 成熟期等多個階段；
缺乏約束的技術體系必然隨著時間推移而腐化，治理不及時會成為技術債務，阻塞業務發展；
同類中介軟體元件的快速引入會有重複建設的效率問題；
中介軟體元件的技術升級週期客觀上都比較長。

實踐證明，只有足夠穩健的底層技術能力才能更好支撐業務的高效迭代。在這個過程中，如何兼顧效率與質量？尊重客觀規律，確保整個過程都有明確的目標和方向，避免走偏，慢就是快。

我們認為，完善的中介軟體元件全生命週期管理策略，首先需要在所有的技術團隊中形成價值共識；再透過元件掃描和元件地圖等手段及時對元件全貌進行洞察；在元件的標準化治理和運營階段實現有規範，補短板；同時在新技術引入時，透過完善的新技術引入規範，覆蓋功能/效能/容量/擴充套件性/成熟度/使用成本等維度；在元件的版本治理上，使用基線版本治理方案，輸出明確的使用標準/版本升級方案/版本收斂策略；最後，在元件的成熟度管理上，我們可以藉助Gartner(高德納)技術成熟度說明和元件能力矩陣，不斷提升元件的成熟度。

綜上，為更高效的支撐業務，在元件管理上我們使用了更加入寬鬆的引入策略，同時也會對元件的全生命週期進行嚴格管理，踐行寬入嚴出策略，透過完善的中介軟體元件全生命週期管理助力業務跑的更快，走的更遠。

3.3 引擎升級探索

展望未來，我們會堅持和踐行引擎升級和平臺建設的 持續迭代思路：

首先是對引擎升級的探索，透過引入新技術來解決當前碰到的研發效率、成本等痛點問題：

在研發效率方向，存在的痛點問題如下：

一是，元件SDK的升級週期長，碎片化問題嚴重；

二是，當前vivo內部主要的是Java、C++技術棧，新業務形態孵化可能會引入新的技術棧，需能夠較好解決跨技術棧的問題。

想要較好的解決以上問題，需要探索基於Java Agent/SideCar技術的標準ServiceMesh模式，將RPC、MQ等中介軟體能力下沉，透明化實現微服務治理、高可用等能力增強，同時元件具備熱升級能力。

此外， 在成本方向，存在的痛點問題如下：

一是， MQ等重資源型應用的CPU、儲存資源利用率差異大；

二是，部分事件驅動場景機器資源利用率低。

要解決以上問題，我們可以透過升級MQ元件，落地存算分離技術，探索計算儲存資源利用率最佳化方案。另外，還可以探索Serverless技術，實現平臺化託管運維，降低資源成本，天然適合小程式、快應用等事件驅動業務場景。

綜上，在引擎升級探索上，我們會基於業務需求和痛點問題，探索和落地ServiceMesh/Serverless/存算分離等雲原生技術。

3.4 平臺建設探索

講完引擎升級探索，我們再來看看在平臺建設上的探索：

作為技術平臺團隊，我們在持續積極的探索“平臺工程”理念，從現在的DevOps實踐到平臺工程，也是團隊協作理念的再次升級。

我們知道，DevOps於2009年出現，2015年在國內火起來，它是一種文化、方法論，是敏捷理念從開發到運維的延伸。DevOps的理念是：踐行誰構建誰執行，開發運維一體化，實現業務的高效交付。

但是，DevOps在實際落地過程中存在以下問題：

“DevOps團隊”的中心化與去中心化取捨問題

【 中心化】指的是，獨立的DevOps團隊，即不在業務團隊中配置DevOps能力，而把DevOps人員集中起來組建團隊，這種完全中心化的模式本質上和DevOps文化相矛盾。同時根據康威定律，可能會製造新的效能瓶頸。“獨立的DevOps團隊”在2014年被Thoughtworks“技術雷達”列為Hold (停止採用)。
【 去中心化】指的是，將DevOps能力分散在業務團隊，這種做法會將大量的和基礎設施相關的工作職責劃給業務團隊；這種方式會隨之出現基礎設施和服務治理缺失、系統穩定性降低、研發和DevOps效能浪費等諸多問題。

因此，想要踐行好DevOps，必須在中心化與去中心化之間取得平衡。

此外，從平臺能力上講，DevOps平臺往往更側重於建設流程和工具鏈，而在使用這些建設的工具技術平臺過程中會大大增加業務開發團隊的認知負荷，存在無法較好向業務開發團隊遮蔽底層基礎設施複雜性的問題。

平臺工程的概念，是在2017年首ci出現，於2022年在國內興起。平臺工程的定義是，一套用來構建和運營支援軟體交付和生命週期管理的自助式內部開發者平臺的機制和架構；它的特點是：平臺在演進中提供足夠的透明度、敏捷性，在建設過程中形成適合業務架構的高效協作模式。在這一過程中逐步將知識體系固化到平臺中，從而使得工程方式標準化、流程化和規模化並持續改善；它踐行的理念是：一個可用的、高效的平臺並非一個技術團隊埋頭苦幹就可以產出的；恰恰相反，一個成功的平臺工程需要企業各個組織部門合作、協調、推廣並根據實際使用反饋不斷迭代。

在具體實踐中，平臺工程約定了“業務團隊”和“平臺團隊”兩個團隊，其中“業務團隊”負責業務研發，“平臺團隊”負責平臺建設；“平臺團隊”透過將技術知識沉澱到“平臺工程”，隱藏和抽象底層基礎設施的複雜性，實現基礎設施即程式碼，為“業務團隊”賦能增效；同時，基於“業務團隊”在使用“平臺工程”的過程中的不斷反饋來持續改進平臺的自助化產品能力，構建一整套覆蓋DevOps全鏈路的簡單易用平臺產品；可以看到，平臺工程是一種最jia實踐，和我們當前的團隊協作模式匹配度非常高。

在平臺建設的整體規劃上：

當前階段：我們構建的統一微服務平臺會持續探索“平臺工程”理念，沉澱配置中心、註冊中心等平臺的技術知識與最jia實踐，構建和打磨業務自助化使用的平臺能力。

展望未來：我們會透過明確的北極星指標，牽引平臺提供更高的研發效率和更好的開發者體驗。

在研發效率上，我們追求單位時間內更多的程式碼產出和需求交付；此外我們也追求更好的開發者體驗，透過降低使用者使用平臺的打斷次數和平臺問題的人工支撐次數，提升業務團隊和平臺團隊兩個團隊的開發體驗。

在具體的落地路徑上，我們始終以開發者使用者為中心，針對研發工作中時間消耗較多的場景進行最佳化，透過北極星指標牽引，形成覆蓋 IDE+PaaS 的平臺工程實踐路徑，持續迭代最佳化平臺能力，提升研發效率與開發者體驗。

vivo 海量微服務架構最新實踐