Разбиение монолита на микросервисы с использованием шаблонов для похожих приложений

Question

У меня огромное монолитное приложение, сервис ASP.NET MVC Framework, предлагающий ~ 50 различных «групп» несвязанных данных, разделенных на 50 различных контроллеров / бизнес-логик. Мне было поручено разбить этот монолит на 50 микросервисов (каждый из которых размещался в контейнерах Docker).

Я планирую создать «шаблонное приложение» с использованием ASP.NET Core в качестве эталонного проекта, и для каждого из этих 50 приложений я fork этот "шаблон "проект, добавьте соответствующий контроллер с необходимой бизнес-логикой и, возможно, потребуется или нет настроить этот шаблон для добавления некоторых специфических функций.

Например, одному приложению может потребоваться ответить на запросы, используя формат CSV вместо JSON, который является стандартом для ~ 45 приложений. Итак, я бы изменил «шаблон проекта», включив в него эту функцию «CSV response», и она будет использоваться другими ~ 4 проектами, которые будут его использовать.

Что я вижу сейчас:

PROS

• Разработка приложения ASP.NET Core проста, но требует некоторых настроек и настроек (CORS, Cache, маршрутов и т. Д.), Которые уже были бы определены в проекте «Шаблон моей компании».

CONS

• Создание и объединение шаблона проекта может быть проблематичным. Если мы обнаружим проблему безопасности в шаблоне, потребуется вручную обновить все 50 проектов и устранить некоторые потенциальные конфликты слияния.

Есть ли другая опция, доступная в ASP.NET Core, чтобы упростить этот «шаблонный» проект для обновлений и обслуживания? Или шаблон дизайна для этого?

Answer 1

Просто используйте библиотеку классов.Общие функциональные возможности и даже базовые контроллеры и тому подобное могут быть использованы в реальных проектах API.Ваш общий конфиг может быть добавлен в библиотеку классов как IServiceCollection extensions:

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

    ...
}

Затем любое изменение этой библиотеки автоматически распространяется на ваши API из-за прямой ссылки.

ОднакоИмейте в виду, что в целом весь смысл микросервисов является слабосвязанным.На самом деле вы должны использовать этот вид функциональности только для тех вещей, которые относительно статичны и не изменятся.Внесение изменений, требующих обновления каждого из 50 сервисов, в значительной степени сводит на нет весь смысл.

Если существует слишком много общих, общих функций, вам нужно спросить себя, действительно ли вы разложили сервисы насубдомены.Таким образом, очень распространенной ошибкой является отсутствие понимания того, что фактические данные также должны быть разделены.В идеале каждый микросервис должен иметь свое собственное хранилище данных (например, базу данных).Если вы пытаетесь заставить микросервисы совместно использовать одно и то же хранилище данных, вы неизбежно столкнетесь со значительным переходом, и будет трудно, если не невозможно, разделить их домены.Это означает, что вы иногда теряете тонкости, такие как внешние ключи, и вам может даже потребоваться некоторое дублирование данных.Вот где CQRS, источник событий и другие связанные с ними шаблоны начинают вступать в игру.