[[419794]]

【51CTO.com快譯】現代電子商務架構的五種設計模式是Strangler模式、Ambassador模式、Sidecar模式、API接口和功能鏈。

一些電子商務公司正在使用微服務為其商店構建一組可重用的組件。這些服務獨立于前端運行，可以更輕松地將其內容大規模地交付到多個渠道。

本文將討論現代電子商務可以實現的幾種設計模式，并解釋它們提供的功能，還將提到一些常見的用例。

理解軟件設計模式

軟件設計模式被定義為解決常見問題的方法。它們幫助開發人員了解系統的組件如何相互關聯和交互。但是并沒有一個“完美”的設計模式，這是因為每種模式都有優點和缺點，并且在特定情況下很有幫助。

大多數開發人員花費數年時間學習正確地獲取這些模式。但是如果正確應用它們，可以取得顯著的成果?，F代電子商務架構有五種設計模式：

(1)Strangler模式：一種從遺留軟件遷移到更先進平臺的有用方法。

(2)Ambassador模式：提供了一種處理網絡問題的封裝方法。

(3)Sidecar模式：可以幫助企業添加功能，而不會與軟件的其余部分過于緊密地耦合。

(4)API接口：幫助軟件服務和組件進行通信。

(5)功能鏈：幫助代碼處理順序任務。

雖然實現是最困難的部分，但了解每個模式的名稱和意圖是必不可少的第一步。企業可以決定采用更適合電子商務平臺的方法。

1.Strangler模式

Strangler模式將系統逐漸從一個平臺移動到另一個平臺。為此，可以通過一個接一個地替換部分軟件，直到最終將舊系統“扼殺”。而在實施過程中，企業可以將其分解為三個步驟：

• 轉換：創建服務的新版本，一次替換一個。
• 共存：可以同時運行新服務和舊服務。
• 淘汰：更換所需的一切，并可以淘汰舊系統。

使用Strangler模式允許持續交付新功能和高代碼覆蓋率。它還促進了模塊化、測試驅動的方法，使企業能夠隔離問題，并確保提供的每項服務都能正常運行。

這是轉移到新軟件設置的好方法，例如從單體應用到微服務。它可以讓企業將工作分解為可管理的塊，從而快速推動結果。此外，可以將任務分配給企業不同的團隊，以增加支持度和責任感。

另一方面，這可能需要一些時間。但是，企業可以通過讓各個團隊并行工作來緩解這種情況。而正確地構建團隊與采用新技術一樣重要。

2. Ambassador模式

在Ambassador模式中，Ambassado服務專門用于通信。企業創建一個代理進程或服務來處理應用程序其余部分的網絡請求。

在使用Ambassado服務之后，可以添加監控、日志記錄和呼叫重新路由等功能。將請求從一種格式轉換為另一種格式非常有用，例如多渠道的電子商務應用中，可以將產品分發給許多不同的前端消費者。

如果同時使用傳統軟件和現代軟件，它可以幫助縮小差距，確保網絡符合現代安全和責任標準。從企業的角度來看，它允許為代理服務本身分配一個團隊，從而允許劃分責任。

雖然Ambassador模式可以快速將不同的系統聯系在一起，但是網絡延遲問題使其效果并不理想。它可以增加服務間通信，并提高內存和CPU的使用率。

如果企業在擺脫單體應用或遺留軟件時遇到問題，例如需要一直維護，那么Ambassador模式可能是規避這些問題的好方法。這種模式允許向舊軟件添加功能，而無需重寫所有內容。

3.Sidecar模式

在Sidecar模式中，企業將一組指定的功能移動到一個單獨的組件中，該組件與主應用程序(父應用程序)共存，通常共享相同的生命周期。

Sidecar組件與其主應用程序一起托管，甚至可以在同一進程中運行。這意味著當Sidecar組件與主應用程序通信時幾乎沒有延遲，并且它可以訪問相同的資源。

但是，它可以使用與主服務不同的編程語言或框架，并且多個Sidecar可以使用不同的語言。這意味著在添加額外功能或迎合不同團隊成員的優勢和偏好時，可以使用適合該工作的工具。

通常，Sidecar應用程序的進程可以處理外圍功能，例如日志記錄或網絡連接，而主應用程序處理核心功能。因此，如果需要移動或重新配置應用程序，團隊可以專注于采用Sidecar應用程序，而無需更改主應用程序。

這是一個具有許多潛在應用的簡單模式。例如在電子商務環境中，企業可以使用它來記錄金融交易。由于詳細記錄在電子商務中至關重要，因此可以擁有一個獨立的記錄來添加和建立。

企業還可以使用Sidecar模式來處理網絡操作，例如向舊服務添加現代加密技術。這可以對原有的電子商務系統實現部分的現代化，而無需完全重寫。

4.API接口

應用程序編程接口(API)是軟件組件使用一組定義的調用相互通信的方式。Web服務或微服務通常使用API。

除了通過網絡通信使用它們之外，還可以將它們用于同一主機上的微服務之間的通信。API接口中有幾種常見的模式。

REST是最受認可的。它是計算機科學課程的主要內容，也是大量網站和服務的標準。它用于實現CRUD模式。RESTful服務是無狀態且可緩存的，因此非常適合Web應用。

在Headless商務中，API允許多個前端應用程序與其后端服務進行通信。可以部署在任何其他平臺上的網站、應用程序和軟件可以將API請求發送到同一位置。這使企業可以單獨處理每個組件，進行改進和添加，而無需擔心對整個生態系統的影響。

5.功能鏈

企業可以在云平臺上構建自包含、無狀態并可按需執行的無服務器功能。AWS、Microsoft Azure和谷歌云等云平臺讓用戶可以創建這些功能，因此不必擔心硬件問題。

用戶可以將無服務器功能組織成一個功能鏈。在這種模式中，每個功能在完成時調用下一個功能。如果操作啟動了一系列處理緩慢的任務，則這種模式是理想的。第一個功能可以響應用戶，所以他們不會等待。

應用這一模式時需要考慮幾個問題。理想情況下，功能是獨立的且可替換的，但這里的功能是相互依賴的。這違反了面向對象的設計原則，但對于某些應用程序是必要的。用戶可以使用排隊系統按順序調用功能，使它們更獨立可操作和可擴展。

功能鏈對于實現定義明確的順序任務非常有用。例如，企業可能希望在用戶下訂單之后調用功能鏈，可以通過不同的微服務處理數據，并將其推送到每個后續數據存儲中。

這些任務都可以獨立發生，也可以在后臺發生。這樣，企業的電子商務商店的用戶界面(UI)將會保持快速運行，而后端功能可能需要幾分鐘才能完成。

結語

總之，人們對軟件模式以及如何將它們應用于電子商務微服務了解得越多，就可以更好地利用這些現有知識來解決問題。

原文標題：Design Patterns for Modern Day Commerce Using Microservices，作者：James Konik

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】