[[419794]]

【51CTO.com快譯】現(xiàn)代電子商務(wù)架構(gòu)的五種設(shè)計(jì)模式是Strangler模式、Ambassador模式、Sidecar模式、API接口和功能鏈。

一些電子商務(wù)公司正在使用微服務(wù)為其商店構(gòu)建一組可重用的組件。這些服務(wù)獨(dú)立于前端運(yùn)行，可以更輕松地將其內(nèi)容大規(guī)模地交付到多個(gè)渠道。

本文將討論現(xiàn)代電子商務(wù)可以實(shí)現(xiàn)的幾種設(shè)計(jì)模式，并解釋它們提供的功能，還將提到一些常見的用例。

理解軟件設(shè)計(jì)模式

軟件設(shè)計(jì)模式被定義為解決常見問題的方法。它們幫助開發(fā)人員了解系統(tǒng)的組件如何相互關(guān)聯(lián)和交互。但是并沒有一個(gè)“完美”的設(shè)計(jì)模式，這是因?yàn)槊糠N模式都有優(yōu)點(diǎn)和缺點(diǎn)，并且在特定情況下很有幫助。

大多數(shù)開發(fā)人員花費(fèi)數(shù)年時(shí)間學(xué)習(xí)正確地獲取這些模式。但是如果正確應(yīng)用它們，可以取得顯著的成果?，F(xiàn)代電子商務(wù)架構(gòu)有五種設(shè)計(jì)模式：

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

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

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

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

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

雖然實(shí)現(xiàn)是最困難的部分，但了解每個(gè)模式的名稱和意圖是必不可少的第一步。企業(yè)可以決定采用更適合電子商務(wù)平臺(tái)的方法。

1.Strangler模式

Strangler模式將系統(tǒng)逐漸從一個(gè)平臺(tái)移動(dòng)到另一個(gè)平臺(tái)。為此，可以通過一個(gè)接一個(gè)地替換部分軟件，直到最終將舊系統(tǒng)“扼殺”。而在實(shí)施過程中，企業(yè)可以將其分解為三個(gè)步驟：

• 轉(zhuǎn)換：創(chuàng)建服務(wù)的新版本，一次替換一個(gè)。
• 共存：可以同時(shí)運(yùn)行新服務(wù)和舊服務(wù)。
• 淘汰：更換所需的一切，并可以淘汰舊系統(tǒng)。

使用Strangler模式允許持續(xù)交付新功能和高代碼覆蓋率。它還促進(jìn)了模塊化、測(cè)試驅(qū)動(dòng)的方法，使企業(yè)能夠隔離問題，并確保提供的每項(xiàng)服務(wù)都能正常運(yùn)行。

這是轉(zhuǎn)移到新軟件設(shè)置的好方法，例如從單體應(yīng)用到微服務(wù)。它可以讓企業(yè)將工作分解為可管理的塊，從而快速推動(dòng)結(jié)果。此外，可以將任務(wù)分配給企業(yè)不同的團(tuán)隊(duì)，以增加支持度和責(zé)任感。

另一方面，這可能需要一些時(shí)間。但是，企業(yè)可以通過讓各個(gè)團(tuán)隊(duì)并行工作來緩解這種情況。而正確地構(gòu)建團(tuán)隊(duì)與采用新技術(shù)一樣重要。

2. Ambassador模式

在Ambassador模式中，Ambassado服務(wù)專門用于通信。企業(yè)創(chuàng)建一個(gè)代理進(jìn)程或服務(wù)來處理應(yīng)用程序其余部分的網(wǎng)絡(luò)請(qǐng)求。

在使用Ambassado服務(wù)之后，可以添加監(jiān)控、日志記錄和呼叫重新路由等功能。將請(qǐng)求從一種格式轉(zhuǎn)換為另一種格式非常有用，例如多渠道的電子商務(wù)應(yīng)用中，可以將產(chǎn)品分發(fā)給許多不同的前端消費(fèi)者。

如果同時(shí)使用傳統(tǒng)軟件和現(xiàn)代軟件，它可以幫助縮小差距，確保網(wǎng)絡(luò)符合現(xiàn)代安全和責(zé)任標(biāo)準(zhǔn)。從企業(yè)的角度來看，它允許為代理服務(wù)本身分配一個(gè)團(tuán)隊(duì)，從而允許劃分責(zé)任。

雖然Ambassador模式可以快速將不同的系統(tǒng)聯(lián)系在一起，但是網(wǎng)絡(luò)延遲問題使其效果并不理想。它可以增加服務(wù)間通信，并提高內(nèi)存和CPU的使用率。

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

3.Sidecar模式

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

Sidecar組件與其主應(yīng)用程序一起托管，甚至可以在同一進(jìn)程中運(yùn)行。這意味著當(dāng)Sidecar組件與主應(yīng)用程序通信時(shí)幾乎沒有延遲，并且它可以訪問相同的資源。

但是，它可以使用與主服務(wù)不同的編程語言或框架，并且多個(gè)Sidecar可以使用不同的語言。這意味著在添加額外功能或迎合不同團(tuán)隊(duì)成員的優(yōu)勢(shì)和偏好時(shí)，可以使用適合該工作的工具。

通常，Sidecar應(yīng)用程序的進(jìn)程可以處理外圍功能，例如日志記錄或網(wǎng)絡(luò)連接，而主應(yīng)用程序處理核心功能。因此，如果需要移動(dòng)或重新配置應(yīng)用程序，團(tuán)隊(duì)可以專注于采用Sidecar應(yīng)用程序，而無需更改主應(yīng)用程序。

這是一個(gè)具有許多潛在應(yīng)用的簡單模式。例如在電子商務(wù)環(huán)境中，企業(yè)可以使用它來記錄金融交易。由于詳細(xì)記錄在電子商務(wù)中至關(guān)重要，因此可以擁有一個(gè)獨(dú)立的記錄來添加和建立。

企業(yè)還可以使用Sidecar模式來處理網(wǎng)絡(luò)操作，例如向舊服務(wù)添加現(xiàn)代加密技術(shù)。這可以對(duì)原有的電子商務(wù)系統(tǒng)實(shí)現(xiàn)部分的現(xiàn)代化，而無需完全重寫。

4.API接口

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

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

REST是最受認(rèn)可的。它是計(jì)算機(jī)科學(xué)課程的主要內(nèi)容，也是大量網(wǎng)站和服務(wù)的標(biāo)準(zhǔn)。它用于實(shí)現(xiàn)CRUD模式。RESTful服務(wù)是無狀態(tài)且可緩存的，因此非常適合Web應(yīng)用。

在Headless商務(wù)中，API允許多個(gè)前端應(yīng)用程序與其后端服務(wù)進(jìn)行通信。可以部署在任何其他平臺(tái)上的網(wǎng)站、應(yīng)用程序和軟件可以將API請(qǐng)求發(fā)送到同一位置。這使企業(yè)可以單獨(dú)處理每個(gè)組件，進(jìn)行改進(jìn)和添加，而無需擔(dān)心對(duì)整個(gè)生態(tài)系統(tǒng)的影響。

5.功能鏈

企業(yè)可以在云平臺(tái)上構(gòu)建自包含、無狀態(tài)并可按需執(zhí)行的無服務(wù)器功能。AWS、Microsoft Azure和谷歌云等云平臺(tái)讓用戶可以創(chuàng)建這些功能，因此不必?fù)?dān)心硬件問題。

用戶可以將無服務(wù)器功能組織成一個(gè)功能鏈。在這種模式中，每個(gè)功能在完成時(shí)調(diào)用下一個(gè)功能。如果操作啟動(dòng)了一系列處理緩慢的任務(wù)，則這種模式是理想的。第一個(gè)功能可以響應(yīng)用戶，所以他們不會(huì)等待。

應(yīng)用這一模式時(shí)需要考慮幾個(gè)問題。理想情況下，功能是獨(dú)立的且可替換的，但這里的功能是相互依賴的。這違反了面向?qū)ο蟮脑O(shè)計(jì)原則，但對(duì)于某些應(yīng)用程序是必要的。用戶可以使用排隊(duì)系統(tǒng)按順序調(diào)用功能，使它們更獨(dú)立可操作和可擴(kuò)展。

功能鏈對(duì)于實(shí)現(xiàn)定義明確的順序任務(wù)非常有用。例如，企業(yè)可能希望在用戶下訂單之后調(diào)用功能鏈，可以通過不同的微服務(wù)處理數(shù)據(jù)，并將其推送到每個(gè)后續(xù)數(shù)據(jù)存儲(chǔ)中。

這些任務(wù)都可以獨(dú)立發(fā)生，也可以在后臺(tái)發(fā)生。這樣，企業(yè)的電子商務(wù)商店的用戶界面(UI)將會(huì)保持快速運(yùn)行，而后端功能可能需要幾分鐘才能完成。

結(jié)語

總之，人們對(duì)軟件模式以及如何將它們應(yīng)用于電子商務(wù)微服務(wù)了解得越多，就可以更好地利用這些現(xiàn)有知識(shí)來解決問題。

原文標(biāo)題：Design Patterns for Modern Day Commerce Using Microservices，作者：James Konik

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】