我很好奇将整体网站转换成微服务所涉及的任务。你需要做些什么来使它工作，即重定向。要实现这一点，以下网站的转换涉及哪些任务？
简而言之，我理解过渡过程的作用，但不了解过渡过程需要做些什么。
答案 0 :(得分：3)
此处缺少许多信息 - 例如什么是您网站的当前架构和技术堆栈。考虑到这是一个非常广泛的问题，我建议这些指导方针：
不要一次重构所有内容 - 这是不可能的。
将Monolith视为带有一些API的黑盒子。它们不一定是RESTful API - 想办法与它进行交互。
添加新功能时，为每个功能创建单独的（微）服务，并让它们与The Monolith的API进行交互。
一段时间后，您将看到只能通过新API访问Monolith的各个部分。即使它们仍然是整体代码库的一部分。垂直移出功能，将核心功能与其数据分离，并将所有前端应用程序重定向到新的API。
一旦你看到有限的上下文冒出来，就可以方便地将它们砍掉Monolith并让它们作为单独的服务工作。
使用微服务，您将需要比以前更多的自动化。提前考虑持续集成和持续部署（CI / CD），容器和存储库，中央日志记录和监控。
我会建议在进入您的具体问题之前先获得一些简明扼要的概念。 This可以是一个好的开始。
答案 1 :(得分：0)
将网站划分为小桶模块列表。然后根据微服务模式逐个/逐个地开发模块。
答案 2 :(得分：0)
很难从您发布的链接中了解网站的复杂性。我假设您正在进行自己的库存和订单管理，而不是将这些任务推送到服务提供商。我还假设您无法在迁移过程中停止功能开发。
任何旧版迁移项目最重要的事情是首先在遗留代码中安装Inversion of Control。这将提供分离现在可能紧密耦合的单独问题的方法。没有IoC，你将会遇到困难。请注意，在迁移旧版应用程序时，构造函数注入是非启动式的。相反，您将不得不使用服务定位器模式，并在将来考虑构造函数或属性注入。
一旦你有一个IoC容器，你就可以开始寻找接缝来分解服务了。您可能会发现自然适用于内部服务的代码，因此重构它们以便由服务定位器解决。系统记录器是一个很好的起点。
前几个月的目标是转向面向服务的体系结构，其中大部分业务逻辑包含在域实体或服务中。不要强调从一开始就获得完美的建筑 - 这是不可能的。迁移过程涉及从一个有臭味的架构转变为具有逐渐减少气味的架构，而不是从单块直接到模块化。只需从UI和控制器中获取业务逻辑，稍后您就可以调整域层或应用层的内容。
请注意，存储库也是一个重点。迁移到服务时，还必须迁移所有数据库访问以使用存储库模式。这将打开实际单元测试的大门。
当您迁移代码以使用服务，存储库和IoC时，您将开始看到可以将某些功能分解为API的接缝。使用一个小功能创建第一个API，并重构您的monolith以使用它。将其缩小是因为它需要大量的基础架构和流程更改，并且您希望尽可能少地同时进行更改。将第一个API分离后，继续将越来越多的功能迁移到该API。
顺便说一句，这是转向CQRS架构和DDD战略的好时机。第一个API应该是完整的有界上下文并使用CQRS实现。 祝你好运！ 顺便说一下，我写了一本关于这件事的书。它专注于.NET，但这个过程适用于任何语言。搜索＆＃34; Bradley Irby＆＃34;在亚马逊上。