Возможно, у нас есть такая группа микросервисов: 
Сервис пользователей и Сервис продуктов - это некие сервисы с собственными бизнес-логами c. Сервис шаблонов - это сервис, который отвечает на заполнение некоторых шаблонов в соответствии со сложными логами c (например, шаблоны писем, которые должны быть отправлены пользователю, et c,). Таким образом, он хранит сам шаблон и общую информацию, используемую для всех шаблонов (доступы, стили и многое другое). Итак, это механизм шаблонов, но он не отвечает за содержимое шаблона, который должен заполнять . Например, у нас есть следующий шаблон: HelloWorldTemplate: «Привет, мир! Меня зовут {UserName}». Когда пользовательской службе необходимо отправить электронное письмо, он просит службу шаблонов заполнить эти шаблоны, отправив запрос с указанием типа (HelloWorldTemplate) и параметров шаблона c (UserName). За стили и общие параметры отвечает сервис шаблонов. Извините за такое длинное введение)
Мы разрабатываем некоторые новые функции в службе «Пользователи», и нам нужен новый шаблон BirthdayGreeting из службы шаблонов. Поэтому, когда мы обновляем UserService с v1.1 до v1.2, нам нужно изменить внутреннее состояние другой службы, Templates. А как это сделать - это мой главный вопрос.
Я могу представить несколько способов сделать это, но все они имеют множество недостатков. (Предположим, что все службы имеют SQL базы данных, это упрощает задачу)
1.Мы можем обновить службу шаблонов перед обновлением служб пользователей и добавить миграцию SQL в эту службу, где мы можем просто ВСТАВИТЬ необходимые данные в таблицы.
Плюсы :
- Очень просто реализовать
- Работает)
Минусы :
- Мы должны предоставить доступ к репозиторию службы шаблонов команде, которая разрабатывает службу пользователей (а также они должны знать внутреннюю структуру БД. шаблонов, что плохо), или мы должны создать отдельную задачу для команды, которая разрабатывает службу шаблонов, чтобы добавить новый шаблон.
2. Мы можем получить доступ к базе данных шаблонов из другие службы и фиксируют сценарии миграции БД, например, в репозиторий службы пользователей.
Плюсы:
Минусы:
- У нас должно быть подключение к базе данных шаблонов из нескольких сервисов, чтобы нарушает инкапсуляцию.
- То же, что и для первого варианта.
3.Мы можем добавить конечную точку HTTP, чтобы добавить новый шаблон в службу шаблонов, и служба пользователей должна выполняться один (или несколько) запросов к этой конечной точке во время миграции с v1.1 на v1.2, вместе с выполнением собственных миграций БД.
Плюсы:
- Мы можем поддерживать согласованность данных (шаблоны могут выполнять некоторые проверки этих запросов, чтобы предотвратить недопустимые данные)
- Мы не раскрываем внутреннюю структуру службы шаблонов миру (поэтому мы можем легко переключиться с SQL БД в другой тип БД, например)
- Эти миграции будут храниться в службе «Пользователи», и команда, которая разрабатывает эту службу, напишет и поддержит их, чтобы мы могли сократить межгрупповое взаимодействие и сократить время доставки функции.
Минусы:
- Трудно реализовать.
- Как сохранить и написать этот запрос? Мы можем использовать существующий формат запросов (CURL, запросы Postman и т. Д., Но он может быть намного более подробным, чем простой оператор SQL DML). Также мы можем создать собственный язык определения запросов, используя yaml, json или другой язык разметки, но это похоже на создание собственного колеса;) Трудно поддерживать транзакции (например, если миграция с v1.1 на v1.2 не удалась, трудно откатить изменения)
Итак, я буду очень благодарен за любые советы, полезные ссылки, шаблоны и лучшие практики, предназначенные для решения этой проблемы.