如何利用雲原生技術建構現代化應用？

簡介： 阿裡雲為企業提供了基于阿裡雲網際網路架構的解決方案，也同時讓這些新的網際網路應用、新的電商平台應用遷移到阿裡雲上。

作者｜愚奇

​

今天，雲和雲計算技術已經被企業廣泛所接受，關于雲、雲計算、雲原生都有非常多的話題，但是我比較想讨論的是在所有雲當中真正的主角，就是我們的應用。

​

因為當企業應用上雲後，這些應用的高可用能力有可能提升了一部分，但仍存有許多問題；而當我們探讨上雲後這些應用的運維效率，卻未必有很大的提升，因為所有的運維都是基于基礎設施進行的，而雲計算是一個比較大的基礎設施的改變；如果我們再問，上雲後整個應用的開發速度是不是得到了極大的提升，這個時候很多人都要說，并不。

​

是以，今天主要探讨的就是如何利用雲原生相關的技術幫助我們的應用去做優化，從傳統應用轉變成現代化應用。

​

非典型的典型——雲上衆生相

​

我們先采取一個從個體再到整體的形而上的方式，來看一個比較典型的企業案例。

​

這個企業雖然和很多上雲企業有很多不同，比如說行業、應用類别、上雲動機等等，但他們同時也有很多共同點：比如上雲後解決了很多問題但仍然遺留了相當多的問題。這個企業屬于新零售行業，有不錯的銷售額。

​

但是随着業務的發展，傳統的 ERP 軟體已經不能滿足業務發展的訴求，最主要展現在當他要參與 618、雙十一這樣的年度大促時，他的 ERP 供應商告訴他，他們的軟體并不能支援達到上千或者上萬的 TPS，隻能夠支援到百級的 TPS。是以對于這些新零售的電商企業而言，他們沒有辦法去滿足大規模業務發展的訴求，也是以找到了阿裡雲。

​

阿裡雲為企業提供了基于阿裡雲網際網路架構的解決方案，也同時讓這些新的網際網路應用、新的電商平台應用遷移到阿裡雲上。整體而言，開發是找了 ISV 去進行委托開發，把客戶的應用從線下 IDC 遷移到了線上公共雲上，在這裡面最主要的技術更新是區域化，上雲之後整體的運維是客戶自己的運維部門來負責。整個遷雲的過程也非常成功，很好地解決了客戶應用的大規模問題，使得客戶可以很好地參與 618、雙十一這類的大促。

​

同時由于整體軟體也就是這個電商平台采用的是自研方式，是以比較大地釋放了像傳統 ERP 一樣高昂的成本。但由于整體的結構疊代非常快，導緻在有一次大促中，由于業務量非常大，導緻原來架構中的一個隐患引發了比較大的生産事故，對客戶自己而言，他們評估這次事故給他們造成了非常大體量的損失。

​

To 雲：“不上很焦慮，上了也焦慮”

​

是以說今天的很多企業，他們對于上雲都有很多的焦慮，展現在他們思考到底要不要上雲，因為上雲不能隻是單純跟風，而是要想上雲到底可以為他們解決什麼問題。

對于上雲之後的企業，他們雖然取得了階段性的成功，也需要思考他們還有哪些問題沒有得到解決。是以說不管有沒有上雲的企業，他們都非常焦慮，這就展現在他們都在思考怎麼樣才能很好地縮短研發周期，以支援快速的業務發展需要；怎麼樣去提升整體的運維效率，并在這個過程中讓他們的 IT 部門具備很強的控制力；在整體上雲和上雲之後，可以比較好地降低整體的 IT 應用成本，以及降低軟體的複雜度，提升整個系統的高可用能力等，這些方方面面絕大部分都聚焦在應用的非功能性特性上面。

1、焦慮的根源

所有的這些焦慮，我們可以從應用的角度去深度分析是什麼原因造成的。

大家知道對于應用而言，核心的就是架構，包括了應用的業務架構和技術架構。從應用架構上去看，需要滿足客戶的應用發展訴求。比如說資料的産生，随着今天 IoT 不斷普及，資料會産生非常大的接入量，對于這些資料的處理也帶來了更高的要求。

基于傳統的、更多的服務于人的請求的響應式資料處理方式已經不能滿足于業務的需求，對于 IoT 裝置更多的是基于請求、響應這類事件的模型和方式。同樣的，企業的業務發展需要跟更多的公司去進行生态的連接配接。這些大量的業務訴求也對底層的技術架構帶來了比較多的要求。這些要求就展現在，要求底層的技術架構能夠支援高度的備援，能支援微服務和海量的業務并發、以及能夠支援動态伸縮、能夠提供 SLA 等。

如果我們再進一步深度發掘，這裡面到底是需要解決什麼樣的核心沖突時，我們可以發現其實核心沖突在于随着上雲、業務的複雜度不斷增加，使得 IT 有更多的管理成本。而這個成本就展現在，所有的微服務、高可用都需要用高度的系統備援去解決。同時由于業務的快速發展，需要整個 IT 系統去響應頻繁的變換。核心沖突就在于，系統的高度備援與系統的頻繁變化之間的沖突，所有的分布式系統都在圍繞這一主要沖突來進行解決。

舉個例子，在原來的單機時代，如果我們隻需要一個人管理一台機器，用一台機器上的軟體就可以滿足自身業務發展的要求，那麼我們顯然沒有這麼多的沖突。隻有當一個人變成幾十甚至上百個人，當這樣一台機器不是運作在一個節點而是幾十上百甚至上千個節點時，整個 IT 需要處理的複雜度就從 1 對 1 變成了 1 對 N 的頻發。是以說整體的複雜度得到了一個極大的提升，這也是我們所講的沖突的根源。

2、快速解和深度解

那麼對于這樣的沖突有什麼樣的解法呢？今天在雲的時代，我們總結了一下有快速的解法和需要更多資源投入的深度解法。

​

快速解就包括了 re-host 的模式，即把應用的運作環境從傳統的線下 IDC 遷移到了雲的環境。在這種模式下，應用的架構沒有發生變化，應用的風險也是比較低的，但是價值的回報隻能說是較高。與此對應的另一個解法就是 re-platform，就是把整體應用的傳遞和運維都改變，但是應用的軟體架構不發生改變。

比如說我們通過容器的方式去改變整個軟體的留存，改變整體的運維留存。那麼在這個模式下面，它的架構變更的幅度是相對比較小的，實施風險是中等且可以得到比較高的價值回報。

但如果我們要徹底解決上面的問題，那麼就要采取整個軟體重構的 re-build 方式，或者對于軟體的重要子產品去進行一個 re-factor 重構的模式。這些模式都會涉及到軟體的架構發生變化，是以它的實施風險也是很高的，但同樣的高投入高風險也帶來了高回報，改變後的應用可以更好地解決沖突。

所有的解法都與雲原生有着非常大的關系。雲原生被提出來的最主要的原因，是企業上雲之後發現很多應用不能很好地去利用雲的特性，是以有人說很多應用不是雲原生類型的應用。是以，雲原生被提出來了。

雲原生的關鍵内涵

​

我們先不去讨論雲原生的定義是什麼，但我們要專門提出關于雲原生的三個關鍵内涵，了解這三個内涵對于我們怎麼樣去利用雲原生建構現代化應用有非常大的幫助。

​

雲原生技術：今天雲原生的技術有閉源的和大量開源的。閉源通常展現在對應用相對透明的雲廠商的基礎設施上面。同樣，大量的開源技術對于應用而言有比較大的關系，因為所有的應用會直接構架在這些開源的雲原生技術棧上面。但如果說這些應用要比較好地去利用底層的雲原生技術，我們通常會建議這些場景中我們的應用可以大量采用雲原生的産品。

​

雲原生産品：一部分客戶的技術棧都基于開源的技術棧所建構，但開源的技術棧雖然在很多技術、功能、穩定性上沒有問題，在可維護性和跟底層基礎設施的配合上卻可能會出現問題。是以我們會推薦應用盡量在雲原生産品上去建構。

​

雲原生理念：光靠技術和産品無法很好地解決前面提到的應用面臨的方方面面的問題，因為技術和産品是生産工具，生産工具的改變往往會導緻整個企業的 IT 文化，也就是生産關系的改變。

在整個 IT 文化當中，起到最主要作用的就是這其中整個企業的生産流程，以及生産流程之間人與人的合作關系。由于雲原生的技術和産品在工具層面帶來了改變，那麼不可避免地就帶來了在整個生産流水線，即企業的生産流程之間的改變。

​

比如說，原先有的崗位對人的要求發生了改變，或者原先的崗位沒有了，同樣一些新的崗位可能就被創造出來了。在這過程中，受到最大影響的就是人，包括人與人之間的協作關系。是以要很好地去運用雲原生，特别要注意的就是雲原生的技術和産品對于整個企業的生産流程、生産流水線上帶來的改變，特别是對于人群組織上面要求的更新。

1、雲原生是雲計算的再更新

雲原生不僅能幫助大家更好地去建好雲、用好雲、管好雲，同樣也是整個雲計算的再更新。

​

這不僅展現在雲的基礎設施層面的更新，即雲計算的提供廠商會意識到今天所提供的基礎設施還不能比較好地滿足應用的要求，需要不斷地更新以能夠更好地滿足應用在高效的傳遞、運維上面的需求。

​

同樣的，他也會要求應用在架構上徹底更新，讓應用展現出更好的彈性、韌性和可觀測性。有了基礎設施和應用的更新，我們會進一步去追求整體研發效率的提升，這其中有采用 Serverless 這些新的計算形态去幫助我們應用提升整體的傳遞和運維效率的方式，以及更重要的就是解決頻繁變化的 IT 系統當中的快速疊代和系統穩定性之間的沖突。

​

是以我們說雲原生是雲計算整體的一個再更新。

​

2、什麼是現代化應用

​

什麼是現代化應用，跟傳統的應用又有什麼差別呢？

現代化應用中包含彈性、可觀測性和度量、無狀态和安全等典型特征，在整體的一個計算結構上我們可以看到，現代化應用跟雲原生應用有非常多相似之處。它們之間的差別在于，現代化的應用不一定要跑在雲上。

​

雲原生應用顧名思義一定與雲相關，但是他們很多特征都是一樣的，它們都要求整體的應用要建構在雲原生的技術産品之上，這些技術和産品能真正地展現在應用采用雲原生的架構時，并且在整體的實施過程中要徹底貫徹雲原生的開發理念。這樣的應用才能夠比較好地跑在各種基礎設施上面。

​

既然提到了架構是承載應用的關鍵要素，那麼雲原生架構有什麼特點呢？

​

雲原生架構

​

雲原生架構是一組架構原則、設計模式和設計方法的組合。在這個組合上面有非常明顯的、差別于傳統架構的特點。

​​

雲原生架構會盡量幫助我們的應用把其中的非功能性代碼進行剝離。而在傳統應用中，有不少代碼需要去處理非功能性的問題。雲原生架構下，這部分代碼剝離出來後會被放到雲原生的基礎設施、産品和技術中去，由底層的 PaaS 平台和 IaaS 平台去承載客戶應用當中非功能性的問題，進而讓開發人員更多關注業務代碼的編寫。

有了這樣的雲原生架構去接管應用中原有的大量非功能特性，業務中原本因非功能性問題造成的業務中斷也可以被避免，同時使應用具備了更輕量、靈活、高度自動化的特征。

​

1、雲原生架構原則

​​

我們在雲原生架構下抽取出了最重要的 7 個雲原生架構原則：

1、服務化原則：微服務化顆粒度可以更好地滿足客戶應用的特征；

2、彈性原則：從虛拟機到容器層面到進一步應用層面具備不同彈性；

3、韌性原則：高可用原則的進一步提升，應用在各種情況下持續為客戶提供服務；

4、可觀測性原則：與監控不同，可觀測性模型可事先提供大量從日志到鍊路跟蹤的有效資訊，進而主動發現系統中的潛在風險；

5、自動化原則：從底層的硬體到軟體、元件，都有比較大的提升，是以更希望有自動化原則去幫助我們更有效地運維，進而降低運維成本；

6、零信任原則：雲原生架構可以運作在不同架構上，因而對安全提出了新的要求，要求所有的應用不管運作在什麼環境都是不信任的，每次運作請求都需要校驗合法性；

7、持續演進原則：可以根據企業的特點，每個階段采取适合的演進目标，長期疊代後使每個目标最終演變到現代化的應用。

​

2、雲原生的主要架構模式

雲原生的架構模式非常多，列舉如下圖所示，詳細的内容可以參考近期出版的《阿裡雲雲原生架構實踐》。

3、阿裡雲雲原生架構方法

​

關于雲原生的架構方法，我們提出了 ACNA 的架構方法。這是阿裡雲關于雲原生架構的一個架構設計方法，包含了對雲原生架構的評估體系和成熟度的度量體系，同時也包含了阿裡雲對廣大客戶在對應用實施雲原生技術改造過程中，積累的最佳實踐和用到的産品體系和技術。在這之中有一些架構視角，我們希望對每個企業來說，他們可以根據自己企業的情況去選擇與之相比對的技術架構能力，最終為業務發展、企業戰略發展服務。

4、阿裡雲雲原生架構閉環

​

整個架構方法是包含了多個視角的綜合體，在這之中我們希望通過架構持續演進能形成一個閉環。

​

整個架構閉環包含了最主要的八個階段。從識别業務痛點到确定架構目标，在評估風險過程中選取相應的技術制定疊代計劃，推動落地計劃中我們建議企業在實施雲原生架構過程中有一些專門的機構去評審整體的風險，進而讓整個過程形成一個閉環。而在這個過程中要特别關注架構治理視角，這需要有相應的組織或人員來幫助應用在疊代過程中進行架構治理。

5、如何衡量雲原生架構的成熟度

在 ACNA 裡我們提出了一個衡量雲原生架構的成熟度模型，其中有六個關鍵次元，我們簡稱 SESORA。

這六個次元的能力，也是在現代化應用中的最主要的六個關鍵名額。每個名額從 0-3 分為了四個等級，每個等級有對應的得分，在評估後可以得出一個關于應用在雲原生架構上得到的評分高低。今天阿裡雲提出的這個 SESORA 模型已經在業界中得到很多機構和企業的采納，進而可以幫助企業在雲原生架構改造上提高成熟度。

​

客戶案例

​

最後來看兩個典型案例。第一個案例是在阿裡雲上的應用怎麼通過雲原生的産品去有效預防在系統架構設計當中穩定性的風險。我們采用了微服務的架構模式，有大量資料是存放在 MongoDB 中的，在這個架構中客戶采用了 PTS、ARMS 和 AHAS 這個組合，這可以比較好地幫客戶去主動探測系統中是否存在潛在的風險，進而去預防穩定性的風險。

第二個案例是關于 Serverless 的案例，解決的問題是幫助微服務應用快速上雲。因為在這個過程中，我們往往需要應用去解決很多問題，而在 Serverless 模式下，這些底層的部署都得到了很大的複雜度降低。

​

當客戶應用有突發流量增加時，Serverless 會探測到并主動申請新資源，進而使新增流量得到及時響應；當突發流量消失時 Serverless 也會主動釋放資源，進而降低成本。

原文連結：

https://developer.aliyun.com/article/785284?

版權聲明： 本文内容由阿裡雲實名注冊使用者自發貢獻，版權歸原作者所有，阿裡雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿裡雲開發者社群使用者服務協定》和《阿裡雲開發者社群知識産權保護指引》。如果您發現本社群中有涉嫌抄襲的内容，填寫侵權投訴表單進行舉報，一經查實，本社群将立刻删除涉嫌侵權内容。