Как разделить один внутренний сервис, связанный с базой данных, на два отдельных сервиса?

Question

У меня есть большая база данных MySQL, D_Big, с кучей данных в ней.У меня также есть сервис S1 с API, которые читают или пишут из этой базы данных.Например, один API может получить что-то из базы данных.Другой может записать строку в базу данных.и т.д.

У меня также есть небольшая вторичная база данных, D_Small, в которую S1 (и только S1) читает и пишет.Я хочу оставить небольшую вторичную базу данных в покое, но я хочу изменить способ доступа к данным из большой базы данных MySQL, D_Big.

Я хочу сделать так, чтобы единственный доступ к большой базе данных MySQLчерез вызовы API для второго сервиса, S2, который также имеет доступ к большой базе данных.Когда S1 хочет получить данные в D_big, он должен вызвать API в S2, которые будут возвращать данные в D_Big.Таким образом, я хочу удалить прямую зависимость S1 от D_Big.

Какие есть хорошие способы сделать это?Какие советы / советы?Кажется, что наиболее простым способом является замена каждого отдельного вызова API в S1, который напрямую обращается к D_Big, с API на соответствующий API в S2, который просто выполняет тот же самый доступ к базе данных, который S1 мог бы выполнить напрямую.Например, представьте, что у нас есть эти API в S1:

• API_1 возвращает столбцы [foo, bar, baz] из table1 в D_Big

• API_2 записывает значение foo в table2 в D_Big

• API_3 возвращает столбцы * из table3 в D_Big

Я бы просто заменил их на:

• API_1 в S1 вызывает соответствующий API в S2, который возвращает столбцы [foo, bar, baz] из table1 в D_Big

• API_2 в S1 вызывает соответствующий API вS2, API_2 которого записывает значение foo в table2 в D_Big

• API_3 в S1, вызывает соответствующий API в S2, который API_3 возвращает столбцы * из table3 в D_Big

Но как насчет случаев, когда идеальное отображение не один в один?Например, когда вам нужно объединить API (например, один API в S1 вызывает два разных API в S2 для получения необходимых данных, или два разных API в S1 вызывают один и тот же API в S2, но с разными параметрами)?

Как сделать хороший интерфейс, отделяющий две службы от того, что раньше было общим источником данных (D_Big)?Предположим, что и S1, и S2 используют систему на основе Java / XML / Spring для передачи данных через вызовы API.

Answer 1

Одна вещь мне не ясна.Будет ли источник данных, к которому обращается одна служба (скажем, S2), создавать несвязанную архитектуру?Разве такие сервисы, как S1 или S3..Sn, не будут связаны с S2 вместо D1_Big, если сам источник данных является общим?Чтобы добиться истинного разделения, источники данных должны быть разделены между собой, что требует тщательного моделирования данных - микросервисы как шаблон помогают иметь более ограниченный контекст, который хорош для развязки.

Микросервисы или нет, я бы подумал вместо этогоналичие отдельной службы S2, предоставляющей операции data , позволяет источнику данных взаимодействовать с отдельной кодовой базой, которая создает библиотеку / интерфейс / jar, которая может быть связана вместе с возможностью развертывания, которая создается для взаимодействующихСервис, такой как S1 и т. Д. Объединение данных jar в S1 может быть обработано в процессе сборки.

Отображение / взаимодействие бизнес-операции с источником данных будет более производительным, чем взаимодействие сервиса вмежду.Уровень может обрабатывать специфические потребности данных в CRUD (простое чтение / запись) или любыми сложными способами (например, представления в реляционной СУБД), которые он считает подходящими, и предоставляет данные, необходимые для бизнес-функций, и сохраняет их независимыми от клиента и по-прежнему остается в качестве масштабируемой опции.

Answer 2

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

CQRS - это превосходный архитектурный шаблон, который будет увеличиваться до необходимого размера.Мне пришлось опустить много важных деталей, чтобы подвести итог здесь.Прежде чем начать рефакторинг, стоит потратить усилия на изучение шаблона.