vivo 海量微服務(wù)架構(gòu)最新實(shí)踐
一、vivo 從 0 到 1 的微服務(wù)架構(gòu)工程實(shí)踐
1.1 為什么需要微服務(wù)及落地挑戰(zhàn)
伴隨業(yè)務(wù)的高速發(fā)展，業(yè)務(wù)的復(fù)雜度越來越高，用戶規(guī)模和訪問量也越來越大；項(xiàng)目的迭代速度越來越快，交付效率要求也越來越高。與此同時(shí)，服務(wù)的集群規(guī)模越來越大，部署架構(gòu)越來越復(fù)雜，故障范圍也越來越不可控。此外，突增的業(yè)務(wù)流量時(shí)刻考驗(yàn)著服務(wù)的水平擴(kuò)容能力，創(chuàng)新業(yè)務(wù)的快速孵化也對服務(wù)的可擴(kuò)展性提出了更高的要求。想要解決以上問題，業(yè)務(wù)架構(gòu)會朝著微服務(wù)架構(gòu)方向演進(jìn)。
正是在這樣的背景下，vivo于2015年開始微服務(wù)架構(gòu)改造，在落地過程中碰到了以下問題：
一是：服務(wù)數(shù)量多，配置修改生效、服務(wù)發(fā)布等變更場景效率低下；
二是：業(yè)務(wù)鏈路長，高可用保障難，問題與故障定位耗時(shí)長，服務(wù)的維護(hù)成本高；
三是：大量的跨服務(wù)通訊，性能和訪問體驗(yàn)優(yōu)化提升難度大；
四是：一個(gè)業(yè)務(wù)鏈路涉及大量的上下游團(tuán)隊(duì)，對接溝通的協(xié)作成本高；
為了解決以上落地過程中的開發(fā)、運(yùn)維、團(tuán)隊(duì)協(xié)作等難題，我們需要建設(shè)配套的微服務(wù)架構(gòu)技術(shù)體系。
1.2 vivo 微服務(wù)架構(gòu)最佳實(shí)踐-架構(gòu)能力矩陣
建設(shè)一套微服務(wù)架構(gòu)技術(shù)體系，助力業(yè)務(wù)又快又好地構(gòu)建微服務(wù)工程，需要哪些技術(shù)能力？我們對微服務(wù)架構(gòu)的主要業(yè)務(wù)場景進(jìn)行了分析，在業(yè)務(wù)實(shí)踐過程中，微服務(wù)主要會涉及同步、異步、定時(shí)任務(wù)三大核心業(yè)務(wù)場景。
在同步調(diào)用場景：涉及的技術(shù)能力主要是RPC框架、注冊中心、服務(wù)治理；
在異步調(diào)用場景：涉及的技術(shù)能力主要是消息中間件；
在定時(shí)任務(wù)場景：涉及的技術(shù)能力主要是分布式任務(wù)調(diào)度。
除了上面介紹的框架和系統(tǒng)，業(yè)務(wù)在微服務(wù)架構(gòu)改造過程中，需要的能力全貌是怎樣的？
在深度參與業(yè)務(wù)微服務(wù)架構(gòu)改造過程中，我們對最佳實(shí)踐能力項(xiàng)進(jìn)行了抽象，從而形成了vivo內(nèi)部的微服務(wù)架構(gòu)最佳實(shí)踐總結(jié)-架構(gòu)能力矩陣，總計(jì)近30項(xiàng)能力。為了更直觀的呈現(xiàn)這些能力，我們從接入層、服務(wù)層、數(shù)據(jù)層的三層架構(gòu)分層，開發(fā)、運(yùn)維等DevOps的關(guān)鍵環(huán)節(jié)對架構(gòu)能力進(jìn)行了梳理，如下圖所示。
圖片
在開發(fā)環(huán)節(jié)：
在開發(fā)接口時(shí)，我們要實(shí)現(xiàn)內(nèi)外網(wǎng)接口分離，保障接口的安全性，為此我們要接入網(wǎng)關(guān)來隔離內(nèi)外網(wǎng)接口；在接入層和服務(wù)層，我們可以通過治理平臺來實(shí)現(xiàn)限流、熔斷、降級等能力，保障業(yè)務(wù)的高可用。
在構(gòu)建內(nèi)部服務(wù)時(shí)，我們要盡可能實(shí)現(xiàn)服務(wù)無狀態(tài)，通過RPC框架實(shí)現(xiàn)內(nèi)部接口的RPC相互調(diào)用，具備異常重試能力，提升服務(wù)的魯棒性；在編碼過程中，我們通過接入配置中心實(shí)現(xiàn)代碼與配置分離，具備運(yùn)行時(shí)動態(tài)調(diào)整配置的能力，提高服務(wù)的變更效率。
在異步調(diào)用場景，我們可以通過接入消息中間件實(shí)現(xiàn)業(yè)務(wù)間的相互解耦、流量削峰；在定時(shí)任務(wù)場景，我們可以通過分布式任務(wù)調(diào)度系統(tǒng)，實(shí)現(xiàn)失敗任務(wù)的自動轉(zhuǎn)移能力。
此外，我們可以通過落地存儲與計(jì)算分離能力，實(shí)現(xiàn)服務(wù)層和數(shù)據(jù)層的解耦，便于分層擴(kuò)容，具備面向未來更大規(guī)模業(yè)務(wù)的擴(kuò)展能力。
在數(shù)據(jù)層，通過落地讀寫分離、冷熱分離等能力，提升系統(tǒng)性能，節(jié)省存儲成本；同時(shí)將這些能力通過研發(fā)框架進(jìn)行封裝，便于業(yè)務(wù)側(cè)復(fù)用。
在運(yùn)維環(huán)節(jié)：
我們可以借助CDN實(shí)現(xiàn)網(wǎng)站的動靜分離訪問，減小系統(tǒng)的請求壓力；在日常運(yùn)維過程中，我們要實(shí)現(xiàn)服務(wù)的可灰度、可回滾；服務(wù)節(jié)點(diǎn)無單點(diǎn)；同時(shí)借助容器技術(shù)快速實(shí)現(xiàn)彈性伸縮能力；提升系統(tǒng)的故障恢復(fù)速度。
在部署時(shí)，通過部署與發(fā)布分離，可以較好規(guī)避發(fā)布變更時(shí)產(chǎn)生的問題，即服務(wù)部署成功，并且健康檢查通過后再發(fā)布到生產(chǎn)環(huán)境，減小故障的影響范圍。
在遇到嚴(yán)重的系統(tǒng)故障時(shí)，需要具備使用備份數(shù)據(jù)從零恢復(fù)的能力，同時(shí)對所有已知的故障場景要有對應(yīng)的預(yù)案，提升系統(tǒng)的故障應(yīng)對能力。
在數(shù)據(jù)運(yùn)維上，我們要確保數(shù)據(jù)屬主唯一，避免多個(gè)業(yè)務(wù)對同一個(gè)數(shù)據(jù)庫進(jìn)行訪問；同時(shí)也要實(shí)現(xiàn)業(yè)務(wù)數(shù)據(jù)和大數(shù)據(jù)的存儲隔離，避免相互影響。
除了以上能力之外，我們還要實(shí)現(xiàn)業(yè)務(wù)的安全合規(guī)，建設(shè)覆蓋Metric、Trace、Log的可觀測能力體系，便于對故障問題的定位排查；在多機(jī)房層面，需要具備同城雙活、異地多活等跨機(jī)房容災(zāi)能力。
1.3 vivo 微服務(wù)平臺能力
為了更好落地以上最佳實(shí)踐，我們構(gòu)建了一套從接入層、服務(wù)層、消息層、框架層到存儲層的平臺能力，完整的平臺能力地圖如下圖所示：
在接入層，我們提供了四層流量網(wǎng)關(guān)和七層微服務(wù)API網(wǎng)關(guān)；在服務(wù)層提供了服務(wù)/流量治理平臺、配置中心、注冊中心、接口管理平臺、分布式任務(wù)調(diào)度等系統(tǒng)。
在消息層提供了消息中間件；在框架層提供了腳手架，可快速集成日志、配置、限流/熔斷、MySQL/Redis等SDK，以及RPC框架。
在存儲層提供了DaaS平臺，包含MySQL、Redis、ElasticSearch、MongoDB、文件服務(wù)等系統(tǒng)能力。
為了更好排查故障問題，我們在可觀測領(lǐng)域構(gòu)建了監(jiān)控中心、日志中心、調(diào)用鏈等系統(tǒng)；此外，還有更好支撐服務(wù)構(gòu)建、變更發(fā)布的CICD系統(tǒng)和IT基礎(chǔ)設(shè)施的配置管理系統(tǒng)CMDB。
截止2019年，vivo基本完成了從0到1的微服務(wù)平臺能力煙囪式建設(shè)。
快速構(gòu)建這些能力的過程，離不開開源組件的賦能。例如微服務(wù)API網(wǎng)關(guān)背后的zuul，注冊中心背后的ZooKeeper和etcd，RPC框架的Dubbo和bRPC；配置中心的Apollo和Nacos，流量治理的hystrix和sentinel，消息中間件的RabbitMQ和RocketMQ，任務(wù)調(diào)度的xxl-job；如下圖所示。
在此，我們也通過VDC(vivo 開發(fā)者大會)平臺，感謝開源社區(qū)的賦能，助力vivo微服務(wù)架構(gòu)技術(shù)體系從0到1的快速構(gòu)建。
1.4 vivo 微服務(wù)現(xiàn)狀
截止當(dāng)前，vivo的微服務(wù)平臺為全球分布在60+個(gè)國家/地區(qū)的5億+用戶提供服務(wù)；其中vivo現(xiàn)有萬級的微服務(wù)，覆蓋全網(wǎng)機(jī)器規(guī)模十萬級，每天處理高達(dá)8000億次的RPC調(diào)用次數(shù)，流量的峰值QPS達(dá)到千萬級以上。
在支撐如此規(guī)模的微服務(wù)過程中，特別是在2020年以后，我們碰到了較多的問題與挑戰(zhàn)，為了解決這些問題，我們使用了微服務(wù)引擎升級和統(tǒng)一平臺建設(shè)的解決方案；下面來一起看看我們碰到了哪些問題與挑戰(zhàn)？
二、微服務(wù)引擎升級與統(tǒng)一平臺建設(shè)
2.1 面臨的問題與挑戰(zhàn)
我們知道，注冊中心和配置中心是微服務(wù)架構(gòu)領(lǐng)域的技術(shù)基石；下面給大家說明下我們在這兩個(gè)基石系統(tǒng)實(shí)踐過程中遇到的問題與挑戰(zhàn)：
首先是注冊中心，眾所周知，ZK是CP特性，在注冊中心場景有較多不可用的問題，此外還有跨機(jī)房多活能力缺失，集群故障半徑大等問題；寫性能無法水平擴(kuò)展，在大規(guī)模Dubbo服務(wù)場景中，接口級注冊模型注冊的數(shù)據(jù)量大，在業(yè)務(wù)高頻變更期間網(wǎng)卡的帶寬峰值會超過1000Gbps。此外還有業(yè)務(wù)易混用，功能缺失；內(nèi)部的多個(gè)技術(shù)棧使用不同的注冊中心，跨技術(shù)棧調(diào)用的研發(fā)運(yùn)維成本高等問題。
在配置中心場景，存在應(yīng)用、組件配置的變更通道不統(tǒng)一，故障場景配置回滾慢，變更審計(jì)日志分散，業(yè)務(wù)恢復(fù)耗時(shí)長等問題；配置變更下發(fā)的時(shí)效不滿足業(yè)務(wù)要求，內(nèi)部存在多套配置中心，都需要和業(yè)務(wù)研發(fā)流程打通，存在審批、審計(jì)、回滾等功能沒有對齊的問題；此外在功能和安全上，還需要實(shí)現(xiàn)內(nèi)部的配置定時(shí)生效，配置加解密等需求，配置訪問通道符合公司的安全要求。
從以上的問題與挑戰(zhàn)中可以看出，基于開源組件快速構(gòu)建的微服務(wù)底層引擎在vivo的內(nèi)部業(yè)務(wù)場景中存在較多的可用性、性能&容量、研發(fā)運(yùn)維、功能&安全問題與挑戰(zhàn)。
2.2 注冊中心引擎升級
為了解決以上的問題與挑戰(zhàn)，我們需要進(jìn)行技術(shù)升級，首先給大家介紹的是注冊中心的解決方案：
針對Dubbo接口級服務(wù)發(fā)現(xiàn)導(dǎo)致ZK注冊中心流量過大的問題，業(yè)界同行都在往應(yīng)用級服務(wù)發(fā)現(xiàn)遷移來構(gòu)建解決方案；通過Dubbo開源社區(qū)官網(wǎng)的介紹，我們可以看到，應(yīng)用級服務(wù)發(fā)現(xiàn)是適應(yīng)云原生，支持更大規(guī)模的服務(wù)發(fā)現(xiàn)模型；
將Dubbo接口級服務(wù)發(fā)現(xiàn)模型升級為應(yīng)用級，可降低單機(jī)50%的內(nèi)存消耗，降低注冊中心集群90%的存儲與推送壓力，從架構(gòu)上支持百萬實(shí)例集群規(guī)模；
因此我們需要將Dubbo框架服務(wù)發(fā)現(xiàn)模型從接口級升級為應(yīng)用級，徹底解決注冊數(shù)據(jù)量大，對注冊中心請求壓力大的問題，同時(shí)具備面向云原生微服務(wù)架構(gòu)的擴(kuò)展能力。
此外，針對注冊中心的可用性、性能&容量、研發(fā)運(yùn)維等問題，我們需要建設(shè)滿足AP特性、支持跨機(jī)房多活的統(tǒng)一注冊中心，使用Session+Data分離架構(gòu)，Data層持久化數(shù)據(jù)，Session層處理和客戶端的長連接，無狀態(tài)Session層能較好收斂客戶端請求，實(shí)現(xiàn)讀寫流量隔離，具備較好的橫向擴(kuò)展能力，真正解決注冊中心的性能、容量和擴(kuò)展性問題。
綜上，我們需要構(gòu)建Dubbo應(yīng)用級服務(wù)發(fā)現(xiàn)能力，構(gòu)建Session+Data分離的統(tǒng)一注冊中心，內(nèi)部的項(xiàng)目代號為vns。
從上面的技術(shù)方案分析中，我們可以看到，通過應(yīng)用級注冊可以徹底解決注冊中心的流量突刺問題；通過Session+Data雙層分離架構(gòu)可以實(shí)現(xiàn)業(yè)務(wù)無感知的多集群拆分，有效縮小故障半徑，那如何來落地呢？
我們首先想到的就是上圖左側(cè)的技術(shù)方案，通過構(gòu)建暴露gRPC協(xié)議、支持應(yīng)用級注冊的vns系統(tǒng)，海量的Dubbo服務(wù)通過雙注冊來實(shí)現(xiàn)遷移；但是在經(jīng)過詳細(xì)的技術(shù)分析之后，我們發(fā)現(xiàn)該方案存在明顯的耦合問題：
首先是Dubbo應(yīng)用級注冊升級的進(jìn)展依賴vns系統(tǒng)的建設(shè)進(jìn)度，Dubbo框架依賴穩(wěn)定的vns SDK，Dubbo框架和vns系統(tǒng)之間存在進(jìn)度依賴問題；
其次還存在回滾依賴問題，當(dāng)vns系統(tǒng)因灰度異常回滾時(shí)，Dubbo應(yīng)用級注冊升級進(jìn)度也會同步回滾；
同理當(dāng)Dubbo流量切換異?；貪L時(shí)，vns的業(yè)務(wù)接入進(jìn)度也會回退。
此外，部分不迭代的業(yè)務(wù)可能需要繼續(xù)使用接口級注冊，無法實(shí)現(xiàn)ZK注冊中心的完全下線。
為了解決以上問題，我們對技術(shù)方案進(jìn)行了升級，改用通過vns系統(tǒng)暴露和支持ZK協(xié)議，實(shí)現(xiàn)Dubbo應(yīng)用級注冊升級和vns系統(tǒng)的能力建設(shè)解耦；當(dāng)vns系統(tǒng)的能力建設(shè)進(jìn)展還未達(dá)到生產(chǎn)環(huán)境要求時(shí)，我們可以通過引入一套新的ZK集群來支持Dubbo的應(yīng)用級注冊模型升級；當(dāng)vns的能力成熟度達(dá)到生產(chǎn)環(huán)境的要求后，可以對引入的ZK集群進(jìn)行替代，整個(gè)過程可以根據(jù)系統(tǒng)建設(shè)進(jìn)展和可用性保障要求，進(jìn)行可控的灰度放量和回滾操作，控制變更風(fēng)險(xiǎn)；最終，vns通過暴露ZK+gRPC雙協(xié)議滿足業(yè)務(wù)的接入訴求。
在整個(gè)技術(shù)方案落地過程中，我們始終堅(jiān)持業(yè)務(wù)導(dǎo)向原則，實(shí)現(xiàn)業(yè)務(wù)升級和遷移的零|低成本；采用穩(wěn)妥、完善的升級遷移方案，確保過程可灰度、可回滾、可觀測；大家可以看到，我們通過兼容ZK協(xié)議，最大限度的保障Dubbo業(yè)務(wù)的平滑升級，切換方案做到了可灰度可回滾可觀測，在減少升級成本的同時(shí)，降低項(xiàng)目落地風(fēng)險(xiǎn)，最終實(shí)現(xiàn)ZK注冊中心的完全下線。
2.3 配置中心引擎升級
介紹完注冊中心，我們再來看看配置中心的解決方案，配置中心主要解決的是配置通道不統(tǒng)一，性能不達(dá)標(biāo)，無法滿足內(nèi)部的業(yè)務(wù)需求等問題。
上圖左側(cè)是我們最新的配置中心技術(shù)架構(gòu)圖，右側(cè)是統(tǒng)一配置通道的示意圖，我們通過支持應(yīng)用配置與組件配置的統(tǒng)一配置通道，實(shí)現(xiàn)了配置管理能力的收斂統(tǒng)一，在此基礎(chǔ)上，建設(shè)一鍵審批/審計(jì)/回滾等能力，實(shí)現(xiàn)了和內(nèi)部業(yè)務(wù)研發(fā)流程的打通，減少人力運(yùn)維投入；此外，在新版配置中心上，我們也實(shí)現(xiàn)了較多的高可用、性能、安全、可觀測能力增強(qiáng)等業(yè)務(wù)訴求；在配置中心升級過程中，我們追求業(yè)務(wù)的無感知升級，通過兼容原有配置中心對外開放的接口，實(shí)現(xiàn)了新系統(tǒng)的平滑升級，原有系統(tǒng)優(yōu)雅下線。
大家可以看到，和注冊中心的升級方案類似，在配置中心的技術(shù)方案設(shè)計(jì)中，我們也較好的遵循了業(yè)務(wù)導(dǎo)向原則。
2.4 統(tǒng)一微服務(wù)平臺建設(shè)
介紹完注冊中心和配置中心等微服務(wù)引擎的技術(shù)升級方案，我們再來看下從0到1快速構(gòu)建的煙囪式微服務(wù)平臺會面臨哪些問題和挑戰(zhàn)？
從上圖左側(cè)示意圖中可以看到，我們快速構(gòu)建的微服務(wù)平臺存在10個(gè)以上的模塊，每個(gè)模塊都有獨(dú)立的入口，用戶使用平臺的易用性很低；此外，這些模塊在建設(shè)過程中，還需要重復(fù)對接云平臺、單點(diǎn)登錄、權(quán)限、工單、監(jiān)控、CMDB等公共服務(wù)系統(tǒng)；系統(tǒng)審計(jì)日志分散，不便于快速定位因變更引起的問題；綜上，煙囪式微服務(wù)平臺存在多入口，功能重復(fù)對接，運(yùn)維、研發(fā)成本高，故障排查與恢復(fù)效率低，易用性不足等問題。
要解決煙囪式微服務(wù)平臺的問題，需要構(gòu)建更合理的產(chǎn)品方案，我們對用戶的使用現(xiàn)狀進(jìn)行了分析：
通過系統(tǒng)埋點(diǎn)數(shù)據(jù)發(fā)現(xiàn)，煙囪式微服務(wù)平臺中用戶使用頻率最高的兩個(gè)系統(tǒng)分別是配置中心、服務(wù)治理。
通過上圖左側(cè)的PV/UV餅狀圖數(shù)據(jù)，大家可以發(fā)現(xiàn)：
配置中心的用戶訪問主要集中在配置的【查詢與變更】、【變更記錄與審批】和配置變更相關(guān)的2個(gè)頁面上，服務(wù)治理的用戶訪問主要集中在【服務(wù)概覽】、【服務(wù)查詢】和服務(wù)相關(guān)的2個(gè)頁面上。
基于埋點(diǎn)數(shù)據(jù)，我們可以看到用戶的訪問集中在少數(shù)的幾個(gè)功能上，通過整合各個(gè)系統(tǒng)模塊高頻使用的功能，建設(shè)統(tǒng)一的平臺入口，實(shí)現(xiàn)系統(tǒng)間聯(lián)動，這也給我們?nèi)绾谓ㄔO(shè)統(tǒng)一平臺提供了較好的思路。
此外，在對各個(gè)模塊的技術(shù)架構(gòu)進(jìn)行分析時(shí)，我們識別到了位于最底層、技術(shù)依賴程度最高的兩個(gè)系統(tǒng)：配置中心、注冊中心，這兩個(gè)系統(tǒng)非常適合作為統(tǒng)一平臺建設(shè)的技術(shù)底座。
區(qū)別于煙囪式微服務(wù)平臺的多個(gè)系統(tǒng)模塊獨(dú)立對接CICD等研發(fā)平臺，在統(tǒng)一微服務(wù)平臺建設(shè)中，我們升級為統(tǒng)一平臺對接CICD等研發(fā)平臺；我們的建設(shè)思路是，以配置中心/注冊中心為底座來建設(shè)統(tǒng)一微服務(wù)平臺：
一是：基于統(tǒng)一的配置通道與CICD等研發(fā)平臺系統(tǒng)進(jìn)行聯(lián)動，建設(shè)一鍵審批、回滾能力，整合研發(fā)流程，降低對接成本；
二是：通過統(tǒng)一平臺的建設(shè)，實(shí)現(xiàn)平臺間聯(lián)動，建設(shè)高階的自動化水平，支撐業(yè)務(wù)進(jìn)一步提升持續(xù)服務(wù)能力。
2.5 引擎升級&統(tǒng)一平臺建設(shè)總結(jié)
接下來，對我們前面講到的內(nèi)容做一個(gè)總結(jié)：在大規(guī)模、海量業(yè)務(wù)的微服務(wù)架構(gòu)實(shí)踐過程中，我們通過引擎升級和統(tǒng)一平臺能力建設(shè)較好的解決了碰到的問題與挑戰(zhàn)。
在升級和建設(shè)過程中，我們需要保證現(xiàn)有業(yè)務(wù)的連續(xù)性，保障不發(fā)生因底層引擎升級和平臺建設(shè)導(dǎo)致的可用性問題。因此，引擎升級和統(tǒng)一平臺建設(shè)的工作需要建立在高可用保障的基礎(chǔ)上；換句話來說，可用性是我們所有工作的底座。
在這個(gè)基礎(chǔ)上，我們實(shí)現(xiàn)注冊中心和配置中心的引擎升級，完成應(yīng)用級注冊模型升級；在這個(gè)過程中，解決底層引擎的擴(kuò)展性、容量、性能、可維護(hù)性和安全性等問題；最后，我們要建設(shè)統(tǒng)一的微服務(wù)平臺能力，實(shí)現(xiàn)平臺間聯(lián)動，構(gòu)建自動/自助化使用能力；賦能業(yè)務(wù)。
大家可以看到，通過完整的方案介紹，在上圖右側(cè)我們呈現(xiàn)了微服務(wù)架構(gòu)實(shí)踐過程中的價(jià)值分層邏輯，即在可用性的基礎(chǔ)上，提升系統(tǒng)的擴(kuò)展性、容量、性能、可維護(hù)、安全性等能力；然后再在此基礎(chǔ)上，交付更高的研發(fā)效率，更好的用戶使用體驗(yàn)。
三、微服務(wù)架構(gòu)升級的總結(jié)與展望
介紹完我們的解決方案后，最后來說明下我們對微服務(wù)架構(gòu)升級的總結(jié)與思考，以及對未來的展望。
3.1 擁抱開源的實(shí)用主義
在構(gòu)建微服務(wù)架構(gòu)技術(shù)體系的過程中，我們始終堅(jiān)持擁抱開源，迭代業(yè)務(wù)適用的技術(shù)平臺；結(jié)合內(nèi)部業(yè)務(wù)的實(shí)際情況，我們走出了一條從開源到開源+自研的研發(fā)路徑。
在從0到1的平臺能力建設(shè)過程中，我們引入開源組件進(jìn)行能力快速構(gòu)建，快速交付滿足業(yè)務(wù)的需求；始終堅(jiān)持業(yè)務(wù)適用原則，不過度設(shè)計(jì)，支撐業(yè)務(wù)的快速迭代；以上階段，我們稱之為“拿來主義”。
在面向更大規(guī)模、海量業(yè)務(wù)實(shí)踐過程中，為了解決碰到的問題與挑戰(zhàn)，我們在開源的基礎(chǔ)上進(jìn)行增強(qiáng)，自研部分能力來解決億級用戶規(guī)模下內(nèi)部業(yè)務(wù)的功能，性能，容量，研發(fā)流程打通等需求；這個(gè)階段，我們稱之為“實(shí)用主義”。
在技術(shù)平臺迭代過程中，我們始終堅(jiān)持2個(gè)原則，一是簡單有效原則，堅(jiān)持用最簡單的解決方案來解決問題；二是迭代和演進(jìn)原則，堅(jiān)持平臺持續(xù)迭代和演進(jìn)的原則；前期基于開源組件快速搭建能力，再基于實(shí)際的業(yè)務(wù)需求和痛點(diǎn)來落地自研架構(gòu)；在這個(gè)過程中，始終堅(jiān)持業(yè)務(wù)適用，不為了技術(shù)而技術(shù)，避免大而全的技術(shù)架構(gòu)。
此外，也要說明一個(gè)常見的誤區(qū)，我們?yōu)槭裁床煌耆匝?？vivo的微服務(wù)平臺建設(shè)從開源社區(qū)獲益良多，堅(jiān)持不閉門造車，站在巨人肩膀上，持續(xù)引入優(yōu)秀特性來支撐業(yè)務(wù)的快速發(fā)展，同時(shí)也會考慮將部分行業(yè)適用的通用優(yōu)秀特性反饋給社區(qū)，和社區(qū)共同成長。
3.2 中間件組件全生命周期管理
大家可以看到，vivo的微服務(wù)架構(gòu)技術(shù)體系引入了較多的開源組件，在實(shí)踐過程中，我們摸索出了一套完整的中間件組件全生命周期管理策略。
我們先來看看業(yè)務(wù)的訴求和底層技術(shù)的特點(diǎn)：
首先是業(yè)務(wù)的訴求：
- 業(yè)務(wù)期望更高的迭代交付效率；
- 快速引入新技術(shù)，使用新技術(shù)助力業(yè)務(wù)創(chuàng)新，但很多時(shí)候新技術(shù)往往意味著成熟度不足，可能存在較多問題；
- 業(yè)務(wù)的不斷創(chuàng)新與發(fā)展，對組件的性能、容量要求越來越高；
對業(yè)務(wù)來說，高效迭代交付需求是第一位的。
然而，底層技術(shù)有它自己的特點(diǎn)：
- 技術(shù)的發(fā)展有它的客觀規(guī)律，需要經(jīng)歷萌芽期 → 膨脹期 → 低谷期→ 復(fù)蘇期→ 成熟期等多個(gè)階段；
- 缺乏約束的技術(shù)體系必然隨著時(shí)間推移而腐化，治理不及時(shí)會成為技術(shù)債務(wù)，阻塞業(yè)務(wù)發(fā)展；
- 同類中間件組件的快速引入會有重復(fù)建設(shè)的效率問題；
- 中間件組件的技術(shù)升級周期客觀上都比較長。
實(shí)踐證明，只有足夠穩(wěn)健的底層技術(shù)能力才能更好支撐業(yè)務(wù)的高效迭代。在這個(gè)過程中，如何兼顧效率與質(zhì)量？尊重客觀規(guī)律，確保整個(gè)過程都有明確的目標(biāo)和方向，避免走偏，慢就是快。
我們認(rèn)為，完善的中間件組件全生命周期管理策略，首先需要在所有的技術(shù)團(tuán)隊(duì)中形成價(jià)值共識；再通過組件掃描和組件地圖等手段及時(shí)對組件全貌進(jìn)行洞察；在組件的標(biāo)準(zhǔn)化治理和運(yùn)營階段實(shí)現(xiàn)有規(guī)范，補(bǔ)短板；同時(shí)在新技術(shù)引入時(shí)，通過完善的新技術(shù)引入規(guī)范，覆蓋功能/性能/容量/擴(kuò)展性/成熟度/使用成本等維度；在組件的版本治理上，使用基線版本治理方案，輸出明確的使用標(biāo)準(zhǔn)/版本升級方案/版本收斂策略；最后，在組件的成熟度管理上，我們可以借助Gartner(高德納)技術(shù)成熟度說明和組件能力矩陣，不斷提升組件的成熟度。
綜上，為更高效的支撐業(yè)務(wù)，在組件管理上我們使用了更加入寬松的引入策略，同時(shí)也會對組件的全生命周期進(jìn)行嚴(yán)格管理，踐行寬入嚴(yán)出策略，通過完善的中間件組件全生命周期管理助力業(yè)務(wù)跑的更快，走的更遠(yuǎn)。
3.3 引擎升級探索
展望未來，我們會堅(jiān)持和踐行引擎升級和平臺建設(shè)的持續(xù)迭代思路：
首先是對引擎升級的探索，通過引入新技術(shù)來解決當(dāng)前碰到的研發(fā)效率、成本等痛點(diǎn)問題：
在研發(fā)效率方向，存在的痛點(diǎn)問題如下：
一是，組件SDK的升級周期長，碎片化問題嚴(yán)重；
二是，當(dāng)前vivo內(nèi)部主要的是Java、C++技術(shù)棧，新業(yè)務(wù)形態(tài)孵化可能會引入新的技術(shù)棧，需能夠較好解決跨技術(shù)棧的問題。
想要較好的解決以上問題，需要探索基于Java Agent/SideCar技術(shù)的標(biāo)準(zhǔn)ServiceMesh模式，將RPC、MQ等中間件能力下沉，透明化實(shí)現(xiàn)微服務(wù)治理、高可用等能力增強(qiáng)，同時(shí)組件具備熱升級能力。
此外，在成本方向，存在的痛點(diǎn)問題如下：
一是， MQ等重資源型應(yīng)用的CPU、存儲資源利用率差異大；
二是，部分事件驅(qū)動場景機(jī)器資源利用率低。
要解決以上問題，我們可以通過升級MQ組件，落地存算分離技術(shù)，探索計(jì)算存儲資源利用率優(yōu)化方案。另外，還可以探索Serverless技術(shù)，實(shí)現(xiàn)平臺化托管運(yùn)維，降低資源成本，天然適合小程序、快應(yīng)用等事件驅(qū)動業(yè)務(wù)場景。
綜上，在引擎升級探索上，我們會基于業(yè)務(wù)需求和痛點(diǎn)問題，探索和落地ServiceMesh/Serverless/存算分離等云原生技術(shù)。
3.4 平臺建設(shè)探索
講完引擎升級探索，我們再來看看在平臺建設(shè)上的探索：
作為技術(shù)平臺團(tuán)隊(duì)，我們在持續(xù)積極的探索“平臺工程”理念，從現(xiàn)在的DevOps實(shí)踐到平臺工程，也是團(tuán)隊(duì)協(xié)作理念的再次升級。
我們知道，DevOps于2009年出現(xiàn)，2015年在國內(nèi)火起來，它是一種文化、方法論，是敏捷理念從開發(fā)到運(yùn)維的延伸。DevOps的理念是：踐行誰構(gòu)建誰運(yùn)行，開發(fā)運(yùn)維一體化，實(shí)現(xiàn)業(yè)務(wù)的高效交付。
但是，DevOps在實(shí)際落地過程中存在以下問題：
“DevOps團(tuán)隊(duì)”的中心化與去中心化取舍問題
【中心化】指的是，獨(dú)立的DevOps團(tuán)隊(duì)，即不在業(yè)務(wù)團(tuán)隊(duì)中配置DevOps能力，而把DevOps人員集中起來組建團(tuán)隊(duì)，這種完全中心化的模式本質(zhì)上和DevOps文化相矛盾。同時(shí)根據(jù)康威定律，可能會制造新的效能瓶頸?！蔼?dú)立的DevOps團(tuán)隊(duì)”在2014年被Thoughtworks“技術(shù)雷達(dá)”列為Hold (停止采用)。
【去中心化】指的是，將DevOps能力分散在業(yè)務(wù)團(tuán)隊(duì)，這種做法會將大量的和基礎(chǔ)設(shè)施相關(guān)的工作職責(zé)劃給業(yè)務(wù)團(tuán)隊(duì)；這種方式會隨之出現(xiàn)基礎(chǔ)設(shè)施和服務(wù)治理缺失、系統(tǒng)穩(wěn)定性降低、研發(fā)和DevOps效能浪費(fèi)等諸多問題。
因此，想要踐行好DevOps，必須在中心化與去中心化之間取得平衡。
此外，從平臺能力上講，DevOps平臺往往更側(cè)重于建設(shè)流程和工具鏈，而在使用這些建設(shè)的工具技術(shù)平臺過程中會大大增加業(yè)務(wù)開發(fā)團(tuán)隊(duì)的認(rèn)知負(fù)荷，存在無法較好向業(yè)務(wù)開發(fā)團(tuán)隊(duì)屏蔽底層基礎(chǔ)設(shè)施復(fù)雜性的問題。
平臺工程的概念，是在2017年首次出現(xiàn)，于2022年在國內(nèi)興起。平臺工程的定義是，一套用來構(gòu)建和運(yùn)營支持軟件交付和生命周期管理的自助式內(nèi)部開發(fā)者平臺的機(jī)制和架構(gòu)；它的特點(diǎn)是：平臺在演進(jìn)中提供足夠的透明度、敏捷性，在建設(shè)過程中形成適合業(yè)務(wù)架構(gòu)的高效協(xié)作模式。在這一過程中逐步將知識體系固化到平臺中，從而使得工程方式標(biāo)準(zhǔn)化、流程化和規(guī)?；⒊掷m(xù)改善；它踐行的理念是：一個(gè)可用的、高效的平臺并非一個(gè)技術(shù)團(tuán)隊(duì)埋頭苦干就可以產(chǎn)出的；恰恰相反，一個(gè)成功的平臺工程需要企業(yè)各個(gè)組織部門合作、協(xié)調(diào)、推廣并根據(jù)實(shí)際使用反饋不斷迭代。
在具體實(shí)踐中，平臺工程約定了“業(yè)務(wù)團(tuán)隊(duì)”和“平臺團(tuán)隊(duì)”兩個(gè)團(tuán)隊(duì)，其中“業(yè)務(wù)團(tuán)隊(duì)”負(fù)責(zé)業(yè)務(wù)研發(fā)，“平臺團(tuán)隊(duì)”負(fù)責(zé)平臺建設(shè)；“平臺團(tuán)隊(duì)”通過將技術(shù)知識沉淀到“平臺工程”，隱藏和抽象底層基礎(chǔ)設(shè)施的復(fù)雜性，實(shí)現(xiàn)基礎(chǔ)設(shè)施即代碼，為“業(yè)務(wù)團(tuán)隊(duì)”賦能增效；同時(shí)，基于“業(yè)務(wù)團(tuán)隊(duì)”在使用“平臺工程”的過程中的不斷反饋來持續(xù)改進(jìn)平臺的自助化產(chǎn)品能力，構(gòu)建一整套覆蓋DevOps全鏈路的簡單易用平臺產(chǎn)品；可以看到，平臺工程是一種最佳實(shí)踐，和我們當(dāng)前的團(tuán)隊(duì)協(xié)作模式匹配度非常高。
在平臺建設(shè)的整體規(guī)劃上：
當(dāng)前階段：我們構(gòu)建的統(tǒng)一微服務(wù)平臺會持續(xù)探索“平臺工程”理念，沉淀配置中心、注冊中心等平臺的技術(shù)知識與最佳實(shí)踐，構(gòu)建和打磨業(yè)務(wù)自助化使用的平臺能力。
展望未來：我們會通過明確的北極星指標(biāo)，牽引平臺提供更高的研發(fā)效率和更好的開發(fā)者體驗(yàn)。
在研發(fā)效率上，我們追求單位時(shí)間內(nèi)更多的代碼產(chǎn)出和需求交付；此外我們也追求更好的開發(fā)者體驗(yàn)，通過降低用戶使用平臺的打斷次數(shù)和平臺問題的人工支撐次數(shù)，提升業(yè)務(wù)團(tuán)隊(duì)和平臺團(tuán)隊(duì)兩個(gè)團(tuán)隊(duì)的開發(fā)體驗(yàn)。
在具體的落地路徑上，我們始終以開發(fā)者用戶為中心，針對研發(fā)工作中時(shí)間消耗較多的場景進(jìn)行優(yōu)化，通過北極星指標(biāo)牽引，形成覆蓋 IDE+PaaS 的平臺工程實(shí)踐路徑，持續(xù)迭代優(yōu)化平臺能力，提升研發(fā)效率與開發(fā)者體驗(yàn)。
