Как управлять многоуровневой средой между переходом от монолитной к микросервисной архитектуре

Question

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

Мы демонтируем монолитное приложение с помощью сервис-ориентированной архитектуры в промежуточный период для некоторого модуля ( когда база данных все еще подключена к базе данных монолитного приложения ), а некоторые мы напрямую переходим на микросервис ( микросервис владеет собственной базой данных, если применимо ).

Мы практикуем выпуск функциивсякий раз, когда он готов вместо того, чтобы следовать за окном выпуска.У каждой команды есть свои собственные этапы для управления этим, поэтому у нас есть несколько этапов среды ( 11 в общей сложности ), каждая со своим собственным набором устаревшего монолитного приложения.

При переходе на архитектуру микросервиса (, хотя я понимаю, что когда мы полностью перейдем к архитектуре микросервиса, для всей компании будет только 1 этап ), нам потребуется сохранить всете этапы, которые означают, что нам потребуется копия микросервиса в каждой промежуточной среде.

(Неозначает направлять ответы в направлении этого решения. Предпочтительно, если есть какие-либо ответы в другом направлении, чтобы у нас было больше вариантов и вариантов для рассмотрения плюсов и минусов) Одна из идей, которая у нас есть,что для каждого дБ у нас есть дополнительный столбец, чтобы отметить, для чего предназначена эта строка данных.Поэтому мы можем поддерживать один единственный экземпляр микросервиса для нескольких этапов.Проблема заключается в том, что для каждого вызова API клиентская сторона должна указывать, для чего она предназначена.Это усложняет разработку каждой службы ( необходимо учитывать, для какой базы данных промежуточного уровня отфильтровывать ), затрудняет вызов конечной точки (, поскольку необходимо указать, к какой промежуточной базе данных вам необходимо получить доступ ) и что более важно, это избыточный код, который, как предполагается, не должен присутствовать в производстве.

Проблема, с которой мы сталкиваемся, заключается в том, что по мере роста числа микросервисов потребуется много ресурсов сервера.( мы решили использовать на локальном сервере для размещения наших kubernetes и Proxmox VM для устаревшего монолита ).Существует ли какая-либо инфраструктурная архитектура, которая бы уменьшала ресурсы, необходимые для этого ?

Answer 1

Я не до конца понимаю все возможные детали, с которыми вы можете столкнуться, но некоторые моменты следующие:

• При переходе на новую микросервисную архитектуру, следуя sth, как шаблон Strangler, вы должны решить,кто / где является источником достоверности ваших данных (не обязательно должен быть одинаковым для всех данных).
• Для микросервисов (MS), которые не изменяют состояние данных (например, новый поисковый микросервис)) обычно я передаю данные из источника правды (например, таблицы RDS монолита) на другую, более гибкую / дружественную для микросервисов среду (в нашем случае мы выбрали Apache Kafka, и эта среда является темой Kafka).MS считывает события из темы и создает свое внутреннее представление о мире (т. Е. Пример поиска направляет события в Elastic Search).
• Для МС, которые также изменяют состояние источника истины, это более сложно.Один хороший подход, на мой взгляд, состоит в том, чтобы поддерживать состояние «источника правды» в вашей новой среде микроуслуг (например, накапливать события в теме, представляющей порядок) и асинхронно передавать обратно в монолитную БД.
• Разные команды (специализирующиеся на разных новых микросервисах) будут иметь собственные темы.

Answer 2

Если я правильно понимаю вашу проблему, то вы планируете использовать выделенный сервер для каждого шестиугольника, прямоугольника и узла БД в диаграмме развертывания на основе микроуслуг.

Хорошая новость заключается в том, что вы можете использовать каждую из этих служб в одном и том же физическом блоке без значительных эксплуатационных расходов, максимально используя свои аппаратные ресурсы. Docker контейнеры являются ответом на это.Вы можете создавать легкие микроконтейнеры, которые могут использовать одни и те же аппаратные ресурсы.Конечно, вы должны учитывать несколько аспектов, чтобы убедиться, что вы не перерасходуете свои ресурсы. Здесь - хорошее объяснение того, что влияет на максимальное количество контейнеров, которые могут работать на хосте докера.Вы получите множество других преимуществ, таких как простота развертывания новой версии, откат к более старой версии, супер быстрая настройка среды разработки и т. Д.

Развертывания Docker становятся все более распространенными даже в производственной среде благодаря использованию оркестровки контейнеров.система типа Kubernetes или DC / OS .

Answer 3

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

Если многие или все микросервисы используют одну и ту же версию базы данных, возможно, вы сможете разместить ихв отдельных схемах базы данных при одном развертывании базы данных с высокой доступностью, что также уменьшает объем ресурсов.

Конечно, это зависит от планируемого использования промежуточных сред.Если у всех команд одновременно заканчиваются демонстрации спринта, кластер может быть перегружен в час пик прямо перед этим.

Answer 4

В вашем случае Kubernetes on-premise может стать решением для вас и вашей команды.
Вы можете создать 2 или более кластера для своей инфраструктуры.Мое предложение как минимум 2 кластера.Первый - для разработки, тестирования и подготовки, второй - для производственной среды.

Теперь вы можете запутаться, как 2 кластера могут управлять вашей 11 различными промежуточными средами.В среде Kubernetes есть пространства имен, которые вы можете создавать с разными именами, и вы можете изолировать эти пространства имен.Итак, в 1 кластере Kubernetes у вас может быть гораздо больше среды для подготовки, тестирования или разработки.

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

Что касается вашего монолитного приложения, ваш метод - лучший способ, медленно разбирая его.Что касается базы данных, если это возможно, сохранение монолитной БД и создание новых БД для микросервисов было бы лучше в будущем, потому что вы можете проанализировать свои потребности и, возможно, добавить дополнительные поля для анализа или метрик в БД микросервисов.

Прежде чем разбирать ваше монолитное приложение, вы можете даже попытаться провести трафик между вашим монолитным приложением и микроуслугами с помощью Istio или Linkerd.