面對"不確定性"的最佳解：現(xiàn)代化應(yīng)用

「長期規(guī)劃」真的無效了嗎？對此，我更傾向持保留意見。自從人類步入快速發(fā)展的數(shù)字化時代，「可確定的未來」在很多時候確實(shí)已成為一種奢侈，就如同新冠疫情絕不會是最后一只黑天鵝，但這并不代表不再「長期規(guī)劃」有效。相反地，現(xiàn)在企業(yè)的「長期規(guī)劃」正在回歸到更為基礎(chǔ)與核心的業(yè)務(wù)本質(zhì)，也就是如何在變革的常態(tài)中，保持業(yè)務(wù)競爭力與創(chuàng)新的活力，讓企業(yè)具備應(yīng)對變化的韌性。

事實(shí)上，即使在去年商業(yè)活動最舉步維艱的那段時間，我們?nèi)钥吹皆S多具備靈活性的企業(yè)快速適應(yīng)了新的環(huán)境，甚至發(fā)掘出新的成長機(jī)會。相信很多人和我一樣好奇，這些企業(yè)的數(shù)字化基礎(chǔ)設(shè)施如何能在極短的時間去適應(yīng)與過去迥異的業(yè)務(wù)需求。我們很快得到了答案──從去年開始，「現(xiàn)代化應(yīng)用」被越加頻繁地提及。

這意味著，更多的企業(yè)意識到現(xiàn)代化應(yīng)用的敏捷性、通用性及擴(kuò)展性等優(yōu)勢，成為企業(yè)立足長期發(fā)展的「標(biāo)配」。當(dāng)你不知道變化將從何而來，也無法制定如同說明書一樣按部就班的發(fā)展計劃時，構(gòu)建與業(yè)務(wù)互相搭配且更為敏捷的現(xiàn)代化應(yīng)用架構(gòu)，就成了面對不確定性的最佳解。

雖然有時候我們會用微服務(wù)、容器化、無服務(wù)器這類技術(shù)名詞去描述現(xiàn)代化應(yīng)用，但必須強(qiáng)調(diào)的是，現(xiàn)代化應(yīng)用及實(shí)現(xiàn)過程并不是技術(shù)和產(chǎn)品的機(jī)械化堆棧。企業(yè)對現(xiàn)代化應(yīng)用的向往并不是因?yàn)槠浼夹g(shù)先進(jìn)，而是為了適應(yīng)業(yè)務(wù)需求并助力業(yè)務(wù)拓展，以不斷發(fā)現(xiàn)新的機(jī)會，或創(chuàng)造更好的產(chǎn)品和服務(wù)。

現(xiàn)代化應(yīng)用：始于業(yè)務(wù)、終于業(yè)務(wù)

雖然現(xiàn)代化應(yīng)用的價值來自一個長周期內(nèi)對企業(yè)業(yè)務(wù)支持的「總量」，但基于與眾多用戶的溝通，我們發(fā)現(xiàn)現(xiàn)代化應(yīng)用也同樣是他們立足當(dāng)下的現(xiàn)實(shí)需求。舉幾個有代表性的例子：有些用戶會希望更少關(guān)注基礎(chǔ)設(shè)施管理，而是專注于業(yè)務(wù)本身；有些則希望軟件架構(gòu)從反映企業(yè)組織架構(gòu)轉(zhuǎn)變?yōu)榉从硺I(yè)務(wù)邏輯；還有些用戶希望開發(fā)團(tuán)隊(duì)花費(fèi)寶貴精力所編寫的每一行代碼都符合業(yè)務(wù)邏輯。

總結(jié)而言，企業(yè)使用者需要現(xiàn)代化應(yīng)用的核心原因之一，就是從設(shè)計、構(gòu)建到管理都與業(yè)務(wù)緊密相關(guān)。現(xiàn)代化應(yīng)用一定是緊緊圍繞著業(yè)務(wù)核心，正所謂「始于業(yè)務(wù)、終于業(yè)務(wù)」。

至于業(yè)務(wù)如何從現(xiàn)代化應(yīng)用中受益，相信很多企業(yè)都有自己的看法和期待。在AWS眼中，現(xiàn)代化應(yīng)用的基本特征，或者說優(yōu)勢，體現(xiàn)在以下幾點(diǎn)：

一、敏捷性：快速開發(fā)、快速應(yīng)用，并且能夠敏捷地迭代；

二、可擴(kuò)展性：例如可擴(kuò)展到數(shù)百萬量級的用戶，確保足夠的彈性以保障業(yè)務(wù)拓展；

三、全球可用：這對于正在「出?！沟钠髽I(yè)尤為重要；

四、毫秒級的回應(yīng)能力：并且能夠處理PB級、甚至EB級的數(shù)據(jù)。

今天，無論是提供給使用者的現(xiàn)代化應(yīng)用服務(wù)，還是自己作為一家公司走過的現(xiàn)代化應(yīng)用歷程，我們所有的迭代與創(chuàng)新都來自于用戶及亞馬遜自身的業(yè)務(wù)需求。這些寶貴經(jīng)驗(yàn)是AWS 15年持續(xù)引領(lǐng)現(xiàn)代化應(yīng)用的重要基石，正如亞馬遜執(zhí)行長Andy Jassy所說：經(jīng)驗(yàn)沒有壓縮算法（There is no compression algorithm for experience）。我們所有的探索都不白費(fèi)，每一步都是經(jīng)過踏實(shí)地累積而來。

1995年亞馬遜創(chuàng)立之初，所有的邏輯只在一個單體式應(yīng)用里，也只有一個數(shù)據(jù)庫。隨著業(yè)務(wù)的拓展，到了2001年，亞馬遜進(jìn)入了面向服務(wù)架構(gòu)（SOA）階段，比如商品、訂單、服務(wù)等模塊都在那個時期成形。此后，亞馬遜進(jìn)入了更多領(lǐng)域，產(chǎn)品迭代和客戶體驗(yàn)迭代的速度越來越快，這些已經(jīng)按照SOA拆分出來的模塊，自己又會變成超大的單體。所以2002年到2006年，亞馬遜正式啟動了微服務(wù)化架構(gòu)。

為了支持新的應(yīng)用架構(gòu)方法，亞馬遜打破職級，將開發(fā)團(tuán)隊(duì)重組為多個小型的自治團(tuán)隊(duì)，規(guī)模小到每個團(tuán)隊(duì)只能用兩個披薩就喂飽。我們讓每個「雙披薩團(tuán)隊(duì)」集中開發(fā)一個特定的產(chǎn)品、服務(wù)或功能集，授權(quán)他們成為產(chǎn)品負(fù)責(zé)人，可以快速對他們負(fù)責(zé)的產(chǎn)品做出決策。從那時起，亞馬遜不只是從技術(shù)，而是包括從組織架構(gòu)和管理策略，建立一整套微服務(wù)體系，團(tuán)隊(duì)可以自行開發(fā)營運(yùn)和迭代。

亞馬遜在建構(gòu)高度可擴(kuò)展基礎(chǔ)設(shè)施的成功拓展新的核心能力，這才有了AWS在2006年的成立。到2020年，亞馬遜已經(jīng)有超過10萬個微服務(wù)，從起初每年部署幾十個功能，到現(xiàn)在可以每年部署幾百萬個功能。

過去15年來一直在現(xiàn)代化應(yīng)用領(lǐng)域持續(xù)投入與創(chuàng)新。與AWS「同齡」的Amazon Simple Queue Service（Amazon SQS）至今仍被許多客戶采用。2012年我們推出了鍵值和文文件數(shù)據(jù)庫Amazon DynamoDB，這個可以隨著應(yīng)用的拓展而幾乎無限擴(kuò)展的無服務(wù)器數(shù)據(jù)庫，目前每天可以處理超過10兆個請求，在Amazon Prime Day期間一度達(dá)到每秒8,920萬次的峰值。

2014年推出的無服務(wù)器運(yùn)算服務(wù)Amazon Lambda更是一個劃時代的創(chuàng)新。如果說我們90%的創(chuàng)新是基于客戶提出的具體需求，那么Amazon Lambda就屬于剩下的10%，此是根據(jù)客戶「只提出要實(shí)現(xiàn)什么目標(biāo)」而進(jìn)行的創(chuàng)新。此后，又推出適用于容器的無服務(wù)器服務(wù)AWS Fargate，和高效能關(guān)系數(shù)據(jù)庫Amazon Aurora──包括后來發(fā)布的Amazon Aurora Serverless V2，可在不到1秒的時間內(nèi)擴(kuò)展至支持幾十萬個數(shù)據(jù)處理交易，從而把客戶「希望從基礎(chǔ)設(shè)施管理中解放出來而專注于業(yè)務(wù)」的目標(biāo)做得更極致。

什么時機(jī)、選擇何種實(shí)現(xiàn)路徑，仍由業(yè)務(wù)「做主」

企業(yè)的現(xiàn)代化應(yīng)用轉(zhuǎn)型，是否有一些可遵循的脈絡(luò)？基于過往服務(wù)全球數(shù)十萬客戶的實(shí)戰(zhàn)經(jīng)驗(yàn)，總結(jié)三個可選擇的路徑，分別是：平移（Replatform）、重構(gòu)（Refactor）和建構(gòu)共享服務(wù)平臺（Shared Services Platform）。

在大多數(shù)情況下，這三個路徑將共同組成一個現(xiàn)代化應(yīng)用架構(gòu)的完整生命周期。因此，企業(yè)用戶在進(jìn)行現(xiàn)代化應(yīng)用轉(zhuǎn)型時，并非只取其一或遵守固定的順序。在什么時機(jī)、什么需求場景、選擇哪種路徑，最終要由企業(yè)特性和業(yè)務(wù)需求來做主。

「平移」通常是企業(yè)上云的第一步，即利用容器把本地數(shù)據(jù)中心的應(yīng)用遷移到云端，快速實(shí)現(xiàn)現(xiàn)代化應(yīng)用的架構(gòu)、交付模式和營運(yùn)模式。對使用者來說，平移的主要目的是把核心應(yīng)用快速上云，利用云端具備彈性的特點(diǎn)簡化基礎(chǔ)設(shè)施營運(yùn)并降低維護(hù)成本。例如在本地使用了Oracle或者SQL Server，就可以快速地將數(shù)據(jù)先搬到云端托管，暫時無需考慮數(shù)據(jù)拆分。

容器化是平移的利器，在這一路徑中扮演著相當(dāng)重要的角色。今天云端托管的容器有80%都運(yùn)行在AWS上，因?yàn)槲覀冊谌萜鞯漠a(chǎn)品和服務(wù)方面帶給使用者更靈活的選擇。

而「重構(gòu)」是透過微服務(wù)拆分、數(shù)據(jù)重構(gòu)以實(shí)現(xiàn)應(yīng)用基于業(yè)務(wù)邏輯的重構(gòu)，從而獲取數(shù)據(jù)驅(qū)動下的敏捷性和創(chuàng)新力。重構(gòu)過程中，微服務(wù)化是最重要的方法──把業(yè)務(wù)邏輯和數(shù)據(jù)透過API向其它團(tuán)隊(duì)公開，打造一個高度解耦的架構(gòu)。微服務(wù)的開發(fā)團(tuán)隊(duì)可以獨(dú)立迭代、發(fā)布應(yīng)用，大幅提升創(chuàng)新速度，同時最小化故障發(fā)生時的影響半徑。

重構(gòu)階段往往是利用新技術(shù)的最佳時機(jī)。例如，在此階段企業(yè)可以優(yōu)先考慮使用Serverless，讓「企業(yè)所寫的每行程序代碼都是應(yīng)用邏輯」的愿景成真。而在AWS，Serverless并不僅僅是無服務(wù)器運(yùn)算Lambda，而是提供給使用者一整套無服務(wù)器服務(wù)，來協(xié)助使用者開發(fā)基于無服務(wù)器的端到端核心應(yīng)用。

從三年前開始，Comcast旗下的影音廣告技術(shù)公司FreeWheel開始將多個本地數(shù)據(jù)中心逐步遷移到AWS全球的基礎(chǔ)設(shè)施。FreeWheel透過采用Amazon Elastic Kubernetes Service（Amazon EKS）容器協(xié)調(diào)服務(wù)，在不改變現(xiàn)有架構(gòu)的情況下實(shí)現(xiàn)應(yīng)用遷移，讓系統(tǒng)獲得了資源彈性；使用Amazon Lambda無服務(wù)器運(yùn)算打造高可用性的微服務(wù)，為各種規(guī)模的應(yīng)用程序提供支持，使得系統(tǒng)更易于開發(fā)和部署。

一系列云端創(chuàng)新的行動，讓FreeWheel能夠在奧運(yùn)會、Super Bowl、世界杯等10多個全球收視率最高的賽事活動期間，成功地支持所服務(wù)的一線媒體，順利因應(yīng)2秒內(nèi)激增100倍的超大流量，大幅提升維運(yùn)效率并節(jié)省了超過50%的資源使用成本。

「建構(gòu)共享服務(wù)平臺」則是為了實(shí)現(xiàn)現(xiàn)代化應(yīng)用的規(guī)?；渴稹?/span>

當(dāng)企業(yè)的微服務(wù)達(dá)到一定規(guī)模，可能會面臨「沒有專門針對微服務(wù)應(yīng)用快速部署營運(yùn)平臺」的挑戰(zhàn)。建構(gòu)共享服務(wù)平臺就是讓企業(yè)利用共享服務(wù)平臺標(biāo)準(zhǔn)化、自動化的營運(yùn)能力，加速現(xiàn)代化應(yīng)用開發(fā)的規(guī)?；?，協(xié)助用戶專注于產(chǎn)品開發(fā)、提高生產(chǎn)力。

如何既能讓每個微服務(wù)團(tuán)隊(duì)敏捷高效，又能讓其程序代碼部署管理更有一致性？AWS的AWS Proton是第一個針對容器和無服務(wù)器應(yīng)用程序部署的完全托管服務(wù)。借助AWS Proton，營運(yùn)平臺團(tuán)隊(duì)可以提供統(tǒng)一管理的無服務(wù)器和容器的模板，使數(shù)百或數(shù)千支應(yīng)用開發(fā)團(tuán)隊(duì)無須自己管理和維護(hù)這些基礎(chǔ)架構(gòu)，只需專注于開發(fā)業(yè)務(wù)邏輯程序代碼。企業(yè)只需按任意順序達(dá)成五個元素。

無論企業(yè)如何實(shí)踐以上三個路徑，最終目標(biāo)都是為了建構(gòu)「有效的」現(xiàn)代化應(yīng)用，使其能夠真實(shí)有效地提升企業(yè)未來的敏捷性和創(chuàng)新速度。

為此，企業(yè)需要做到讓自身的現(xiàn)代化應(yīng)用按任意順序去達(dá)成五個元素，其中既包括設(shè)計和建構(gòu)方式，也包括管理模式的轉(zhuǎn)型。

五個元素敘述如下：

一、架構(gòu)微服務(wù)化

微服務(wù)克服了單體式應(yīng)用龐大、添加改進(jìn)功能復(fù)雜等挑戰(zhàn)，應(yīng)用程序由獨(dú)立組件組成，每個組件作為一個服務(wù)運(yùn)行，實(shí)現(xiàn)一個特定業(yè)務(wù)功能，按照需求進(jìn)行靈活更新、部署和擴(kuò)展。在當(dāng)下，微服務(wù)已經(jīng)成為現(xiàn)代化應(yīng)用「靈魂」般的存在。

二、數(shù)據(jù)庫專用化

應(yīng)用現(xiàn)代化之后，資料和應(yīng)用也可以解耦了。數(shù)據(jù)庫和微服務(wù)相輔相成，可以帶來多個好處：微服務(wù)數(shù)據(jù)量成長時只需變動相對應(yīng)的數(shù)據(jù)庫，獲得更好的擴(kuò)展性；可避免單體式數(shù)據(jù)庫故障而影響整個應(yīng)用，容錯性更強(qiáng)；微服務(wù)可以自由選擇最適合業(yè)務(wù)需求的數(shù)據(jù)庫，靈活度更高。

三、自動化的軟件交付管道

當(dāng)單個團(tuán)隊(duì)獨(dú)立交付軟件，尤其是在手動交付時，彼此的協(xié)調(diào)性和質(zhì)量一致性就成為挑戰(zhàn)。對此，我們采用的解決方案是標(biāo)準(zhǔn)化和自動化雙管齊下。首先，將軟件交付流程定義為最佳實(shí)踐模板，各個團(tuán)隊(duì)都用模板配置基礎(chǔ)設(shè)施資源，確保正確起步；其次，透過自動發(fā)布管道，包括持續(xù)整合和持續(xù)部署（CI/CD），可以快速測試和發(fā)布大量程序代碼，最大限度地減少錯誤。

四、基礎(chǔ)設(shè)施無服務(wù)器化

當(dāng)我們說「無服務(wù)器」時，我們指的是那些不需要基礎(chǔ)設(shè)施供應(yīng)和擴(kuò)展，具有內(nèi)建的可用性和安全性，并使用按需付費(fèi)模型的服務(wù)。無服務(wù)器能夠讓團(tuán)隊(duì)從那些與業(yè)務(wù)沒有直接關(guān)連的基礎(chǔ)設(shè)施維護(hù)工作中解放出來，專注于創(chuàng)造更有價值的用戶體驗(yàn)和創(chuàng)新產(chǎn)品。

五、安全特性整合化

在現(xiàn)代化應(yīng)用中，安全功能內(nèi)建于每個組件，隨版本變化自動測試和部署。這也意味著，安全不再只是安全團(tuán)隊(duì)的責(zé)任，而是深入整合到開發(fā)生命周期的各個階段，工程、營運(yùn)和合規(guī)團(tuán)隊(duì)都要發(fā)揮作用。

寫在最后

以上是AWS對于現(xiàn)代化應(yīng)用的一些觀點(diǎn)和經(jīng)驗(yàn)總結(jié)。我認(rèn)為現(xiàn)在與大家深入探討現(xiàn)代化應(yīng)用恰逢其時──企業(yè)對基礎(chǔ)設(shè)施敏捷性和彈性的高度需求是前所未見的，而作為連續(xù)11年被Gartner評為領(lǐng)導(dǎo)者的云端服務(wù)供貨商，AWS帶來的一整套現(xiàn)代化應(yīng)用建構(gòu)方案及方法論，也確實(shí)值得被關(guān)注和思考，因?yàn)檫@些探討都經(jīng)過無數(shù)實(shí)際應(yīng)用的檢驗(yàn)，而且已被證明有效。

現(xiàn)代化應(yīng)用轉(zhuǎn)型將是一個長期、持續(xù)的過程。在這趟旅途中，AWS也期待聆聽所有客戶的需求，并運(yùn)用我們在云端服務(wù)領(lǐng)域卓越的廣度、深度和創(chuàng)新速度，為每一個客戶建構(gòu)可支持未來長期業(yè)務(wù)創(chuàng)新的現(xiàn)代化應(yīng)用架構(gòu)。

（本文作者顧凡為AWS大中華區(qū)產(chǎn)品部總經(jīng)理）