對於企業來說，微服務比單體架構應用更靈活，尤其是零售和電子商務行業來說。瞭解這個解決方案面臨的挑戰和系統架構。
背景
傳統上，零售商使用ATG、WCS、Hybris等電子商務平臺建立和管理自己的網店。這些單體應用程序都是基於三層架構開發的。在很長的一段時間內，這些制定化的模塊，與許多其他企業系統集成在一起運行，並且客戶在這樣的系統上花費了大量的資金。然而，近年來，許多零售商已經開始從這些平臺轉向基於微服務的應用架構，以便方便實現定製特性和可擴展性的靈活性，以敏捷的方式滿足全渠道需求。一般的來說，重構的道路是漫長的，儘管最終會有回報。本文的觀點是使用新的辦法，來加速重構過程的。
為微服務推薦特定的技術棧或框架不是本文的目標。
現代化背景下：電子商務
客戶體驗正在成為真正的全渠道、上下文和個性化。這給網站功能的可用性和可擴展性帶來了新的挑戰。企業需要迅速地為不斷變化的環境和對競爭的反應做好準備。電子商務應用程序需要不斷髮展以應對挑戰，同時支持持續交付。
轉向微型服務的主要驅動力是:
能夠快速實現更改、快速部署和回滾
需要響應性UI、實時數據和沉浸式用戶體驗
網站的不可用性會極大地影響收入和聲譽
在系統忽然暴漲時需求擴大
不同的特性需要不同級別的可用性和可擴展性
保持低運營成本
全渠道個性化體驗(不支持開箱即用，定製困難/慢)
SaaS和雲服務的電子商務平臺
儘管SaaS平臺可以解決一些問題，比如成本和可用性，但零售商通常需要定製的差異化特性和真正的全渠道功能，這些功能是通過這些平臺不支持的。企業想要快速運行新的實驗，或者為他們組織的典型過程帶來效率。傳統電子商務平臺的雲服務也不能提供這種靈活性。
行業趨勢
許多一級零售商已經從單一的電子商務平臺轉向微服務、雲、CI/CD和DevOps。通過這樣做，他們能夠對快速發佈的特性有更多的控制，這些特性是他們的業務願景所獨有的。另一些人將追隨這一趨勢，因為他們需要更快、更全面的渠道和可用性，這對他們的競爭力至關重要。
企業應用程序的微服務
雖然微服務幾乎可以用於任何事情，但真正的驅動因素是快速改變的能力。對於許多企業應用程序(如財務、人力資源等)，重點通常是穩定性而不是靈活性。但是，有一些企業應用程序已經開始轉換(例如使用ML/AI/IoT在WMS中驅動效率)，這些應用程序可能是嘗試微服務的好候選者。事件驅動設計將有助於與遺留應用程序無縫集成。
以微服務為基礎的電子商務
將電子商務平臺重構為微服務是一個漫長的過程。通過提前計劃，遵循已建立的架構模式，並在對運行系統進行重大更改之前準備好生態系統，這一過程可以更快、更無風險。
在敏捷性交付、持續整合和部署、DevOps、12-要素（12-Factor ）應用程序設計、DDD、基於雲的、聚合體glot編程為構建微服務的基礎工作時，開始探索和建造能力，通常是個好主意。領域驅動設計是一個不斷髮展的過程，微服務應該設計為易於重構。
通過DevOps、雲本地設計以及持續集成和部署，微服務可以在私有云或混合/公共雲上運行。公共雲始終是電子商務應用的更好選擇。
團隊組織
將一個複雜的整體分解為微服務需要識別內聚的業務功能和實體(域)，並在獨立的有界上下文中對它們進行建模。這種粒度分離導致識別微服務(以及團隊)。這些團隊通常規模較小，在開發和操作方面擁有混合技能。
12要素（12-Factor） /原生雲應用
12要素應用程序構建基於方法論/部署指導,規模和獨立地管理它們。它們很容易從一個平臺/雲轉移到另一個平臺/雲，並且可以快速啟動/擴展並優雅地關閉。
DevOps
DevOps實踐幫助在團隊中構建協作，通過刪除依賴項、傳遞和可重複的手動配置，提供自動化、快速和頻繁交付所需的框架。
微服務框架
建議使用微服務框架來處理服務的橫切關注點，例如
- 服務註冊Service Registry
- 服務路由和過濾Service Routing and Filtering
- 訪問令牌Access Token
- 終端器Circuit Breaker
- 客戶端負載均衡Client-side load balancer
- 儀表Instrumentation
此外，選擇一個易於替換/升級的框架，並支持多個平臺。
重構順序
下圖描述了電子商務應用程序的一個傳統的整體實現。
通常，電子商務平臺是由多層(表示、業務、持久性等)組成的，而不是由功能組成的。這通常反映在數據模型中，它把不同的功能域緊密的耦合在一起。
依賴於其他組件使將該組件重構為微服務變得很困難。通常，建議從 headless平臺開始，並在其之上構建一個新的反應式UI層。
大型遷移項目的風險緩解策略之一是應用扼流圈模式來代替完全的切換。
電子商務平臺由目錄、購物車、促銷等模塊組成。
為了獲得可用性，需要首先將關鍵內容/組件移動到雲。主頁和瀏覽/搜索頁面的點擊量最大。產品描述頁面通常緊隨其後。
以下是來自電子商務引擎的域名列表，以及遷移它們的可能順序:
- 搜索 Search
- 產品目錄Catalog
- 產品定價Product Pricing
- 庫存Inventory
- 配送Shipping
- 交付Delivery
- 客戶賬戶Customer account
- 促銷活動Promotions
- 購物車Cart
- Associate facing tools
儘管這是一個典型的順序，但該順序應由產品的緊迫性來決定的。從一個精幹的團隊開始做小事情也很有幫助。同樣，它也不需要從平臺完全遷移，也就是說，如果一個組織的需求僅僅通過將平臺的一些關鍵功能轉換為微服務來實現的話。
為了使新服務在其有界的上下文中組織數據和語義，需要在轉換期間與遺留平臺集成時轉換上下文。一個小團隊可以採用增量過程，在構建臨時架構時，只將關鍵功能遷移到微服務。
由於我們把單體應用拆分成了多個不同的領域服務，因此需要構建由來自不同微服務的數據組成的物化視圖。
例如，需要根據產品、價格、庫存、促銷活動構建和更新產品目錄物化視圖。
通過使用事件的驅動，我們避免了服務之間的耦合，同時也避免了延遲。不同的使用者應用程序將需要基於個人需求的自己的物化視圖。
推薦使用基於事件的訂閱的多級別分佈式緩存和緩存驅逐。
下圖是基於微服務的電子商務的目標體系結構：
挑戰
隨著電子商務平臺轉化為服務，目標應該是讓服務成為唯一的數據來源。例如，不應該有特定的通道的庫存服務。然而，傳統上，零售企業的組織方式是這樣的，這需要許多團隊協同工作，以實現他們自己的優先目標。在此期間，可能需要創建具有路線圖的副本，以便其他團隊開始使用該服務。
重構通常由一個新的團隊完成(使用不同的技能集)。作為風險緩解步驟，可能需要在舊平臺和新平臺中實現一些增強(除非新功能可以在舊平臺和新平臺可以集成的單獨服務中完全實現)。
微服務增加了應用程序管理的複雜性。建議使用容器平臺。微服務框架可以幫助解決跨領域的問題，如API網關、可觀察性等。選擇一個易於在部分中替換的框架，並支持多門語言。
發展趨勢
我預計，從單一的電子商務系統轉向微服務的趨勢將持續下去。但這將更多地適用於大型零售商，他們認為現有的電子商務單一系統是不靈活的，他們想做更多，但卻做不到。大型零售商另一個關鍵驅動力是他們的內部技術力量和他們在高質量FSDs(全棧開發人員)上的能力。
規模較小的零售商也可能通過開始構建一兩個微服務(比如搜索或瀏覽)來測試市場，然後再決定繼續使用核心購物車和支付功能。
閱讀更多 程序你好 的文章
