Amazon Web Services 的現代應用程式
創新一直是 Amazon 公司堅持追求的核心目標。約20年前，我們經歷了一次徹底的轉型，旨在建立起“發明、釋出、再發明、再發布、重新開始、洗牌、再重複”的快速迭代流程。正是此番探索，徹底改變了我們構建應用程式乃至組織企業結構的根本方式。
那時候，Amazon 服務的群體在規模上遠遠不及當下。但我們很清楚，要想不斷擴充套件 Amazon 的產品與服務，就必須改變應用程式架構的設計思路。
我們曾經為 Amazon.com 建立起龐大的單體式“bookstore”應用，但與之關聯的笨拙資料庫限制了我們的速度與敏捷性。每當我們打算為客戶提供新的功能或產品（例如影片流），就被迫得在專門為 bookstore 設計的應用程式上編輯並重寫大量程式碼。這個過程漫長且繁瑣，需要複雜的協調溝通，因此嚴重拖累了我們快速推動大規模創新的能力。
為此，我們透過“分散式計算宣言”建立了變革藍圖。透過這份用以描述新架構的內部文件，我們決定將應用程式重組為更小的部分，即“服務”，並藉此大幅提升 Amazon 的可擴充套件性。
但應用程式架構的變革還只是開始。從1998年時開始，各個 Amazon 開發團隊就一直在同一款應用程式之上工作，因此這款應用的每個發行版本都必須在各團隊間統一協調。
為了支援新的架構方法，我們對其功能層級進行分解，並將組織重新整合成多個小型自治團隊。各團隊的體量很小，只要訂兩塊披薩就能解決一頓飯，這就是所謂“雙披薩團隊”。每支團隊只關注特定的產品、服務或者功能集，這就讓他們獲得了對應用程式中特定部分的更高操作許可權。如此一來，開發者們搖身一變成為產品所有者，能夠迅速做出影響各自產品的具體決策。
此番重整組織與應用程式結構無疑是個大膽的計劃，好在 Amazon 獲得了良好的收效。我們能夠更快為客戶提供創新成果，並隨著自身業務的發展而將每年部署的功能總量由數十項，快速發展為數百萬項之巨。更值得一提的是，我們在構建高度可擴充套件基礎設施領域的卓越成功，最終衍生出了新的核心業務能力，這就是2006年正式亮相的 Amazon Web Services。
如今，我們仍然在堅持雙披薩團隊的運作模式。我們的目標並不僅僅是追求快速創新。為了保持全面的市場競爭力，我們還需要提高敏捷性，以便不斷發現新的機遇並創造更好的產品。秉持著相同的理念，越來越多客戶與 Amazon 踏上了相同的發展旅程，全面轉向現代應用程式開發道路。這種新方法要求組織由已經非常熟悉的單體式架構轉向元件或微服務架構，而這一切影響到的不只有技術的設計與構建方式，更要求我們重新審視自己的管理思路。
亞馬遜雲科技開發者社群為開發者們提供全球的開發技術資源，這裡有技術文件、開發案例、技術專欄、培訓影片、活動與競賽等。幫助中國開發者對接世界最前沿技術，觀點，和專案，並將中國優秀開發者或技術推薦給全球雲社群。如果你還沒有關注/收藏，看到這裡請一定不要匆匆劃過，點這裡讓它成為你的技術寶庫！
為了讓應用程式開發成為敏捷性與創新速度的重要驅動力，組織必須關注五大關鍵要素：微服務、專用資料庫、自動化軟體釋出管道、無伺服器運營模型、外加持續自動化安全體系。
架構模式：微服務
像 Amazon 這樣的企業最初大多是從單體式應用程式起步，因為這是當時開發速度最快、複雜度最低的系統架構選項。但是，緊密組合的各個流程迫使我們必須將應用程式看成統一的整體，由此帶來無數令人頭痛的難題。如果應用程式中的某一程式遇到需求高峰，我們就得擴充套件整個架構才能消化掉該程式的相應負載。
此外，隨著程式碼庫體量的提升，新功能的新增與改進變得越來越複雜，導致我們難以嘗試或實施新的方法。單體式架構也增加了應用程式的可用性風險，其中眾多相互依賴且緊密耦合的程式會顯著放大單一程式故障引發的影響。
正因為如此，微服務架構隨著企業的發展而自然出現。使用微服務架構，應用程式將由無數獨立元件構成，各個元件會將應用程式中的各獨立程式視為單一服務。每項服務對應且僅對應一種業務功能，例如線上購物車。這種獨立執行以及由專項團隊負責的設計，讓企業得以輕鬆更新、部署及擴充套件各項服務，藉此滿足應用程式提出的具體功能需求。例如，我們可以在銷售旺季擴充套件購物車服務以支援更多使用者。
隨著組織由單體式服務轉向微服務，不少開發人員希望透過管道來管理不同服務中的依賴項，同時尋求新的應用程式打包與程式碼執行方法。面對這些硬性需求，計算例項長期以來的統治地位開始有所動搖。
如今，我們可以使用容器或者 Amazon Lambda 函式。容器已經成為目前最具人氣的程式碼打包選項，也憑藉著出色的應用程式可移植性與執行靈活性成為管理遺留應用程式的最佳工具。而使用 Lambda，您將獲得出色的便捷性——除了核心業務邏輯之外，大家再不必編寫任何其他程式碼。
另外需要強調的是，微服務架構包含的大量微服務，給服務間通訊帶來了新的挑戰。一部分應用程式繼續沿用 API 連線，但除此之外還有更多用於服務間資料交換的選項，例如用於實時資料處理的流傳輸、用於根據資料變更觸發響應的事件，以及用於應用級通訊與可觀察性的服務網格等等。不同的選項各有優劣，大家需要根據應用程式的實際需求做出取捨。
資料管理：專用資料庫
現代應用程式以解耦資料儲存構建而成，不同於以往全面依賴同一套大型資料庫的方式，微服務架構中的資料庫與微服務保持著一一對映的關係。以往單體式應用程式的整體增長，必然帶來擴充套件與容錯層面的嚴峻挑戰。此外，單體資料庫必然引發單點故障，而且同一資料庫很難滿足一組不同微服務的需求。而隨著資料與微服務間的脫鉤，大家可以更自由地選擇最適合自己的具體資料庫方案。
對於大部分應用程式，最好的選項仍然是經典的關聯式資料庫。但也有不少應用程式會提出自己的資料需求。例如，假定您所執行的應用程式需要處理高度關注的資料集——例如推薦引擎——那麼不妨選擇圖資料庫（例如 Amazon Neptune）用以儲存並導航關係資料。
或者，如果您的應用程式要求實時訪問資料，則最好選擇記憶體內資料庫，例如 Amazon ElastiCache。這種資料庫特別適用於遊戲及物聯網應用程式。總之，哪種資料庫能夠全面滿足您的微服務需求，哪種就是最好的選擇。
軟體交付：自動釋出管道
在由 Amazon.com 單體式架構轉向雙披薩團隊的過程中，我們關停了單一發布通道，轉而允許各個團隊獨立釋出自己的功能與產品。
雖然這種方式消除了交付與更新流程中的協調難題，但也讓新的流程變得極度分解、難以掌控。很明顯，在全部團隊的釋出流程與質量水平方面保持統一變得無比艱難，而釋出流程中大量的手動操作也讓發生人為錯誤的機率顯著提高。
我們的解決方案包含兩大基本元素：標準化與自動化。
首先，我們定義一套關於軟體交付流程的最佳實踐模板，用於為雲環境下基礎設施資源的建模與配置設定標準。這些“基礎設施即程式碼”模板為各個團隊提供良好的起點，以程式碼取代手動流程的方式為應用程式提供技術堆疊。在 Amazon，這種方式將保證各個團隊都根據統一的要求規劃流程與部署工作。
其次，我們使用自動化技術消除軟體交付流程中的手動操作環節。憑藉包括持續整合與持續部署（CI/CD）在內的自動化釋出管道，我們得以快速測試併發布大量程式碼，同時儘可能減少錯誤機率。藉助持續整合，我們的團隊地定期將程式碼變更合併至中央 repo 當中，而後執行自動化構建與測試以儘早發現問題。藉助持續部署，我們的團隊每天可以完成多輪變更，並在保證變更有效後將其自動新增至生產環境當中。
最初，我們發現在不加人為干預的前提下推進部署相當“恐怖”。但在投入時間建立起正確的測試與故障處理機制後，最終成果不僅大大提升了 Amazon 的運作速度與敏捷性，同時也顯著增強了程式碼質量。
運營模型：儘可能推廣無伺服器模式
現代應用程式中包含大量活動部件，不同於傳統的單體式應用程式與資料庫，其中還存在成千上萬項服務。每一項服務都有自己的專用資料庫，外加一支援續釋出新功能的自主團隊。
我們可以將這些活動部件分為以下兩類：
- 企業自己的獨門絕技，例如創造出獨特的使用者體驗或開發出前所未有的創新產品。
- “無差別繁重工作”，即必須完成但卻無法提供任何競爭優勢的任務。對大多數企業而言，這類任務可能涵蓋伺服器管理、負載均衡與應用安全補丁等內容。
2014年，隨著 Amazon Lambda 的推出，我們提出了“無伺服器”這一概念。Amazon Lambda 是一種計算服務，可幫助客戶在執行程式碼的同時，無需置備或管理任何伺服器。這也極大支援了我們的總體目標，即透過將未經區分的任務移交給 Amazon Web Services 以幫助客戶最佳化自己的“獨門絕技”，同時全面實現應用程式的現代化程式。在完成無伺服器革新之後，企業能夠將資源集中投入到產品創新等有助於建立市場優勢的工作當中。
這裡所說的“無伺服器”，是指無需配置及擴充套件基礎設施即可執行的服務。無伺服器架構具備內建可用性與安全性保障，並採用按實際使用量付費的模式。無伺服器不僅限於 Lambda，而是涵蓋整個應用程式堆疊。
應用程式堆疊通常包含以下三個部分：
- Amazon Fargate 等計算服務，用於執行應用程式邏輯。
- MySQL與PostgreSQL 等關聯式資料庫提供的資料儲存方案，或者 Amazon Aurora 等資料持久儲存服務。
- 整合層，例如用於管理資料移動的 Amazon EventBridge 等事件匯流排。
這些無伺服器構建單元，將幫助企業在應用程式中實現無伺服器模式的最大化收益。
在 Amazon，我們還沒有全面普及無伺服器模式，但已經在朝著這個方向努力。我們的很多客戶也走在同樣的探索道路之上。也許在不久的未來，下一代開發人員再也不必接觸伺服器，而僅僅需要編寫業務邏輯。
到那個時代，無論是構建新型 Web 應用還是遷移舊有應用，我們都可以使用無伺服器原語實現計算、資料與整合，由此保證企業充分發揮雲端計算的敏捷性優勢。
安全性：人人有責
以往，很多企業將安全性視為一種“魔術”——在即將釋出的應用上修修補補，然後聽天由命。但在持續釋出週期中，這種原始的方法顯然無法奏效，組織必須採用新的安全方法以圍繞應用程式構建起完善的防火牆。但這同樣帶來新的挑戰，畢竟各項微服務往往有著天差地別的特性與需求，為其分別設定安全配置將帶來巨大的工作壓力。
為此，在現代應用程式當中，安全功能被內建在應用的各個元件之內，並隨著每個發行版本完成自動測試與部署。如此一來，安全不再是安全團隊的專屬責任；相反，安全保障深入整合到開發生命週期的各個階段，並要求工程、運營與合規團隊參與貢獻自己的力量。
具體來講，安全保障將被整合在程式碼 repo、構建管理程式以及部署工具之內，同時服務於釋出管道本身與透過該管道釋出的軟體成果。
藉助無伺服器模式，由於每項服務都內建有基礎設施安全要素（例如作業系統版本更新、軟體修復與監控等），因此極大降低了安全狀態的維護難度。
探索之旅
那麼，客戶是如何實際推進這種架構變革，最終實現應用程式現代化的？這個問題沒有統一的答案，但我們可以在這裡分享一點Amazon親身總結出的共通性經驗。
當初決定專注創新並大幅擴充套件 Amazon.com 的時候，我們一步步完成了應用程式重構、組織結構重組、外加針對雲環境的自動化與抽象最佳化等工作。以 Yelp 為代表的不少 Amazon Web Serviecs 使用者也採取了類似的過渡方式。
如果您以往是在本地設施內託管應用程式，那麼最常規的方法應該是選擇“直接遷移”的方式將應用程式重新託管至雲端。以此為基礎，客戶們開始逐漸熟悉雲端的託管服務，嘗試將資料庫與 API 管理等工作遷移至 Amazon Web Services，並將解放出的資源與人力集中在開發業務邏輯身上。
如今，越來越多的客戶開始重塑自己的發展道路，包括將新應用構建為無伺服器微服務形式，藉此提升對雲優勢的使用能力。必須承認，並不存在侱正確的現代化方法；您應該結合自身實際情況，穩紮穩打地探索 Amazon Web Services 上的成功之路。
但至少有一點可以肯定：透過構建現代化應用程式，客戶的整個業務體系都將獲得收益，特別是改善時間與資源的分配能力。他們能夠把更多精力投入到定義業務邏輯當中、擴充套件系統以輕鬆滿足峰值客戶需求、提高業務敏捷性，並更快更頻繁地釋出更多新功能。
例如，專注於釋出車輛資訊的 Edmunds.com 網站就將新功能的釋出週期由以往的六個月縮短至一個星期 。初創企業 Bynder 則將產品上市時間由一年縮短至一個月。在這個以技術為主導的新時代，對技術運用的能力將直接影響業務的運作方式。
而這一切，正是現代化應用程式的力量所在。
文章來源：https://dev.amazoncloud.cn/column/article/62b452ad849b456b984...