Как управлять общими компонентами интерфейса на микросервисах

Question

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

Позвольте мне устранить проблему. У нас более 5 групп людей, работающих на разных микросервисах в большом одном проекте. И почти у всех из них есть общие, общие компоненты на frontend. И эти компоненты огромны, поскольку они уже представляют собой другой проект, но полностью разделены. Теперь, как управлять этими разделяемыми компонентами или мы должны их дублировать?

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

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

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

Как мы можем сбалансировать это или можем ли мы?

Благодаря @kayess: Вскоре, как применить совместное ядро ​​на микросервисах, поскольку команды не будут зависимы друг от друга?

Answer 1

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

Я считаю, что ваше понимание microservice неправильно. Определение Фаулера из microservice:

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

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

Вы должны управлять своими компонентами в отдельном репозитории каждый. Используйте semantic versioning, чтобы публиковать обновления и следить за нарушениями совместимости.

И очень сложно поддерживать, так как в будущем различные группы могут различные потребности от компонента.

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

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

Answer 2

Мы столкнулись с той же проблемой, но не только с компонентами переднего плана.

Итак, мы создали простую систему управления компонентами под названием «Бит». Мы выпустили его на GitHub:

https://github.com/teambit/bit

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

Приглашаем вас попробовать. Вы также можете свободно подключаться к бесплатному community hub, чтобы разместить ваши компоненты с открытым исходным кодом или найти и поделиться с вашей командой/сообществом. Вот пример многоразового компонента с лицензией MIT и 2 прошедших теста под названием array/diff.

Удачи вам!