InfoQ：2022第三季中國卓越技術團隊訪談錄（83頁）.pdf

《InfoQ：2022第三季中國卓越技術團隊訪談錄（83頁）.pdf》由會員分享，可在線閱讀，更多相關《InfoQ：2022第三季中國卓越技術團隊訪談錄（83頁）.pdf（83頁珍藏版）》請在三個皮匠報告上搜索。

1、T 0 p T E C H【DEIB 描。戰事在阿里達摩院搞了四年數據庫，我來聊聊實際情況lnfoQ T E A M 目錄 封面故事 在阿里達摩院搞了四年數據庫，我來聊聊實際情況.i 重磅訪談 不到三年覆蓋 25 個行業，華潤集團系統上云比例超過 99%.1 突圍電商大促場景，得物在高可用上的探索與實踐.14 用三年替換掉二十年老系統，民生保險數字化轉型秘籍.28 從基礎架構到用戶體驗，字節跳動是如何打造移動端架構團隊的？.38 一年100%云原生化，眾安保險架構演進的探索與實踐.48 封 面 故 事 i 中國卓越技術團隊訪談錄2022 第三季 在阿里達摩院搞了四年數據庫，我來聊聊實際情況 嘉

2、賓：汪晟、譚劍和謝炯 作者：羅燕珊 編輯：鈺瑩 2017 年的云棲大會，阿里巴巴達摩院宣布成立。5 大研究方向，16 個實驗室，數據庫與存儲實驗室便是達摩院下設實驗室之一。成立伊始，達摩院定位發力硬核基礎科技。ii 中國卓越技術團隊訪談錄2022 第三季 前沿數據庫技術，就是發力方向之一。五年時間，社交媒體上每隔一段時間就有人出來問“阿里達摩院搞出來什么成果了？”，“阿里達摩院的技術水平是什么樣的？”，“達摩院里面的人平常的 KPI 是什么？”，“什么樣的人可以進阿里達摩院？”InfoQ 日前對達摩院數據庫與存儲實驗室的三個核心團隊的負責人汪晟、譚劍和謝炯進行了集中采訪，了解他們在數據庫前沿研

3、究的具體工作，以及這些工作對阿里云數據庫實力的加持，同時也一窺達摩院的人是如何開展研究工作的。密態數據管理，重新定義數據要素時代的安全邊界 數據有望成為新型生產要素推動社會變革，然而現階段卻面臨著巨大挑戰。人類社會的演進離不開生產要素的升級：從農業經濟時代的土地、勞動力，到工業信息時代的資本、技術。在如今的數字經濟時代，全球數據爆炸式增長，大數據、人工智能等技術不斷涌現，數據正儼然成為這個時代最核心的生產要素。然而，為使數據真正成為生產要素，我們仍然面臨著巨大的挑戰：不同于其他生產要素，數據的易復制性、非排他性等特征導致其極易被泄露、難以被限制用途用量，如何在保障數據機密性、隱私性的前提下進行

4、數據的大規模集中管理和跨組織有序流通是數據走向資產化的一大挑戰?！安┦科陂g，我的研究方向是傳統的數據庫系統內核，與數據安全并沒有太多關聯。加入達摩院后，我逐漸意識到在云計算、數據互聯迅速普及的當下，數據管理與流通 iii 中國卓越技術團隊訪談錄2022 第三季 中的隱私安全是非常嚴峻的挑戰，會成為數據庫系統突破其能力邊界的一個重要方向。但具體可以做成什么樣子，我腦子里起初也很模糊，只是不停地朝著這個方向探索?！蓖絷捎?2018 年加入達摩院，是數據庫與存儲實驗室的第一位專注基礎研究的科學家（Research Scientist）。自加入之后，他就開始探索數據庫安全可信方向的研究，并帶領團隊從

5、0 到 1 完成了全密態數據庫技術的研究突破與產品落地，使阿里云成為了全球少數具備全密態數據庫管理能力的云廠商。傳統數據庫系統的安全體系中已經有很多經典的技術，比如存儲落盤加密、訪問控制、網絡傳輸加密等。但所有這些技術考慮的情境是：數據庫管理著企業內部的數據，數 iv 中國卓越技術團隊訪談錄2022 第三季 據庫服務所在的服務器被放置在企業專屬的、物理安全的機房中，數據庫與服務器的管理人員是完全被信任的企業內部員工，安全防護措施只需要保證沒有權限的外部人員無法訪問數據庫即可。但是，數據應用和云計算的出現改變了數據的使用和管理方式，從而顛覆了上述情境。例如，數據應用業務鏈路越來越復雜，經常涉及企

6、業自己數據在其他企業的系統中流動（比如電商場景的平臺、商家、物流等），不同企業間是不完全信任的；在企業內部，業務團隊的數據是由 IT 基礎設施團隊統一管理的，不同團隊間也可能是不完全信任的。也就是說，數據的機密性、完整性、隱私性等問題，這是傳統數據庫系統在設計時從未考慮過的。因此，業內也開始將研究重點聚焦在全密態數據庫上。全密態數據庫旨在解決數據全生命周期的隱私保護問題，使得系統無論在何種業務場景和環境下，數據在傳輸、運算以及存儲的各個環節始終都處于密文狀態。當數據擁有者在客戶端完成數據加密并發送給服務端后，在攻擊者（包括黑客、超級用戶等任何角色）借助系統脆弱點竊取用戶數據的狀態下仍然無法獲得

7、有效的價值信息，從而起到保護數據隱私的作用。全密態數據庫這個概念可追溯至 2010 年 MIT 提出的 CryptDB，該項目不是指某種特定的數據庫，而是一種針對加密數據的查詢技術，允許用戶查詢加密后的 SQL 數據庫，在不解密數據的情況下返回結果。CryptDB 使用的是特殊的加密算法，包括保序加密、可檢索加密、半同態加密等，但各算法支持的計算操作極為有限，安全強度也各異，難以在復雜的業務場景中使用。v 中國卓越技術團隊訪談錄2022 第三季 此外，全同態加密被譽為密碼學領域的圣杯，一旦實現就代表著所有計算都可以在密文上執行，且其安全性也能得到保障，因此受到了學術界的追捧。但其性能非常低，雖

8、然過去幾年業內有很多研究機構推出了各種各樣的加速方案，但實際效果還是會與其他方案存在數量級上的差距。那么，其他方案具體是指什么呢？第二種方案是多方安全計算。將數據存放在多個互補共謀的云平臺之上，單一云平臺上的數據顯示為毫無意義的字節串，多個云平臺的數據組合在一起才可以計算出想要的結果。其缺點是受到多云架構的制約，與集中化、單一的云平臺設計初衷相違背，數據計算過程嚴重依賴跨云或者跨數據中心的網絡交互，信息傳輸成本極高，難以處理大規模數據。第三種方案是基于可信硬件（TEE）的方式實現。相較于普通服務器只需要有根用戶或超級用戶權限就可以訪問任何進程中的任何數據內容，可信硬件內部的資源是由硬件機制保證

9、隔離的，即便擁有上述權限也無法訪問由可信硬件保護的區域內部。即便攻擊者控制了整個服務器也無法竊取其中的數據。這種模式的缺點是十分依賴硬件的能力，且存在側信道攻擊隱患等。目前國際上比較成熟的是英特爾的 SGX 技術，達摩院內部也已經具備自研的 TEE 技術。汪晟團隊對上述三種技術方案均有研究布局，但技術研究和產品落地是兩回事，經過多方權衡，團隊當前選擇了第三種方案進行商業化落地?！鞍⒗镌剖侨虻谌脑朴嬎闾峁┥?，支撐著無數企業用戶。我們希望研究出來的密態數據管理技術可以適用于任何場景下的任何數據庫系統，且在硬件加持下，最終的性能損耗是可以無限趨近于零的。如果針對特別敏感的數據子集，不希望依賴硬件

10、安全，我們可以對這部分數據使用同態加密算法做進一步加固，這自然是建立在犧牲性 vi 中國卓越技術團隊訪談錄2022 第三季 能的基礎上實現的，需要企業自行抉擇?！痹?2020 年初，汪晟團隊的研究成果已經開始在阿里集團內部業務試運行，2021 年 9月份，全密態數據庫系列產品正式在阿里云對外發布，成為全球第二個全密態數據庫云服務。阿里云的幾大數據庫產品，比如 PolarDB、RDS 均已接入該能力。從性能指標來看，在事務型（OLTP）場景下，性能可以達到明文數據庫的 50%到 90%，具體性能損耗與實際運行的工作負載有關，這個損耗與業內其他方案相比已經把控得相當優秀了。當然，用戶可以在安全與性

11、能之間自行選擇向哪一側傾斜。從改造視角來看，團隊發現實際落地需要考慮的問題不單單是產品技術能力本身，更需要考慮與原有數據庫的兼容性、降低遷移成本和提供回遷備案等?；谶@些訴求，團隊又研發了定制的數據庫連接驅動，在業務無感的情況下自動完成數據加解密，無需修改應用側代碼?！疤峁祿靸鹊拿軕B數據管理能力只是個開始，最終企業客戶希望得到的一定是覆蓋整個數據生命周期全鏈路的密態數據管理能力。只有做到了這一點，才能真正實現數據要素的資產化和市場化，這是個更具挑戰但也更有價值的研究問題?！蓖絷蓤F隊的研究不僅停留在數據庫系統層面，面向上述數據全生命周期密態管理的問題，他們最新的研究成果已經轉化為學術論文發表

12、在了數據庫領域頂會 VLDB2022 上，得到了業界同行的認可。除此之外，他們在防篡改數據存儲、隱私增強計算引擎等全方位數據安全技術的研究和產品化上也在進行著持續的探索突破。在汪晟悶頭研究數據庫安全可信技術的時候，同處一個實驗室的譚劍正在思考數據庫到底能不能“自動駕駛”。vii 中國卓越技術團隊訪談錄2022 第三季 AI FOR DB：讓數據庫實現“自動駕駛”1970 年代，DBMS 的出現簡化了應用開發人員對數據進行統一管理的棘手問題。數據庫通過關系型模型和 SQL 聲明式語法，為事務、存儲、查詢、性能等一系列問題提供了一個高效的，自動的解決方案。這個階段數據庫的優化工作聚焦在數據庫內核的

13、若干基礎原子能力，例如針對索引，或分區分表等“點”上的自動優化。1990 年代，主流的 DB2，Oracle 等數據庫推出更加全面的專家自動優化系統，可以在一個更大的決策空間中對不同配置下的系統性能進行估計，用來指導系統的自動優化。雖然在之前“點”上的優化進一步擴大到了“面”，但大多時候仍然高度依賴 DBA 的經驗和人的手工操作。2010 年代，云計算的興起對數據庫自動駕駛的能力提出了更高的，更直接的要求。在云原生數據庫的彈性平臺之上，單純依靠人力已經不可行，迫切要在更豐富的“體”上，對多樣的數據庫形態實現要求更高的“自動駕駛”。其實關于數據庫自治的研究早在十幾年前就已經在學術界提出，但真正的

14、大規模商用落地則是在云計算成熟之后的近幾年。譚劍團隊推出的數據庫自治產品 DAS，自成為阿里云產品以來用戶數和營收近兩年一直保持在 70%到 80%以上的快速增長，就是一個直接的證明。viii 中國卓越技術團隊訪談錄2022 第三季 Gartner 報告指出，預計到 2023 年全球 75%的數據庫都會跑在云上，這與傳統數據庫的天下發生了本質變化。在這么一個復雜的系統環境中，數據庫運行的過程中會出現各種性能問題，概括起來主要分為三類：一是從可觀測的角度，數據庫性能指標多，難快速形成對故障的可解釋性診斷；從可控制的角度，難做到對實例的個性化運維。比如，DAS 支持的一個典型頭部客戶，一個 DBA

15、 管理了數百個數據庫實例，性能問題和故障告警很容易淹沒在海量的觀測數據之中，故障現場也很難捕捉，要做到故障定位和快速精準恢復就更難了。二是數據庫要做到 24 小時永不停歇，持續調優，保持穩定，傳統上需要專業的 DBA ix 中國卓越技術團隊訪談錄2022 第三季 來負責，需要豐富的運維經驗。但是，對于云上的大規模數據庫，由于人力不足或者經驗存在差異，并不總能保質保量的解決問題，而這種不確定性在要求很高的商用生產環境中是要盡力避免的，因為“線上問題無小事”。三是面對發展的業務對資源需求的動態變化，如何做好容量規劃和資源優化，避免人工頻繁干預，降低運維成本，這些都是在云時代的背景下，企業和開發者對

16、自治數據庫的實質需求。從技術層面來看，數據庫自治是一系列原子技術的組合，廣義上包含兩大類：數據庫外部運維和內核技術的智能化。外部運維就是最近流行的 AIOps，內核技術則是用 AI技術提升數據庫內核的某些性能。目前學術上對后者有很多前沿研究，比如 MIT 提出過使用深度學習網絡代替 B-tree 做索引，在一些實例上取得了不錯的效果；IBM 使用深度模型做 SQL 執行計劃優化等。但是，目前離成熟的、大規模產品落地還有一段距離?！爱斍?，業界的實現路徑呈現百家爭鳴，百花齊放的狀態。我們采取的策略是外圍包圍內核，先從 AIOps 做起，逐步進入內核智能化的領域。不過有時候這兩者界限并非那么明顯，我

17、們有的產品能力本身屬于內核能力的一種外置。例如我們研發的外置 SQL 優化，對 MySQL 等開源數據庫特別適用。商用數據庫往往都有很成熟的執行器優化，可惜是幾個傳統頭部數據庫公司的商業機密。對開源托管類的數據庫，往往是欠缺的狀態，而我們提供的外置優化可以直接解決客戶很多問題?！睌祿熳灾?DAS 基于全量 SQL 和性能指標的大數據能力，深度融合人工智能和專家經驗，可以分成上游的可觀測技術，和下游的可控制技術兩個系統。上游包括例如異常 SQL 定位，信號異常檢測，針對稀疏數據或傾斜分布的高效統計采樣，還有把觀測 x 中國卓越技術團隊訪談錄2022 第三季 技術的結果按場景進行歸類，用來驅動下

18、游的控制。下游技術包括例如 SQL 外置優化，限流，壓測，調參，彈性擴縮容，資源調度，SQL 審計等。這是一個復雜的，包含眾多原子技術的體系。通過單點技術的原子能力，加上體系上的構建的豐富的產品功能，和阿里云上獨有的規?；姆?，三者的結合構成飛輪效應，呈現給用戶智能化的數據庫自治能力，讓用戶聚焦在自己的業務創新和發展上。對自治中可控制技術的部分，數據庫可能會通過改變物理設計/參數配置/物理資源等方式進行自動優化，可能會包含多種不同的優化方式。從這個角度來看，阿里達摩院研發的數據庫自治產品架構，采用了讓多種優化服務通過解耦的方式協同滿足客戶的需求，在具體業務場景中各種服務會呈現不同的自治形態。

19、一是改變物理設計。例如改變表結構?？赡荛_始 OLTP 表的設計不是特別合理，如一些需要頻繁更新的數據和以讀為主基本不變的數據大量放在了一起。這從優化的角度會更多以推薦的形式推送給客戶，因為除非引擎產品直接支持混合事務分析 HTAP，那么改變表結構需要由客戶來評估線上的影響，再決定是否采納。二是優化參數配置。這是當前比較熱門的研究方向，數據庫有數以百計的性能參數，通過專家經驗可以總結出來一些核心的參數。這些可以與智能壓測相結合，對參數進行優化。這里往往也涉及到在線變更的操作，所以需要和數據庫領域知識以及業務場景的分析結合起來。三是對資源的優化。例如自動擴縮容，一定程度上已經比較成熟，阿里云數據庫

20、多個產品都推出了自動擴縮容的功能。另外一個例子是自動限流，當數據庫突然出現 CPU負載高，造成響應異常等問題，我們會自動定位到造成問題的 SQL 語句，對其進行限流，甚至 kill 等操作，通過止血來避免對其他任務造成影響。當然了，這些主動運維 xi 中國卓越技術團隊訪談錄2022 第三季 的操作都需要客戶的事先授權?；趯Σ煌窂降难芯考翱陕涞匦缘目剂?，阿里云數據庫于 2020 年推出數據庫自治產品 DAS，以期實現數據庫的“自動駕駛”。采訪中，譚劍提到，數據庫自治關注的是讓數據庫不但“可用”，還要“好用”。終極的目標就是讓數據庫運維做到無人自動駕駛。提到自動駕駛，大家就會想到 AI 技術，

21、這在數據庫自治上同樣適用，只不過這里的 AI是更廣義的角度，不局限于現在大家比較熟悉的深度學習技術，還包括傳統的控制，統計，優化等方法。更重要的是，這些 AI 技術需要和數據庫的領域知識結合起來。從產品角度，數據庫自治提供了自感知、自決策、自恢復、自優化、自安全的能力，保障服務穩定、安全和高效。從技術角度，譚劍提到“可以形式化借用編程 class 的語言來描述：DAS 是一個繼承了多種數據庫引擎內核能力，實現了 AI 和大數據兩個接口的一個子類”。DAS 支持的引擎包括 Redis、PolarDB、MySQL、PostgreSQL、Mongo、SQL Server 等多種內核，在原引擎基礎上提

22、供的一種增值能力。這對自建數據庫也是一個很好的場景。在此基礎之上，DAS 實現了兩個接口：一是 AI 算法，提供智能化決策能力；二是大數據技術，基于用戶全量 SQL 的日志數據和性能指標數據，實現感知和審計能力。上述兩者之所為稱為接口，是因為對不同的數據庫引擎有具體的實現差異，不同的業務場景也有不同的產品需求?！敖衲暌詠?，系統的可觀測性概念火了，其實從數據庫自治的角度，還有一個對偶的概念叫做可控制性。事實上，二者在控制理論中存在嚴格的對偶關系?？捎^測性和可控制性兩者的有機結合，才構成了數據庫自治的完整鏈路?！眡ii 中國卓越技術團隊訪談錄2022 第三季 這種能力具體到阿里云自研的 Polar

23、DB 數據庫上是如何體現的呢？PolarDB 是一個分布式數據庫，支持水平和垂直擴縮容。從自動擴縮容 Auto Scaling 的角度，需要考慮是優化只讀節點還是寫入節點以及兩者的關系；從負載的角度，需要進行針對性的優化；從遷移角度，當客戶從其他數據庫遷庫轉到 PolarDB 時，為了不影響在線業務和評估容量，可以使用 DAS 提供的智能壓測能力，將原有數據庫與目標數據庫（PolarDB）做一次性能評測和容量評估。DAS 支持不同速度的回放，保障多次回放過程的數據庫運行時狀態一致，便于客戶進行評測，這些都可以對 PolarDB 進行特色支持。自治能帶來一些什么具體的業務價值呢？流利說的基礎架構

24、負責人表示：“阿里云數據庫的自治使得運維人效大幅提升，實現團隊轉型升級”。捷順的運維總監則表示：“自治大幅降低了數據庫故障時間，提高了系統的可用性?！笨梢?，自治數據庫已經在企業中落地并獲得了實際的業務價值。在譚劍團隊忙著“落地”數據庫自治技術的時候，謝炯團隊正被“空天數據”問題深深吸引?？仗鞌祿煲妫禾斓厍?，萬象合一 隨著對地觀測技術、物聯網和數字孿生技術的快速發展，車聯網/自動駕駛、視覺定位、物流配送等位置服務將隨時在、隨地在、隨身在。與之而來，多維空天數據呈現爆發式增長，給數據存儲、處理與分析計算帶來極大挑戰。在謝炯看來，空天數據有狹義和廣義之分。狹義上，空天數據（aerospace

25、data）主要來自天基和空基，例如，基 xiii 中國卓越技術團隊訪談錄2022 第三季 于天基平臺的 GNSS（全球導航衛星系統）數據和各類衛星遙感數據等，基于空基平臺的傾斜攝影、航拍影像、視頻數據等。廣義上，則可以將空天數據定義為涵蓋 Spatial（空，即地理空間）和 Space（天，即宇宙空間）的地、海、空、天各類與位置相關數據。天問一號攜祝融號在火星的登陸為我們傳來大量火星遙感影像和空間信息，使大家最直觀地感受到來自地球之外的空天大數據。謝炯在浙大教過本科，在中科院做過研究，也曾經和一群伙伴創過業，一直熱衷于數據庫技術。2018 年，他選擇加入阿里云，這被他認為是人生中很重要的一個選

26、擇?！爱敃r，云計算發展迅速，我認為這代表著未來的演進方向，阿里云在國內做得最早，xiv 中國卓越技術團隊訪談錄2022 第三季 影響力最大，當時腦海里奔出四個字，“順勢而為”。此外，阿里很擅長將技術轉化為產品，不僅內部有高德、菜鳥、本地服務等大量位置服務場景，通過阿里云這個平臺能輻射更廣闊的行業和客戶，這和我做研究是不一樣的?！痹谒磥?，傳統的空間數據庫（spatial database）主要處理點、線、面等空間幾何對象，這類數據體量和結構復雜性相對可控。但現今遙感影像、時空軌跡、傾斜 3D 等大量位置傳感型數據面臨著數據結構復雜多樣難以管理，數據動態變化要求更高維度計算，大數據和大計算場景性

27、能不佳以及智能化需要多模態數據融合管理等一些列難題。這類新型多模態數據無論在存儲上，還是計算上，都需要基于云的池化能力和彈性能力，才能在性能、成本、規?；线_到有效平衡。謝炯認為，將空天信息處理融入 PaaS 服務（Platform as Services），以云數據庫與存儲平臺為核心解決空天數據的實時接入、高效存儲和彈性計算，是支撐傳統時空信息云化架構向縱深發展的必走之路。在謝炯看來，這種架構演進具體可分解為平臺即服務、多模融合、計算下推和云原生四個方向。1、平臺即服務 是將空天數據處理內置于云上 OLTP 數據庫、OLAP 數據倉庫、NoSQL 多模數據庫等不同系統，相比傳統中間件方案在易

28、用性、計算效率和事務一致性處理上存在先天優勢。難點在于技術融合之后涉及數據庫內核技術、圖形圖像技術和空天數據專業處理技術的跨學科交叉，這三個方向各自的技術門檻都不低，同時熟悉這三個方向的技術人才則是少之又少。xv 中國卓越技術團隊訪談錄2022 第三季 2、多模融合 是跨結構的多模態數據融合和一體化處理。有兩個層次，首先在空天數據層次，不同空天多模態數據有非常大的結構差異和計算方式，只有模型打通，數據結構打通，算法才能真正打通（高效率）；其次是泛空天求解，把獨立的空天數據處理能力嵌入到時序、圖、文本等更多通用模型中，實現時序時空、空間/時空圖、空間文本等跨界融合，這些不同模型之間數據結構和計算

29、方式差異巨大，融合的挑戰自然更大。3、計算下推 是將空間信息系統業務關鍵計算下推數據庫系統，讓計算離數據更近。難點在于生態共建，已有上層的 CIM/BIM/GIS/RS 等涉空間系統都需要升級換代。謝炯談到，差不多十年之前我就在推動這一架構轉型，但面臨很多挑戰。直到最近幾年，大家看到了這一技術架構帶來的利好，不少行業廠商和數據庫廠商才主動加入這一方向陣營。4、云原生 新一代空天數據庫一定要與云原生能力緊密結合，與公有云結合，并由公有云走向混合云。謝炯團隊認為，云服務的本質是算力經濟，數據要靈活，算法去補；而算法要靈活，算力去補，即借助足夠彈性的算力來保障算法的純粹性和普適性。公共云廠商在這方面

30、具有獨特優勢，因為可以把空天計算能力下沉到存儲、硬件等更底層次做垂向優化。Ganos 是在綜合以上四個方面基礎上，實驗室研制推出的首個云原生、跨數據庫平臺的空天數據庫引擎。該引擎已內置于了云關系型數據庫 RDS PG、云原生關系型數據庫 PolarDB PostgreSQL、云原生數據倉庫 AnalyticDB PostgreSQL 和多模數據庫Lindorm 中，將傳統空間數據、新型空天數據和其他類型數據實現了多模一體化處理。用戶可以按不同數據庫產品獨立使用，也可以基于產品組合構建空天數據庫大數據一 xvi 中國卓越技術團隊訪談錄2022 第三季 體化底座。談到 Ganos 與傳統空間數據庫

31、的區別，謝炯認為主要有三點：一是云原生，Ganos 從誕生就在云上，充分利用了云原生能力進行設計。二是專業特性上突出了多維、動態、場景化。多維是既兼容傳統 2D，也支持 3D；動態是指時空變化的表達能力，比如移動對象數據庫；場景化是指視覺和行為信息處理，比如原生支持各類 3D 建筑的視覺信息處理，共享單車（移動對象）的開鎖、閉鎖事件描述等。Ganos 分別在 2018 年和 2021 年在業界首個推出了基于云的移動對象數據庫和 3D 場景數據庫，并在今年的 VLDB 2022 數據庫頂會上作了整體介紹，獲得了業界同行的認可。而傳統空間數據庫對多維、動態、場景化僅提供非常有限的支持。三是跨數據庫

32、平臺，Ganos 未來的目標是一站式空天/時空數據處理平臺。業界對于多模態數據的處理和支持大多處于早期落地階段，雖然學術屆開展了長期、廣泛的學術探討，但真正商品化提供服務的一直未見有成熟系統?？仗鞌祿且活愖畹湫?，且應用廣泛的多模態數據。早在 2018 年，Ganos 就結合 PolarDB 推出了完全自研的移動對象數據庫，并在這幾年快速迭代發展。這背后得益于與阿里內部場景的廣泛結合，所謂的“母體帶動”。在達摩院，Ganos 在支持包括自動駕駛實驗室的小蠻驢，機器智能實驗室的 AI Earth，XR 實驗室的 3D 空間計算等各類創新場景；同時，Ganos 也在支持包括高德、網商銀行大山雀、本

33、地生活等各類位置相關業務場景。據不完全統計，云上 Ganos 引擎被創建次數達到 3 萬 6 千多次，目前已廣泛應用到航空航天、自然資源、共享出行、災害應急、交通物流、遠程銀行、農業/海洋/水利以及社交/健身/O2O 等總計 45 個不同行業/應用方向。天地乾坤，萬象合一，這個“一”就 xvii 中國卓越技術團隊訪談錄2022 第三季 是萬物在時空中的位置，也正因此，空間計算業已成為數字化浪潮中的關鍵基礎設施。達摩院眼中云原生數據庫的未來 過去幾年，達摩院的前沿技術研究與阿里云數據庫的產品商業化服務形成相互促進的“飛輪”，前沿技術研究保證了數據庫產品技術及時更新換代，帶給客戶更多價值，同時大規

34、模服務客戶遇到的豐富場景推動達摩院不斷在前沿技術研究領域獲得突破。這種良性互動的“飛輪效應”體現在阿里云數據庫自研產品 PolarDB 等云原生數據庫技術創新中：PolarDB 在業內率先實現了一種全新的架構計算、內存和存儲的三層解耦，首次實現內存池化。這種架構創新能夠幫助下一代云原生數據庫顯著提升性能和彈性，大幅降低成本。在汪晟團隊的努力下，阿里云成為全球僅有的兩家實現了全加密數據庫產品商業化輸出的云廠商之一（另外一家是微軟）；在譚劍團隊的努力下，達摩院豐富的智能算法在數據庫領域的深度應用，讓 PolarDB 等數據庫產品擁有了“自動駕駛”能力，方便客戶簡便、智能、高效地使用；在謝炯團隊的努

35、力下，PolarDB 可以高效管理多維、動態、場景化的空間/時空/網格數據，更好地支持數字孿生城市等復雜 3D 多模態數據管理場景。接下來，汪晟、譚劍和謝炯所在的數據庫與存儲實驗室將繼續為云原生數據庫的未來努力著。今年初，中國信通院對數據庫領域關于智能化數據庫、關系型數據庫的安全能力，自 xviii 中國卓越技術團隊訪談錄2022 第三季 動運維能力，全密態、防篡改等標準均在起草中，達摩院數據庫與存儲實驗室深入參與了每一個標準的制定。在全密態數據庫的技術層面，汪晟團隊接下來將會思考如何做出一個可信密態的數據管理體系，涵蓋數據全生命周期的安全性，這是從技術視角要解決的一個問題；在業務價值的層面，

36、團隊希望能夠將當前的能力進一步標準化，讓不同的數據庫均可無縫接入到該體系；在生態建設層面，將密態數據推廣到數據管理的各個層面，從數據收集到數據處理，再到數據共享等環節都能通過生態化共建的方式進一步完善現有能力。DAS 目前已經是首批通過信通院數據庫管理系統智能化標準的兩大廠商之一。而且，該標準和 DAS 目前的產品能力高度一致。未來一年，譚劍所在團隊會主要解決如何更好地將自治技術與數據庫領域知識結合，用來解決復雜的根因診斷問題，將數據庫領域的知識和經驗沉淀下來，和 AI 結合讓客戶真正能夠從可解釋性的角度更好地運維和優化數據庫，并理解其運行狀態。除了 AI for DB 的數據庫自治，譚劍團隊

37、最近也推出了 DB for AI 產品，將 AI 的能力直接構建在 DB 的內核之上，讓客戶通過數據庫直接獲得原生的 AI 能力，為其提供價值挖掘能力和解決方案。例如今年 7 月，通過PolarDB 推出的 Polar for AI 產品，可以對數據庫典型場景和客戶提供各種 AI 解決方案。在 Ganos 的未來發展上，謝炯團隊會面向云原生和云孿生結合，朝向大規?？仗鞌祿徽臼焦芾矸较蜓葸M。系統層面，向下會從多模態并行查詢、擴展存儲引擎等方向發力，向上會從算法層面針對軌跡、影像、3D 等新型空天數據實現高性能分析計算，把整體能力做深做精；我們會重點把云和 LBS、數字孿生/元宇宙等業務結合，借

38、助數據庫產品與行業 ISV 開展更廣泛的生態合作，把解決方案做好，實現從技術到產品到產業化應用的快速迭代。xix 中國卓越技術團隊訪談錄2022 第三季 在達摩院做科研是種什么體驗（因本文三位嘉賓均來自數據庫與存儲實驗室，故此處只從他們的視角談科研體驗。）做研究，擁有自由探索的空間 從數據來看，阿里云數據庫團隊過去幾年在國際頂級會議上發布的論文數量不斷創下新高，從2018年的2篇增長到2022年的15篇。在剛剛結束的數據庫頂會VLDB2022上，數據庫與存儲實驗室向 Industrial Track 投稿的五篇論文被全部接收（該 Track 全球共接收 22 篇），這也意味著實驗室的相關探索得

39、到了業內的廣泛認可。實驗室內部對論文的質量審核極其嚴格，這也是一投即中的重要原因。從實際感受來看，三位嘉賓認為實驗室的整體氛圍還是不錯的，實驗室總負責人李飛飛在對技術方向的把控上十分到位，并會給予大家自由的探索空間，達摩院的品牌效應及阿里內部廣泛的落地場景給研究帶來了極大優勢?！白鲅芯亢妥霎a品不同，團隊氛圍非常重要，產品商業化之后可以立刻收到市場反饋，但研究有時候沒那么快與商業產品相結合，實驗室中的資深專家們會及時對大家的工作成果給出評價反饋，讓大家更容易認可和強化手頭工作的研究價值?！蓖絷稍诓稍L中表示。實驗室 70%成員是博士，歡迎交叉學科人才加入 數據庫與存儲實驗室內部有很多相對年輕的成員

40、?！凹夹g的未來需要更多顛覆性創新，xx 中國卓越技術團隊訪談錄2022 第三季 因此我們非常歡迎年輕的同學加入進來”。目前，該實驗室 70%左右的同學都是博士，來自海內外各大名校，研究方向也非常多樣化。此外，雖然實驗室的定位是數據庫，但并不是只接收數據庫背景的人才，也歡迎交叉學科的同學加入。嘉賓介紹 汪晟，計算機博士，畢業于新加坡國立大學，達摩院數據庫與存儲實驗室系統與安全方向負責人，全面負責下一代云數據庫安全可信與隱私計算體系的科學研究和產品落地。新加坡國立大學計算機博士，研究領域為大規模實用數據管理系統，主要研究興趣包括云原生數據庫系統、隱私與機密計算、云數據庫安全、數據分析系統、區塊鏈等

41、，在SIGMOD/VLDB/ICDE等數據庫與存儲領域頂級會議上發表學術論文近40篇，獲得 IEEE ICDCS 2020 最佳論文獎、ACM MM 2015 最佳論文獎提名。譚劍，電子與計算機系博士，畢業于美國哥倫比亞大學，阿里云數據庫自治服務和達摩院智能數據庫方向負責人。曾先后任職 IBM 沃森實驗室研究員和俄亥俄州立大學電子工程與計算機系終身制教職。研究興趣包括分布式計算系統的資源與性能優化，AIOps 系統設計與實現，隨機系統的數學建模與算法分析，優化算法的理論與應用。五次獲得最佳論文獎，在俄亥俄州立大學曾獲美國自然科學基金支持，并在多個著名學術會議中任執行委員會成員。謝炯，博士，畢業

42、于浙江大學，達摩院空天數據庫方向技術研發負責人，CCF 計算機協會數據庫專委會委員，中國測繪學會智慧城市專委會委員。近十五年來聚焦多模態 xxi 中國卓越技術團隊訪談錄2022 第三季 數據處理和空間數據庫系統研究，感興趣于三維對象數據庫、遙感圖像數據庫、軌跡大數據處理和 NoSQL 時空分布式系統等領域，研發成果曾獲得了科技部國產優秀軟件獎、國家科技進步二等獎、中國電子學會科技進步一等獎等獎項。重 磅 訪 談 1 中國卓越技術團隊訪談錄2022 第三季 不到三年覆蓋 25 個行業，華潤集團系統上云比例超過 99%采訪嘉賓：肖海山，華潤數科技術委員會主任、華潤云總經理 馮錚，華潤數科華潤云事業

43、部 SRE 服務部技術總監 2019 年 11 月，華潤云正式上線。從這時起算，華潤集團要求所有板塊要在 3 年之內完成上云工作，也就是說，2022 年底就是最后期限。充滿挑戰性的任務背后，承載的是華潤集團全面深化數字化轉型的決心。華潤集團智能與數字化部在十三五期間提出“智慧華潤”建設愿景，制定了“云優先，智生長”技術戰略，構建轉型的技術基礎和關鍵實施路徑。本文將從華潤云的視角，深入了解大型傳統集團型企業對于上云的思考和實踐，以及是如何探索數字化轉型之路。從華潤云的建設說起 2015 年開始，伴隨著華潤集團統一數據中心的建設，華潤集團開始布局云的建設。2019 年底華潤云已完成基本的 IaaS

44、、PaaS、及部分 SaaS 產品研發及建設，在 2019年 11 月份宣布華潤云正式上線，并開始為全集團 25 個行業提供云計算及相關服務。2 中國卓越技術團隊訪談錄2022 第三季 在華潤集團開展上云工作的同時，華潤云也堅持自主研發和持續迭代，到 2022 年 7月，云計算（IaaS/PaaS）相關產品每半年發布一個迭代版本，逐步豐富出了覆蓋私有云、混合云、邊緣云、公有云、信創云場景的產品系列。肖海山表示，華潤集團的數字化道路走得比較早，在 2013 年就已經有大面積的信息化嘗試。比如華潤萬家涉獵電商、O2O，門店運營業務數字化。只是當時大家僅認為這是降本增效的一種辦法，鮮少人提“數字化”

45、這個詞，但放到今天的語境來看，這都屬于數字化場景實踐。華潤集團大多數行業都面向民生，伴隨移動互聯網的發展，這些年集團內也有大量 C端業務做了數字化場景探索。因此華潤早就意識到數字化轉型是需要解決什么關鍵問題：井噴式增長的業務數字化需求和有限的 IT 能力之間的矛盾。具體而言，這里的 IT 能力主要體現在兩方面：一是組織能力，是否有專業的人以及人才的數量是否足夠；二是這些人是否有足夠強的武器去打贏這場仗?！拔淦鳌敝傅氖?IT 用的平臺、工具或者能力，華潤云認為最核心的答案是云平臺，將企業數字化轉型所需的各種能力定位成不同的 PaaS 平臺能力。在華潤云出現之前，華潤集團內有不少子單位已經用上了云

46、，并且不少業務跑在公有云上。但在集團看來，無論是作為央企的責任驅動或是從數據安全挑戰的角度考慮，由集團層面牽頭統一建設云是勢在必得的，而且這件事迫在眉睫?！霸俨唤y建云，下面好多單位就要自己建了?！? 中國卓越技術團隊訪談錄2022 第三季 云架構思考 為了打造自己的云，華潤集團依托華潤數科成立了相應的華潤云事業部。當時團隊把市場上國內外所有主流廠商的云“都摸了遍”。一番調研過后，團隊發現，由于這些廠商做云的初衷是解決自身的業務需求，因此其架構設計理念還是圍繞互聯網的場景出發，或者就是純粹為了賣服務器。很多中小企業做的是互聯網業務、游戲業務，那么采用主流的云就會覺得很合適，很方便?！毙ずＩ秸f道。

47、但對于傳統企業，情況則大不相同“傳統企業對云的訴求跟公有云提供的服務還是有很大差異?！毙ずＩ奖硎?，互聯網應用日常就有可能出現有百萬人或千萬個人的訪問量，因此其公有云服務的性能要求是“高彈性、高并發”。然而，傳統企業很少面對高并發的壓力，一個系統有 1000 人同時并發訪問已經稱得上是“很有壓力”。從華潤集團自身來說，盡管信息化建設在央國企陣營算是走在前列，但大多數系統還是傳統架構，還有些系統訪問量雖然很低，甚至低至幾個人，但數字化的場景是主要是 2B 類型（工廠、庫存、物流等等）其后臺運算邏輯的復雜性不小，對后臺運算的壓力比互聯網應用要大很多倍，且更重視架構的“穩定性、安全性、高性能”。另一個

48、關鍵問題是：當時多數私有云廠商提供的是最基本的 IaaS 服務，但是 IaaS 能力對于傳統企業來講，能夠創造的價值非常有限，因為離業務太遠。離業務越近的 IT能力才是業務側所需要的，那就是 PaaS 層。4 中國卓越技術團隊訪談錄2022 第三季 肖海山指出，雖然互聯網廠商也提供不少 PaaS 層的能力，但基本是依據互聯網的場景設計，這意味著如果傳統企業直接拿互聯網廠商的公有云架構來用，最終可能會發現“IaaS 能力不是自己想要的、PaaS 層也沒有相應的 IT 組織能力用?！比A潤要做的云平臺，是要讓自己所有的互聯網應用和傳統應用都能在上面跑起來以傳統企業的線下場景為主，輔以互聯網場景。其技

49、術架構設計，不僅要能支持主流與前沿技術架構，還要兼容大量傳統應用。拒絕敏捷開發，對分布式和微服務架構持謹慎態度 對于大量企業應用，業務需求有明確的業務確認方，因此華潤數科的研發團隊并不照搬互聯網模式“敏捷開發”模式?！氨仨毷窍认朊靼?，想明白了，業務確認了再來做，這樣才能做出好東西來，這一點是跟很多互聯網企業有很大的差異?！睋ずＩ浇榻B，華潤云的整個架構設計是進行了充分的研討過后才定下來。而華潤云下面所有產品的架構設計都需要經過他親自把關判斷產品適用于哪些行業、哪類企業、多大規模和處于什么發展階段的企業等，而這些判斷背后的依據是其過去十余年的咨詢經驗以及在華潤工作十多年的經歷。除了不照搬敏捷開發

50、模式，華潤云也不推崇大量采用分布式、微服務等前沿技術架構。微服務架構體系在前幾年就已經非常流行，尤其備受各大互聯網公司青睞，微服務允許研發人員以松耦合的模式來開發應用，盡管其具備靈活部署、可擴展、技術異構等優點，但同時也大幅增加了所需的服務器等資源成本，也顯著增加了后期運維的復雜性和成本。對大多數企業應用而言，大量應用微服務、分布式技術最后往往得不償失。5 中國卓越技術團隊訪談錄2022 第三季 事實上，團隊內部對于微服務的采用與否、如何用產生過不少思想碰撞。肖海山一開始便對微服務持謹慎態度，“微服務的理念很先進，它并沒有錯，但很多企業應用要全部走到微服務這一步，還需要很多年，投入很多成本?！?/p>

51、但由于華潤云研發團隊在組建初期從互聯網行業吸納了很多人才，因此也有不少人是傾向用微服務模式。等真正用過之后，大家才逐漸發現，微服務架構反倒會讓產品研發效率變慢，并且需要非常多的服務器資源才能部署出一套系統。以華潤云門戶為例，在產品設計之初就采用微服務架構，投入大量的人和資源，最終做出來卻發現業務側的可配置性存在較大的問題?！按蠹乙婚_始容易把大量的時間和精力花在微服務的設計上，而對業務側的可配置性欠缺考慮，不夠重視。因為大家原來在互聯網公司都是專注做某款面向 C 端客戶的產品，而不是賣軟件，采用敏捷開發模式，產品體驗有不合適就改，快速響應變化，不斷迭代?！钡且u軟件，這要求他們做出來的東西具有

52、高度可配置性，面向不同企業可以做動態調整，提高項目開發效率。到 2021 年，肖海山意識到這樣下去行不通，每做一個項目都需要投入大量的人做研發，成本太高。他決定大面積改造華潤云產品把微服務顆粒變粗，把“寫死”的代碼變成可配置化?！斑@是個很痛苦的過程?！背嗽崎T戶，肖海山表示，像監控中心、ITSM（IT 服務管理）等好幾個產品項目最終都被強制改過來，還是微服務架構，但顆粒變粗了、可配置性也變強了，客戶部署起來也簡單很多?！拔⒎盏姆较蚩梢宰?，但是不要走太急，微服務的做法可以有，但是不要拆得非常 6 中國卓越技術團隊訪談錄2022 第三季 細，我們還是要選擇一個平衡，就微服務顆粒度要科學、要合適，

53、這樣才能保障在有限的人、有限的資源的情況下，讓產品做得更好?！本劢勾笾行推髽I數字化轉型各方面痛點，華潤云采用了一套獨特的云架構，從底層 IDC共享到整個 IaaS、多云管理平臺，再到各種能力中臺。這套能力中臺能讓企業快速實現數字化轉型，讓企業僅用很少的 IT 人員就能完成數字化轉型，只需極少人員即可運維?？偟膩碚f，從華潤云的觀察和實踐來看，傳統集團型企業對云計算的訴求，IaaS 是占比最小的，但也是“最特別”的。傳統集團型企業要求的不是提供多厲害的彈性服務，更關心的是所提供的服務性能有多好、穩定性有多高、運維有多簡單。數字化轉型策略 華潤集團采取“云優先、智生長”的數字化轉型策略?！霸苾炏取笔?/p>

54、指華潤集團借助云計算這樣一個高效和安全的平臺，作為華潤集團未來 7 中國卓越技術團隊訪談錄2022 第三季 信息化建設、數字化轉型、智能化發展的基礎，幫助華潤集團更好地落地各種轉型，同時賦能華潤數十萬家上下游企業和行業伙伴?！爸巧L”是從業務價值的角度出發，擁抱新一代信息技術，探索符合行業特性、華潤特性的數字化轉型道路，鼓勵探索新模式、孵化新業態、培育新產業，塑造新的核心競爭能力。顯而易見，在該策略下，云是數字化轉型歷程的前置條件。其主張新業務盡可能云上部署，已有業務逐步云化部署，進而結合自身的產品優勢，逐步實現數字化、智能化轉型升級。從觀望到信任 過去兩年多，隨著華潤云平臺不斷迭代，目前華潤

55、云的 PaaS 及 SaaS 產品序列在華潤內部已經覆蓋了 26 個業務單元。盡管是華潤集團統建，但這朵華潤云，在剛面世之時還是會引來不少質疑聲。從在內部被質疑到被信任的這個過程，肖海山認為大致經歷了三個階段。第一個階段是觀望，這時華潤集團內的各個板塊、各業務單元均在觀望，大家都等著看集團“敢不敢上”、“上得怎么樣”。因此，首當其沖的必須是華潤集團總部的財務、人力資源等多個核心系統，“因為你敢把財務搬上去，敢把人力資源搬上去，就說明這個平臺是足夠穩定，因為如果財務、人力資源系統搬上去華潤云后出了問題，那無疑會波及華潤集團兩千多家子公司和 37 8 中國卓越技術團隊訪談錄2022 第三季 萬人。

56、”“開始搬集團的系統的時候，產品團隊的人著急，其他平行部門也不放心，就覺得 萬一這個不穩定，出了問題責任在我身上怎么辦？”肖海山回憶到，“我勸說沒關系，第一，出了問題責任都是我的?！薄暗诙?，你先搬一些系統來測試，你先上去看看。測試沒問題再搬生產。第三，反正我兜底了，出了問題任何責任都是我的，他們就放心了，那就搬?！碑敿瘓F敢于把總部系統搬到華潤云后，其他一些業務單元也開始“將信將疑”地上華潤云了，這時開始集團上云進入第二階段。肖海山回憶道，當時某個千億級單位的財務系統上云之后，整體性能提升至少 5 倍。上云后程序運行跑得快多了，這種變化讓業務側很是感觸。據悉，在華潤萬家的財務系統上云之后，華潤萬

57、家財務特地給華潤云發了封感謝信。對于華潤集團內的許多一線業務單位來說，系統運行“效率低、性能差”是老大難問題，而有著架構師背景的肖海山也意識到這跟架構性能問題有很大的關系。因此，在思考“如何在不給成本帶來很大的變化的情況下，能讓企業有上云的動力”之時，他想到的突破點是“性能”，“上云之后，我要讓大家明顯看到性能帶來的巨大變化?！毕到y性能可以說是華潤云架構自設計之初就被重點考慮的因素。另一方面，架構的安全可靠也是核心要素。肖海山表示，以往數據中心傳統資源池，每年至少會發生一次重大安全事故。而華潤云上線之后，至今出現重大安全事故的次 9 中國卓越技術團隊訪談錄2022 第三季 數為零，其架構在設計

58、之時就奔著“不允許任何一個單臺物理設備的故障影響業務”的目標而來。進入第三個階段，華潤集團旗下多個業務單元對于華潤云產生信任，紛紛主動找上門，希望能盡快搬到云上。肖海山強調，華潤云給各業務單位帶來的明顯變化是可以用財務指標來衡量的。以華潤萬家財務系統為例，其上云之前每年在 IBM 小型機折舊加維保的成本大概在 100萬至 200 萬，而從 IBM 小型機換到云上后，其一年只需花費 20 萬便已足矣。上云的價值 從上云的出發點和路徑來看，華潤集團旗下企業上云可以大致分為以下三類：1.第一類是響應集團戰略，將系統搬至云上。很多系統的架構無法進行大的調整，就直接遷移上云，并做架構高可用的優化調整，同

59、時也去掉了小型機。2.第二類是為了降本增效，希望通過上云能省一些資源，整體容器化，應用代碼和架構不做任何改造，也可以大幅度提升資源利用率。3.把應用做微服務架構改造，再單獨容器化?！澳壳暗谝活愓急染佣?，第二類和第三類加起來的比例不到一半?！毙ずＩ教寡?，過去華潤在信息化過程中購買了許多套裝軟件，這類軟件難以改造，要將其都解耦重構需要一定的時間。那么，在 IT 資源有限的情況下，基于華潤云的 PAAS 能力，如何讓數字化轉型可以更 10 中國卓越技術團隊訪談錄2022 第三季 高效地推進？肖海山舉了個華潤建筑重構 ERP 的例子，其中發揮核心作用的是華潤云PaaS 能力平臺：“數字化平臺”。為優化

60、建筑行業管理效率，已經使用 5 年的 ERP 已經成為企業數字化轉型的障礙。華潤建筑需要逐步解耦其 ERP 系統核心模塊，以開發出更符合其業務需求的建筑行業核心平臺?！盎谌A潤對傳統企業業務的場景的理解，我們把很多常見的、共性的東西，全部包裝成了標準組件?！毙ずＩ竭M一步介紹道，數字化開發平臺具有完備的技術組件、通用組件、開發工具能力，讓企業可以在不增加 IT 人員的情況下，進行數字化轉型，通過小步快跑的模式，低成本高效率完成大量數字化轉型應用的建設。最終，華潤建筑 ERP 改造任務僅花費一年半時間以及投入 12 個人便完成。華潤集團內現有超過 5 家單位基于數字化開發平臺進行 ERP 系統的解

61、耦重構或新增的大量數字化應用建設。SRE 一體化運維 在華潤集團實現整體上云的過程中，SRE 運維團隊起著關鍵作用。目前，該團隊主要面向華潤集團內外部提供一體化運維服務（如整體運維、整體上云、國產數據庫遷移等）和運維體系咨詢規劃及建設。據華潤數科華潤云事業部 SRE 服務部技術總監馮錚介紹，目前 SRE 運維團隊規模約100 多人，技術棧覆蓋操作系統、數據庫、容器、中間件、大數據、集成，以及重載商業套裝應用系統 Oracle EBS 和 SAP。SRE 緊緊圍繞著華潤云的愿景與目標，提供 11 中國卓越技術團隊訪談錄2022 第三季 華潤云整體上云+一體化運維服務的一站式解決方案?！鄙显七w移是

62、一項復雜而嚴謹的系統性工作，在進行上云遷移過程中，必須要有一套完整周密的方法來指導、支撐上云遷移過程。馮錚表示，針對某項上云服務，華潤云 SRE團隊基本上先對其系統架構進行梳理和評估，比如現有的架構有哪些缺陷和問題，如何讓架構變得更科學，通過哪個上云方案能夠達到什么樣的效果等等。據了解，SRE 運維團隊所提供的上云服務主要涵蓋 6 大步驟：系統現狀梳理和評估：采用“調研模板+現場/遠程訪談”的方式，對企業系統現狀進行收集、梳理和評估；上云技術路線規劃：遵循“可落地、可優化、可迭代”的原則建設技術體系，規劃適合企業的上云技術路線；試點上云規劃：選擇和規劃合適的上云試點，對后期上云技術路線規劃、云

63、平臺特性驗證提供參考；整體上云規劃：基于上云遷移策略要求，制定系統遷移計劃和方案、風險應對方案等，并建立團隊提供及時響應和服務保障支持；試點/整體上云實施：提供詳細的需求調研和方案設計，通過評審、測試等機制，確保上云實施的執行結果與計劃的一致性。信創遷移服務：基于華潤云自研全國唯一的信創一鍵切換平臺，能夠快速將原來大量存在的國外數據庫遷移到國產數據庫，確保數據庫結構、數據、程序的全自動處理。同時，團隊經過長期遷云實踐，總結出一套通用上云遷移管理流程“四階八步”，為集團及各業務單元在實施云遷移工作時提供方法指引和參考：12 中國卓越技術團隊訪談錄2022 第三季 四階：遷移準備、遷移實施、系統測

64、試、割接上線。八步：1.遷移準備；2.云資源申請；3.數據庫部署；4.應用部署；5.功能驗證；6.集成測試；7.數據同步；8.業務割接?！吧显撇粌H是物理位置的變化，更重要的是一次架構梳理、優化提升的過程，其目的在于提升 IT 管理水平和管理效率?！瘪T錚強調道。數字化轉型不只是 IT 的事情 上云，一方面是為了資源層面的成本下降，其更多的價值體現在企業的信息化、數字化、智能化建設的全面鋪開。如今，華潤云已在華潤集團全面應用，華潤集團下屬 25 個行業全面使用華潤云，華潤集團系統上云比例超過 99%，上云應用系統共計 800 多個；數字化方面，華潤云提供完整的數字化解決方案，已在快消品、燃氣、水泥

65、、醫藥、電力、地產等 8 個行業應用，涉及 100+個 PC 數字應用，40+個移動應用。華潤云上線后，華潤集團整體的資源交付效率提升 432 倍、基礎設施成本降低 30%、項目建設效率提升 70%、項目建設成本降低 45%?！捌髽I數字化轉型要回答幾個問題，第一，為什么轉？第二，往哪里轉？第三，怎么轉？”肖海山總結說，從企業側的角度，數字化轉型可以分為三大類型：企業戰略轉型?；谧陨硇袠I化的特點，再結合數字化的技術，衍生出一種平臺級或者生態盟主級別的新業務模式。而戰略轉型也分為主動戰略性和被動轉型，主動 13 中國卓越技術團隊訪談錄2022 第三季 轉型的企業很罕見，一萬家企業可能只有一家企業

66、發現主動戰略轉型的機會。被動轉型則比較常見，來自異業競爭、互聯網跨界等等威脅，行業龍頭企業需要積極應對，躲不掉就要直接面對。企業生態轉型。數字中國下的企業，必須匹配數字生態，離 C 端越近的企業被迫響應社會的變化，C 端上游也被迫跟著變化。這時候企業進行生態轉型的選擇主要有二：大企業主動打造生態，基于企業的行業領導地位，讓行業的上下游以我為中心，鞏固企業的生態地位，共同抵御異業競爭的行業沖擊；中小企業加入行業生態，融入互聯網的數字化鏈條。加強自身的企業核心競爭力，在生態中保持存在的地位和價值。管理、運營和用戶體驗的轉型。讓傳統的信息化從辦公室走出來，讓信息科技服務能覆蓋到企業的方方面面，讓原來

67、想管但管不了的場景有科技支持，讓信息科技服務所有必要的業務場景，進一步降本增效、提升體驗、節能減排等等。進入數字經濟時代，數據被視為生產要素，針對有些企業一做數字化轉型就先建個大數據中臺的現象，肖海山認為這是典型的“沒有從業務的角度來看 IT 的作用”的體現?！昂芏鄷r候企業沒想明白，只簡單把數字化轉型的事當做 IT 的事，IT 只是工具。數字化轉型永遠是業務的事?！痹谛ずＩ窖劾?，企業做數字化轉型必須先把業務場景想明白，比如在什么場景下需要數據、需要什么數據、需要用數據創造什么價值等等，否則建設的大數據中臺只會淪為擺設?！鞍褬I務想明白了，這時 IT 配合去落地就行。用最快的速度、最低的成本幫業務

68、做出來數字化轉型的效果，這就是 IT 應該帶來的價值?！边@也是華潤云的使命所在，從業務價值的角度出發，以云為基礎平臺和技術，把有限的 IT 資源放到創造價值最大的領域，推動華潤集團“上云用數賦智”，為華潤集團及旗下業務單元的數字化轉型提速。14 中國卓越技術團隊訪談錄2022 第三季 突圍電商大促場景，得物在高可用上的探索與實踐 采訪嘉賓：金思宇、陳貞寶、胡強忠 編輯：辛曉亮 大型電商系統并非一開始就具有完整設計的高可用特性，而是隨著用戶的不斷增加與業務的快速增長逐步演進與完善的。當前高可用架構體系是互聯網企業系統架構的基礎要求，隨著公司的業務發展，尤其是對于電商平臺，每次發生穩定性故障帶來的

69、影響越來越大，提供穩定的服務，保證系統的高可用已經變成了整個技術部面對的問題?；诖?，我們深度采訪了得物技術團隊核心成員，探索他們在高可用架構上的實踐、演進，深入了解大促備戰是如何進行的？異地多活體系是如何建設的？全鏈路壓測是怎么實踐的等過程。得物高可用架構演進 和大多數互聯網公司一樣，得物目前也是采用主流的微服務架構來應對高可用的挑戰。同樣的，得物也是從大單體演進而來，經歷了涵蓋服務規劃、服務拆分與合并、存儲拆分等過程的微服務構建，集成并自研了基礎開發框架及其腳手架、微服務通訊框架、微服務治理體系、微服務生命周期管理平臺、微服務支撐基礎設施、微服務安全設施，從大單體架構逐步演化成微服務架構。

70、15 中國卓越技術團隊訪談錄2022 第三季 在這一過程中，得物結合自己的業務背景，自研了符合自己特色的微服務架構支撐平臺，比如網關、流量回放平臺、預案平臺、DAL、全鏈路壓測平臺、灰度發布系統、微服務發布平臺、微服務統一調度平臺等，并在分布式核心場景中沉淀自己的最佳實踐設計，如服務的無狀態化、服務的冪等、分布式鎖、分布式事務、緩存失效的設計等?；仡欉^去，得物高可用架構的整體演進與中國電商平臺的業務架構的演進階段比較相似，大致可以分為四個階段。第一階段，得物早期，業務場景比較簡單，功能不復雜，團隊的規模也較小，使用的開發語言是 PHP，采用的是單體架構，在高可用的建設上也比較少，當時的主要目標

71、是為了快速滿足基礎的交易需求。隨著業務規模的逐步增大，團隊規模也越來越大，單體架構已經不能支撐業務的快速發展。得物開始做架構升級，語言從 PHP 轉到了 Java，框架上使用的 SpringCloud全家桶，業務域也進行了拆分，獨立出了訂單、出價、優惠、商家、商品幾個應用，但這個階段在服務治理上的建設還比較薄弱。時間來到 2019 年下半年，由于業務發展速度太快，得物的交易系統開始暴露出更多問題。一方面系統架構無法承載高并發的流量，經常出現性能問題；另一方面，前期業務模型的設計對日漸復雜的業務需求支撐也不友好。于是得物啟動了“五彩石項目”，按照領域驅動設計的思路，對得物交易體系重新規劃和設計。

72、只用了 3 個月的時間，就完成了整個系統的重構。新的架構形成新的 6 個核心域，對大數據量場景也做了分庫分表，得物也開始逐步建設自己的監控體系、服務治理體系、預案系統，在基礎設施中不斷升級，來確保系統的高可用。16 中國卓越技術團隊訪談錄2022 第三季 關聯閱讀：業務百倍增長，得物如何在三個月完成交易平臺重構？第四階段，隨著業務的進一步快速發展，業務規模越來越大，對交易系統的高可用、穩定性有了更苛刻的要求。一旦業務出現問題就會被快速放大，甚至出現輿情。得物就在原有架構不斷治理、升級的基礎上，逐步啟動了異地雙活、容器化項目，讓系統的高可用、可擴展、跨地域的容災能力得到新的提升。異地多活混合云架

73、構體系建設 前文提到，得物位了應對規模更大更復雜的業務情況，在高可用架構上做了異地多活、多機房部署等升級。災備架構選擇 目前常見的災備架構有冷備、熱備、雙活、多活等幾種。冷備：只有主數據中心承擔業務請求，備份數據中心定期同步主數據中心的數據或者在停機的情況下才開始對主數據中心的數據進行備份，當主數據中心掛掉，需要停機一段時間，手動拉起。從嚴格意義上講，在當前對分布式系統高可用的要求下，冷備技術不能算真正的災備技術，恢復時間過長，對業務影響較大。熱備：只有主數據中心承擔業務請求。主數據中心會實時向備份數據中心實時同步數據，當主數據中心掛掉，可以通過控制中心自動切換到備份數據中心，通過這種方式來實

74、現高可用。還有一種概念是暖備，與熱備架構類似，只不過不能夠自動切 17 中國卓越技術團隊訪談錄2022 第三季 換，需要人工介入。雙活/多活：分為同城雙活/多活，異地雙活/多活，跨國多活。多個數據中心都會承擔業務流量，不同的架構，在具體的落地細節上的復雜度也是相差較大。而且在不同的業務體系下，也會有不同的流量路由、機房部署方式。得物目前采用的是熱備+雙活的模式。熱備成熟可靠，在存儲層采用熱備，發生故障情況下，可以快速切換到備份節點進行恢復，備份節點一般不對外提供服務，因此熱備的資源利用率相對來講比較低。此外得物雙活，基于雙數據中心，兩個數據中心同時對外提供服務。這里杭州為主數據中心，主數據中心

75、承擔主要的流量（一般為 70%），在發生故障時，將流量切換到另一個數據中心。雙活資源利用率高，相對一個數據中心，更加的可靠，但是技術難度高，需要投入比較大的時間和人力成本進行技術建設，針對核心買家鏈路、微服務框架、微服務治理體系、微服務基礎設施等做了相應的技術改造來實現。按需配置多機房部署方案 多機房部署模式一般分為同城、異地（跨城）、跨國幾種，異地一般又分為遠端城市和近端城市兩種。一般情況在部署地區上有以下幾個方面需要考慮：兩個機房部署在同一個城市，如果遇到城市級別的停電或者自然災害，很容易出現兩個機房都不可用的情況，達不到災備的要求。兩個機房部署在異地，那么相對同城來說，同時遇到自然災害的

76、概率要小一些。但是選擇兩個較遠的城市還是選擇兩個較近的城市需要根據自己的業務場景、用戶屬性、數據同步延遲的要求以及實際需要解決的問題來決定的。18 中國卓越技術團隊訪談錄2022 第三季 選擇兩個比較遠的城市，比如北京和深圳，那適合的業務場景是對用戶以及中心數據進行分區，北方的用戶訪問北京的機房，南方的用戶訪問深圳的機房，比較適合本地生活服務類的業務場景。一個機房能夠滿足用戶的實用需求，能夠接受較長時間的數據同步延時。得物雖然是多機房部署，但不是這種模式，得物多機房部署的目的是可以對用戶進行調度，當一個機房出現問題的時候，自動調度到另外一個機房，面臨大流量或者促銷活動的時候，通過流量調度來確保

77、系統穩定。而且對于目前電商的業務模式，商品中心的數據需要確保兩個機房的實時性，遠端城市的部署方式是不適合的。得物在綜合技術、人力、業務復雜度、業務場景、時間成本等情況后，決定部署異地雙活-近端城市的架構模式，后續會逐步演進發展到兩地三中心、異地多活并且結合混合云的部署架構。異地雙活要解決的核心問題是“確保在極端情況下買家核心鏈路依然可用”，聚焦于買家鏈路的穩定性保障。在故障發生時，能夠將買家流量從一個數據中心調撥到另一個數據中心。從技術上，需要解決的一個難題就是如何確保買家跨數據中心調撥后，依然能夠保證事務的一致性。這一點非常的困難。舉一個例子，比如用戶訂單數據，該數據寫入杭州數據中心，但是當

78、流量調撥到上海中心時，用戶依然能夠在之前的事務上下文訪問到正確的數據。這意味著用戶訂單相關數據必須保證兩個機房都能夠正常訪問到，即使數據雙向同步。這里的數據會涉及到 MySQL、Redis、ES、HBase、MQ 等。同樣的，這條鏈路的服務依賴需要隔離在 19 中國卓越技術團隊訪談錄2022 第三季 同一個機房，服務路由需要就近路由避免跨機房路由，具體一點，假設數據都存儲在MySQL 的話，那么 DB 的數據就存在僅中心機房部署、中心寫單元讀部署、單元化部署（雙邊寫并雙邊同步）。這就要求從基礎設施到業務服務進行技術改造來實現?；A設施的建設與改造 為了更好的支持異地多活，需要做一些基礎設施，為

79、雙活奠定基礎。首先需要做一個雙活控制臺，用于整體控制流量調撥并監控雙活的運行狀態。之后對基礎設施進行技術改造以支持雙活，在這里會涉及到網關 DLB 層、RPC 服務路由與注冊中心、配置中心、MQ、TOC、Redis、MySQL、ES、HBase 等，還定制了數據復制中心（DRC）、數據巡檢中心（DCP、DAL）來實現流量的調度。確保流量調度后，在新的數據中心能訪問到正確數據，與之前事務上下文保持一致。業務系統的改造 業務系統的改造專注于核心買家鏈路，并不是對所有的鏈路進行單元化，有些面向 B端的應用系統甚至完全不用改造。不同的買家鏈路架構改造方式不同，比如庫存鏈路的 DB 會完全采用中心化部署

80、的方式；商品詳情鏈路中商品庫會采用中心寫單元讀模式；訂單鏈路則完全采用單元化部署方式。買家鏈路的改造需要從流量入口開始梳理，先進行單元化鏈路標記，接著梳理上下游，根據上下游是否需要單元化并進行改造。然后再梳理 MQ、Redis、MySQL、TOC 等中間件，確定相應的單元化方案。雙活的業務復雜度很高，對業務系統的影響也比較大，得物目前一共有 70 多個業務系統涉及單元化改造。這么大的改造對測試同學的挑戰也非常大，除了需要測試正常 20 中國卓越技術團隊訪談錄2022 第三季 的業務場景，還需要驗證雙活場景下的流量調度是否正確。高可用平臺治理方案 應對“天災人禍”為了預防突發事件，高可用架構需要

81、在設計時提前考慮很多的異常場景，即所謂的“天災人禍”，比如機器宕機、集群節點宕機、網絡抖動、網絡攻擊、下游服務異常、服務自身代碼 bug、消息堆積等。因此在做技術設計&實現時要做好相應的防災難設計與措施，比如通過機器冗余、集群故障失效轉移、主從復制斷點續傳、業務隔離、性能壓測、限流/降級、流量回放、變更控制等手段來保障系統的高可用。這里，可以把“天災人禍”的原因歸為幾類：1）硬件問題，比如機器宕機、集群節點宕機、網絡抖動、網絡攻擊，一般依賴于企業的基礎設施和相應的支撐團隊，這種情況一般通過災備來解決和預防，得物通過自建異地雙活來實現極端情況下硬件問題的故障防控。2）軟件問題，比如服務本身異常、

82、下游服務異常、代碼 bug、中間件異常等，這里是故障防控的重點，也是故障頻發的部分。軟件問題具體可以歸因為：（1）80%故障是變更引起的故障；（2）流量和容量變化引 21 中國卓越技術團隊訪談錄2022 第三季 起的故障；（3）依賴故障；（4）機房、網絡等環境故障；（5）其它：比如冪等失效、分布式 Id 溢出導致的故障。得物一般是建立變更故障防控、大促故障防控、日常故障防控，對軟件問題進行預防，從微服務本身、微服務上下游依賴、微服務依賴的技術環境三個部分梳理潛在問題，并提前做好相應預案，在問題發生時可以通過執行相應的預案來預防和進行故障的快速恢復。3）人為問題，一般涉及到各種線上誤操作，通過軟

83、件產品自身的完備性、成熟的技術規范、操作 SOP、管控措施、CheckList 來應對。此外在得物的系統鏈路中都有自定義的限流、熔斷手段，當埋點數據觸發閾值時，會執行指定的異常處理方法，進行限流或者對下游進行熔斷、甚至是通過業務開關直接對指定的業務進行降級。除了系統鏈路中自動的熔斷、降級措施外，我們還在自研的預案平臺中有配置的各種預案，當出現異常情況，會人工或基于埋點的自動執行，來實現優雅降級，確保系統的高可用。全鏈路壓測平臺 得物全鏈路壓測平臺于 2019 年 8 月底完成，在 2020 年的 618 大促首次使用生產環境進行壓測，經歷了多次大促實戰，目前已經能夠非常順滑的驗證核心鏈路應對大

84、促突增流量的穩定性。去年雙十一和今年 618，在限流和預案開啟或關閉的情況下，得物采用梯度遞增、脈沖、穩定水位進行流量驗證，分別經過 3 輪和 2 輪壓測后，核心鏈路達到預期的壓測目標，并且在大促當天所有核心鏈路均符合預期表現。得物整個全鏈路壓測平臺建設及實施涵蓋了以下內容：22 中國卓越技術團隊訪談錄2022 第三季 1）由 Fusion 封裝了壓測接入 API，所有中間件必須按照統一規范接入和使用；2）構建流量漏斗模型，即外部流量從網關入口開始，在每個調用鏈路上的變化比例，流量配比參考歷史雙十一峰值 QPS；3）通過 Mock 模塊處理外部依賴的調用鏈路；4）流量標透并建立影子中間件，包括

85、 MySQL、Redis、MonogoDB、Kafka、RocketMQ、HBase、ES、分布式鎖等；5）流量標透傳并進行核心鏈路改造，基于 Fusion 框架識別測試流量標，進行相應改造；6）建設測試環境和仿真環境；7）構建測試用戶和測試數據；8）實施單機接口測試、單機混合鏈路測試、全鏈路壓測。得物的流量標方案，就是要解決數據隔離問題，壓測產生的臟數據不能寫入線上環境，通過中間件平臺封裝的 fusion 腳手架，在 RPC、Redis、DB、MQ、跨線程中透傳壓測標，如果識別是壓測流量，產生的數據會寫入到影子庫，以此來實現數據的隔離，確保線上穩定，為全鏈路的壓測奠定了基礎。在全鏈路壓測平臺

86、的建設中，我們也逐步摸索出了得物特色的全鏈路壓測流程。得物的全鏈路壓測流程包括：系統摸高，限流演練，預案演練。通過全鏈路壓測，幫助發現系統性能瓶頸，限流配置，預案缺失等諸多問題。大促備戰經驗分享 大促是考驗電商高可用平臺的最好時機，首先作為前提的是，每一次大促都會有一個 23 中國卓越技術團隊訪談錄2022 第三季 目標策劃，確定本次大促的業務和技術目標，之后進行大促備戰。得物大促備戰主要涵蓋三個部分：1）整體穩定性保障；2）業務需求交付；3）組織保障。大促需要以保障穩定性為前提，做好按時的業務需求交付，同時整個組織需要具備強悍的項目管理能力。到目前為止，得物整個大促備戰從整體保障、域內保障、

87、組織保障都有清晰的 SOP 和系統化的沉淀。一般分為啟動階段、規劃階段、各域執行交付階段、壓測&驗收階段、作戰階段、作戰復盤階段實施等等，大促備戰是井井有條的。首先，得物有專門的 PMO 組織來整體保障需求的流水線交付，保障大促需求的按質交付，下面介紹得物的穩定性保障，主要分為兩大部分：大促整體備戰；各業務域備戰。大促整體備戰，顧名思義從全局視角關注突增流量對全域買家鏈路的影響，確保在大促當天這些核心買家鏈路應對突增流量的穩定性。因此，首先會先對業務目標進行拆解，之后確定各個鏈路的流量，做好鏈路的容量評估以及各個服務的擴縮容。之后會從鏈路的穩定性入手，梳理鏈路的架構風險、鏈路自身的風險，做好鏈

88、路的預案和演練。最后，通過幾輪的壓測，確保各個主要鏈路滿足既定業務目標的流量。整體上會規劃好大促推進的節奏，準備當天的大促備戰。各業務域備戰，則是圍繞著業務域的核心鏈路穩定性展開，這些鏈路一般是 P0 鏈路，規劃需要做的事情，并在總體節奏上符合整體大促備戰的節奏?？偟膩碚f，鏈路穩定性保障一般會從幾個部分來展開：1）架構大圖、業務鏈路梳理；24 中國卓越技術團隊訪談錄2022 第三季 2）可見性建設；3）風險識別與架構治理；4）可控性建設。下面做簡單描述。架構大圖，涵蓋業務架構、IT 架構，關于架構圖，大家都很熟悉了，推薦一個架構模型C4，可以使用 C4 的 L1、L2 來清晰描述 IT 架構。

89、接著是域用例梳理，通過域用例推導業務鏈路，業務鏈路一般是域用例的頂級服務交互。一個業務鏈路的入口，一般就是一個服務，這個服務由服務自身、服務上下游依賴關系、服務依賴的底層技術環境（如 RPC、DB、緩存、MQ、Job、JVM、容器、物理機等）三個部分構成。通過架構大圖、業務鏈路梳理，就可以把域內系統和鏈路描述的比較清晰，使我們對構建的系統就有比較全局性的理解。這一步相當于我們穩定性建設的目標判斷?？梢娦越ㄔO，得物聚焦在系統監控大盤、業務鏈路大盤、域業務監控大盤，以及系統和業務鏈路精準報警幾個部分構成。通過可見性建設，我們可以實時觀測系統、業務鏈路的運行狀況，及時發現正在發生的風險以及潛在的風險

90、。風險識別和架構治理，聚焦在鏈路風險識別并制定治理方案。有了可見性建設，我們可以從鏈路通訊的歷史數據，主要圍繞 P0 鏈路進行體系化的鏈路風險分析，一般涵蓋架構變更風險、SLA 風險、超時和重試合理性風險、強弱依賴風險、鏈路調用風險、鏈路依賴技術環境風險、集群或拓撲風險等，之后針對識別的風險制定相應的架構治理方案?？煽匦越ㄔO聚焦于風險識別與預案體系。風險識別，我們會通過精準告警、SLO 巡檢來識別，SLO 巡檢有相應的 CheckList 判斷是否系統有故障發生，并查看風險發生鏈路對應的預案。在故障發生之后，可以對故障快速定位和止損，理想的目標是每一個故障都有相應的預案應對。實際中，并不是所有

91、的故障都有預案，但可以根據歷史故障和一些先驗知識將故障進行歸類，建立相應的預案。另外，預案要能方便執行和觸發。25 中國卓越技術團隊訪談錄2022 第三季 得物在出價庫存域大促穩定性保障方案，整體方案主要涵蓋以下內容：大促作戰手冊：梳理大促前、大促進行時、大促結束時需要按照時間節點完成的作戰事項；業務鏈路穩定性保障：容量評估、預案與演練、接口限流、流量治理、壓測與復盤；架構治理：架構分析與核心鏈路梳理、慢鏈路治理、DB 治理、Redis 治理、JVM治理、定時任務/數據回流與商家后端管控；資損防控：梳理資損點、應急工具、處理 SOP 等；應急工具：數據核對、出價應急處理等。寫在最后 高可用是互

92、聯網企業系統架構的基礎要求之一，從架構師所能解決的問題的能力劃分，小到解決一個子域或模塊，大到一個組織，要求的能力完全不同。架構師需要具備準確的定義問題能力和解決高可用系統面臨的技術挑戰的能力，這要求架構師具備強的思考力以及解決問題的技術能力。構建高可用的系統一般要求架構師能夠：1）具備合理的架構設計推導邏輯；2）理解業務并將業務挑戰映射到技術挑戰；3）從 0 到 1 構建一個滿足業務目標的高可用系統；4）在快速業務迭代演進的過程中保持系統高可用。首先，架構設計推導邏輯，是架構師最基本的要求，要求架構師能夠從用戶問題洞察出發，理解用戶問題的解決路徑，定義商業流程及組織角色，構建出系統業務架構；

93、接著，從業務架構推導 IT 架構，即應用架構、技術架構和數據架構。這就要求架構師 26 中國卓越技術團隊訪談錄2022 第三季 具備架構分析、設計的相應方法論、工具。比如 TOGAF 企業架構方法論、DDD 方法論、C4 架構模型、UML 建模工具箱、四色模型等等，形成一套自己實戰的方法論。第二，理解業務并將業務挑戰映射到技術挑戰，就要求架構師在業務理解下，能夠設計合理的架構方案并引導架構活動實施。架構方案要從明確的業務或技術目標展開并對目標合理性進行一定的干預，基于當前的商業環境、企業技術基礎設施、企業技術文化，在有限資源和成本約束下，通過合理的架構活動滿足目標用戶需求，最終確保技術方案實施

94、能夠實現商業價值。架構師不是僅僅解決用什么技術、什么架構去實現的問題，而是要考慮業務的方向，從技術角度如何合理的實現，為企業業務支撐帶來更高的 ROI。最后，架構師需要具備較強的微服務架構及其支撐的基礎設施相應儲備，微服務架構一般包含服務拆分與合并、微服務開發框架、微服務治理體系、微服務生命管理平臺、微服務支撐基礎設施、微服務安全體系等等能力。整體知識非常的龐大，當架構師對微服務架構有深入理解和支撐基礎設施較為廣度及深度的知識儲備，并且通過實踐進行驗證積累實踐經驗，就能夠從高可用目標出發，進行合理技術選型，實現服務規劃、構建和治理，使得服務構建和之后的演進都能滿足高可用目標。27 中國卓越技術

95、團隊訪談錄2022 第三季 嘉賓介紹 金思宇：得物技術 Leader 畢業于東北大學，先后在中興通訊、阿里巴巴、唯品會任職，并有 2 次創業經驗。對電商及上下游有比較豐富的開發及業務架構經驗。19 年加入得物 App，目前主要負責交易平臺及中間件平臺，帶領團隊支撐得物 App 交易域的業務需求，完善業務基礎能力；同時負責中間件團隊的管理及技術演進規劃。陳貞寶：得物出價&庫存 Leader，曾在 Sybase、廈門銳特、阿里巴巴任職，有 5 年創業經歷。曾負責 2 次 S 級大促以及多次的域內穩定性保障，在架構設計與治理、大促穩定性保障有較多實戰經驗和體系化思路。21 年加入得物 App，目前主

96、要負責得物出價&庫存團隊，帶領團隊完成技術規劃、業務交付、穩定性保障等工作。胡強忠：得物業務架構師，曾在中國航信的不同分支機構任職，有過一次創業經驗。對 OTA、電商行業有較豐富的開發、架構經驗。19 年加入得物，目前主要負責交易域的架構演進規劃、業務領域建模、穩定性治理等工作。28 中國卓越技術團隊訪談錄2022 第三季 用三年替換掉二十年老系統，民生保險數字化轉型秘籍 采訪嘉賓：沈勇毅、孔偉、蘇彥春 作者：Tina 作為傳統 IT 鐵三角的核心腹地，金融行業過去十年的“去 IOE”運動備受關注。這種在過去 30 年中被廣泛使用的集中式架構逐漸難以適應金融業務的線上化、數字化、智能化需求，正

97、在逐漸被替換。因為需要修改底層技術，涉及到很多代碼的重寫、技術架構的重組和遷移，去 IOE 基本上是一種“小步慢走”的過程，本身就是 5-10 年的工作。金融行業的變革從銀行開始，逐漸帶動了保險行業。這幾年保險行業的數字化轉型走得特別快，一眾頭部保險公司都在自我改革以適應時代的改變。金融企業的數字化轉型，通常是規劃長遠、實施復雜的項目，需要有懂技術、有大型項目經驗的人，做出既穩妥又大膽的決策，而一般的企業不可能無限制在技術上進行投入，那么在投入有限、人才缺乏、技術實力儲備不足等剛性約束條件下，轉型之路究竟該怎么走？絕大多數機構并沒有清晰的答案。作為一家中型金融機構，民生人壽保險也曾面臨上述困難

98、。2019 年的時候，民生開啟了一場快節奏、深層次的數字化轉型，將用了近二十年的架構，一舉搬上了混合云架構上。原來需要 5-10 年時間的項目，也只花了 3 年就宣告完成。民生保險探索出來的這條數字化轉型路徑，或許也能給亟需變革的其他中小型企業帶來一點啟發。29 中國卓越技術團隊訪談錄2022 第三季 重構核心系統，一次性到位進行轉型 在1955年首屆財富500強名單中，只有12.2%的公司在2014年仍然保持在該位置。雖然一些下滑是因為品牌重塑或并購，但其中大部分反映了許多曾經的大牌未能在現代社會中生存下來的事實。在技術不斷進步的環境中，未以正確的方式接受變革并進行創新，這些衰亡的企業是帶有

99、警示意義的例子。一般企業都是循序漸進的發展，但是新技術的革新，讓企業的 IT 環境可能進行革命性的變化，沒有壯士斷腕的決心，可能真的無法適應業務的發展而被淘汰。一邊是當前企業都有變革的壓力，另一邊是金融企業里的特殊現狀。金融行業有自己的特性，使用的是一些成熟的技術或者在其它領域已經應用多年的技術。而現在，數字化轉型普遍是將已有互聯網的技術、流程、實踐置于服務的構思和交付方式的核心。這也就是說，徹底、全面的轉型意味著“不破不立”。民生人壽保險面臨的狀況也是如此。在 2003 年成立的時候，受制于當時的技術環境，民生人壽保險采用了傳統的 IOE 架構，以及單體應用。技術架構的層面發展到現在，已經變

100、得陳舊，應用之間的耦合度也非常高，很難去適應現在快速業務的變化。在過去二十年的時間里，民生保險在集中化的 Oracle 數據庫中積累了大量數據，但各方面的指標口徑沒有進行統一，數據也缺少標準治理。民生保險的轉型目標是，用“民生保險”公眾號和官網將 90%常用的業務實現線上處理、用“掌上民生”實現保單銷售全流程線上化，通過引入人工智能實現運營服務的自動化，打造了“業務中臺”和“數據中臺”雙中臺模式，以支撐公司轉向以客戶為中心的經營 30 中國卓越技術團隊訪談錄2022 第三季 模式。圖源：https:/ 技術選型是項目中最大的風險點 壽險行業的數字化轉型在此之前并沒有成熟的案例。作為求穩的金融企

101、業之一，民生保險沒有在老系統上進行“修修補補”，而是進行徹底變革。民生新一代的 IT 建設分為兩大部分，一部分是建設新一代的業務核心系統，另一部分是重建技術架構。在基礎架構選型的時候，民生保險探索過多種路徑，包括超融合，自己搭建Kubernetes集群支撐應用，基于 MySQL、PostgreSQL、CDH 用開源搭建大數據平臺，但考慮到 31 中國卓越技術團隊訪談錄2022 第三季 使用的效果和維護的成本，最終還是放棄了完全使用開源的實現方式。原來使用的 Oracle 產品有自己的特色，能同時適用于交易場景和分析場景，所以在這一塊兒上并沒有一個對等的可取代它的軟件?，F在，互聯網的實現思路是將

102、交易型的數據庫和分析型的數據庫拆解開來，再加上大數據平臺去做海量數據的建?；蛘哂嬎隳芰Φ闹??；诖?，民生選擇了分布式數據庫 TDSQL、TBase 等來替換掉 Oracle。同時考慮到新一代的業務架構是基于分布式 Kubernetes 集群，適應未來 5 到 10 年的發展變化，核心應用比較倡導微服務網格化和基于云的研發應用一體化的模式，所以底層基礎架構一開始定位為公有云服務。但在把主流國內云廠商看了一遍之后，從數據資產的私有化來考慮，發現公有云的方式不完全滿足現在金融行業的需求，于是民生保險跟騰訊深度合作，為大部分的數據和核心應用建立了一個私有云，再用公有云承載對外流量，以及實現活動場景下

103、的彈性擴展預留。新一代業務系統和新一代云數據中心都是采用的最新的技術，跨度很大，選擇新技術也意味著接受挑戰。針對復雜的技術和業務場景面臨很多未知的情況，前期在做第一輪試驗性“掌上民生”App 產品時候，怎么運行，怎么快速解決技術上的問題，沒有一個可以用來參考的標準，還需要充分融合整個應用架構和云平臺 PaaS 的能力，來尋找一個最佳的均衡點，所以這個項目中最大的風險也是來自于初期。整體的架構設計和探索“花了大概 5、6 個月的時間才能定下來”，民生保險數據服務部副總沈勇毅表示，這也是整個項目開頭最難的一個點。32 中國卓越技術團隊訪談錄2022 第三季“采用新技術總會有一定的風險，作為吃螃蟹的

104、人，總歸是要慢慢摸索”，沈勇毅介紹說。但經過了半年的并行期以后后面就很順了，因為已經很清晰地知道自己的技術路線怎么走，業務轉型的時候要考慮哪些問題，就相對來說按部就班地去做，只是看時間到底拉的多長。傳統金融機構的技術架構升級有著復雜的步驟，比如先建立一個數據中心，再建立第二個數據中心，逐步考慮兼容，是一個 5 到 10 年長遠的發展過程。民生保險的數字化轉型從 2019 年啟動，采用比較先進的混合云基礎架構和云原生的業務架構，一步到位地實現了兩地三中心、同城雙活、災備，到投產上線、存量遷移，總共只花費 3年時間，創造了一個行業里少見的案例。技術投入要講究一個“均衡點”CXO 控制著整個項目的風

105、險系數。在企業的轉型過程中，技術只是一個應用，任何改變，如果沒有考量到“人”的因素，必然無法達到真正的轉型。人的因素可以分為兩個部分。一方面是面向“消費者”。數字化轉型的根本起源是“業務訴求”。因為人口眾多，所以各行業都大量增加了線上業務，進行深加工，所以底層的數字化轉型它其實不是一個技術層面的推動，它是一個業務層面的推動，是出于業務的需要。民生保險在轉型是將視頻、圖章、監管、報送等等這些系統業務進行線上化，線上業 33 中國卓越技術團隊訪談錄2022 第三季 務還需要有數據的二次加工和分析。在具體業務場景上，推動業務層面去使用“新技術”，改變業務模式、運營模式、服務體系，這些都是面向消費者的

106、事情。另一方面，“組織內部的人”更是轉型的成敗關鍵。技術和產品的問題總能夠去解決，引入新技術不是最難的事情，這可以通過引入比如騰訊這樣的云服務商作為合適的合作伙伴，借助于各行各業的經驗支撐技術的轉型。而業務上的問題，主要靠組織和管理層面?！耙话咽帧倍麻L的決心和戰略決定了“轉型”的基調，然后管理層才能從公司層面明確建設目標，制定規劃，內部各部門的協調和合作，從頂層向下推動整個公司轉型。在數字化轉型中，CTO 或 CIO 也起著比較決定性的作用。一方面，作為“總設計師”，他需要根據企業的實際情況來去選擇一個最佳的路徑。數字化轉型的路徑不止一種，基礎好一點的可能循序漸進，每年可能動一點點，但是它的

107、代價可能是花費的時間會很長很長。之前的基礎差一點的，在技術大的變革時代，可能采取相對大膽激進的策略，能夠在比較短的時間內能實現彎道超車，達到既定的目標，但是可能執行起來的整體風險也會比較高。一步到位還是逐步迭代，這些需要CTO 或者 CIO 來做決策和選型?！癈TO 控制整個項目的風險系數，在不同的階段去調整不同的風險”，作為民生保險信息化服務部門負責人，沈勇毅的角色也相當于 CTO 或者 CIO。另一方面，CTO 還需要靠確定整個組織架構，構建符合數字化的新的人才和體系?！懊裆@個項目的周期跨度 3 年，這也是我們有史以來最長的一個項目。參與的人數 34 中國卓越技術團隊訪談錄2022 第三

108、季 也很多，就我們自己民生和各個廠商的參與人數基本上全部加起來高峰的時候有 400-500 號人?！痹诙鄰S商的管理上，合作能力的配合上，實施能力的管理上，包括民生自己內部多部門的管理和協調上，其實都有一些挑戰。另外是人員能力，涉及到很多新技術引入，雖然很多新技術在互聯網行業已經成熟，但對民生這樣的一個金融企業來說，這個技術卻是全新的。對民生保險來說，項目的實施需要很多懂技術，又有很多有大型項目經驗的人員去推動。而且項目實施之后，技術怎么去沉淀，怎么去傳承，怎么去保證確保所有的技術迭代和穩定的運轉，這都是需要想辦法解決的問題。這也是大多數轉型中的中小企業需要面對的問題：作為一個甲方企業，不能無限

109、制的在技術上去投入。沈勇毅表示技術人員的投入也要講究一個“均衡點”，民生的辦法是借助于騰訊這樣的廠商來接一部分基礎云平臺的部署和持續運維問題，同時也要清楚雙方邊界。但在應用層面還是要做到自主可控，培養自己的技術隊伍。民生已經有專門的技術架構的團隊，也是為了適應整個云的變化，近幾年重構了這個團隊，從原有的 IOE 的模式直接進行了轉型，更多地去實現管理的職能或職責，做好資源分配和運用。切割二十年的老系統 民生保險混合云有著自己的模式，基于國產自主生態的私有云、公有云、信創云混合的新一代基礎設施。35 中國卓越技術團隊訪談錄2022 第三季 民生將內部區域劃分為幾個大功能區，公有云更多是服務一些外

110、網的業務，比如官微、官網、掌上民生。在項目實施過程中，開箱即用的公有云還承擔著一個比較大的作用，就是在緊急的時候充當測試環境，畢竟私有云的搭建還包括購買服務器和網絡等。辦公和核心放在了私有云上，這也是比較傳統一些的 IT 交付模式。私有云基于騰訊云專有云全棧解決方案 TCE（Tencent Cloud Enterprise）打造，包括 70%節點基于通用 x86 架構的私有云和 30%節點基于全國產芯片為基礎的私有云。騰訊專有云和公有云由同源同構的一套代碼實現而來。騰訊專有云在金融行業落地時，還在網絡、硬件、服務、網絡安全、防護上，針對金融用戶的屬性做了深度定制。作為騰訊云金融的主打技術產品之

111、一，TCE 最早的實踐案例可以追溯至微眾銀行，逐步擴展到交通、工業制造、傳媒、零售、政府、泛互聯網等行業，打造了建設銀行、深證通、中國銀聯、永輝零售云、央視頻等多個行業標桿。據騰訊介紹，TCE 本身歷經數十次版本迭代，增強的功能和特性超過 500 項，涉及代碼數百萬行，也有完整的交付管理流程和自動化工具，從需求調研包括高低階方案的設計，到基礎設施包括云平臺的實施，以及數據跟業務的投產遷移。民生保險于今年 5 月 1 號開始切割，當時處于疫情全封閉的狀態，數百名項目參與人員居家隔離，實現遠程“云上線”。關鍵線上業務還挺多，需要去做一些協同和管理?！按蠹叶际歉髯栽诩依?，去做了一個這么大的切換。這還

112、是挺厲害的”，沈勇毅感慨。項目切換過程中，大家的工作有一個“完整的清單”，每一個任務由誰負責，大家都要清楚自己在做什么，明白自己執行到了哪一個步驟，都需要非常明確和細致。在各個組織結構上分得很清楚，由“總控”去整體把控，底下有各個執行組、指令組，各個平臺的支撐組、支持組，還有各模塊的用戶驗證組，以及騰訊也有一支支持隊伍，大 36 中國卓越技術團隊訪談錄2022 第三季 家不斷地相互之間去協調和通信，經歷一個月的多輪預演，最后正式切換。難度和風險最大的有兩個，第一個技術選型，在第一次引入新技術試錯的時候，第二個是最后一次性切割的時候?！鞍凑瘴覀儸F在整個策略，遷移過程當中絕對不大會有一次性遷掉的那

113、種模式，但是就算分階段，分步驟慢慢去切割，到最后也有一次整個的最后切割。就像 5 月份云切割就是最終的一個版本，最終的一個全量的掃尾切割。失敗的可能性最大的就是存量掃尾切割這一塊?！薄耙驗樗械臍v史的問題，歷史的債，肯定需要在那個點上做一個切割和梳理。我們也是一個快 20 年的一個公司，那么積累的歷史問題不會少。其實在最后一次遷移過程中，我們還是遇到了一些不一定需要臨時去解決的問題，這些問題我們會放到后面慢慢再梳理?！睖p少風險的辦法，就是“最后一次切割之前，一定要把風險看得清楚，把問題理得清楚，再去做這件事情?！比缃?，“新一代”的業務系統已經穩定運行數月，各方面能力得到了明顯提升，也曾在切割之

114、后支撐了民生有史以來并發量最高的一個業務節點。另外，云平臺成本提供同樣的計算資源的情況下，要比原來至少節省一半以上的成本。且從安全性上來說，應對一些重保也是會比原來要好很多。37 中國卓越技術團隊訪談錄2022 第三季 寫在最后 數字化發展和數字化轉型已成為全球多個國家的戰略?？梢哉f企業進行數字化轉型不是可選項，而是必答題。企業數字化轉型的動力也是現實的：在疫情時代，數字化協同能讓企業能夠去高效地運轉下去；線上化和新渠道上的用戶運營是企業活下去的關鍵動力；新技術能夠更加地降本增效，提升服務體驗。民生保險的彈性、穩定的云原生方案，也是保險企業轉型的一個典型樣本。對比國內外保險行業，沈勇毅認為，無

115、論是全球還是亞洲的同類企業，雖然他們在業務邏輯設計和敏捷方法論上更為先進，但國內企業借助敏捷加上分布式交付，以及云廠商的成熟運轉模式，在引入新技術的速度上比國外企業要快不少。服務過幾千家金融企業的騰訊專家也表示，不管在保險行業還是在金融行業，甚至在一些現在比較特殊的制造行業來看，中國在各個業務場景，各個行業的業務場景上面是足夠豐富的，也是領先于其它國家的。在使用所謂的互聯網技術或者使用所謂的數字化轉型技術上，幾乎所有的行業都不落后于國外，甚至快于國外。最重要的是，互聯網企業在創新和創造的過程之后，能將這些技術變成了一種成熟的基礎架構技術，賦能給金融行業、制造行業等，讓這些技術應用得比國外更快、

116、更強。采訪嘉賓 沈勇毅，民生保險數據服務部副總經理 孔偉，騰訊云專有云產品中心首席產品架構師 蘇彥春，騰訊金融云交付總監 38 中國卓越技術團隊訪談錄2022 第三季 從基礎架構到用戶體驗，字節跳動是如何打造移動端架構團隊的？采訪嘉賓：孫念、楊萍 采訪：Tina、閆園園 編輯：閆園園 2012 年，字節跳動成立，到今年，正好是它的第十個年頭。雖然在年齡上，這家公司還非常年輕，但從影響力上來看，它早已成長為移動互聯網時代的新興勢力。如今提起這家公司，外界給它貼上了很多標簽，其中令人印象深刻的無外乎：龐大、低調。的確，字節跳動鮮有發聲，這也使得它與一眾互聯網巨頭相比，多了幾分神秘的色彩。不過，如果

117、要探尋字節成功的原因，引用一位大佬總結，創始人張一鳴的一句話或許能成為答案：字節跳動的核心競爭力，直接來說是我們的產品，產品背后是我們的技術系統，技術系統背后是我們的團隊和文化。如今，再過多去渲染字節的產品稍顯多余，畢竟對于開發者群體來說，目光也更多的聚焦在后半句持續、豐富的 APP 研發的背后究竟有著怎樣的技術支撐。在本期訪談中，InfoQ 有幸采訪到了字節 AppInfra 團隊。作為字節跳動移動端基礎技術的研發團隊，他們主要負責字節跳動的移動端基礎設施建設，支持的產品包括但不限于抖音、今日頭條、西瓜視頻、飛書等，在與他們的交談過程中，我們沿著團隊一路成長軌跡探尋到了字節跳動移動端基礎設施

118、的構建之路，以及支撐如此冗雜的工作背后的 39 中國卓越技術團隊訪談錄2022 第三季 團隊精神和文化，現整理此文，希望能對讀者有所啟迪?，F象級 App 爆紅帶來團隊成長 2018 年，抖音日活破 2 億，一躍成為中國頭部 App 之一。這一年，也被外界稱為“字節跳動成為巨頭，與 BAT 們正面交鋒的一年”，自那時候起，字節業務開始觸及多個領域，擴大旗下 App 矩陣，其中，多款 App 獲得了成功。在外界看來，這是字節的高光時刻，但人們看不到的是，彼時字節的內部也開始做出轉變來應對業務的高速發展。以本文的主角 AppInfra 團隊舉例，其前身可追溯到之前支持移動平臺的基礎技術部門。2017

119、 年之前，基礎技術部門大約只有十幾個人規模；2018 年之后，業務的迸發促使部門開始擴張，“2019 年至今，我們吸納了不少領域內的專家，一方面幫助團隊支撐起平臺職能；另一方面也開始投入做一些技術研究?！睏钇颊劦?。在此過程中，基礎技術部門逐漸孵化出今天的 AppInfra 團隊。業務多，場景也隨之多樣化，對于技術團隊來說，堆人頭、拼時間勢必不是長久之計，這種情況下，整個公司開始更加注重技術復用。對于 AppInfra 來說，他們的主要職責，正是將場景中的通用技術能力抽象出來，加以建設，沉淀出通用工具再落地到業務中去。AppInfra 的應用基建過程覆蓋了整個開發周期中的各個環節，包括本地編碼、

120、代碼審查、測試、打包、部署、性能優化等。發展至今，整個 AppInfra 團隊的規模已經逐步擴大，并且進一步細化為了四個子團隊AppHealth 團隊、Research Center 團隊、端智能團隊以及 Devops 團隊。AppInfra 團隊使命是提升移動端效能、性能質量、產品核心指標和智能化水平，并關 40 中國卓越技術團隊訪談錄2022 第三季 注新技術研究與落地。那么為什么要分化出這四個方向呢？對此，另一位受訪嘉賓孫念總結為團隊的定位是為支持業務而生。他表示，與其說團隊的架構是自頂而上規劃而出，倒不如說是隨著業務的需求慢慢生長出自己的形狀來的貼切?！澳?AppHealth 團隊來說

121、，當應用達到一定量級，性能、穩定性等指標會直接影響用戶產品體驗。隨著業務規模持續增長，這部分問題一旦開始凸顯，團隊也會加大這些方面的投入?！庇纱艘部梢?，組織架構的演變其實是和技術、業務息息相關的。當業務改進時，新技術就會通過架構的分支與原有技術連接在一起，共同工作，更高效率的解決業務需求。如果把組織架構的成長分為支持業務而生、賦能業務中去、引領業務發展三個階段的話，目前看來，AppInfra 團隊已經同時邁入了第二階段與第三階段。那么，對于一個通用技術建設團隊來說，它們是如何與業務團隊進行有效協作，從而發揮技術能力的最大價值，更好的賦能業務呢？對于這個問題，楊萍是這樣回答 InfoQ 的：第一

122、，明確職責是前提。在字節內部，雙方團隊的職責是比較明確的：業務團隊主要是以需求迭代和業務交付為目標，他們的側重點在于保障需求側的交付；而 Infra 團隊主要是以技術方向為目標，側重點在于技術的實現情況以及解決技術難點。第二，保持緊密的協作關系。在業務團隊提出需求后，背后的技術或者中臺團隊會迅速調整去做支撐，同時技術團隊還充當業務團隊的智囊團角色，以應對業務團隊可能會面臨的各種突發技術狀況。另一方面，業務團隊在長期需求迭代過程中也會有比較多的業務視角經驗，他們會將這種經驗傳導到技術團隊中，從而沉淀出典型的解決方案或者技術上的經驗，賦能給更多業務?！翱梢哉f，這兩個團隊之間更多的是一個哺育與反哺育

123、的關系?！?1 中國卓越技術團隊訪談錄2022 第三季 性能優化已成移動端開發重要議題 我們做優化，到底優化到什么程度才算可以呢？我想字節文化中的敢為極致能夠給予我們這個答案。從 2007 年興起，移動端已經經歷了十幾年的發展。目前來看，移動端的技術棧，可以用百家爭鳴來形容：原生 App 技術棧：安卓平臺的 Java 技術棧，iOS 平臺的 Object-C 技術?；?Swift技術棧?；旌?App 技術棧：典型代表有 PhoneGap、Cordova、Ionic 等框架?？缙脚_ App 技術棧：典型代表有 React Native、Xamarin、Flutter 等。對于字節來說，移動端的主

124、要技術棧也無外乎如此，“我認為，近幾年來看移動端開發的架構或者框架演進過程并沒有發生質的變化，技術棧的出現也屬于漸進式變化，包括底層編程語言以及 UI 層面?！睏钇冀榻B道。同時她也談到一個新的趨勢，相較現如今比較成熟的技術棧來說，大家開始更關注 App 體驗和性能的優化。對于擁有旗下多款 App 的字節來說，這一趨勢顯然更需要提起重視。也因此，其中一部分重擔落到了AppInfra 子團隊 AppHealth 團隊身上提升全產品線的性能、穩定性和工程效率。作為 AppHealth 團隊的負責人，孫念畢業后的第一份工作是在高通集團，“當時主要是做安卓底層和芯片比較緊密的系統軟件的優化”。后來隨著手

125、機廠商的快速發展，他轉而加入手機廠商做安卓系統的相關優化。如今，再總結這兩段工作經歷，孫念感觸頗深，他認為自己的工作層面從偏底層轉而到應用層面，明顯對自己的技術視野和深度上有相當大的幫助。42 中國卓越技術團隊訪談錄2022 第三季 2019 年，孫念加入字節，他回憶當時擺在自己面前的第一個任務就是組建團隊。最開始，團隊成員中擁有做監控能力的開發者比較多，“所以，當時的我們主要是做性能監控，一方面是加強線上的歸因能力，另一方面是加強線下深入分析的相關工具建設?！彼M一步介紹，對于線上和線下來說，其實想要監控的指標和發現的問題其實是一致的，但更希望能把問題在線下就處理掉，以避免線上造成更大范圍的

126、損失。因此，線上層面，團隊著重制訂更好、更合理的指標，同時，建立整套問題的報警、響應、解決流程，來及時發現、解決問題；而線下層面，則從性能角度建立了較為精細的防劣化機制。所謂劣化，是指在業務迭代和架構優化過程中，遇到了很多不符合架構設計的代碼，而導致架構出現劣化?！氨热?，我們會去定制 Android 手機 ROM，通過固定ROM里面的參數控制硬件的波動，來減小數據測量的誤差，來達到更加精準防劣化，”通過建立精細化防劣化機制及時發現問題，并進行攔截和消費，來保持項目整體架構持續正向演進。在解決性能監控問題的同時，AppHealth 團隊也開始在全球各地吸納更多單點技術領域和方向的人才，開啟更多通

127、用技術能力的探索。其中，“編譯器成為我們重要發力點之一”，孫念介紹，對于工具鏈的探索主要有兩個原因：第一，工具鏈的改造能直接縮小包體積或者提升應用性能，但對于開發者來說只需要替換工具鏈，而沒有其他感知；第二，移動端工具鏈的潛力挖掘的還不夠充分，可做的事情比較多。目前，AppInfra 團隊在包體積方面也已經得到了初步效果。孫念舉例，團隊通過定制自己的鏈接器替換蘋果默認鏈接器，可以做到消除全局重復代碼，從而將 iOS 二進制文件優化百分之十幾左右?！斑@塊目前業內還是做的比較少的，之后我們也會將實踐做更詳細的分享?！?3 中國卓越技術團隊訪談錄2022 第三季 前沿技術的相關探索 務實是我們團隊非

128、常重要的一個業務視角，也是我們反復強調的一點。如果說性能優化是目前大廠們做產品勢在必行的大事之一，那么與此相對，四個子團隊中的 Research Center 團隊的工作似乎與業務相去甚遠，畢竟從介紹來看，Research Center 主要負責前沿技術創新，以及與一些學術機構的合作。然而在實際中情況卻恰恰相反，對于字節來說，Research Center 團隊的存在不僅不是“可有可無”，甚至已經成為 AppInfra 團隊更好地去服務業務發展的重要一棋?！拔覀兊睦砟畈⒉皇亲鲆粋€單純的學術研究部門，我們做的是技術研究，終歸還是要講究去落地的?！睏钇颊劦?。與孫念的經歷相似，Research Ce

129、nter 團隊的負責人楊萍同樣有著豐富工作經驗。研究生畢業后，她選擇供職于英特爾，工作內容主要涉及與手機攝像頭相關的軟件，且以應用層為主。2018 年，楊萍加入字節，最初在 AILab 字節跳動人工智能實驗室工作負責 QA 技術團隊的搭建。2020 年，楊萍所在的團隊開始轉型技術方向探索，更名為 Quality Lab，Quality Lab 的主要職責是探索前沿技術如何進一步測試能力從而去賦能業務?！斑@個過程基本上延續到今年年初，我們的研究方向以質量測試技術、效率和自動化為主?！蓖瑫r她也坦言，在這個過程中，團隊面臨了不少挑戰，也做了很多變化去應對：第一，組織架構角度，除了算法工程師以外，加入

130、更多客戶端、服務端的工程師來做產品化支撐；第二，拓展與高校、機構等深度的交流和學術合作?！拔磥?，我們再去看組織定位時也會發生一些變化，變化主要在于 DevOps 或者極致的性能與體驗的優化?！彪S著組織定位的進一步清晰，在公司戰略調整下，AppInfra 44 中國卓越技術團隊訪談錄2022 第三季 正式成立了 Research Center 團隊?！癛esearch Center 會持續跟進加深一些學術合作，繼續前沿技術的探索；另外，我們也會繼續在自動化測試上的投資；最后，我們還嘗試將主攻方向從端延伸到整個代碼，去做針對程序方面的探索?！蹦敲磳τ?Research Center 來說，為什么會

131、選擇從自動化測試入手開展現有工作呢？楊萍介紹，這主要在于測試技術在開發過程中屬于比較關鍵的節點，能夠在研發、QA甚至其他決策方等多個方面為項目帶來明顯的優化以及提升。首先，越是在項目、業務眾多的情況下，開發者團隊越能體會到代碼審查的必要性，可以說不做代碼審查基本相當于背著定時炸彈前進，時刻有炸了的危險。而在代碼審查中，測試是關鍵的一環。一般來講，單元測試成本最少，代價也最小，“但對于開發者來說，需要面對快節奏的迭代任務，多半情況下可能并沒有多余的精力去維護好單測?！币虼?，自動化測試的重新定義及探索也顯得尤為迫切?；仡欁止澱麄€自動化測試平臺建設，楊萍總結為一路朝著集成、一體化方向發展的?！?01

132、8 年時，字節并沒有所謂的測試平臺的概念”，并且早期服務端測試還是空白的，主要依靠客戶端測試同學去兼顧。隨著業務規模的擴大，字節設置了專門的服務端 QA的角色，來填補相應技術層面的空白。同時，性能穩定逐漸被重視，字節也隨之設置了服務端性能測試平臺來提供相應支撐。這樣一來，字節的整體自動化測試平臺發展到今天，既具有了從客戶端到服務端廣度，又具有從功能到性能的深度，能夠從更加全面的維度為項目及業務做支撐。當然，建設自動化測試平臺中，Research Center 團隊也在做觀察及調研，他們發現市面上針對客戶端測試的自動化測試工具有很多，比較典型的有 Facebook 研發的Sapienz 以及 A

133、ndroid 自帶的隨機測試工具 Monkey 等，但其中對 iOS 系統的軟件 45 中國卓越技術團隊訪談錄2022 第三季 測試工具基本上沒有，并且，類似字節多業務現狀這種情況，也沒有一個自動化測試工具能做到完全的適配?！罢w評估過后，我們決定自己探索這部分問題?！睏钇冀榻B。因此，2019 年，字節在自動測試方面加大投入，研發了智能化測試服務 Fastbot。楊萍進一步談道，Fastbot 最核心的技術本質上是如何在海量的數據中更好、更快的遍歷完整個測試地圖，“當我們抽象出來這個問題之后，就可以在低層去做多端或者 OS層面的兼容?！边@也意味著 Fastbot 不僅可以支持安卓，還能支持 i

134、OS，甚至做到了支持跨端框架。當然，對于新技術的探索，點滴成功的背后無疑是多次的失敗，Research Center 團隊也并不例外，“自動化的工具，過程中會有非常多的技術探索，也會面臨很多失敗，但這些失敗其實并不足以改變我們的初衷，我們希望用更多的新技術去解決業務中的實際測試問題?！比说膯栴}才是根本性問題 本次訪談中，InfoQ 照例與兩位團隊的負責人聊到了他們眼中團隊亟需解決的問題。令人印象深刻的是，除了談及技術以及業務上的規劃，本次兩位負責人還不約而同談到了他們對于“人”的問題的理解。對于 AppHealth 團隊來說，孫念認為目前還是需要進一步建設好人才梯隊?！拔覀冞€是會持續再補充一些

135、優秀同學進來，包括在海外的招聘進度?！蓖瑫r他也談到，雖然字節在海外的知名度已大有提高，但與 Google，Facebook 等國際巨頭的影響力差距仍然存在，這是需要承認，并不斷努力提高的一點。46 中國卓越技術團隊訪談錄2022 第三季 而對于 Research Center 團隊來說，楊萍談到，他們目前最需要的則是正視目前潛在的人才結構化的風險。展開來講，作為前沿技術探索領域的先行者，一方面，團隊需要引進更多資深的青年學者，去做更多技術探索，但也應該注意到，研究型人才的加入可能會削弱團隊本身的工程和業務視角。因此，另一方面，她直言接下來團隊引入更多來自業務領域的技術專家角色，使團隊更好地傳承

136、以技術研究落地為主的使命和愿景。寫在最后 近年來，不少公司將目光放遠，向國外大廠學習，學習他們那些極客精神，對產品的極致打造。這是一個極好的現象和趨勢，代表了國內技術圈子追求進步的腳步從未停止。但同時，我們也應該意識到，這些優秀經驗的背后，大多也源自這些公司本身的文化和精神。談及各自團隊的文化，孫念是這樣告訴 InfoQ 的，他說：“我們做優化，到底優化到什么程度才算可以呢？我想字節文化中的敢為極致能夠給予我們這個答案?！倍鴹钇紕t告訴 InfoQ：“務實是我們團隊非常重要的一個業務視角，也是我們反復強調的一點?！敝链?，回到文章開頭，或許我們能從 AppInfra 團隊窺探到字節跳動的核心競爭力

137、所在。47 中國卓越技術團隊訪談錄2022 第三季 嘉賓介紹 孫念 字節跳動終端基礎架構部門 AppHealth 方向負責人，專注于 App 性能、穩定性方向，帶領團隊通過對操作系統資源利用、虛擬機、編譯器工具鏈，高性能基礎庫等方向的深度優化和建設各個核心指標全鏈路的監控體系和分析調試工具，協助字節各業務提升產品質量和體驗。楊萍 字節跳動終端基礎架構部門 Research Center 團隊負責人，負責端架構基礎研究與智能化能力建設，帶領團隊孵化并落地多個行業領先的端質量產品（Fastbot，精準測試），也對目前 AI 技術在大前端研發體系的應用有較多了解。48 中國卓越技術團隊訪談錄2022

138、 第三季 一年100%云原生化，眾安保險架構演進的探索與實踐 采訪嘉賓：歐昀、鄢晶 編輯：辛曉亮 金融行業的蓬勃發展，業務規模的不斷擴張，用于支撐業務運行的系統和基礎設施也日趨龐雜，強監管安全合規的屬性又使得他在云原生的選擇上比其他行業多了一絲謹慎，面臨更多挑戰。眾安保險從 2016 年就開始探索實踐云原生相關技術，在服務治理、自動化運維等方面積累了大量的經驗。為了深入了解眾安在金融保險領域的探索和思考，近日，InfoQ采訪了眾安保險技術團隊，圍繞金融保險云原生架構治理問題逐一展開探討。眾安云原生之路：從追隨者到實踐者 2016 年，眾安就開始逐步嘗試云原生技術，屆時眾安已充分意識到云原生技術

139、本身適用于任何行業，慢慢地眾安對云原生的理解也從早期概念的追隨到現在大規模落地的實踐者甚至是布道者。這個模式的轉換更多的是依據云原生的定義搭配眾安自身的演進實現，同時結合業務實際，由淺至深，由點到面的過程。早期云原生在定義過程中，主要是應用的容器化，以及面向服務架構，容器編排等等。隨著云原生生態的逐漸成熟，眾安現在更關注的是標準實踐之后的深度治理，比如在 49 中國卓越技術團隊訪談錄2022 第三季 不可變基礎設施，微服務三要素等落地規范的定義下，如何最大化的實現云原生技術紅利，并不斷探索云原生標準的最佳實踐等。眾安對云原生理解總結為一個詞就是彈性。主要分為三個方面，分別對應彈性基礎設施，彈性

140、應用架構，以及彈性研發交付流程，也分別對應容器、微服務和持續交付相關技術。容器輕與快的特性能夠讓企業實現按需的編排使用，對于需要使用的資源實現快速的彈性伸縮。微服務應用架構則是作為部署與交付的介質，低耦合的設計能夠充分發揮容器和持續交付的能力。此外借助 DevOps 實現的持續交付流程則能夠使眾安更快、更敏捷的去響應需求的變化?？偟膩碚f，云原生為眾安提供了一套指導思想，讓企業以更輕更快的方式去實現構建部署以及交付應用。眾安架構演進：邁向云原生 同其他互聯網公司相似，眾安的技術架構也是一直在演進與升級的，整體可以分為三個階段。第一階段是在成立之初采用的傳統單體架構，滿足業務快速上線。第二階段，隨

141、著互聯網業務對新開通高并發、低延時的要求，眾安開始進行微服務架構的升級，這個階段又可以細分為閉源與開源兩個過程，最初使用國內大廠閉源的技術組件，之后慢慢擁抱開源生態。第三階段就是現階段，采用基于 K8s 構建云原生的架構，包含了容器化的基礎設施、微服務架構、服務治理、DevOps 體系建設等等。眾安在進行架構演進的過程中，首先會進行目標架構的規劃，解決方案的規劃也會成為目標架構演進過程中的目標路徑。這就意味著方案規劃需要符合長期的目標架構，50 中國卓越技術團隊訪談錄2022 第三季 同時在中短期也要能夠解決當前或者即將面臨的問題。另外眾安將技術架構的關鍵能力聚焦在業務復雜度提升和數據量變高帶

142、來的海量數據、低延時高并發等互聯網式的極端流量問題之上，這也要求眾安停下來去審視當前的技術架構是否能夠支撐業務形態的轉變，以適應未來五到十年的變化為目標去進行架構規劃。云原生架構建設思路 眾安在云原生架構上的建設思路，恰如眾安對云原生的定義理解，也是分為三個層次，包含基礎設施層，應用架構層，以及研發管理層?；A設施層次建設改造主要是指的是容器化的改造，包含容器服務，容器編排，以及如何將應用部署在容器當中等。其重點在于容器云平臺的搭建，眾安采用 K8s 并在其之上自研了一套自己的多集群統一管理容器云方案，實現了全公司全環境容器服務以及編排的統一管理。另外，通過鏡像可視化編排、鏡像插件等手段去標準

143、化約束基礎鏡像，實現業務系統快速進行容器環境的適配。在此之上面向云原生設計并落地了新一代數字化保險系統稱之為無界山2.0。在應用架構與研發管理層，眾安主要采取架構標準化與微服務治理和自研 DevOps 體系的思路，我們在下文服務治理段落將進行詳細講解。關于標準化的約束，眾安集成在流程與工具當中，形成一套事前自動生成、事中標準指導以及事后檢查的機制。在體系建設方面眾安采用核心能力擁抱開源，服務能力進行自研的方式建設基礎設施、應用架構和持續交付體系。在開源工具的選擇上，眾安會充分考慮一些 CNCF 認證的項目與規范，同時也會采取像社區共建、團隊貢獻、定制私有等方式，和社區保持長期穩定的一種參與關系

144、。51 中國卓越技術團隊訪談錄2022 第三季 此外眾安在云原生安全方面也有著非常重要的考量，一方面會借助云上的安全產品去建設基本硬件級的安全防護能力。另一方面眾安面向金融場景，圍繞容器、應用、數據、業務方面進行安全能力自研孵化網絡安全、應用安全、數據安全產品，形成面向不同行業和場景的安全合規、業務安全的風險管理解決方案。同時眾安將安全能力和研發管理流程深度集成形成了現有的 DevSecOps 體系，這些都是眾安在規劃架構上的思考。強監管行業安全上云 保險銀行證券都是屬于強監管的金融行業，上云對于他們來說既是挑戰，也是機遇。最基礎最關鍵的就是如何選擇一個好的云服務商，根據行業的一些特性，可以從

145、合規、安全、數據一致性等高要求來考慮。因此在架構升級上眾安會主要從兩個方面考慮。首先在業務方面，傳統的金融產品和服務，存在一定的門檻，效率低下，同質化嚴重，可能無法滿足客戶的特定需求，客戶更多的需要線上化、個性化、場景化的金融產品和服務。其次在技術層面，金融行業屬于信息化程度相對比較高的一個行業，傳統的金融 IT 架構存在較多問題，比如研發周期長，協作溝通問題，運維成本高、創新比較慢等等，還會遇到人才儲備不足的難題。結合目前數字轉型在整個行業的深化，眾安看到了越來越多的云原生技術在行業上的運用。眾安開始逐步嘗試云原生技術在生產實踐中的運用，充分利用和發揮云的優勢，同時做到靈活、低成本的方式構建

146、彈性和可擴展的應用。在幫助研發的過程中，將研發的焦點，由資源為中心轉向以應用為中心，利用彈性的概念去充分發揮云的優勢，52 中國卓越技術團隊訪談錄2022 第三季 幫助提升產研的能力，支撐業務的創新。整體來說的話，眾安認為云原生技術能夠為金融行業，尤其是互聯網金融行業帶來巨大的紅利，為眾安構建新一代的數字化基礎設施，以及幫助企業數字化轉型帶來強大的推力。最大挑戰只有一個：技術升級不能影響業務 技術升級最不缺的就是挑戰，整個架構升級切換的過程，眾安的技術專家表示，就像大家說的“開著飛機換引擎”，最主要的挑戰就一個，技術升級的同時不能影響業務。在整個遷移的過程中，遇到了大家熟知的微服務問題，容器化

147、，DevOps 等等，既不能影響生產業務，又不能影響日常開發的運維流程，挑戰還是比較大的。眾安主要分了兩個階段去嘗試：第一階段，眾安早期的業務形態，主要是圍繞電商場景去開展，這個時期需要在很短的時間內做更多的生態，比如健康生態、汽車生態等等。早期的業務架構并不是很匹配未來的業務情況，因此早期有業務架構升級的需求，所以眾安在做業務架構的同時，也將底層的技術架構做了升級，完成了早期云原生基礎設施的轉換。第二階段，有了云原生的基礎，通過云原生的基礎能力，眾安對基礎設施進行了底層的封裝之后，確保上層應用運行環境的穩定，同時眾安加強了 PaaS 層服務能力的建設，降低開發者對底層基礎設施和公用組件的使用

148、門檻和成本，這也可以幫助后續做到無感升級。同時為了降低日常運維的流程，眾安還自研了 DevOps 產品，實現從構建到部署的自動化，并將標準化延伸業務交付。53 中國卓越技術團隊訪談錄2022 第三季 從探索容器到服務治理 眾安云原生的發展階段也可以分為三個階段：容器探索階段、微服務化、服務網格治理。前面提到，眾安從 16 年就開始起步探索容器技術，以 Docker Swarm 為技術核心建設了第一代容器管理和應用平臺，在一些邊緣應用上進行了小規模的試點應用。實踐下來，在網絡及其穩定性方面存在比較大的問題。時間來到 18 年，這個時期眾安以 K8s 為技術核心建設云原生基礎設施，將微服務應用部署

149、到容器環境。在容器微服務化階段眾安的遷移改造已經比較徹底，實現了業務應用 100%容器化。目前正處于第三服務網格服務治理階段，當下眾安主要以 Istio 和 Agent 為技術核心實現網格化的服務治理，對以 K8s 為主的云原生基礎設施進行進一步的增強?？偟膩碚f，階段二的遷移最具挑戰，遷移的過程耗時將近一年，無論是涉及到的系統規模，還是復雜度都是最高的。另外由于底層基礎設施形態的轉變，技術復雜度也比較高，眾安通過藍綠驗證的方式，通過網關的能力進行流量的逐步切流，利用這種手段做到業務逐步遷移，保證了遷移過程中業務的連續性不中斷，實現業務的無感遷移。提及轉向云原生收益之前先介紹一下眾安的基建規模，

150、眾安這邊的主機規模，按照4C8G 這種機器的規格去計算的話大概是在一萬加以上，應用規模是一千多個，技術人員的規模大概是在兩千以上。眾安技術架構在轉向云原生之后，結合資源彈性編排帶來的成本節省，以及 DevOps 體系建設和落地，有效提升了需求交付率，縮短了交付周期。從統計的數字上來看，21 年眾安發布次數在 12 萬次以上，相交于云原生之 54 中國卓越技術團隊訪談錄2022 第三季 前增長了 22 倍，關于轉向云原生，眾安還是獲得了非常明顯的收益。目前的難題 架構演進是一個持續的過程，企業會不斷面臨各種各樣的問題與挑戰，眾安分享了其中一個多語言環境下架構治理問題。關于如何看待多語言，首先眾安

151、保險不希望開發語言成為公司吸納各路人才的阻礙，不同的編程語言也會有他適合的一些應用場景，比如說人工智能 Python 會比較適合，云原生 Go 會比較適合，企業級的一些業務系統可能 Java 會比較適合。在語言棧選擇上眾安秉承著開放的策略，但語言棧的開放帶來的就是維護復雜度、治理困難的問題。為了實現統一架構的治理目標，將治理能力不斷下沉到基礎設施是眾安認為唯一的標準答案。眾安方案的抓手是流量劫持，從東西向流量和南北向流量這邊分別去展開。對于南北向流量眾安將治理的能力放在網關層，同時眾安的目標也是建設 API、業務、安全的三合一網關；對于東西向流量眾安則是依托服務網格技術，在全公司全場景覆蓋，提

152、供基礎設施級的流量權限與可觀測能力。眾安架構服務治理方案 隨著眾安技術伴隨整個業務發展進入第九年，公司在業務形態和體量上都發生了巨大的變化，整個技術架構如何去支撐業務的線上運營與發展就就變成了非常有挑戰的課題。55 中國卓越技術團隊訪談錄2022 第三季 眾安保險內部架構治理遵循公司統一架構目標，以技術架構、業務架構作為支撐點，主要分為三個方面。第一，基礎設施層面眾安要求百分百部署在云上，充分使用云服務提供的計算、存儲、網絡等能力；第二，在技術架構方面，眾安基于云構建了技術中臺，能夠向業務系統提供統一的容器、中間件等 PaaS 能力；最后在應用層面，業務系統統一使用類 Spring Cloud

153、 生態的微服務架構?？偟膩碚f，目前眾安已經形成了較為完善的云原生生態的建設，治理著超過上萬服務的大規模集群。強監管的金融行業屬性 首先金融保險屬于強監管的行業，安全合規是紅線，金融保險架構治理也會有一些特殊的地方。因此眾安在做基于架構標準的時候就會設定一些合規性的下限，在業務設計的過程中要幫助和指導大家去考慮合規性需求的擴展和一致性。其次，由于整個金融行業存在一些“歷史包袱”，尤其是一些中小型金融企業，對于技術改造存在較大的風險和挑戰。所謂金融企業的“歷史包袱”，可以從兩個方面展開來講。第一是業務上的挑戰，第二是技術方面的挑戰。大家可能知道，組織結構會決定技術的架構，眾安早期遵循的一套架構叫做

154、“胖前置，瘦核心“，這是因為眾安前期強調的業務形態是前臺的業務部門高效迭代的能力。在整個架構升級過程中，尤其上發展到現在業務穩步發展的階段之后，就會更加關注業務的效率和質量，然后持續加大一些業務中臺和技術中臺的投入。最后在整個過程中不但有底層的業務架構的升級，以及匹配到技術架構的升級，整協同過程中組織架構的一些調整也會有沖擊。還有一點可以補充的是，像傳統的金 56 中國卓越技術團隊訪談錄2022 第三季 融行業的業務系統，大家可能知道企業使用的像小型機，重量級的一些數據庫，甚至閉源的廠商，都是比較普遍的。關于這個方面，金融企業上云也會存在一些阻力。不過受訪專家表示，眾安也相信技術先進性會讓之前

155、的一些業務開展由不可能會變成可能，同時也在不斷鼓勵金融創新，鼓勵技術先進性的探索也會成為眾安架構治理的一個重要環節。此外，在服務治理的過程中也會發現新的一些架構和交互對于傳統的業務流程和組織結構帶來的一些沖擊，眾安也發現轉變企業的文化，打破部門的一些壁壘，夯實數字化的一些群眾基礎也是非常重要的事情。三大企業架構治理方案 眾安在企業架構治理課題上具體來講有以下幾個方向：首先是微服務治理，眾安根據自身業務覆蓋廣、周期長的特性，使用開源體系落地實踐的方案。以 Spring Boot 為基礎，在此基礎之上建設了可遞進、可共建的統一微服務應用框架，為業務系統提供框架組件版本的統一管理能力，同時開放共建能

156、力也可以讓各事業線的技術團隊參與到標準的制訂以及演進過程當中。眾安采用無侵入為主、多語言的異構體系為輔的技術方案。盡量避免對業務代碼產生侵入，升級也能夠做到盡量減少對業務這塊的一些感知與影響。簡單來說就是 Istio 配合 Agent，或者稱之為 Agent 加 Mesh 雙治理的體系。眾安應用服務技術體系，雖說是擁抱多語言，但實際上更多還是以 Java 占據絕對的比例。目前眾安使用這兩種技術體系共同完成不同業務場景的覆蓋，這也是金融保險行業比較先進的治理方式。再談數據治理，眾安作為國內較早開始數字化轉型的企業之一，非常注重數據帶來的 57 中國卓越技術團隊訪談錄2022 第三季 價值，為此眾

157、安還成立了專門的數據治理組織。數據治理上眾安保險主要關注兩個方面，一是數據質量，二是數據安全，目前兩個方面眾安都是通過一些平臺化的能力進行治理。數據質量方面眾安搭建了企業內部的數據質量平臺，通過不斷去維護運營過程中積累的像業務和數據的一些相關規則。比如說保險，保險是受強監管的，在業務處理的事前、事中、事后都要及時地對相關數據進行質量監控。另一方面，在數據安全上，眾安自研了關于數據管理方面的平臺，取名綠洲數據服務中心，通過系統對數據的一些流轉和使用，進行相應的數據相關的一些權限和安全的控制。最后是 DevOps 治理方面，或者叫研發過程的治理。這里眾安是以一站式研發管理作為指導思想來建設一體化的

158、 DevOps 平臺，并且從文化、組織和工具層面對眾安的研發一體化的體系進行落地。眾安整個 DevOps 體系的設計遵循了兩個理念，一個是運維 N+1 的一個理念，一個稱作“小工具大平臺”的理念。什么意思呢？首先運維 N+1，指的是一個基礎運維，N個運維場景，也可以理解為是一個運維中臺，N 個運維平臺。眾安使用運維控制管道概念去提供基礎的調度能力，去屏蔽底層比如容器調度、主機調度甚至文件調度，實現統一的命令和文件管道，同時上層工具平臺遵循統一的數據和 API 標準。在此標準之上眾安建設了像持續交付，可觀測，數據治理包括 ITSM、IT治理等眾多的應用場景?！靶」ぞ叽笃脚_”則指的是眾安運維體系模

159、塊化的設計，通過微前端等的一些技術手段，去實現模塊的按需組合，并且按照研發角色例如開發運維測試等形成不同的工作視圖。58 中國卓越技術團隊訪談錄2022 第三季 金融基建新挑戰 此外，信創基礎設施作為當下較為火熱的課題，眾安在此方面亦有相關動作。金融安全關系國家命脈，在自助可控的重要性方面尤為突出。眾安積極響應國家戰略，在基礎設施、核心系統方面的信創適配工作有著很大的投入并產生了不錯的成果，面向行業推出了安全、運維、基礎架構等領域的眾多滿足信創要求的產品。另外，眾安保險具備金融、互聯網雙重行業特性。同時區別于傳統公司，眾安的基礎架構體系 100%構建于云上，是在云上進行大規模生產實踐的典型案例。在與云商等產業機構聯合共創之下，快速設計了有眾安特色的信創云方案并進行嘗試，目前已經有一定比例的科技投入。同時眾安也非常愿意以科技賦能行業為目標持續輸出相關產品與經驗。寫在最后 中國信通院云大所云計算部副主任陳屹力曾提到，云原生是保險行業新一輪數字化升級的必經之路，眾安在金融保險領域的成功實踐也驗證了這一點，盡管目前大多數企業還處于探索階段，但在未來幾年，金融保險行業將全面迎來云原生時代。