技术团队和管理层非常热衷于使用一个称为微服务的新流行语。但这涉及转换的成本。
您如何进行这种转变？进行转换值得吗？还是继续进行一些修改以继续使用当前方法是否好？您如何决定？
从遗留系统本身定义微服务的过程是一个传奇。
让我们以单体/整体/旧式系统的POS应用程序域为例。这是每个人都普遍理解的领域。
它由庞大的系统中内置的以下广泛模块组成：
我们如何计划此类系统的迁移？当我们迁移整个系统时，这看起来很容易。但是企业不能等到一切都迁移了。
当采用增量方法并将域切成多个垂直部分并逐步迁移时，存在一些体系结构方面的挑战。
我将解释实现微服务目标所需的一些步骤。如上所述，所有步骤都不必是连续的。例如，三个团队可以并行执行步骤1、2和3。步骤1和2是在考虑其他步骤之前进行计划的非常重要的步骤。
步骤1
迈向微服务方法的第一步是为您的微服务规划DevOps。完成一些准备部署的功能后，您应该为构建，测试和部署微服务设置连续的部署方法。
您还可以查看用于Kubernetes的容器和工具进行编排。由于这是一个通用主题，因此我们将不涉及技术细节，并将继续让您选择自己喜欢的技术。
在此之中，重要的是可以用来组成多个API的API网关技术。
步骤2
接下来的一件重要的事情，也许是最重要的一件事情，是确定将用于新的微服务重写的单一登录技术。这一点至关重要，因为其他服务将是独立的，并且在一次登录时浏览应用程序以查找不同的微服务时提供流畅的体验非常重要。
步骤3
重写的下一步是确定系统中的垂直业务域子系统。在我们的示例中，我们有客户，购物车，产品，促销和付款。
我建议您仔细阅读Eric Evans的领域驱动原理DDD，以创建一个框架来识别核心域并支持系统中的域。深入了解“边界上下文”原理，以将域垂直拆分为解耦的层，这一点也很重要。
在这些业务域子系统中，假设您选择重写的第一个域是促销。
选择促销模块作为第一个重写的优点是什么？
团队对微服务的了解可能在一开始就不成熟。因此，一开始选择一个非常核心的业务领域组件（例如购物车或付款）可能会更加冒险。同时，核心业务仍将需要在旧系统中运行，并且在一段时间内，其他支持域或辅助域可以与旧系统集成而无需紧密耦合，并且可以与旧系统集成运行。
在此过程中，应尽可能减少对整体的依赖，并且必须将模块与其他服务分离。在某些罕见的地方可能需要依赖。为此，请从整体中公开一个新的API，然后通过新服务中的API网关访问该API。
步骤4
还根据域的垂直切片对数据层进行切片。请记住，微服务中的所有内容都应与其他服务分离。重要的是，除了UI和API层之外，还为给定的微服务创建了数据层，而没有任何交叉引用。这对于在不等待其他服务完成的情况下按自己的速度独立构建和部署微服务也很重要。
步骤5
从传统中切分微服务的原则应该将重点放在功能上，而不是解耦代码并从整体中提取代码重用。专注于重写功能并摆脱旧的代码。原因是：
- 现有代码取决于许多环境依赖性，例如运行时配置，数据存储，缓存和会话，并使用旧框架。这些代码大部分都需要重写。托管微服务的新基础架构将需要一种非常不同的样板代码。
- 现有代码可能未使用明确的域概念编写。这导致保留了不能反映新域模型并且需要进行大量重组的数据结构。
- 经历了许多更改和开发生命周期的旧版代码可能具有较高的代码毒性级别和较低的重用价值。
步骤6
然后是计划下一个需要处理的模块。到这个时候，团队将对微服务过渡进行充分的演练。团队可以在订单付款，购物车，产品，客户中进行转换。最后，我考虑了客户，因为它在所有模块中都具有依赖性，并且由于购物车使用其他依赖性作为主数据，因此回溯到遗留的依赖性将最小。您可能会考虑并行开发某些模块，并继续与各自的团队进行维护。在任何情况下，团队都应按照上面给出的顺序保持设计目标，以实现平稳过渡。
设计单个服务时仍然存在挑战。由于体系结构代码的数量很容易膨胀。为了简化此方面，我构建了FlexBase。
FlexBase会为您的功能需求生成60-80％的管道代码，在遵循上述步骤5时非常有用。使用Flexbase，过渡到微服务的过程变得更加容易，并且不易出错。