vivo 海量微服務架構最新實踐
一、vivo 從 0 到 1 的微服務架構工程實踐
1.1 為什么需要微服務及落地挑戰
伴隨業務的高速發展，業務的復雜度越來越高，用戶規模和訪問量也越來越大；項目的迭代速度越來越快，交付效率要求也越來越高。與此同時，服務的集群規模越來越大，部署架構越來越復雜，故障范圍也越來越不可控。此外，突增的業務流量時刻考驗著服務的水平擴容能力，創新業務的快速孵化也對服務的可擴展性提出了更高的要求。想要解決以上問題，業務架構會朝著微服務架構方向演進。
正是在這樣的背景下，vivo于2015年開始微服務架構改造，在落地過程中碰到了以下問題：
一是：服務數量多，配置修改生效、服務發布等變更場景效率低下；
二是：業務鏈路長，高可用保障難，問題與故障定位耗時長，服務的維護成本高；
三是：大量的跨服務通訊，性能和訪問體驗優化提升難度大；
四是：一個業務鏈路涉及大量的上下游團隊，對接溝通的協作成本高；
為了解決以上落地過程中的開發、運維、團隊協作等難題，我們需要建設配套的微服務架構技術體系。
1.2 vivo 微服務架構最佳實踐-架構能力矩陣
建設一套微服務架構技術體系，助力業務又快又好地構建微服務工程，需要哪些技術能力？我們對微服務架構的主要業務場景進行了分析，在業務實踐過程中，微服務主要會涉及同步、異步、定時任務三大核心業務場景。
在同步調用場景：涉及的技術能力主要是RPC框架、注冊中心、服務治理；
在異步調用場景：涉及的技術能力主要是消息中間件；
在定時任務場景：涉及的技術能力主要是分布式任務調度。
除了上面介紹的框架和系統，業務在微服務架構改造過程中，需要的能力全貌是怎樣的？
在深度參與業務微服務架構改造過程中，我們對最佳實踐能力項進行了抽象，從而形成了vivo內部的微服務架構最佳實踐總結-架構能力矩陣，總計近30項能力。為了更直觀的呈現這些能力，我們從接入層、服務層、數據層的三層架構分層，開發、運維等DevOps的關鍵環節對架構能力進行了梳理，如下圖所示。
圖片
在開發環節：
在開發接口時，我們要實現內外網接口分離，保障接口的安全性，為此我們要接入網關來隔離內外網接口；在接入層和服務層，我們可以通過治理平臺來實現限流、熔斷、降級等能力，保障業務的高可用。
在構建內部服務時，我們要盡可能實現服務無狀態，通過RPC框架實現內部接口的RPC相互調用，具備異常重試能力，提升服務的魯棒性；在編碼過程中，我們通過接入配置中心實現代碼與配置分離，具備運行時動態調整配置的能力，提高服務的變更效率。
在異步調用場景，我們可以通過接入消息中間件實現業務間的相互解耦、流量削峰；在定時任務場景，我們可以通過分布式任務調度系統，實現失敗任務的自動轉移能力。
此外，我們可以通過落地存儲與計算分離能力，實現服務層和數據層的解耦，便于分層擴容，具備面向未來更大規模業務的擴展能力。
在數據層，通過落地讀寫分離、冷熱分離等能力，提升系統性能，節省存儲成本；同時將這些能力通過研發框架進行封裝，便于業務側復用。
在運維環節：
我們可以借助CDN實現網站的動靜分離訪問，減小系統的請求壓力；在日常運維過程中，我們要實現服務的可灰度、可回滾；服務節點無單點；同時借助容器技術快速實現彈性伸縮能力；提升系統的故障恢復速度。
在部署時，通過部署與發布分離，可以較好規避發布變更時產生的問題，即服務部署成功，并且健康檢查通過后再發布到生產環境，減小故障的影響范圍。
在遇到嚴重的系統故障時，需要具備使用備份數據從零恢復的能力，同時對所有已知的故障場景要有對應的預案，提升系統的故障應對能力。
在數據運維上，我們要確保數據屬主唯一，避免多個業務對同一個數據庫進行訪問；同時也要實現業務數據和大數據的存儲隔離，避免相互影響。
除了以上能力之外，我們還要實現業務的安全合規，建設覆蓋Metric、Trace、Log的可觀測能力體系，便于對故障問題的定位排查；在多機房層面，需要具備同城雙活、異地多活等跨機房容災能力。
1.3 vivo 微服務平臺能力
為了更好落地以上最佳實踐，我們構建了一套從接入層、服務層、消息層、框架層到存儲層的平臺能力，完整的平臺能力地圖如下圖所示：
在接入層，我們提供了四層流量網關和七層微服務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個頁面上。
基于埋點數據，我們可以看到用戶的訪問集中在少數的幾個功能上，通過整合各個系統模塊高頻使用的功能，建設統一的平臺入口，實現系統間聯動，這也給我們如何建設統一平臺提供了較好的思路。
此外，在對各個模塊的技術架構進行分析時，我們識別到了位于最底層、技術依賴程度最高的兩個系統：配置中心、注冊中心，這兩個系統非常適合作為統一平臺建設的技術底座。
區別于煙囪式微服務平臺的多個系統模塊獨立對接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年首次出現，于2022年在國內興起。平臺工程的定義是，一套用來構建和運營支持軟件交付和生命周期管理的自助式內部開發者平臺的機制和架構；它的特點是：平臺在演進中提供足夠的透明度、敏捷性，在建設過程中形成適合業務架構的高效協作模式。在這一過程中逐步將知識體系固化到平臺中，從而使得工程方式標準化、流程化和規模化并持續改善；它踐行的理念是：一個可用的、高效的平臺并非一個技術團隊埋頭苦干就可以產出的；恰恰相反，一個成功的平臺工程需要企業各個組織部門合作、協調、推廣并根據實際使用反饋不斷迭代。
在具體實踐中，平臺工程約定了“業務團隊”和“平臺團隊”兩個團隊，其中“業務團隊”負責業務研發，“平臺團隊”負責平臺建設；“平臺團隊”通過將技術知識沉淀到“平臺工程”，隱藏和抽象底層基礎設施的復雜性，實現基礎設施即代碼，為“業務團隊”賦能增效；同時，基于“業務團隊”在使用“平臺工程”的過程中的不斷反饋來持續改進平臺的自助化產品能力，構建一整套覆蓋DevOps全鏈路的簡單易用平臺產品；可以看到，平臺工程是一種最佳實踐，和我們當前的團隊協作模式匹配度非常高。
在平臺建設的整體規劃上：
當前階段：我們構建的統一微服務平臺會持續探索“平臺工程”理念，沉淀配置中心、注冊中心等平臺的技術知識與最佳實踐，構建和打磨業務自助化使用的平臺能力。
展望未來：我們會通過明確的北極星指標，牽引平臺提供更高的研發效率和更好的開發者體驗。
在研發效率上，我們追求單位時間內更多的代碼產出和需求交付；此外我們也追求更好的開發者體驗，通過降低用戶使用平臺的打斷次數和平臺問題的人工支撐次數，提升業務團隊和平臺團隊兩個團隊的開發體驗。
在具體的落地路徑上，我們始終以開發者用戶為中心，針對研發工作中時間消耗較多的場景進行優化，通過北極星指標牽引，形成覆蓋 IDE+PaaS 的平臺工程實踐路徑，持續迭代優化平臺能力，提升研發效率與開發者體驗。
