使用类似应用程序的模板将单体应用程序分解为微服务答案

【问题标题】：Breaking a monolith into microservices using templates for similar apps使用类似应用程序的模板将单体应用程序分解为微服务
【发布时间】：2019-08-02 22:23:49
【问题描述】：

我有一个巨大的单体应用程序，一个 ASP.NET MVC 框架服务，提供约 50 个不同的不相关数据“组”，分为 50 个不同的控制器/业务逻辑。我的任务是把这个单体分解成 50 个微服务（每个都托管在 Docker 容器中）。

我打算做的是使用 ASP.NET Core 创建一个“模板应用程序”作为参考项目，对于这 50 个应用程序中的每一个，我都会fork这个“模板”项目，添加相应的具有必要业务逻辑的控制器，可能需要或不需要自定义此模板以添加一些特定的功能。

例如，一个应用程序可能需要使用 CSV 格式而不是 JSON 来响应请求，JSON 是大约 45 个应用程序的标准。因此，我将修改“模板项目”以包含此“CSV 响应”功能，并且它将被其他 ~4 个使用它的项目使用。

我目前能看到的：

优点

开发 ASP.NET Core 应用程序很容易，但它需要一些已经定义到“我的公司模板”项目中的配置和自定义（CORS、缓存、路由等）。

缺点

分叉和合并模板项目可能很麻烦。如果我们在模板中发现安全问题，则需要手动更新所有 50 个项目并修复一些潜在的合并冲突。

在 ASP.NET Core 中是否有其他选项可以使这个“模板”项目更易于更新和维护？或者为此的设计模式？

【问题讨论】：

标签： asp.net asp.net-mvc asp.net-core microservices

【解决方案1】：

只需使用类库。通用功能甚至基本控制器等都可以到那里并被实际的 API 项目引用。您的通用配置可以作为IServiceCollection 扩展添加到类库中：

public static class IServiceCollectionExtensions
{
    public static IServiceCollection AddMyCors(this IServiceCollection services)
    {
        services.AddCors(...);
        return services;
    }

    ...
}

然后，由于直接引用，对此库的任何更改都会自动传播到您的 API。

但是，请记住，微服务的全部意义在于松耦合。你真的应该只为相对静态且不会改变的事物共享这种功能。进行需要更新 50 项服务中的每一项的更改，几乎完全违背了这一点。

如果有太多常见的共享功能，您必须问自己是否真的将服务分解为子域。这种方式的一个非常常见的错误是没有意识到实际数据也应该被隔离。理想情况下，每个微服务都应该有自己的数据存储（例如数据库）。如果您试图让微服务共享相同的数据存储，那么您将不可避免地最终出现大量交叉，并且即使不是不可能隔离它们的域也是很困难的。这意味着您有时会丢失诸如外键之类的细节，您甚至可能需要产生一些数据重复。这就是 CQRS、事件溯源和其他相关模式开始发挥作用的地方。

【讨论】：