亞馬遜 CTO 的「中臺論」

做者 Werner Vogels 是 Amazon.com 的 CTO，他撰寫了一篇文章，總結 AWS 這二十多年來，如何經過變革應用程序架構、調整企業組織架構等方式，讓構建現代應用程序的客戶「將更多時間花在定義業務邏輯上，擴展系統以輕鬆知足高峯期客戶需求，提升敏捷性，同時更快、更頻繁地向市場發佈新功能」。在文中他提到亞馬遜「龐大的總體式‘書店’應用程序以及臃腫的數據庫極大限制了咱們的速度與敏捷性。每當咱們打算爲客戶提供新的功能或者產品，咱們就必須在專爲書店設計的應用程序當中編輯甚至重寫大量代碼」，將組織架構調整爲小團隊並「賦予他們對應用程序內特定部分的更多操做權限」，經過改變對技術的運用方式，業務交付速度提高很是明顯，好比某汽車領域客戶將將新功能的推出時間由六個月縮短至一週。這篇文章體現的，對比咱們如今倡導的「中臺論」，不少地方都不謀而合了。也可謂是亞馬遜的「中臺論」，雖然他們並無使用這個詞。

創新一直是亞馬遜公司 DNA 中的重要組成部分，但大約 20 年以前，咱們迎來了一場完全的轉型。當時的目標，是讓咱們的迭代過程——發明、啓動、從新發明、從新啓動、淘汰陳舊事物、再次重複——在速度上進一步提高。而咱們作出的變革，則深深影響到咱們構建應用程序甚至組織企業結構的具體方式。

那個時候，亞馬遜所服務的客戶數量遠不及當下。儘管如此，咱們很清楚若是想要對自身提供的產品與服務加以擴展，首先必須改變咱們的應用程序架構。

龐大的總體式「書店」應用程序以及臃腫的數據庫雖然爲 Amazon.com 提供了充沛的動力，但同時也極大限制了咱們的速度與敏捷性。每當咱們打算爲客戶提供新的功能或者產品——例如視頻流——時，咱們就必須在專爲書店設計的應用程序當中編輯甚至重寫大量代碼。這是一個漫長並且繁瑣的過程，須要複雜的協調努力，並且極大限制着咱們快速推動大規模創新的能力。

爲了從根本上解決這一難題，咱們經過《分佈式計算宣言》創建起新的變革藍圖。這是一份描述新架構的內部文檔。經過這份宣言，咱們開始將自身應用程序經過衆多被稱爲「服務」的小型基本單元加以重組，從而大幅提高對亞馬遜總體業務的擴展能力。

可是，變革應用程序架構只是故事的前一半。至於後一半……當時是 1998 年，亞馬遜內部的各個開發團隊都在使用相同的應用程序，所以每位員工都必須針對其當前版本進行跨團隊協調。

爲了支持這種新型架構，咱們分解了功能層級結構，並將企業組織從新編排爲小型自治團隊——小到每次點餐只須要兩份披薩。咱們將這些「雙披薩團隊」委派到不一樣的特定產品、服務或者功能集上，賦予他們對應用程序內特定部分的更多操做權限。這使得咱們的開發人員成爲產品全部者，並可以根據本身的決策迅速對個別產品產生影響。

拆分咱們的組織與應用程序結構無疑是個大膽的想法，但同時也是個行之有效的好主意。咱們得以更快地爲客戶提供創新成果，並且隨着亞馬遜的快速發展，咱們已經從每一年部署數十項功能發展爲現在部署數百萬項。更使人始料未及的是，咱們在構建這種高度可擴展基礎設施方面得到的成功，最終促成了另外一大核心競爭力的發展與壯大——這就是 2006 年誕生的 AWS。

而咱們，現在仍在堅持雙披薩團隊這一基本建制。

固然，咱們毫不是惟一一家強調創新的公司。爲了保持競爭力，亞馬遜必須不斷提升敏捷性，從而持續發現新的機遇並創造出更好的產品。也正由於如此，纔會有愈來愈多的客戶踏上與亞馬遜當年相同的旅程，並轉向現代應用程序開發。這種新方法須要從總體式架構遷移至更小的基本單元——或者說「微服務」，並且除此以外，現代應用程序的最佳實踐還要求在改變設計與構建技術之餘，從新考慮其管理方式。

爲了成功提高應用程序開發當中的敏捷性與創新速度，組織必須根據適合自身的順序採用如下五大元素：微服務、專用數據庫、自動軟件發佈流水線、無服務器運營模式以及持續自動化安全保障。

1架構模式：微服務

像亞馬遜這樣的大多數企業最初都是以總體式應用程序做爲業務基礎，由於這是一類開發速度最快、難度最低的系統。可是，這種將各個進程緊密組合並做爲單一總體服務的做法，每每會帶來一系列嚴重問題。若是應用程序中的某個進程遭遇需求高峯，咱們只能擴展總體架構才能實現單個進程的擴容。

另外，隨着代碼庫規模的增加，功能的添加與改進也開始變得很是複雜，這讓企業很難試驗以及實現新的想法。總體式架構還增長了應用程序的可用性風險，由於大量相互依賴且緊密耦合的進程會增長單一進程因故障受到的影響。

這就是微服務架構隨企業發展而出現的緣由所在。利用微服務架構，應用程序將由衆多獨立組件構成，這些組件將各個應用程序的進程以單一服務形式運行。服務將專爲業務功能而構建，例如在線購物車，並且每項服務只負責本身的一項功能。這些進程獨立運行並由對應的一支開發團隊負責管理，所以咱們能夠對各服務進行獨立更新、部署與擴展，最終知足對應用程序特定功能的需求。舉例來講，當出現用戶購買峯值時，咱們能夠單純擴容購物車服務以強化承載能力。

隨着組織由總體式架構逐步轉向微服務架構，不少開發人員也但願經過流水線管理各項服務中的依賴關係——這就要求咱們創造出新的方法以實現應用程序打包與代碼運行。好消息是，憑藉着強大的創新成果儲備，現在實例已經再也不是咱們的惟一計算選項。

你們也可使用容器或者 AWS Lambda 函數。容器是目前最受歡迎的代碼打包選項，同時也是實現遺留應用程序現代化的最佳工具之一。容器技術，爲咱們帶來出色的應用程序可移植性與設置靈活性。而利用 Lambda，你們則可以更輕鬆地獲取所需功能——利用代碼編寫出業務邏輯便可。

微服務架構的另外一大需求，在於咱們必須爲之創建一種服務間的相互通訊方式。目前大部分應用程序都繼續沿用 API 鏈接，但也有一些選擇在不一樣服務之間發送數據。具體包括用於實時數據處理的流、用於根據數據變化觸發響應的事件，以及用於應用級通訊及可見性的服務網格等等。你們能夠根據自身需求選擇最適合本身應用程序的集成方法。

2數據管理：專用數據庫

現代應用程序採用解耦式數據存儲機制，其中微服務與數據庫一一映射，意味着咱們再也不須要維持一套龐大的總體數據庫。這也是對傳統應用程序的一大重要革新，旨在解決總體式應用程序隨規模增加而遭遇的擴展性與容錯性難題。此外，單一數據庫同時也表明着單點故障源，並且很難知足一組不一樣微服務提出的特定需求。經過將數據與微服務剝離，咱們能夠自由選擇最適合自身需求的不一樣數據庫類型。

對於大部分應用程序，最佳選項仍然是關係數據庫；但也有其它一些應用程序有着不一樣的數據需求。例如，若是咱們運行的是使用高度鏈接型數據集的應用程序（例如推薦引擎），則能夠選擇具有存儲與導航關係的圖數據庫，例如 Amazon Neptune。

或者，若是您的應用程序須要實時訪問數據，也能夠選擇 Amazon ElastiCache 等內存內數據庫，其經常使用於遊戲以及物聯網應用場景。通常來講，可以充分知足您微服務需求的數據庫，就是最理想的數據庫選項。

3軟件交付：自動發佈流水線

咱們當初告別總體式架構並重組爲雙披薩團隊時，自動發佈流水線也就應運而生。這是爲了擺脫本來的單一版本發佈通道，容許各個團隊獨立交付本身的開發成果。

雖然這種新方式消除了更新的開發與交付等協調性挑戰，但同時也給咱們帶來了很多新的難題。首先，維持所有團隊的發佈流程與質量一致性變得很是困難。特別是考慮到發佈流程中的每一個步驟都在以手動方式完成，這無疑會大大增長產生人爲錯誤的可能性。

咱們的解決方案採起左右開弓的方式：標準化加上自動化。首先，咱們將軟件交付流程定義成最佳實踐模板，旨在爲雲環境下的一切基礎設施資源的建模與配置提供標準。這些「基礎設施即代碼」模板可以幫助咱們的團隊從正確之處起步，由模板經過代碼爲應用程序提供總體技術堆棧，而再也不依賴於手動過程。在亞馬遜，這種做法確保了各個團隊都可以根據咱們的要求實現對流程與部署的配置。

第二點，咱們開始利用自動化技術將手動流程從軟件交付流水線中剔除出去。在自動化發佈流水線的幫助下（包括持續集成與持續部署，簡稱 CI/CD），咱們得以快速測試併發布大量代碼，同時最大限度減小錯誤機率。經過 CI，咱們的團隊會按期將代碼變動整合至同一套中央庫內。然後，咱們會對其運行自動構建與測試，以確保可以儘早發現問題。而利用 CD，咱們的團隊天天能夠屢次提交變動，且無需任何人爲干預便可將成果投入生產。

起初，咱們發現去掉人爲干預只會帶來至關糟糕的部署後果。可是，咱們投入了大量時間編寫正確的測試與故障解決方案，並最終發現新體系大大提升了咱們的速度與敏捷性，同時也顯著加強了代碼質量。

4運營模式：儘量採用無服務器模式

現代應用程序當中包含大量活動部件。現在的現代應用程序每每由數千項服務組成，這遠遠超出了以往單一應用程序與數據庫的範疇，並且每一項服務背後都對應着一套專用數據庫外加一支負責不斷髮布新功能的團隊。

這些活動部件能夠分爲如下兩類：

• 做爲企業「獨門絕技」的活動組件，負責保障業務成功，例如可以創造獨特用戶體驗與開發創新產品的部分。

• 一般被咱們稱爲「無差異承載性」活動組件，這些活動必須完成，但自己沒法提供任何競爭優點。對於大多數企業來說，此類任務包括服務器管理、負載均衡以及安全補丁應用等等。

咱們在 2014 年提出了「無服務器」概念，並同時發佈了 AWS Lambda。AWS Lambda 是一種計算服務，可以幫助你們在無需配置或者管理服務器的前提下運行代碼。這種能力支撐起咱們的整體目標，即經過將無差異任務交給 AWS 負責以幫助客戶專一於優化本身的「獨門絕技」。事實上，這一切已經成爲現代應用程序開發中的關鍵性元素。無服務器模式使你們解放精力，將更多時間投入到真正讓您的業務不同凡響的方面——例如產品創新。

當咱們提及「無服務器」時，咱們指的是在無需分神於基礎設施配置或者擴展的狀況下運行的服務，其具備內置的可用性與安全性保障，且採用按使用量計費的方式。無服務器不僅有 Lambda，它是一套完整的應用程序堆棧。

應用程序堆棧一般由如下三大要素組成：

• 像 AWS Fargate 這樣的計算服務，用於運行應用程序邏輯

• 像 MySQL 以及 PostgreSQL 關係數據庫這樣的數據存儲方案，也可使用 Amazon Aurora 等實現數據的持久駐留

• 相似於事件總線 Amazon EventBridge 這樣的集成層，用於實現數據移動

這些無服務器構建單元使企業可以打造出充分發揮無服務器模式優點的應用程序。

在亞馬遜，咱們本身也尚未徹底實現無服務器化，但咱們正在朝着這個方向努力。實際上，咱們認爲很快就會出現一整代只負責編寫業務邏輯、而從未接觸過服務器的開發人員。這裏的緣由很簡單，不管您是在構建全新應用程序仍是遷移舊有應用程序版本，使用無服務器原語進行計算、數據處理以及集成，都能確保你們從雲環境提供的敏捷性優點中獲取最佳收益。

5安全性：每一個人都有責任

過去，不少企業都把安全視爲一種神奇的「調味料」——在應用程序準備好發佈以後，再匆匆撒上一把。但這種方式在持續發佈週期中顯然會水土不服，所以組織必須採起新的安全方法，圍繞整個應用程序構建起防火牆。但這一樣帶來新的挑戰：以往咱們只須要爲總體式應用程序創建一種安全設置；但面對微服務架構中成千上萬的獨立進程，以往的安全思路根本解決不了問題。

有鑑於此，在現代應用程序當中，咱們將安全功能內置於應用程序的各個組件以內，並隨着每一個版本進行自動測試與部署。這意味着安全性再也不是安全團隊本身的責任——相反，安全深深融入到開發生命週期的每一個階段，而工程、運營以及合規團隊都將在其中發揮本身的做用。

安全性將被整合至代碼庫、build 管理程序乃至部署工具當中。這既適用於發佈流水線自己，也一樣適用於經過該流水線發佈的軟件。並且在使用無服務器服務的狀況下，安全狀態的維護難度更低，這是由於底層基礎設施的安全運營工做——包括系統版本更新、軟件修復與監控等——都之內置形式存在於各項服務當中。

6現代化之旅

那麼，衆多客戶是如何實施這些變動，從而推進應用程序現代化的？必須認可，其中不存在統一的路徑，但卻有着很多常見的模式，也包括咱們在亞馬遜採起的方法。

當咱們決定專一於創新並大幅擴展 Amazon.com 時，咱們重構了總體式應用程序，對組織結構進行從新編排，然後利用自動化與抽象化兩大手段推進雲資源優化。Yelp 等客戶也採起了相似的現代化轉型方式。

對於之內部託管應用程序做爲起點的客戶，最多見的方法天然是從新託管，即「將應用程序直接遷移至雲端」。在此以後，不少客戶開始進一步探索雲環境中的託管服務，嘗試將數據庫與 API 管理等任務遷移至 AWS，從而保證將本身的工做重心放在業務邏輯身上。

現在，愈來愈多的客戶踏上了從新發明的道路，將新的應用程序構建爲無服務器微服務形式，旨在充分發揮雲服務優點。現代化沒有統一的正確方法，由於在 AWS 平臺上，各類各樣的應用程序都可以以不一樣的狀態共存，並經過任意路徑實現成功交互。

但咱們也在其中看到了重要的共通點，即構建現代應用程序的客戶可以審視自身總體業務優點，特別是對時間與資源的優化分配。他們將更多時間花在定義業務邏輯上，擴展系統以輕鬆知足高峯期客戶需求，提升敏捷性，同時更快、更頻繁地向市場發佈新功能。

以向汽車買家提供最新車輛信息的 Edmunds.com 網站爲例，他們將新功能的推出時間由六個月縮短至一週。初創企業 Bynder 公司也將產品上市週期由本來的一年減小至一個月。經過改變對技術的運用方式，企業可以顯著改善本身的業務交付途徑以及相關體驗。

而這，正是現代應用程序的力量所在。

 

原文連接：https://www.allthingsdistributed.com/2019/08/modern-applications-at-aws.html