技術沙龍 | 雲時代下的架構演進—企業雲及雲原生技術落地實踐
雲改變了IT行業的形態和市場格局，催生了應用的發展。隨著雲端計算技術的不斷演進，作為一名優秀的架構師，必須深入瞭解雲端計算平臺的特點及架構設計，包括構建資料庫、大規模落地微服務、Service Mesh和全鏈路監控等才能緊跟時代的步伐。
12月21日，京東雲開發者社群和英特爾聯合舉辦的「
雲時代下的架構演進—企業上雲及雲原生技術落地實踐」沙龍在北京順利召開，在本次活動中來自京東技術專家從頂層視角解讀京東集團的雲化之路、京東物流的上雲之路、探尋資料庫上雲的探索之路、京東雲的落地服務網格和DevOps系統，五個模組同現場的百位技術從業者進行了分享與交流。
1 京東的集團上雲之路
對於京東雲來說，必定要走一條與其他雲廠商不同的道路，而京東雲認為，集團上雲就是京東雲與其他雲廠商的重要差異點。因此，集團上雲在京東內部就是一個戰略方向，京東雲客戶成功部專家級架構師湯源解釋道，京東的戰略就是構建以零售為基礎的技術與服務。這個技術服務是TO B的技術與業務能力，需要去變現，它必須要有一個商業平臺，因此，京東集團做公有云，在戰略層面是堅定不移的。京東內部也是非常全面的去認識集團上雲，但京東雲的集團上雲，並不是說要轉變京東雲的業務方向，也不是狹義上集團把自有業務遷移上雲（Cloud Migration），我們京東雲將集團上雲細分為自用上雲、回家上雲、投後上雲、賦能上雲、推薦上雲五個場景，來區別對待，所以說京東雲的集團上雲是一個廣義上借上雲來探索雲化之路（Cloud Transformation）。在這個前提之下，京東雲集團上雲的路徑實際上也就是京東雲作為整個集團的技術服務後臺的路徑，同時，這也是集團技術轉型自身的發展思路一脈相承。
如果我們從Cloud Transformation這個視角來解讀，大家可能知道，早期的京東技術體系，還是基於Microsoft .Net技術棧的，所以，大概在2012年前後，京東決定要把.Net技術棧轉成基於Linux的開源技術棧，到了2015年，京東有第一朵雲問世，實際上就是京東做了一個私有云。京東把零售的業務、所有的計算，包括資料庫都做了容器化和資源池化，也做了一套基於開源的中介軟體體系，包括應用的治理。
2015年下半年，京東開始研發公有云2016年的4月京東雲正式開始提供公有云服務。
2019年，劉總提出集團上雲，將集團上雲作為京東的戰略目標。這就是所謂的京東雲2.0階段，在此階段，京東將私有云和公有云打通，做成混合雲，利用混合雲架構來做集團的自用上雲。
湯源表示，京東計劃在明年到後年完成自用部分的上雲，到後年年底，將京東集團的所有業務都遷移到京東雲上。這就是一個Cloud Migration的過程，完成這個過程之後，或這過程中的一些新業務，京東雲的CloudTransformation還會採用雲原生（Cloud Native）模式。
那麼，京東是如何理解、推動和執行集團上雲的？從京東雲的視角來看，京東集團的技術棧它分為四個層次，底層是一體化物理層，主要是IT硬體基礎設施，這部分京東雲與英特爾有比較深入的合作，包括CPU的定製。最上層是產品化的場景化服務。中間層是元件化能力和平臺化能力層，實際上就是一箇中臺的概念，京東雲把中臺分為業務中臺和技術中臺，在業務中臺注重元件化，因為業務都是非常複雜的，研發人力重與時間週期長。同時，業務中臺承載了京東所有的營銷、交易、商品等系統。這樣，就可以消弭之前的煙囪式的軟體架構，根據不同的業務場景去組合來提供快速的交付，提升業務賦能的速度，這個在京東零售出海東南亞得到了很好的應用實踐。在技術中臺方面，則把IaaS、AI、包括資料平臺都集中在了技術中臺之中。
眾所周知，京東集團有很大的體量，也有很豐富的產品，同時也具有豐富的業務場景。無論是在計算還是儲存的量級上，都是很海量的，這些豐富的場景對於京東雲的公有云平臺和產品的成熟度有著非常有效和快速的促進作用，在內部京東雲也把集團內部客戶作為一個超級VVIP，這樣也鍛鍊了作為To B業務的公有云團隊在規劃方案、交付、技術服務方面的能力。因此，實際上是京東的業務發展和技術轉型戰略驅動京東走上了集團上雲之路。
但在京東的集團上雲之路中，安全問題、包括資料資產安全問題以及這樣一個大體量富場景雲遷移中的實際問題，其實都給京東雲帶來了很大的挑戰，但京東雲透過保持安全邊界、適配安全監控、對於新業務直接採用雲原生方式以及選擇組合多種遷移方式等方法在2019年做了積極探索，並將在接下來的兩年中完成集團上雲2.0階段的Cloud Transformation。而京東雲經過這四年多的發展，不管在豐富度還是成熟度、穩定度上，都有足夠說服力讓我們的內外使用者可以放心上、大膽上京東雲。
同時，在接下來的京東雲3.0階段，京東雲還會在安全、資料處理、遷移方式方面繼續發力，讓使用者可以更加放心的使用京東雲。
2 京東物流系統上雲實戰分享
京東物流集團基礎保障部架構師史季強則主要從啟動上雲、遷移準備工作、遷移過程詳解、案例解析、收益和問題、願景規劃六個方面對物流系統上雲實戰進行了分享。
史季強表示，京東物流之所以需要遷移上雲，除了整個京東集團上雲戰略上的考慮，從物流集團內部自驅來看有三點考慮，即
輕資產化、降低成本、架構升級。
物流是非常重資產的行業，要有庫房、大量的員工還有物流系統也是非常龐大的，而這麼大體量的系統卻常年跑在很多物理機上面，隨著時間的推移，這些物理機可能過保或者損壞，帶來了大量的維護成本，而隨著業務的發展，還要採購更多的物理機，這就導致資產會越來越重。而從整個網際網路趨勢來看，大家都是希望自己的架構越來越輕，資產越來越輕。
第二就是降低成本，大家都知道雲端計算的特點就是虛擬化和共享化。如果資源在不使用的時候可以回收掉，使用的時候可以採用按需申請，包括計費的模式，就可以按小時按天進行計費。這樣對集團內部資產進行規劃，對於集團制定伺服器的預算都有很好的幫助。
第三，如果只是簡單的把系統搬到雲上去的話是沒有任何意義的，僅僅把系統伺服器部署從私有云搬到公有云上意義也不大，真正有意義的是，在這個遷移的過程中，可以對自身的系統架構進行梳理，同時也可以對陳舊的、過時的和現在業務發展不太匹配的系統架構進行一定的升級，包括雲原生的架構，這是一個非常好的機會。
而這三點就是京東物流啟動上雲的驅動力。
在確定了上雲的策略之後，接下來就是遷移的準備工作，而這些準備工作首先就要從架構的重新設計做起，史季強表示，這是因為京東的物流系統非常複雜，不太可能照搬原來的架構直接遷移上雲。因此，就需要對原來的物流架構進行有效的梳理。
而從物流系統框架圖來看，在上層，京東物流有很多的業務模組，包括冷鏈供應鏈、最大的客戶商城等，這些支援的系統及資料平臺是非常複雜的。此外，這些系統上還包含了底層的業務中介軟體、最底層依賴的基礎設施資料庫及快取各種儲存，整個系統都是龐大且複雜的。
為此，在確定新的雲上架構時，採用了VPC架構，VPC是某一個BG有獨立虛擬的私有云區域，在這個區域中可以劃分不同的子網，根據不同業務型別，將其放在不同的子網裡。這樣做的最大的優勢在於，安全上有一定的隔離，流量上同樣也是。同時，由於在新架構中同時包含了對公子網、業務子網和資料子網，而物流系統中有很多對外提供公共服務的系統，透過VPC架構，則可以將它們與私有環境分離開，從而保證了物流系統的安全性。
在將基礎架構環境定義好後，下一步是啟動遷移工作。這其中包括上線、配置CMDB、部署監控等 。史季強表示，在遷移前監控的事情一定要做好，這其中包括資源監控和效能監控，否則上線之後系統執行就處於一個沒有監控的狀態，公有云平臺提供的相關資產和監控工具更主要面向商業客戶，適合小規模的公司，如果是大型公司，那必須在這些方面要根據OpenAPI有自己定製化的設計。
史季強詳細介紹了京東物流遷移的過程。首先是雲主機的遷移，研發透過Jone釋出到應用，同時釋出到私有云分組和公有云分組，執行到一定階段比較穩定後，那麼就從中間切開，相當於所有的應用例項都跑到公有云分組。基於這種模式，物流研發的所有應用基本上都在公有云上進行了部署，部分的系統完全把私有云分組裝置資源下掉，只保留在公有云分組。
京東物流之前使用的是自研的分散式快取服務（JIMDB），經過調研，雲團隊提供的快取產品具備更大的優勢，雲快取是基於Redis協議的線上快取服務，可以滿足大部分業務對可用性、可靠性和高讀寫性的要求，支援雙機熱備、自動容災切換、彈性擴容等特性，經過雙方反覆的磨合，在產品化的基礎上，Redis向物流定製了主從版及叢集版，物流可以按需選擇，更加靈活，更加容易控制成本，此外在使用者介面層除了控制檯及SDK外，透過OpenAPI將雲管能力整合到物流系統中，實現共同治理。從JIMDB到雲Redis的資料遷移，要求業務不能中斷，雙方制定了可持續讀寫的全量與增量實時同步方案，經過反覆的測試與實踐，目前已支援全自動同步，遷移效率大大提升。
但是資料庫上雲的遷移相比應用伺服器遷移，難度要高出很多，畢竟線上海量資料的複製轉移很難在短時間完成，而且生產時段的遷移還可能會影響到線上資料庫的穩定性，對於遷移時間視窗也有很嚴格的要求，因此對於資料庫的遷移方案是慎之又慎。經過多方論證和測試，我們採用以下兩種方式進行資料遷移：
資料庫原生的主備模式
：主要針對核心系統資料庫，要保證資料庫遷移過程中，如果有任何的問題，都可以做到新老叢集的快速切換，這樣的場景只有mysql原生的主從複製模式是最為合適的。但是要保證私有云mysql資料庫的版本和RDS資料庫版本一致，對於5.6和5.7版本還需要開啟GTID，因此這種方式只能適合少部分系統。
使用自研的DTS工具，資料蜂巢Dcomb
：Dcomb是一款輕量級的資料處理平臺，支援Join，Union，Where和使用者自定義邏輯同步等功能，支援從MySQL到MySQL、ES、Cassandra、JDQ、MQ、PostgreSQL等目標端的實時資料同步，平臺基於分散式架構，具有高可用及負載均衡等特點。大多數資料庫上雲都採用資料蜂巢進行。
雖然資料庫遷移過程比較艱辛，但遷到公有云之後還是有很多收益的，這其中包括故障恢復快、產品豐富、介面規範、智慧監控、自動備份和快速部署。
史季強最後表示，京東物流在上雲過程中算走在京東集團的最前列，截止目前已經有超過90%的應用在公有云上部署了例項，包括今年的雙11.11大量業務都是執行在公有云上，在業務流量超過了三倍以上的情況下，整體運營還是比較平穩的，後續京東物流還將持續推動系統去雲。上雲要做架構升級，不是簡單的搬遷。而未來，京東物流的願景有四個方向，分別是容器化的軟體部署模式、伺服器資源利用率的提升、架構最佳化，服務治理以及基於公有云的基礎平臺，進行流程化的質量和效能平臺建設。
3 京東資料庫上雲探索之路
京東雲產品研發架構服務架構師張成遠講述了京東資料庫上雲探索之路。張成遠從
傳統運維時代到雲時代、上雲的條件與時機、如何上雲以及雲時代DBA職業發展思考四個方面為大家分享了他對資料庫上雲的深刻理解和豐富經驗。
為什麼要把資料庫上雲？原因是顯而易見的，因為雲資料庫具有高度的彈性和擴充套件性，而這些對於京東這樣的電商應對例如618、雙11.11等購物節帶來的突發海量流量的情況是非常適合的。
京東雲資料庫能提供資料自動備份保證資料高可靠、實現自動高可用切換、線上擴縮容以及一整套完整的監控報警體系等功能，能夠保證使用者資料安全、有效提升業務可用性，輕鬆應對突發訪問流量。
關於上雲的條件和時機，張成遠給出了他自己的理解：一是建議創業者直接用雲。創業者應該聚焦真正想做的事情，基礎設施建設對於創業者所做的業務來講往往不是核心內容，直接用雲就好。二是已有本地IDC服務。這種情況下可以做兩種考量，一是業務發展趨於平穩，但所用機器四年左右過保了，過保以後怎麼辦？二是業務繼續發展，機器繼續採購，但機房裡需要新增機架比較困難怎麼辦？
張成遠最後總結，他表示上雲的關鍵是資料庫遷移。分幾種情況，第一種情況是新部署的業務或者歷史資料可以歸檔的業務，資料不需要往上遷，這是最簡單的，直接申請建立新的資料庫即可。第二種情況是資料要遷移，這個事情比較麻，需要進行很多評估，比如資料量有多大，資料不可寫程度怎麼樣，業務允許停止的時間等。遷移過程中可能會有一個階段是應用跨IDC訪問資料庫，此時很容易遇到的一個問題是網路延遲，網路延遲可能只是增加一毫秒，但在互動次數較多的情況下，整個業務的延遲也會被嚴重放大，對業務影響比較大，有些甚至是業務系統層面要做相應的最佳化，所以資料庫遷移上雲是一個需要綜合考慮的事情。
4 Istio服務網格入門指南
眾所周知，lstio是業界關注度最高、生產環境落地最多的服務網格系統。王碧波從服務網格概念、Istio功能、Istio場景、Istio使用難點、京東雲和Istio五個方面帶來了Istio服務網格入門指南的課程分享。
首先，王碧波以老人和小孩對於數字技術的不同態度作為類比，闡述什麼是雲原生的應用。他認為，在應用一開始設計和實現的時候就充分採納能利用雲彈性、基礎元件豐富等優勢的技術，這樣的應用就是雲原生的應用。而微服務和容器就是雲原生技術的典型代表。
王碧波表示，微服務簡單來說就是把大業務切分成小單元的服務，以更加方便管理和維護，因為功能單一的小單元相對於複雜的系統更容易進行研發、最佳化和調整。涉及到微服務，就不得不談到切分和配合。切分不只是指切分業務邏輯，同時還需要將資料、配置、工具、執行環境等與業務邏輯分離。關於如何拆分，可以參考康威定律，領域驅動設計、十二要素等思想和方法。其次，是與微服務的配合，包括服務之間的關係什麼樣，服務依賴的其他服務怎麼配合，服務與所依賴的持久化服務怎麼配合，和研發上線過程怎麼配合，問題定位怎麼配合，配合是比拆分更大的話題。因此就產生了新的概念叫服務治理，服務治理主要就是解決這些微服務之間怎麼配合的問題。
王碧波認為，服務治理的能力可以分成以下五類：
流量治理、安全治理、生命週期治理、業務輔助、服務觀測。流量治理包括從最基本的服務發現，到負載均衡，熔斷、呼叫協議、策略路由、流量複製錯誤、資訊注入，API管理等，主要解決流量的管理。安全治理就是如何保證程式碼執行、資料配置等方面的安全。生命週期管理包括CI、CD的機制，關於服務部署怎麼做、彈性伸縮和故障恢復怎麼做等等。業務輔助提供一些標準的基礎能力，幫助業務實現功能邏輯。服務觀測解決如何準確掌握系統的執行狀態，以及如果有線上問題如何能快速定位問題。
而服務治理能力時有兩種使用方式，一種可以稱之為整合方式，另外一種是服務網格。前幾年更多是整合方式，業務需要引入很多服務治理相關的庫，與開發語言和框架耦合較緊。後來誕生了服務網格這一類的技術，其核心理念就是把業務模組和服務治理徹底的切分開。這使得開發人員完全不用關注業務，直接在網路代理裡面中就可進行。而且服務網格還可以在不需要做任何的研發的情況下，直接進行線上的配置就可以實現想要的一些功能。後續有新的治理需求時，也可以直接透過網格來統一提供和配置，起到“一次接入、持續受益”的效果。
在服務網格的技術框架中，Istio是目前比較流行的技術框架，它具有架構清晰、功能完整、實現開放等諸多優點，其中Galley解決配置管理的問題、Pilot可以做服務發現，客戶端負載均衡，還可以根據Host、Path、Header等靈活配置路由，靈活配置容錯。Mixer的功能則包括配置呼叫Quota、許可權策略、請求轉換邏輯等，同時它還負責各種觀測資料的收集。
王碧波介紹說，京東雲是在2018年中開始嘗試使用服務網格，到2019年底已經有一百多個應用在服務網格里執行了。為了保證穩定性，京東雲建立了比較完備的測試和質量評價的體系，Istio的每個版本，放到測試框架裡面持續執行，以便及時發現問題。另外，京東雲的團隊裡邊也有很多關於網路和服務治理的專家，在選定版本之後，假設後期發現該版本有比較嚴重的問題，這些專家有能力進行修改。在使用體驗方面，京東雲也做了很多簡化工作。同時，還研發了大量線上運維工具。另外，還整合了內部的關於安全、Devops、觀測等系統，讓各團隊可以更容易的應用網格的各種功能。最後，京東雲投入了很大的精力在各個團隊配合和接入上，服務網格有很多新的理念、新的用法，和原有方式是有很大差別的，需要做很多的溝通探討。
下面是最終效果的示意圖：底層devops系統解決一些資源管理、應用管理、日誌許可權等等一些事情，服務網格解決了服務發現、呼叫服務、安全治理、呼叫鏈等問題，最終使得各業務可以靈活的灰度，伸縮，簡化部署過程，最佳化流量管理，獲得原生安全能力以及更好的觀測能力。
透過內部一年多的線上運維，京東雲積累了豐富的線上運維經驗。京東雲已經將這些能力和經驗產品化，推出了雲服務網格產品，歡迎大家試用。
5 雲原生下的DevOps實踐
井亮亮從雲原生 & DevOps、雲原生下的 DevOps 發展演進以及京東雲 DevOps 案例三個方面進行了闡述。
雲原生 & DevOps：雲原生貫穿了現在軟體的整個研發週期，重塑了整個軟體研發生命週期，是雲原生是提出的一個概念，它是一個思想的集合，包括（DevOps、持續交付、微服務、容器）。可以說雲原生既包含技術（像微服務、容器這種基礎設施），也包含管理（DevOps，持續交付），還有例如像康威定律，重組等。雲原生也可以說是一系列Cloud技術、企業管理方法的集合。
DevOps同樣是比較抽象的東西，DevOps（Development和Operations的組合詞）是一組過程、方法與系統的統稱，用於促進開發（應用程式/軟體工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。每個企業環境不一樣，角度不一樣，DevOps解決的問題也是不一樣的。
雲原生下的 DevOps 發展演進：最明顯顯著的就是基礎設施的變化。在雲原生之前，我們的服務是這樣的，最底層是傳統的IDC，機房、硬體、網路、的基礎上，服務app一般是會部署在物理機中的，或者是基於物理機進行虛擬化的虛擬機器中。研發和運維不僅僅要關注業務，也得關注硬體以及網路等資源。在雲原生時代，或者說雲的時代。我們只需關注app，業務層。底層資源雲廠商都幫我們解決了。我們可以花更多的時間在業務研發上。更加聚焦業務的研發。這是基礎設施的變化。
第二部分就是軟體交付方式的變化。隨著技術的不斷髮展，軟體的交付方式也發生的巨大的變化。為了將資源最大化，這時候軟體會發布到虛擬機器中，為了提升釋出效率，釋出方式也變成了指令碼化。隨著資源的不斷增加，虛擬化技術的發展，慢慢地企業都開始自建私有云，隨著業務的發展，釋出的方式也變成了自動化釋出。大家也知道隨著容器技術的成熟，容器成了應用釋出交付的標準。隨著公有云的發展，好多企業開始擁抱公有云，提升企業的效率和成本，那麼企業內的釋出方式變成了容器和包共存。企業的基礎設施架構也基本上都是混合雲的模式。釋出的方式，在自動化的基礎上開始智慧化，想彈性伸縮，故障自愈變的越來越受到推崇。
京東雲 DevOps 案例：在第三部分，井亮亮分享了京東雲構建DevOps的經驗。
這些年，很多企業都把多雲作為企業的戰略，雞蛋不會都放在一個籃子，那又怎麼支撐整個多雲戰略挑戰呢？我們透過摸索和實踐證明，配置管理CMDB是企業內部實施DevOps的基礎，決定了整個DevOps的成功和失敗。
京東雲的CMDB模型以應用為核心，管控整個資源的層面，把整個業務的模型服務數的形式表現出來。關於系統怎麼使用這資料，CMDB準確性十分重要。整個CMDB模型的構建並不完善，有以下三個點供參考：第一個是提供最簡單的介面錄入方便研發、測試、運維把整個資料貫徹進去，另外需要提供API，讓關聯的業務系統能夠方便把資料關聯起來。最後是透過Agent採集的方式，把一些機器中資料透過agent主動採集上報上來。確保cmdb資料的準確性。
第二個是客戶端資源的挑戰，據據2019年devops中國社群的統計報告資料，顯示有超過五成的企業在管理100臺以上的機器。在這麼多機器上，就會帶來一系列客戶端的挑戰，可能會面臨機器中各種Agent多、各種資源限制、存活守護、部署後更新升級和維護髮布等問題。基於這樣挑戰，我們構建了超級Agent。根據業務訴求，具體到不同的業務Agent。
第三個是持續交付。早期，我們的方式都是程式碼包的形式，這些年隨著傳統的基礎設施從自建或者託管IDC機房的方式，轉變向公有云、混合雲；軟體架構也都在向微服務方向靠攏，部署的方式也由原來的包部署變成docker映象的方式，Docker 映象形成了應用分發和交付的標準，可以將應用與底層執行環境實現解耦；因此在持續整合方面，不僅僅需要支援程式碼包的構建，也需要支援映象的方式，但最終所有的構建產物需以版本化的方式分別存在製品庫中。持續整合一方面除了要做構建，另外也會透過流水線的方式把程式碼的靜態檢查，安全漏洞檢查結合起來一塊，提升程式碼質量和安全。關於構建語言這塊，因為所有的構建都在映象中，那麼需提供各種語言的編譯映象，當然使用者可根據需求，定製一些自己特殊的編譯映象；docker的構建，我們會提供統一的執行映象，這樣會規避一些os環境不一致，或者作業系統版本不一致的情況。這是CI方面。
部署有兩方面，一個包的部署，一個容器的釋出。包的釋出整個CMDB有業務模型，向上構建業務模型，向下構建資源模型，設定好整個部署的一些策略就可以去做釋出。容器釋出注意兩點，第一點是把一些偏計算應用放在容器裡面應用，做到整個容器的日誌儲存和展示。第二點是一定要打通關聯絡統。另外，每家企業的需求不一樣，彈性伸縮也不一樣，可以根據業務場景擴縮或按需擴縮。複雜業務場景支援編排部署，其特性就是可以實現暫停設定、併發設定、自動重試、失敗閾值、一鍵回滾等。同時，故障自動處理機制可以實現實時發現告警，預診斷分析，自動處理恢復故障，並打通周邊系統實現整個流程的閉環。以下是DevOps能力全貌。
最後井亮亮分享了在企業如何落地實施DevOps。第一步考慮清楚為什麼要改變，找到你的痛點是什麼，哪個地方有問題。如何得到支援。第二步分析現狀，有兩種方式，一是基於現有的DevOps能力成熟模型，自查企業中DevOps哪個階段需要提升，二是找諮詢公司。找一些外部顧問深入企業團隊中，評估哪些環節需要提升。第三步是分析現狀去設計要解決什麼問題，是採購還是基於開源，抑或是自己研發，根據企業現狀設計出來一套DevOps模型。最後也是最難的一點就是推廣，在設計工具時一定要考慮到相容性。在大家不願意改變的情況下，先進行試點，實質產生價值後進行規模化複製。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/69912185/viewspace-2672515/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- 從技術支撐到落地實踐 華為雲全面賦能“新雲原生企業”
- 探索雲原生時代：技術驅動的業務架構革新架構
- 雲原生技術
- 雲原生時代，應用架構將如何演進？應用架構
- 技術集錦 | 大資料雲原生技術實戰及最佳實踐系列大資料
- B站雲原生混部技術實踐
- 雲原生技術領域的探索與實踐
- 雲原生架構白皮書學習筆記(6)：主要雲原生技術-Serverless架構筆記Server
- 構築雲原生安全技術底座 | 綠盟科技釋出《雲原生安全技術報告》
- 中國銀行雲原生技術探索與實踐
- 技術盤點：雲原生中介軟體的技術演進與未來趨勢展望
- PouchContainer 容器技術演進助力阿里雲原生升級AI阿里
- GaussDB(for MySQL)雲原生資料庫技術演進和挑戰MySql資料庫
- 雙 11 技術攻略：企業雲架構的正確姿勢架構
- 【IT技術】阿里RDS首席產品架構師何雲飛：阿里雲資料庫的架構演進之路阿里架構資料庫
- Docker技術全景：推動雲原生架構的關鍵力量Docker架構
- 2024年的雲原生架構需要哪些技術棧架構
- 雲原生架構下的微服務選型和演進架構微服務
- 技術架構分享：美團配送系統架構演進實踐架構
- 餘額寶技術架構及演進架構
- 【上海線下活動】基礎運維及運維架構演進 -- 滬江技術沙龍運維架構
- 【技術乾貨】時速雲企業級容器PaaS技術沙龍 第八期
- 技術架構演進的思考架構
- 數棧技術大牛分享：雲原生大資料系統架構的實踐和思考大資料架構
- 大部分中國傳統線下實業企業不需要雲原生技術？
- 雲原生五大技術
- 重塑技術引擎 阿里落地全球最大規模雲原生實踐支撐雙11阿里
- Spring Cloud微服務分散式雲架構 - 整合企業架構的技術點SpringCloud微服務分散式架構
- 智慧安全3.0實踐｜SASE技術架構的演進之路架構
- 擁抱雲原生，作業幫多雲架構實踐之路架構
- 雲原生技術在離線交付場景中的實踐
- 容器技術在企業落地的最佳實踐
- DTCC演講 | PolarDB-X技術架構：雲原生分散式資料庫架構分散式資料庫
- 阿里雲的“全站加速”技術演進歷程阿里
- （二）spring cloud微服務分散式雲架構-整合企業架構的技術點SpringCloud微服務分散式架構
- （二）spring cloud微服務分散式雲架構 - 整合企業架構的技術點SpringCloud微服務分散式架構
- （二）微服務分散式雲架構 - spring cloud整合企業架構的技術點微服務分散式架構SpringCloud
- 騰訊雲CDB的AI技術實踐：CDBTuneAI