簡介：在雲原生等技術的加持下，2022 年的架構領域有哪些值得關注的趨勢？雲原生如何撐起架構的未來？

作者：辛曉亮

採訪嘉賓：至簡、彥林

軟體架構發展至今，經歷了從單體架構、垂直架構、SOA 架構到現在的以微服務、服務網格等雲原生技術為主的演變過程，雲原生技術發展勢不可擋，老生常談的“雲原生”將依然會是未來的熱門話題。而且隨著數字化轉型加速，企業對於雲的使用將會達到新的水平，雲原生架構和雲原生應用也將會持續迭代演進。

那麼在雲原生等技術的加持下，2022 年的架構領域有哪些值得關注的趨勢？雲原生如何撐起架構的未來？本文轉載自 InfoQ 架構頭條，阿里雲 MSE 負責人李豔林（彥林）、阿里雲高階技術專家李雲（至簡）一起做客 InfoQ 視訊號，分享雲原生架構領域最新趨勢。完整視訊回放點選閱讀原文觀看。

軟體架構演進過程

InfoQ：軟體架構經歷了從單體架構到 SOA 架構再到後面以微服務雲原生為代表的架構形態，中間有哪些關鍵的節點？

至簡：講今天的雲原生我覺得我們還是需要回顧一下歷史，去了解一下它是怎麼一回事。

• 2000 年的時候，還沒有虛擬化的概念，大家看到的都是物理機；
• 2001 年 VMware 橫空出世，不過這個時候交付的還是一個虛擬機器；
• 之後 2006 年亞馬遜推出 IaaS（基礎設施即服務）平臺 AWS，這個時候的思路已經是把 CAPEX（資金投入成本） 變成 OPEX（運營成本）。就是我不需要再買一大堆機器，而是用到了再去雲上買；
• 2009 年 Heroku 提出 PaaS，這個時候不再是用虛擬機器來交付，變成了 Buildpacks，也開始了有了容器化的概念，還有 12 要素應用程式的一套規則；
• 2010 年，出現了 OpenStack，它其實是通過開源的方式來做 IaaS，目的是跟 AWS 做競爭，它構建的 building block 還是一個 VM；
• 2013 年，Docker 的出現帶來了比較大的變化，這個時候交付就變成了容器。

今天講的 Cloud Native 最早由 Pivotal 提出，後來由 2015 年成立的 CNCF（Cloud Native Computing Foundation）進行了定義。

其實整個過程中我們能很明顯的看到一些變化，從大型機、Server 到 VM、Buildpacks，再到容器，隔離的單元也是越來越小，從很重很大到後面通過微服務軟體架構把它變得很小。這中間最重要的目的是為了做解耦。大家可能對 Cloud Native 有很多想法，但我覺得關鍵的一點就是 Cloud Native 的核心是什麼，從我自己的認知來看，我覺得所有的軟體都有一條至理名言，我們叫做分而治之，也可以叫做解耦，或者高內聚低耦合。通過不斷的解耦變成微服務，讓整個互動更加敏捷。而不是像以前單體應用耦合在一起，很難協同，很難交付。

Cloud Native 還有一個重要的要素就是 no lock-in，即避免技術鎖定。從 CNCF 定義標準說起，CNCF 不會直接說某個東西是一個標準，他們會認為這個東西是一個關鍵的元件，並表示這個元件是被廣泛採納的，也是我們 CNCF 認可的。這樣的話就會有更多的人去用，也知道這個軟體會有長期的維護，自然而然它就會標準化，而這種標準化帶來的好處就是 no lock-in，我覺得可以從不同的維度去理解它。

從廠商的角度來講，你可以靈活的選擇不同的雲供應商；另一種就是對於工程師講，你在 A 公司的平臺上做業務開發，很有可能離開 A 公司後就沒有辦法施展了，no lock-in 帶來的好處就是不會把員工鎖定在一家技術公司，只要你掌握的是 Cloud Native 技術，你所從事的崗位就可以在人才市場上做流通。

彥林：剛才至簡是從整個軟體行業的角度去講的，我從產業角度簡單說一下我的理解。

現在的雲原生技術，包括軟體架構的形態跟網際網路 1.0、2.0、3.0 是有很大關係的。最早網際網路 1.0 時代都是靜態頁面，這個時候多數網站承載的內容比較簡單，單體應用基本上加 CDN 就能解決；隨著網際網路進入 2.0，各種入口網站、Web 應用湧現出來了，也開始有互動了，更多的互動、更多的渲染對技術的整體要求變高了，單體應用已經不能滿足日益複雜的業務需求，軟體變得複雜，場景變得複雜，人力協同數字化程度變得越來越高，這個時候就進入了 SOA 和微服務的時代；之後整個產業又發生了一個比較大的變革，就是移動網際網路，第三個時代的到來對實時性提出了更高的要求，包括“主動獲取、被動推送”。資訊的獲取量、實時渲染量更大，整個 IT 系統在這個階段也是爆發性的增長，對數字化系統要求更高。

隨著整個雲端計算的發展，其實更多的隨著雲的發展，在 2015 年左右的時候，按照剛至簡說的，通用化和標準化這個事情基本上在逐漸的形成，在 2015 年之後，行業中的關於各種的容器化，比如 Docker、K8s 包括 Spring Cloud 都是在這個時代陸續的產生，大概是這麼一個情況。

InfoQ：經歷了這麼多年軟體行業和產業的變化，雲原生架構現在發展到了一個什麼樣的階段呢？

至簡：我覺得今天來看的話，可以說雲原生架構已經被各行各業廣泛接受。

以 Service Mesh 為例，服務網格現的接受度在過去一年有很大的增長。講雲原生架構之所以拿 Service Mesh 來舉例，是因為雲原生整體的概念已經被廣泛接受，比如像雲原生下的 K8s 毫無疑問已經是一統江湖的局面，而相比之下 Service Mesh 是偏晚的。Service Mesh 曾經被質疑的問題比如效能等，到今天已被逐步接受，接受並非代表性能問題被完全解決，而是大家知道如何揚長避短地用好。

今天很多企業考慮的問題是我如何去落地雲原生這個技術。我覺得雲原生不管是理念也好、設計模式也好，它是一個組合在一塊的。我不會簡單的說雲原生髮展到整個歷程的 50% 或 60%，不會用這個思維去看待它，而是說我們能不能先上到雲原生，隨著雲原生技術的演進，我也能跟著這個節奏去往前走。

我覺得好的地方是整個大眾對雲原生技術有很好的認知和理解，然後雲原生整體趨勢也是樂觀和蓬勃發展的。

彥林：我講一下我對這個事情的理解，首先從軟體技術上分層去講的話，今年大家可以看到，包括阿里雲和其他所有的雲都在講容器 Anywhere，其實容器已經成為了一種基礎設施，隨著未來三到五年的發展，保有容器的量可能比單獨跑在 ECS 上的要多。

從微服務角度去看，因為我們最近在做兩年規劃，大家應該也看到了一些關鍵的資料，比如中國程式設計師的平均工資多少，平均工資那就是人力成本，其實已經遠遠高於 IT 的算力成本和資源成本。容器更多解決的是資源排程成本、運維成本，微服務更多解決的是研發成本、協同成本。因為大家在一個程式碼上去共建人太多的話，效率是非常低的。所以第一個面臨的問題就是人力與效率越來越重要，而且隨著整個行業競爭的加劇，你跑得快就有優勢，跑慢了就會錯過這個機遇，網際網路行業就是“快魚吃慢魚”。

我在關注的資料中還有一個比較新的事情是整個程式設計師的年齡分佈，90 後已經成為構建數字化經濟的核心中堅力量，他們的協作模式和工作風格與老成員已經不太一樣了。他們喜歡更敏捷更獨立的協作模式，微服務其實就是更符合他們的一個協作模式。

目前從整個行業來看的話，微服務已經成為一種主流的選擇。而且我們從另外的兩個資料也可以看到：第一個就是從整個行業看微服務每年有差不多 20% 以上的增長，就是說整個行業每年有數萬家企業在做微服務的改造；第二個就是除了網際網路公司進行容器化和微服務改造，許多傳統行業，比如零售、醫療、金融等等，陸續開始進行數字化升級，微服務在整個社會有了更廣泛的運用空間。

從另外一個技術角度來看，不管是單體應用、微服務，還有未來的服務網格、Serverless 等，都有自己的應用場景，今天可能是因為人力成本的提升，整體年輕化對協作要求更自由、更獨立，容器跟微服務在這個大趨勢下越來越重要了。

InfoQ：剛才我們聊的過程中也看到了不少觀眾表示受認可的情況，也提到了一些落地的案例，兩位老師有沒有相關落地案例分享？

彥林：落地案例其實非常多，我簡單舉幾個可以對外講的例子吧。

來電科技在前幾年就完成了整個雲原生的技術改造，容器化、微服務都做了，在研發效率、資源利用率上都得到了比較大的提升。現在他們已經走到了雲原生的第二個階段，當下比較大的問題是服務治理，比如優雅上下線、無損下線，同時也會面臨高可用的問題，比如它實際場景，線上線下融合，對線上穩定性有更高的要求，就需要一套高可用體系，包括限流、降級、熔斷、回滾、全鏈路灰度。他們目前是已經走到了這個階段，在服務治理上也是比較高的一個層次，代表了一些傳統企業和網際網路有交集的一個案例。

另一個就是斯凱奇，他們也趕上了數字化轉型，知道數字化經濟在國內已經是勢不可擋的趨勢， 不加入這個趨勢就可能會被淘汰。他也聯絡我們準備做整個中臺系統，差不多幾個月的時間裡快速複用阿里中臺技術架構，構建他的整個零售系統，當然在這個過程中也遇到了一些問題。就是做微服務系統的時候，之前他的整個系統有 POS 機、Web、App 多端接入，包括有一些傳統架構，一部分是新的微服務架構，這個過程中，通過新的雲原生閘道器解決了內網到外網的安全問題，比如證書管理、Web 防護、安全認證等。

另外斯凱奇也會做大促，峰值是平時的好幾倍，他們複用了阿里的高可用體系，從入口到後端，做了一個端對端全鏈路的限流降級熔斷的機制，保證整個交易過程中的高可用。也通過整個全鏈路壓測系統去演練，提前一個月就演練成功，支撐了整個斯凱奇在雙 11 當天交易的電商系統。

幾個月的時間能打造這樣的一個系統，這就是整個雲原生給大家帶來的一個紅利，我就簡單分享這兩個案例。

至簡：我簡單補充一下，今天講雲原生架構的落地不是很小的數字了，已經是成千上萬的概念。

如果你經常關注整個行業，就可以看到，幾乎有一點名氣的網際網路大廠，都不是說在探索了，已經是深度用了，我認為在這點上是沒有任何疑問的。

InfoQ：在這個過程中或者說新技術的落地和應用會遇到什麼問題，又該如何面對？

至簡：我們在面對新技術的時候，“新”不是最大的問題。

我恰恰認為每個新技術的出現，伴隨著的是會讓我們重新去審視每個企業在發展過程中留下來的技術債務。包括之前在阿里集團內部做 Service Mesh 落地，我感受最痛的不是這個技術新不新、或你不能把它做出來，而是你要花大量的精力和時間先去把把歷史包袱處理好。

所以在落地的過程中，我看到的一個最大的痛點其實還是改造的成本，包括以前的架構搬到雲原生上來，可能要做服務的拆分等。因為雲原生架構不是簡單的說你把它搬到容器上這個事情解決了，而是說我們要借這個契機，該做微服務化的做微服務化，至少在效率上我們要有所體現。

彥林：我講一下我在實踐中的一些具體感受，首先大家對新技術要抱一個開放的態度。舉個例子，不管是微服務還是容器的改造，它改變的不僅僅是軟體的架構，還有組織的架構。比如我們把阿里的軟體架構輸出到一些傳統企業時發現，阿里整個組織都是扁平的，微服務也是扁平的分散式的，所以大家協同效率比較高，是敏捷開發模式。但是很多組織還是金字塔的形式，跨部門協作效率會比較低。當然隨著軟體架構的改變，組織架構也會隨著軟體架構去改變，這個大家可以慢慢體會。

然後當大家解決心態問題邁出第一步之後，確實會陸續面對一些問題，因為軟體行業沒有銀彈，沒有萬能的架構，比如微服務架構它確實是超過 10 個人的團隊，超過 5 個子系統才會在整個生產力上有更大的優勢。大家在做微服務本身改造的過程中更多的問題是我的系統拆到什麼力度？我認為“一主一備”是比較合適的一個區間，拆得太細會帶來更多的協同成本跟運維成本。當然也不是說拆得細了就一定不行，有一些業務場景偏離線計算型的，它更輕就可以拆得更細，這個就需要有經驗的專家去做領域的切分。

具體說微服務拆分，我當時遇到的第一個問題就是定位，微服務之後你會發現日誌跑到十幾臺機器中去了，檢視所有日誌代價是非常大的，出問題的診斷代價也是非常大。現在行業鏈路追蹤，包括 APM，還有監控報警就是解這個領域的問題。

另外我們看到一個數據，就是容器裡 70% 都非常容易的去實施微服務，為什麼呢？因為微服務之後，你應用的部署更細更多，運維成本會上升。容器很大部分通過自動化的模式解決了運維成本，實現了相輔相成的效果。通過容器的演進，解決了微服務拆分之後的一個部署成本的問題。

從整體上來看，我能慢慢感受到的是，現在整個容器跟微服務的使用的門檻已經比之前低多了。今天通過開源和雲端計算的發展，降低了這些技術的門檻，剩下的可能更多的是決策者在尋找合適的時機。比如我知道業務要爆發性增長了，複雜度變高了，我要做雲原生架構的演進，把問題解決掉，大概是這樣。

未來架構趨勢展望

InfoQ：可以簡單聊聊多雲架構是怎麼回事嗎？

至簡：在我們看來雲原生很重要的一個驅動力就是防止鎖定，也是企業比較在意和希望有一個標準化的東西。

多雲的話，當前的客戶管理多雲會有一些挑戰。我覺得這會是一個過程，從最開始大家講要上雲原生，到多雲、混合雲，這兩者毫無疑問是雲原生的關鍵內容，也會讓開發者越來越方便使用這一技術，它是以開發者為中心的角度去做的，所以未來肯定是會有相關的技術和產品陸續出來，包括現在已經有一些了。

另外，我理解短期內大家可能會覺得沒有那麼好用，但是我認為這個會越來越好用，這肯定是各個雲廠商都會去重點關注的，因為我們發展的重點還是看我們能解決客戶的哪些痛點，幫助客戶更好地發展他的業務。

彥林：多雲這個可能不同的廠商有不同的叫法，比如跨雲、混合雲，我們這邊更多的強調分散式雲。我能感受到的是，行業裡為什麼選擇多雲，大家有不同的理念。

海外的情況可能是有一些高可用的需求，國內就是大家希望有更便宜的資源，打價格戰。海外就是希望利用每家雲的優勢，比如 AI 大資料谷歌雲強一點，傳統 IDC 領域 AWS 強一點，這樣就可以混合去使用，線上業務在 AWS，離線的放在谷歌，諸如此類，配合使用。

我舉這個例子就是說，對於大部分的廠商跨雲一定是有成本的。國內部分企業可能希望選擇多家雲廠商，談一些折扣，但帶來的結果是，跨雲之後的運維複雜度上升和管理成本上升，我瞭解到的國內網際網路行業在這方面投入了比較大的人力去抹平。

InfoQ：我們之前收集了一些社群問題，想問一下未來五年軟體架構會出現什麼樣的新形態？

至簡：架構究竟是什麼我覺得我們需要先捋一捋，我理解的架構是由三個要素組成的，核心就是概念，第二個是概念跟概念之間的關係，在概念和關係之上施加的第三個要素就是約束。

雲原生的出現其實講的是一種架構的實踐，這種實踐它是基於我們過去所看到的和麵臨的問題，重新回顧和反思，把之前的概念打破、拆分，再重新去塑造這個概念，最後形成了今天所講的 Best Practices（最佳實踐），包括很多設計模式比如 Sidecar、Operator 等等。

如果說未來五年完全沒有新的架構理念出來也不太可能，但是顛覆性的，我個人認為不太會。如果要顛覆雲原生架構，首先雲原生技術需要應用到一定程度，然後遇到了還有更極致的追求的狀況。至於變化，有新的概念提出來是很正常的，行業的發展就是不斷的有人塑造概念，這恰恰是技術發展的現象和自然而然的一個狀態。

彥林：除非量子計算髮聲，我認為這個時代來臨之前分散式時代會長期的存在。然後在長期存在的分散式時代裡，我們能感受到一些趨勢在發生。

因為有了容器，有了微服務，業務變成無狀態了，今天整個靈活排程的彈效能力做到極致的話，未來 Serverless 是有可能的。從我們今年的技術架構中介軟體客戶端輕量化，業務側會 Serverless 化的去演進，因為業務現在是越來越無狀態了。隨著底層基礎設施的完備，彈效能力的具備，有往上去演進的可能性，但從我們今年角度就是說偏前端比如離線計算的一些任務 Serverless 會比較容易。我相信隨著基礎技術的不斷突破，包括硬體加速的技術等，包括很多大廠對 Serverless 都有佈局，之前大家談 Serverless 都是說應用架構，現在比如訊息儲存都有對應的 Serverless 產品，所以 Serverless 可能就是未來的一個技術思想。

另外，我能感受到的是容器以下，更多的是關心 DevOps，解決運維效率，雲原生前半場解決 Ops 的問題，就是運維的問題，未來更多的是解決 Dev 的問題，就是怎麼讓研發效率更高，開發迭代更快。當然在這個過程中，中介軟體包括微服務可能更多的解決預設的安全可信和穩定性問題。

架構師成長經驗分享

InfoQ：不少程式設計師在從普通開發者轉向架構師的時候會遇到一些瓶頸，兩位老師有什麼架構師成長上的經驗可以分享給大家嗎？

至簡：其實架構師領域有很多東西可以講的，我先說一下我的想法，簡單分享幾點，彥林可以做補充。

首先做架構師第一點就是對技術要有追求，需要在技術上有一些積累，對軟體設計的追求，也就是我們講的《架構之美》。

第二點就是懂得切換視角，站在不同的角度去看待事情。我做架構師最大的感受就是，如何站在使用者、客戶或者說使用者的角度去看待我們正在做的事情。當你站在使用者或者客戶角度去看事情的時候，會發現完全不一樣的東西。

從我自己在過去一年做商業化這件事情上來講，是有蠻大一個感觸的。無論是開發交付給客戶用一個產品，還是做內部的一個模組，如何站到對方的角度去看，會發現我們熟悉的一個技術術語覺得很自然和簡單，但客戶或使用者並不這麼認為。

我個人覺得比較重要的就是思維的不斷升級，從關注個人，到關注的是更大的團隊、組織，是一個不斷突破的過程。做一個好的架構師，要有持續抽象能力，需要很務實，需要有產品思維和商務思維。認知越往高處走，會發現技術只是一部分，但是我要強調的是不要認為技術不重要，恰恰是把基礎技術打紮實了，才能有自信往前去突破。

彥林：剛才至簡講的很好，切換視角是很多人從程式設計師變成架構師或者是 PD、領導者的時候，都繞不過的一個坎兒。然後我補充以下我這邊的幾個想法，我經常面試，所以會結合這個來講一下我比較關心的幾個事情。

首先，就基礎技術或者軟體開發來說，我比較喜歡有好奇心的人，對技術感興趣，就能不斷把技術做深，反之做技術就容易浮在表面，很難有長期的技術沉澱。有好奇心驅動，才能深耕發展和走得更遠。

第二，就是工作中主動擔當。我也經常跟團隊的同學講，你搞不定我幫你一起做。在這個過程中，你可以得到更多的資源和幫助，獲得更快的成長。很多的成長都是往高區域跳一下，挑戰一下更有難度的事情，這樣才能不斷鍛鍊自己，站在更高層面思考問題。

第三，就是思考維度。剛才至簡提到了使用者視角和技術視角，還有一個視角也比較重要，就是全域性觀。

舉例來說，比如剛入職的員工看問題、拆解問題，不會想特別多，能把 10 個問題拆解成 5 個需求，5 個問題就已經上了一個層級，能從這 5 個需求中找出不合理的同時避開，這就有了產品的思維，再平衡排期把剩餘合理需求做完就鍛鍊了投入產出比與優先順序思維。而當你完整做完一整個產品的時候，你會不斷跟前後端、運營等做協同，協同的過程中能力就會慢慢鍛煉出來。同理，再往上走就是更多的周邊資源協同的能力等等。

簡單總結一下，入職 2-3 年，核心技術的深度積累是非常重要的，有了深度才能走的更遠；技術紮實之後，第二點就是培養產品思維，產品思維很重要，不要只是做技術；具備產品思維之後，第三個要做的就是上下游人的協同，做做架構師需要跟多個角色打交道才能把事情做好；等到協同做好了要解決的問題就是領導力與規劃未來的能力，這個要求就會比較高了。

InfoQ：非常兩位老師的解答，因為時間關係今天的直播就差不多到這裡結束了，非常感謝大家的觀看，也很感謝至簡和彥林帶給我們的精彩分享。

嘉賓介紹：

李雲（花名：至簡），阿里雲服務網格混合雲產品技術負責人。2018 年開始在阿里集團帶領團隊從事服務網格技術的發展與建設工作，在 QCon 做過多次雲原生與服務網格的技術分享。

李豔林（花名：彥林），Nacos PMC，阿里雲 MSE 產品創始人，阿里雲軟負載團隊負責人。

原文連結

本文為阿里雲原創內容，未經允許不得轉載。