亞馬遜如何從單體中臺轉變到微服務？ - All Things Distributed

banq發表於2019-09-07
亞馬遜微服務

像亞馬遜這樣的大多數公司都是以單體（中臺）方式開展業務，因為它是最快，最容易開發的系統。但是，將程式緊密組合並將它們作為單個服務執行是存在問題的，如果一箇中臺應用程式遇到需求高峰，則必須擴充套件整個架構以處理該一個程式的負載。
此外，隨著程式碼庫的增長，新增和改進功能變得更加複雜，使得難以試驗和實現新想法。單片中臺架構也增加了應用程式可用性的風險，因為許多依賴和緊密耦合的程式會增加單個程式故障的影響。
這就是微服務隨著公司發展而出現的原因。使用微服務架構，應用程式由獨立元件組成，這些元件將每個應用程式的程式作為服務執行。服務是為業務功能而構建的。

例如線上購物車，每個服務都執行單一功能。它獨立執行並由單個開發團隊管理，因此可以獨立更新，部署和擴充套件每個服務，以滿足對應用程式特定功能的需求。例如，購物車可以在銷售時支援更大量的使用者。
隨著組織從單塊服務轉向微服務，許多開發人員發現他們希望透過管道管理每個服務中的依賴關係 - 他們必須建立打包應用程式和執行程式碼的新方法。由於這些創新，例項不再是您唯一的計算選項。
容器是打包程式碼最受歡迎的選項，也是遺留應用程式現代化的絕佳工具，因為它們提供了出色的可移植性和應用程式設定的靈活性。使用Lambda，您可以獲得最簡單的功能。您編寫的唯一程式碼是業務邏輯。
微服務的另一個考慮因素是它們需要一種相互通訊的方式。許多應用程式繼續使用API​​連線，但是還有其他幾種用於在服務之間傳送資料的選項。這些包括用於實時資料處理的流，用於觸發對資料變化的響應的事件，以及用於應用級通訊和可觀察性的服務網格。您可以選擇最符合您的應用程式需求的整合方法。

資料管理：專用資料庫
現代應用程式使用分離的資料儲存構建，其中存在資料庫和微服務的一對一對映，而不是單個資料庫。這是傳統應用程式架構的一個重要轉變，因為正如單個應用程式隨著它的增長而出現擴充套件和容錯挑戰，資料庫也是如此。此外，單個資料庫是單點故障，單個資料庫很難滿足一組不同微服務的特定需求。透過將資料與微服務分離，您可以自由選擇最適合您需求的資料庫。
軟體交付：自動釋出管道當我們離開Amazon.com的整體架構並重組為兩個披薩團隊時，我們停止使用單一版本管道並開始讓每個團隊獨立釋出。
雖然這消除了製作和提供更新的協調挑戰，但分散我們的開發和釋出流程帶來了一系列新挑戰。維護所有團隊的釋出流程和質量一致性變得困難，特別是當釋出流程的每個步驟都是手動的時候，這就產生了人為錯誤的可能性。
我們的解決方案是雙管齊下的：標準化和自動化。首先，我們將軟體交付流程定義為最佳實踐模板，為在雲環境中建模和配置所有基礎架構資源提供標準。這些“基礎架構作為程式碼”模板可以幫助我們的團隊正確開始，因為模板透過程式碼為應用程式提供整個技術堆疊，而不是使用手動過程。在亞馬遜，這可確保團隊根據我們的要求配置其流程和部署。
其次，我們已開始使用自動化從軟體交付工作流程中刪除手動流程。藉助自動釋出管道，包括持續整合和持續部署（CI / CD），我們可以快速測試和釋出大量程式碼，同時最大限度地減少錯誤。透過CI，我們的團隊會定期將程式碼更改合併到一箇中央儲存庫中。然後我們執行自動構建和測試，以便我們儘早發現問題。使用CD，我們的團隊每天多次提交更改，無需任何人工操作即可投入生產。
起初，我們發現沒有人為干預的部署是可怕的。但是在我們花時間編寫正確的測試和故障保險後，我們發現它不僅大大提高了我們的速度和靈活性，還提高了程式碼的質量。

運維模式：儘可能無伺服器
現代應用程式有很多活動部件。現代應用程式可以由數千個服務組成，而不僅僅是單個應用程式和資料庫，每個服務都有一個專用資料庫和一個不斷髮布新功能的團隊。
這些運動部件可分為兩類：

  • 作為公司“秘密醬”的一部分的活動，使其在市場上取得成功，例如創造獨特的使用者體驗和開發創新產品。
  • 我們經常稱之為“無差別的重舉”的活動，這些活動必須完成，但不能提供競爭優勢。對於大多數企業而言，這些任務包括伺服器管理，負載平衡和應用安全補丁等。

我們在2014年推出了“無伺服器”概念，推出了AWS Lambda，這是一種計算服務，可讓您在不配置或管理伺服器的情況下執行程式碼。這支援了我們的總體目標，即透過將無差別的任務解除安裝到AWS來幫助客戶最佳化其秘密資源的資源，並已成為現代應用程式開發中的關鍵元素。無伺服器使您可以專注於使您的公司與眾不同的活動，例如產品創新。
當我們說“無伺服器”時，我們指的是在不需要基礎設施配置和擴充套件的情況下執行的服務，具有內建的可用性和安全性，並使用付費價值計費模型。無伺服器不只是Lambda - 它是整個應用程式堆疊。
應用程式堆疊通常由三個元件組成：
  • 像AWS Fargate這樣的計算服務來執行應用程式邏輯
  • 資料儲存，如MySQL和PostgreSQL關聯式資料庫，或Amazon Aurora，用於儲存資料
  • 像事件匯流排Amazon EventBridge這樣的整合層來移動資料

這些無伺服器構建塊使公司能夠構建最大化無伺服器模型優勢的應用程式。
在亞馬遜，我們自己並不是完全沒有伺服器，但我們正朝著這個方向前進。許多客戶也是如此。實際上，我們預計很快就會有一整代開發人員從未接觸過伺服器而只編寫業務邏輯。原因很簡單。無論您是構建新的全新應用程式還是遷移舊版本，使用無伺服器原語進行計算，資料和整合都可以使您從雲提供的最大敏捷性中受益。

總結
構建現代應用程式的客戶可以看到整個業務的優勢，特別是他們如何分配時間和資源。他們將更多時間花在定義業務的邏輯上，擴充套件系統以輕鬆滿足高峰客戶需求，提高靈活性，並更快，更頻繁地向市場提供新功能。
例如，向汽車購物者提供最新車輛資訊的Edmunds.com將新網站功能的推出時間從六個月減少到一週。創業公司Bynder還將產品上市所需的時間從一年減少到一個月。透過改變他們接近技術的方式，公司可以改善他們開展業務的方式。
這是現代應用的力量。

相關文章