將電子商務解決方案遷移至 Azure

  • 發行項

簡介

將現有的電子商務解決方案移至雲端，可為企業帶來許多優點：其可擴縮性、為客戶提供 24/7 的輔助功能，並更容易整合雲端服務。 但首先，將電子商務解決方案移至雲端是一項重大工作，而決策者必須瞭解的成本。 本文件說明 Azure 移轉的範圍，目標是通知您選項。 第一個階段從 IT 專業人員開始，將元件移至雲端。 當您在 Azure 上時，我們會描述電子商務小組可以採取的步驟來增加您的投資報酬率（ROI），並利用雲端。

在十字路口

雖然全球電子商務交易只佔零售總額的一小部分，但該管道仍持續穩步增長。 截至2024年，電子商務銷售占零售總額的五分之一，高於2016年的8.6%（ 來源）。 隨著電子商務的成熟，隨著雲端運算的出現，零售商正處於十字路口。 有選擇。 他們可以設想其商業模式，其新功能是透過不斷演進的技術而實現的：而且，他們可以規劃其現代化，因為他們目前的功能使用量。

改善客戶旅程圖

電子商務主要著重於客戶旅程圖，具有許多不同的屬性。 這些屬性可以分成四個主要區域：探索、評估、購買和購買后。

客戶行為會擷取為數據。 購物漏鬥圖是應用程式的連接點集合，用於檢視產品數據、交易、庫存、出貨、訂單履行、客戶配置檔、購物車和產品建議等。

典型的零售業務仰賴從客戶面向應用程式到基礎應用程式的大型軟體解決方案集合。 下列繪圖顯示一般零售業務中存在的功能檢視。

圖表會比較外部可見的功能與核心功能。

雲端有機會轉移組織取得、使用和管理技術的方式。 其他優點包括：降低維護數據中心的成本、改善可靠性和效能，以及新增其他服務的彈性。 在此使用案例中，我們將探討零售企業可採取的路徑，將其現有的基礎結構移轉至 Azure。 我們也使用重新裝載、重構和重建的階段式方法，利用新的環境。 雖然許多組織可能會遵循此系列現代化路徑，但在大多數情況下，組織可以進入任何階段作為起點。 組織可以選擇放棄重新裝載其目前在 Azure 上的應用程式，並直接跳至重構或甚至重建。 此決策對應用程式而言是獨一無二的，且組織最符合其現代化需求。

重新裝載

這一階段也稱為「隨即轉移」，需要將實體伺服器和 VM 依原樣移轉至雲端。 只要將目前的伺服器環境直接轉移到 IaaS，即可獲得節省成本、安全性和提高可靠性的優點。 節省的成本來自在適當大小的 VM 上執行工作負載等技術。 現今，內部部署 VM 和實體機器的功能經常超過零售商的日常需求。 VM 必須能夠處理每年只發生幾次的季節性商務尖峰。 因此，您在淡季期間支付未使用的功能。 使用 Azure 時，您可以根據目前商務週期的需求來挑選大小正確的 VM。

若要在 Azure 中重新裝載，有三個階段：

  • 分析 ：識別及清查內部部署資源，例如應用程式、工作負載、網路和安全性。 在此階段結束時，您有現有系統的完整檔。
  • 移轉 ：將每個子系統從內部部署移至 Azure。 在此階段中，您將使用 Azure 作為資料中心的延伸模組，應用程式會繼續通訊。
  • 優化 ：當系統進入 Azure 時，請確定大小正確。 如果環境顯示配置太多資源給某些 VM，請將 VM 類型變更為 CPU、記憶體和本機記憶體有更適當的組合。

分析

執行下列步驟：

  1. 列出內部部署伺服器和應用程式。 此程式依賴代理程式或管理工具來收集伺服器的相關元數據、伺服器上執行的應用程式、目前的伺服器使用量，以及伺服器及其應用程式的設定方式。 結果是環境中所有伺服器和應用程式的報表。
  2. 識別相依性。 您可以使用工具來識別哪些伺服器彼此通訊，以及彼此通訊的應用程式。 結果是所有應用程式和工作負載的對應或對應。 這些地圖會饋送至移轉規劃。
  3. 分析組態。 目標是瞭解您在 Azure 中執行時所需的 VM 類型。 結果是所有可移至 Azure 的應用程式報告。 它們可以進一步分類為具有：
    1. 沒有修改
    2. 基本修改，例如命名變更
    3. 次要修改，例如稍微變更程序代碼
    4. 需要額外努力才能移動的不相容工作負載
  4. 建立預算。 您現在有一個清單來列舉每個CPU—記憶體等等，以及每個應用程式的需求。 將這些工作負載放在適當大小的 VM 上。 雲端平台帳單成本是以使用量為基礎。 工具存在，可將您的需求對應至大小正確的 Azure VM。 如果您要移轉 Windows VM 或 SQL Server，您也應該查看 Azure Hybrid Benefit，以降低您在 Azure 上的費用。

Microsoft 提供數個工具來分析和編錄您的系統。 如果您執行 VMware，您可以使用 Azure Migrate 來協助探索和評量。 此工具會識別可移至 Azure 的機器、建議要執行的 VM 類型，並估計工作負載的成本。 針對 Hyper-V 環境，請使用 Azure Site Recovery 部署規劃工具。 針對需要移動數百或更多 VM 的大型移轉，您可以與 Azure 移轉合作夥伴合作。 這些合作夥伴具有移動工作負載的專業知識和經驗。

移轉

開始規劃要移至雲端的哪些服務，以及依何種順序移動。 因為此階段牽涉到移動工作負載，請遵循下列順序：

  1. 建置網路。
  2. 併入身分識別系統（Microsoft Entra ID）。
  3. 在 Azure 中布建記憶體片段。

在移轉期間，Azure 環境是內部部署網路的延伸模組。 您可以將邏輯網路與 Azure 虛擬網絡 連線。 您可以選擇使用 Azure ExpressRoute ，在從未接觸因特網的私人連線上，保持網路與 Azure 之間的通訊。 您也可以使用站對站 VPN，其中 Azure VPN 閘道 會與內部部署 VPN 裝置交談，並使用 Azure 與網路之間的加密通訊安全地傳送所有流量。 我們已發佈參考架構，詳細說明如何在這裡設定混合式網路。

設定網路之後，請規劃商務持續性。 建議使用即時復寫將內部部署數據移至雲端，並確保雲端和現有數據相同。 電子商務商店永遠不會關閉;重複提供從內部部署切換至 Azure 的能力，對您的客戶的影響最小。

開始將數據、應用程式和相關伺服器移至 Azure。 許多公司都使用 Azure Site Recovery 服務移轉至 Azure。 此服務的目標是商務持續性和災害復原（BCDR）。 這非常適合從內部部署移轉至 Azure。 您的實作小組可以在這裡閱讀如何將內部部署 VM 和實體伺服器移轉至 Azure 的詳細數據。

將子系統移至 Azure 之後，測試以確定一切如預期般運作。 一旦所有問題都關閉，請將工作負載移至 Azure。

最佳化

此時，您將會繼續監視環境，並變更基礎計算選項，以隨著環境變更而符合工作負載。 神秘 不過會監視環境的健康情況，應該監看每個資源的使用量。 目標應該是在大部分 VM 上具有 75-90% 的使用率。 在使用率異常低的 VM 上，請考慮將它們封裝成更多應用程式，或移轉至 Azure 上保留適當效能層級的最低成本 VM。

Azure 也提供將環境優化的工具。 Azure Advisor 會監視環境的元件，並根據最佳做法提供個人化建議。 這些建議有助於改善應用程式中所用資源的效能、安全性和可用性。 Azure 入口網站 也會公開應用程式健康情況的相關信息。 您的 VM 應該利用適用於 Linux 和 Windows 的 Azure 虛擬機擴充功能。 這些延伸模組提供部署後設定、防毒、應用程式監視等等。 您也可以利用許多其他 Azure 服務，透過 網路監看員、服務對應、Application Insights 和 Log Analytics 等服務進行網路診斷、服務使用量和警示。

雖然組織的部分已在 Azure 中將系統優化，但開發小組可以開始移至移轉後階段：重構。

重構

完成移轉之後，您的電子商務應用程式就可以開始利用其在 Azure 中的新首頁。 重構階段不需要等到整個環境移動為止。 如果您的 CMS 小組已移轉，但 ERP 小組沒有，則沒有問題。 CMS 小組仍然可以開始重構工作。 此階段牽涉到使用其他 Azure 服務，藉由重構您的應用程式來優化成本、可靠性和效能。 在隨即轉移的位置，您只會利用提供者管理的硬體和OS，在此模型中，您也會利用雲端服務來降低成本。 您可以繼續依現狀使用目前的應用程式，並變更一些次要的應用程式程式代碼或組態，並將您的應用程式連線到新的基礎結構服務，例如容器、資料庫和身分識別管理系統。

重構工作會變更很少的程式代碼和組態。 您將有更多時間專注於自動化，主要是因為此階段採用的技術依賴腳本來建置和部署資源;部署指示是腳本。

雖然可以使用許多 Azure 服務，但我們將著重於重構階段中使用的最常見服務：容器、應用程式服務和資料庫服務。 我們為什麼要看看重構？ 重構提供強大的程式代碼基礎，藉由將程式代碼債務保留在理性之內，以降低長期成本。

容器提供組合應用程式的方式。 由於容器虛擬化操作系統的方式，您可以將多個容器封裝成單一 VM。 您可以將應用程式移至具有零到少數程式代碼變更的容器;您可能需要設定變更。 此工作也會導致將應用程式組合至容器的腳本。 您的開發小組會花費其重構時間撰寫和測試這些腳本。 透過 Azure 支援容器化Azure Kubernetes Service （AKS） 和相關 Azure Container Registry 可讓您用來管理容器映射。

針對應用程式服務，您可以利用各種 Azure 服務。 例如，您現有的基礎結構可能會藉由將訊息放入RabbitMQ之類的佇列來處理客戶訂單。 （例如，一則訊息是向客戶收取費用，第二則是寄送訂單。重新裝載時，您會將RabbitMQ放在個別的 VM 中。 在重構期間，您可以將 服務匯流排 佇列或主題新增至解決方案。 此時，您可以重寫 RabbitMQ 程式代碼，並停止使用提供佇列功能的 VM。 如果無法一次重寫所有程序代碼，您可以使用訊息網橋等模式來橋接傳訊佇列之間的差距。 這可讓您逐一移轉端點，而不是一次全部移轉。 無論哪種方式，當所有端點最終都移至 Azure 服務匯流排 時，這會以永遠開啟的訊息佇列服務取代一組 VM，以降低成本。 您可以在 Azure 入口網站 中找到其他應用程式服務。

針對資料庫，您可以將資料庫從 VM 移至服務。 使用 Azure 支援 SQL Server 工作負載Azure SQL 資料庫 和 Azure SQL 資料庫 受控執行個體。 數據 遷移服務 會評估您的資料庫、通知您在移轉之前必須執行的工作，然後將資料庫從 VM 移至服務。 Azure 支援MySQL、PostgreSQL 和其他資料庫引擎服務也一樣。

重建

直到這一點為止，我們嘗試將電子商務系統的變更降到最低，我們只剩下工作系統。 現在，讓我們討論如何真正利用雲端。 這個階段意謂著透過積極採用 PaaS 或甚至 SaaS 服務和架構來修改現有的應用程式。 此程式包含新增功能或重新架構雲端應用程式的主要修訂。 受控 API 是利用雲端系統的新概念。 我們可以藉由建立 API，讓系統更容易更新服務之間的通訊。 第二個優點是能夠深入了解我們所擁有的數據。 我們藉由移至 微服務加上 API 架構，並使用機器學習和其他工具來分析數據來執行此動作。

微服務 + API

微服務會透過外部面向的 API 進行通訊。 每個服務都是獨立的，而且應該實作單一商務功能，例如：建議客戶的專案、維護購物車等等。 將應用程式分解為微服務需要時間和規劃。 雖然沒有定義微服務的硬式規則，但一般概念涉及將可部署的單位縮減為一組幾乎一律變更在一起的元件。 微服務可讓您視需要部署變更，同時降低整體應用程式的測試負擔。 某些服務可能非常小。 針對那些，使用 Azure Functions 的無伺服器可正常向外延展至所需的呼叫端，同時在不使用時不耗用任何資源。 其他服務將圍繞商務功能進行細分：管理產品、擷取客戶訂單等等。

無伺服器機制確實有缺點：在輕量負載下，當雲端中的某些伺服器設定和執行程式代碼時，回應速度可能會很慢。 對於客戶大量使用的環境部分，您想要確保客戶可以快速且輕鬆找到產品、下單、要求退貨等等。 每當效能變慢時，您都有可能失去購物漏鬥中的客戶。 如果您有必須快速回應的功能，請將該功能重建為 Azure Kubernetes Service 中的個別可部署單位。 對於其他情況，例如需要大量記憶體、數個CPU和大量本機記憶體組合的服務，在自己的VM中裝載微服務可能很合理。

每個服務都會使用 API 進行互動。 API 的存取權可以直接導向微服務，但這需要任何與服務通訊的人才能知道應用程式拓撲。 API 管理 之類的服務可讓您以集中的方式發佈 API。 所有應用程式都只會連線到 API 管理 服務。 開發人員可以探索可用的 API。 API 管理 服務也提供功能，讓您的零售環境運作良好。 服務可以限制應用程式的不同部分對 API 的存取（以防止瓶頸）、快取回應以緩慢變更值、從 JSON 轉換成 XML 等等。 您可以在這裡找到完整的原則清單。

使用您的數據和 Azure Marketplace

由於您在 Azure 中擁有所有資料和系統，因此可以輕鬆地將其他 SaaS 解決方案納入您的企業。 您可以立即執行一些動作。 例如，使用 Power BI 將各種數據源結合在一起，以建立視覺效果和報表，並取得見解。

接下來，請查看 Azure Marketplace 中的供應專案，其可協助您執行優化清查、根據客戶屬性管理行銷活動，並根據客戶喜好設定和歷程記錄向每位客戶呈現正確的專案。 預期會花一些時間將數據設定為在 Marketplace 供應項目中運作。

元件

在重新載入期間使用：

  • Azure Advisor 是個人化的雲端顧問，可協助您遵循最佳做法來將 Azure 部署最佳化。
  • Azure Migrate 服務會評估要移轉至 Azure 的內部部署工作負載。
  • Azure Site Recovery 會協調和管理 Azure VM 和內部部署 VM 和實體伺服器的災害復原。
  • Azure 虛擬網絡 可讓許多類型的 Azure 資源，例如 Azure 虛擬機器（VM），安全地彼此通訊、因特網和內部部署網路。
  • Azure ExpressRoute 可讓您透過連線提供者所提供的私人連線，將內部部署網路延伸至 Microsoft 雲端。

在重構期間使用：

  • Azure Kubernetes Service 會管理裝載的 Kubernetes 環境，讓您快速且輕鬆地部署和管理容器化應用程式，而不需要容器協調流程專業知識。
  • Azure SQL 資料庫 是 Microsoft Azure 中一般用途的關係資料庫受控服務。 它支持關係型數據、JSON、空間和 XML 等結構。 SQL 資料庫 提供受控單一 SQL 資料庫、彈性集區中的受控 SQL 資料庫，以及 SQL 受管理執行個體。

在重建期間使用：

  • Azure APIM 可協助組織將 API 發佈給外部、合作夥伴及內部開發人員，以發揮其資料與服務的潛力。
  • Azure Functions 是用來在雲端中輕鬆執行少量程式碼片段或「函式」的解決方案。
  • Power BI 是一套商務分析工具，可在整個組織中提供深入解析。

結論

將電子商務系統移至 Azure 會採用分析、規劃和定義的方法。 我們已探討重新裝載、重構和重建的三個階段方法。 這可讓組織從一個工作狀態移至另一個工作狀態，同時將每個步驟的變更量降到最低。 零售商也可以選擇重構甚至重建元件，同時略過重新裝載。 許多時候，您將有一條明確的現代化道路，在您可以的時候加以採用。 當您獲得在 Azure 中執行的經驗時，您會看到更多機會來新增功能、降低成本，以及改善整體系統。

參與者

本文由 Microsoft 維護。 原始投稿人如下。

主要作者：

下一步

許多開發小組都傾向於同時進行重新裝載和重構，以解決技術債務和更好的槓桿能力。 跳到後續步驟之前，先重新裝載有好處。 部署至新環境的任何問題都比較容易診斷和修正。 這反過來又讓您的開發和支援小組有時間隨著 Azure 作為新環境而增加。 當您開始重構和重建系統時，您要建置在穩定且可運作的應用程式上。 這允許較小的目標變更和更頻繁的更新。

產品檔案：