Прежде всего, я хотел бы сказать, что здесь нет правильного пути, и я высказываю свою точку зрения на то, как мы уже сделали вещи, надеясь, что это поможет вам найти решение, наиболее подходящее для ваших требований. .
Итак, чтобы понять вашу дилемму, у вас есть базовый продукт vanilla, который представляет собой API SAAS, и для некоторых клиентов также существует индивидуальное развертывание. Но так как вам приходится создавать пользовательские развертывания для каждого клиента, вы замечаете общий шаблон, в котором большая часть функций повторяется в SAAS для каждого клиента.
Теперь, если у меня есть правильное требование, я бы Скажем, микроуслуги обеспечат в вашем случае определенные преимущества с точки зрения масштабирования и пользовательской настройки c, которой будут управлять независимые группы.
Но многое зависит от того, как структурирована логика вашего бизнеса c и насколько велика и обширна ваша настройка. Вот некоторые из этих вопросов, которыми должно руководствоваться ваше решение.
- Можете ли вы хранить данные, определенные клиентом c, в центральном хранилище данных или на стороне клиента? & Как будут структурированы ваши базы данных и сколько их будет?
- Насколько велики настройки? Являются ли они Cosmeti c или придерживаются рабочего процесса?
- Сколько перекрестной связи вы ожидаете между различными сервисами, такими как Пользователь, Магазин и Проект, и если есть какая-либо связь через A.User - B.User или A. Проект - B.Store, et c?
Теперь перейдем к некоторым важным вещам, которые вы могли бы рассмотреть после ответа на вышеуказанные вопросы.
Замечание 1 . Если хранилища данных могут находиться в одном центральном месте, вы можете go опередить один кластер, в котором могут быть развернуты все ваши микроуслуги. Но, глядя на предоставленные данные, я могу предположить, что у вас есть несколько баз данных на клиента, и я бы рекомендовал хранить их отдельно и не вводить никакой связи между ними. Таким образом, вы можете получить один микросервис или микросервис для каждого клиента, который взаимодействует только с базой данных этого клиента. (подробнее на рис.1)
Замечание 2. Насколько мне известно, настройка должна быть отделена от самой службы, и каждая ваша служба должна иметь вход для загрузки конфигурации, который будет управлять служебным поведением. Опять же, в зависимости от того, насколько велика ваша настройка, может быть ограничение этой конфигурации, и в этих случаях я рекомендую создать новый сервис со встроенными настройками.
Рассмотрение 3. Это является основным фактором для определения количества микросервисов, которые у вас могут быть, но граница каждого сервиса должна определяться доменом, например, сервисом пользователя, Служба магазина и Служба проекта. Это ванильные сервисы, которые взаимодействуют друг с другом для создания правильного бизнес-сценария. И каждый из клиентов - это только специализированные экземпляры этих услуг.
ok Теперь, когда это сделано, давайте замаскируем ваши основные вопросы ...
Микросервисы Des могут быть повторно использовать в разных проектах? - Да, вы можете, но опять же, это зависит от того, как вы спроектировали рабочий процесс, внедрение конфигурации.
Если мы делаем разделение, создаем ли мы микросервис, который используют все или мы создать экземпляр для пользовательской сборки? - Да, это был бы идеальный сценарий, позволяющий разделить проблемы между проектами, поскольку мы не хотим смешивать границы данных и специфичные для клиента конфигурации c. Тем не менее, может быть случай, когда единственное микросервисное решение - это то, что требуется, но должно быть сделано с осторожностью.
Если мы создадим экземпляр каждого микросервиса для пользовательской сборки, не будет слишком сложно управлять связью между всеми микросервисами в рамках одной и той же пользовательской сборки? - Связь через микросервис является важной частью или фактором, который в большинстве случаев неизбежен. Таким образом, учитывая, что вам потребуется некоторая форма межсервисного взаимодействия, вы можете посмотреть на корпоративную шину или API-интерфейс на основе ваших требований. Но, по моему мнению, это известная мелочь.
Или мы придерживаемся одного экземпляра на микросервис, который используют все, и мы указываем источник проекта? - Я бы не рекомендовал это, поскольку приведенный в вашем вопросе пример модуля для инъекций базы данных не кажется мне хорошей идеей. Это приведет к созданию высокосвязанной системы. И это также может означать, что если один из сервисов не будет работать на всех ваших клиентских сайтах go. Вы, конечно, не захотите этого !!!
Теперь, как говорится, картинка стоит тысячи слов ...
