微服务实战: 从电子商务平台到微服务电子商务(Omni-Commerce)

对于企业来说，微服务比单体架构应用更灵活，尤其是零售和电子商务行业来说。了解这个解决方案面临的挑战和系统架构。

背景

传统上，零售商使用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(全栈开发人员)上的能力。

规模较小的零售商也可能通过开始构建一两个微服务(比如搜索或浏览)来测试市场，然后再决定继续使用核心购物车和支付功能。