Переносить монолит на микросервисы, не касаясь базы данных

Question

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

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

Не будет ли это проблемой на уровне базы данных, когда выесть несколько процессов (по одному для каждой службы)?

Answer 1

Рефакторинг аспекта обработки вашего приложения без рефакторинга данных, которые он использует, потенциально может привести к проблемам, одной из которых является постоянно увеличивающаяся техническая долговая нагрузка.Поскольку вы получаете большую согласованность «бесплатно» с вашей большой СУБД, планируете ли вы также отложить внедрение всех событийных асинхронных уведомлений и обновлений, которые вам нужно будет добавить для поддержки каждой службы?Если эти конечные точки даже не были идентифицированы, похоже, что после первоначального завершения работы ваших микросервисов вы будете проводить рефакторинг не только вашей базы данных.Помимо независимой от структуры базы данных основной бизнес-логики, ожидайте еще одну итерацию разработки этих микросервисов после того, как вы разбьете свою базу данных.

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

Я бы предложилболее целостный подход, при котором вы постепенно реорганизуете свою базу данных и монолит в микросервисы.Выберите легко выделить часть вашего монолита и начните с этого.Он может содержать небольшой API из пары конечных точек REST и отделять свои данные от своих собственных таблиц.Для REST GETS используйте любой метод для перемещения данных из вашей монолитной БД в эти таблицы, чтобы синхронизировать их.Для постоянных методов используйте очередь событий и простой сервис для обновления монолитных данных из вашего хранилища данных микросервиса.Затем перейдите к следующему сервису.Продолжая, вы можете начать списывать сервисы и любые другие механизмы, которые вы использовали для поддержания согласованности данных между вашими микросервисными схемами и схемой монолитной базы данных.Без накопления неизвестного технического долга, возможно, будет даже лучше спрогнозировать результат вашего проекта после того, как будут реализованы первые несколько пользовательских историй!

Answer 2

База данных Oracle внедряется в фундамент PCF.Вы можете сделать это следующим образом ..

• Служба CUPS
• Компонент Service Broker

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

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

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

Распространенный метод называется «Модель удушения».Такой подход позволяет постепенно переносить монолит на микросервисы.При таком подходе вы извлекаете ценные функции и конвертируете их в микросервисы.Тогда старый монолит либо игнорирует эти функции, либо подвергается рефакторингу для вызова этих микросервисов.

Существуют и другие соображения, которые необходимо учитывать.Они включают в себя обработку сеанса, ведение журнала в файлы и т. Д.

Надеюсь, это поможет!