Обмен кодом и схемой между микросервисами

Если вы идете для архитектуры микросервисов в своей организации, они могут совместно использовать конфигурацию через zookeeper или ее эквивалент. Однако каким образом различные службы должны иметь общую схему db? общие константы? и общие утилиты?

Один из способов - разместить все микросервисы в одном хранилище кода, но это будет противоречить развязке, которая поставляется с микросервисами...

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

Еще одним способом было бы реализовать функциональные микросервисы без контекста\состояние, но это обычно не реалистично и подтолкнуло бы архитектуру к центральному концентратору, который поддерживает контекст\состояние и большой трафик от\к нему.

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

Ответ 1

В отношении общего кода лучше всего использовать систему упаковки. Поэтому, если вы используете Java, тогда используйте maven, если вы используете Ruby, то Gems, если python then pypi и т.д. В идеале система упаковки добавляет небольшое трение, поэтому у вас может быть (например, git) репозиторий для общей библиотеки lib (или нескольких общих библиотек для разных тем) и публиковать свои артефакты через репозиторий артефактов (например, private maven/gems/pypi). Затем в микросервисе вы добавляете зависимость от требуемых libs.So повторное использование кода легко. В некоторых случаях системы упаковки добавляют некоторое трение (maven для одного), поэтому можно предпочесть использовать один репозиторий git для всего и многомодульную настройку проекта. Это не так чисто, как первый подход, но работает и не так уж плохо. Другие варианты заключаются в использовании подмодуля git (менее желательно) или git поддерева (лучше), чтобы включить исходный код в один "родительский" репозиторий.

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

Итак, вкратце - общий код (утилиты, константы и т.д.) - используйте систему упаковки или некоторую ссылку на исходный код, например git -tree

База данных - ты не трогаешь меня, я не трогаю тебя. Это лучший способ обойти это.

HTH, Ran.

Ответ 2

"Самый чистый" подход, то есть тот, который дает вам наименьшее количество связей, заключается в том, чтобы не передавать какой-либо код.

Если вы обнаружите, что две службы (назовите их A и B) нуждаются в одинаковой функциональности, ваши варианты:

split, если отключен как отдельная служба C, поэтому A и B могут использовать C
укусить пулю и продублировать код

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

На практике, как обычно, это компромисс.

Если общая функциональность существенна, я бы пошел на отдельную службу.
Если это просто константы, то наилучшим решением может быть использование общей библиотеки. Однако вам нужно быть очень осторожным в отношении обратной совместимости.
Для данных конфигурации вы также можете реализовать определенную службу, возможно, используя некоторые существующие технологии, такие как LDAP.
Наконец, для простого кода, который, вероятно, будет развиваться самостоятельно, лучшим решением может быть просто дублирование.

Однако, что лучше всего будет зависеть от вашей конкретной ситуации и проблемы.

Ответ 3

Из моего опыта проекта

Поделитесь WSDL при использовании SOAP (а не кода модели службы, поскольку они должны быть сгенерированы из WSDL). При использовании REST есть отдельные модели (копия да, но не общий) для клиента и сервера. Как только второй или третий потребитель начнет играть, вы попадете в беду. Держите их развязанными. Эксплуатация и использование сервиса изменились в моем прошлом чаще, чем структуры данных. Другой клиент хочет использовать вашу службу, или вторая версия должна работать одновременно.

Некоторые дополнительные мысли

Совместное использование частично противоречит масштабируемости. Share-nothing и share-some/share-all имеют как плюсы, так и минусы. Совместное использование ничего не дает вам полной гибкости в любое время. Микросервисы являются независимыми компонентами, предоставляющими определенные услуги домена.

Совместное использование моделей данных бизнес-домена является общей схемой (http://www.ivarjacobson.com/resources/resources/books/#object%20oriented%20software), которая предотвращает дублирование одного и того же. Поскольку микросервисы делят и управляют бизнес-частями, может быть сложно поделиться чем-то вроде модели данных бизнес-домена.

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

Ответ 4

Что касается принципа ISP (принцип разделения интерфейса), клиенты должны зависеть от интерфейса, а не реализации. Я бы предположил, что, если возможно, совместное использование интерфейсов не реализуется таким образом, было бы лучше отключить систему от реализации.