Перед тем, как ты смотришь на меня вот так ...

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

Итак, что я имею в виду, когда говорю микрокомпоненты? Я бы описал это как интерфейс, спроектированный таким образом, что более крупное приложение разбито на множество мелких компонентов, которые независимы и не знают о других компонентах в приложении. Если вы занимались разработкой SPA (Angular, React, Vue и т. Д.), Этот шаблон будет казаться знакомым для шаблона взаимодействия компонентов «родитель-потомок».

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

Обзор

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

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

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

Высокий уровень

В моем конкретном примере, который я объясню ниже, используется Vue.js. Однако вы можете сделать то же самое с Angular или React. Vue.js имеет очень простой процесс создания «библиотек», который является основой того, как компоненты для микрокомпонента генерируются и затем используются. Вдобавок к этому было нефункциональное требование использовать Vue.js для нашего конкретного проекта.

Вот как выглядит обычное монолитное приложение.

Есть одно приложение без компонентов, все внутри единой базы кода. А вот и образец микрокомпонентов.

Вы можете видеть выше, что линий намного больше. Фиолетовые линии представляют собой соединение с опубликованным пакетом NPM. Разумеется, реестр NPM должен быть частным, если только вы не хотите, чтобы ваш корпоративный код был доступен для всеобщего обозрения. Мы используем Verdaccio на локальном сервере в качестве нашего частного реестра.

Черные линии обозначают подключение к репозиторию (мы используем Bitbucket).

Здесь есть небольшая оговорка, на которую я хотел бы обратить внимание. Обратите внимание, как черные и пурпурные линии для каждой строки сходятся в одну строку, следовательно, один репозиторий для четырех компонентов и один пакет для четырех компонентов (число четыре произвольно). Мы решили хранить компоненты с одинаковой направленностью в одних и тех же репозиториях и пакетах, потому что знали, что у нас будет около 40 всего компонентов, и было бы сложно управлять 40 репозиториями и 40 пакетами. Позже я объясню, как это работает. В конечном итоге вы можете разбить каждый компонент на отдельный репозиторий и пакет, если вам так больше нравится.

Код

Следующие изображения и код покажут, как все это работает.

Вот структура папок нескольких компонентов в одном репозитории и то, как они экспортируются для использования из пакета.

Слово «вариант» произвольно. Это деловой термин для нашего клиента, но вы можете заменить его на «компонент», потому что это то, чем является каждый вариант. У каждого компонента есть своя собственная папка, в которой он полностью автономен. Он выполняет все свои собственные вызовы API, извлекает все свои собственные переменные среды и предоставляет входные и выходные данные для связи.

В package.json build-option:all-options запускает команду интерфейса командной строки Vue.js для создания библиотеки из всех компонентов, экспортированных из index.js. Затем весь код помещается в папку dist.

Затем мы запускаем npm publish, чтобы загрузить компоненты в наш частный реестр. Оттуда мы можем запустить npm i --save <package-name>, чтобы использовать пакет в нашем приложении, а затем рассматривать его как любой другой пакет NPM.

Это так просто.

Шучу, конечно, есть над чем подумать:

Как вы тестируете каждый компонент?

Я создал «игровые площадки» для тестирования каждого компонента, так что игровая площадка очень похожа на то, как приложение будет использовать компонент. Запуск vue serve запускает компонент на localhost: 8080 для тестирования.

Как вы справляетесь со средой? Пакеты предварительно собраны, поэтому как они переключают переменные среды перед сборкой?

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

Вероятно, у вас есть еще много вопросов, и я буду рад ответить на них в комментариях. Моя контактная информация также внизу.

Заключительные мысли и подводные камни

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

  • Запуск новых сборок без изменения кода приложения работает только в том случае, если ваши пакеты не меняют основные версии (например, 1.2.3 -> 2.0.0). Если вы измените основную версию компонента, вам потребуется обновить версию этого компонента в файле package.json вашего приложения.
  • Существуют процессы развертывания, которые будут различаться в зависимости от вашего продукта CI / CD, однако они должны быть очень похожими для разных продуктов CI / CD. Мы используем Jenkins. Например, чтобы использовать частный реестр npm, вы должны предоставить файл .npmrc в корне сборки. Выполнение этого может зависеть от разных CI / CD.
  • Вы должны быть на 100% посвящены этой архитектуре. Одна нога внутрь, одна нога наружу не подойдет.
  • Я, вероятно, убедил бы вас не использовать эту архитектуру для небольших проектов, поскольку преимущества не преодолевают сложность. Всегда проверяйте, соответствует ли архитектура микрокомпонентов вашему бизнесу и техническим потребностям.

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

Обо мне

Я работаю в Orange Bees, консалтинговой компании по разработке программного обеспечения в Гринвилле, Южная Каролина, в качестве главного инженера. Я пишу приложения Angular и .NET, разрабатываю проекты в Azure (сертифицированный партнером Azure Developer Associate) и занимаюсь ElasticSearch и Node.js.
Вы можете найти меня в LinkedIn.