Действительно ли контейнеры полезны для фронтенд-разработки? Ответ положительный.
Когда я впервые рассказал одноклассникам по фронтенду своей компании о контейнерной технологии «Amway», многие люди сказали: «Контейнеры? Разве это не технология, используемая на бэкенде? нельзя использовать».
Но на самом деле тот «фронтенд», который мы сегодня обсуждаем, уже не является «фронтендом» в традиционном понимании, а проявляется прежде всего в разнообразии типов терминалов, таких как iOS, Android, апплет и т. д. В Кроме того, с появлением таких технологий, как Node.js, границы фронтенд-разработки также постепенно расширяются до серверной части. В эпоху больших интерфейсов каждый успешный интернет-продукт постоянно исследует, как разрабатывать приложения инженерным, сервис-ориентированным и автоматизированным способом для достижения непрерывной бизнес-итерации, высокой доступности и высокой параллелизма, и постепенно становится все более важным. Контейнерная технология значительно повысила эффективность этого процесса.
В этой статье будет объединен практический опыт контейнерной платформы Ma Honeycomb, что позволит создавать клиентские приложения, а также представлены принципы проектирования и реализации всей платформы, некоторые достигнутые результаты и решения по оптимизации проблем.
Место соединения контейнера и переднего конца
Вообще говоря, процесс разработки внешнего интерфейса выглядит следующим образом: создание услуги/проекта → локальная разработка → тестирование среды разработки → тестирование производственной среды → производственные оттенки серого → онлайн.
Преимущество фронтенд-разработки на базе контейнерной платформы заключается в том, что фронтенд и бэкенд полностью разделены, и нам нужно сосредоточиться только на построении фронтенд-проекта, не упаковывая его с кодом бэкенда. Каждая версия сборки и каждое правило доступа также независимы, и сбой сборки одной версии не влияет на сборку и доступ к другим версиям.
Итак, где стык контейнера и передка? Где преимущества контейнеров проявляются при разработке интерфейсных приложений? Мы можем посмотреть на это с трех стадий разработки, тестирования и производства.
Ссылка на разработку
Контейнеры устраняют различия между онлайн- и офлайн-средами и обеспечивают согласованность среды и стандартизацию жизненного цикла приложения. Для фронтенд-разработки задача, которую необходимо выполнить, часто состоит в том, чтобы завершить представление контента и ответить на ввод данных пользователем, обработав статические ресурсы, такие как HTML, JS, CSS и т. д. Файлы отправляются клиенту напрямую без работающей среды. , Контейнеры не используются.
А время сборки? Ведь разные проекты собираются с разными версиями Node, и разные контейнеры могут входить в разные версии Node, чтобы не загрязнять локальную среду Node. Но на самом деле контейнера нет, а фронтенд также может использовать NVM для управления Node-версией, которую очень легко переключать, то есть это можно сделать одной-двумя строчками команд. И локальная разработка очень удобна, кажется, что контейнеры действительно не нужны.
Возможно, сам контейнер не помогает интерфейсу быть более удобным на этапе разработки. Поэтому, если вы не знакомы с технологией контейнеров, нет необходимости использовать контейнеры на этапе разработки.
тестовая сессия
В прошлом распространенным решением, которое мы использовали для тестирования с виртуальными машинами, было то, что передний отдел исследований и разработок загружал свой собственный код в каталог виртуальной машины, а отдел контроля качества мог напрямую проводить тестирование через доменное имя. Но проблема в том, что у компании много продуктовых линеек, и может быть много проектов, которые тестируются одновременно. Виртуальная машина потребляет много системных ресурсов, количество ограничено, и ее сложно расширять, что сказывается на эффективности тестирования.
Эта проблема не возникает, если используется контейнерная платформа. Поскольку контейнер очень легкий, с низким потреблением и быстрым запуском, его можно быстро расширить, не беспокоясь о недостаточном использовании.
Производственные процессы
Еще одно преимущество контейнеров заключается в том, что они позволяют контролировать версии приложений. Например, после выхода в сеть мы обнаруживаем, что существует проблема с версией, которую необходимо откатить.Эта ситуация неизбежна.Традиционный метод – откат через Git или SVN.Как только слитый код хочет откатиться назад или разделить, трудно работать, и передислокация также трудна.Требуется много времени.
На основе контейнерной платформы мы можем напрямую переключать трафик на старую версию через управление потоком, что занимает несколько секунд, а эффективность отката значительно повышается.
Другой пример, важным показателем производительности интерфейса является время загрузки страницы.Если домашняя страница белая, это разрушит пользовательский интерфейс.Особенно при выполнении действий мы направляем почти весь трафик на активную страницу, а белый экран будет очень плохо. После расследования эксплуатации и обслуживания было обнаружено, что сервер завис, что можно было решить только путем перезапуска. Но в перезапуске машины много неуверенности, и возможно, что машина не встанет, что очень часто.
Однако, если он работает на контейнерной платформе, контейнер — это процесс. Если машина выйдет из строя, кластер быстро подтянет службу с другого узла, и это за секунды. В принципе, не нужно беспокоиться о пользователях. проблемы с доступом.
Таким образом, основные преимущества контейнеров по сравнению с виртуальными машинами заключаются в том, что они могут обеспечить быстрое расширение емкости, откат второго уровня и стабильную поддержку активности. Поэтому для фронтенд-разработки важнее контейнеризация, чтобы обеспечить быструю итерацию сервисов и стабильность онлайн-сервисов.
Знания о контейнерах указывают на то, что интерфейс должен знать
Благодаря вышеприведенному вступлению я полагаю, что у всех есть определенные чувства по поводу изменений, которые технология контейнеров привнесла в разработку интерфейса. Таким образом, чтобы лучше применять эту технологию, студенты, работающие с интерфейсом, также должны овладеть некоторыми базовыми знаниями о контейнерах.
что такое контейнер
Во-первых, давайте посмотрим, что такое контейнер и почему он легкий и высокопроизводительный. На следующем рисунке мы можем сделать более интуитивное сравнение между виртуальными машинами и контейнерами:
Виртуальная машина имитирует аппаратную систему, запуская гипервизор поверх физического сервера, чтобы улучшить возможности и мощность сервера. В каждой виртуальной машине есть ядро, на котором работают разные операционные системы, и после запуска оно будет выполнять такие функции, как управление процессами и памятью. Однако для построения фронтенд-приложений может понадобиться только использование Nginx в качестве статического сервера, в этом случае использовать виртуальную машину слишком тяжело.
Причина легкости контейнеров заключается в том, что контейнеры не имеют уровня гипервизора и уровня ядра, и каждый контейнер разделяет ядро и системные вызовы хоста. Таким образом, контейнер содержит только минимальное количество файлов, необходимых для запуска программы.Запуск контейнера означает запуск процесса, который требует меньше ресурсов и его легче поддерживать.
Образы, контейнеры и Docker
Это три слова, которые люди часто упоминают, говоря о контейнерных технологиях.Давайте поговорим об их соответствующих концепциях и связи между ними.
зеркало: это можно просто понимать как набор послойных файловых систем или набор каталогов. Например, для нашего внешнего кода нижний уровень каталога может быть двоичным файлом, необходимым для запуска Nginx, а затем другим уровнем каталога выше является наш код, например index.html. После создания всех слоев этого слоя изображения они доступны только для чтения, и каждый слой файлов не может быть изменен.
контейнер: На самом деле, это добавить еще один каталог к указанному выше каталогу. Но на самом деле это пустой каталог, разница в том, что верхний слой контейнера доступен для чтения и записи, то есть контейнер = изображение + слой чтения-записи.
Например, если я хочу изменить предыдущий index.html, это происходит путем накопления новой версии предыдущего изображения. То есть после создания контейнера все изменения происходят в верхнем слое image-writable, нижние слои не могут записываться в них, но могут накапливаться, как деревья стекирования, а исходные постоянно добавляются.Изображения не изменяются контейнерами, поэтому изображения могут совместно использоваться несколькими контейнерами.
Docker: На самом деле контейнерная технология существует уже давно. Docker — это инструмент, используемый для реализации технологии контейнеризации, а также наиболее распространенный в отрасли способ помочь нам создавать образы, а затем запускать образы в контейнеры и управлять ими. .
Как контейнерные платформы расширяют возможности клиентской части
После введения простых концепций давайте взглянем на общую архитектуру контейнерной платформы Mafengwo, на то, как мы расширяем интерфейс и какие возможности мы предоставляем.
Мы создали контейнерную облачную платформу на основе Docker и Kubernetes, которая абстрагирует возможности создания приложений, развертывания, планирования ресурсов и управления приложениями и предоставляет их персоналу отдела исследований и разработок в качестве услуги для повышения стабильности онлайн-сервисов и эффективности исследований и разработок. На следующем рисунке показан жизненный цикл интерфейсного приложения на контейнерной платформе с точки зрения приложения:
Центр приложений
Приложение является основным операционным объектом контейнерной облачной платформы. Очень большим преимуществом облачной платформы является то, что она защищает типы проектов, независимо от их внешнего или внутреннего интерфейса. Таким образом, под оболочкой приложения, будь то внешний код или внутренний код, вы можете пользоваться одним и тем же сервисом. Например, такие возможности, как ограничение тока, слияние и управление услугами, применяемые к серверной части в традиционном смысле, также могут быть переданы клиентской части, чтобы студенты, изучающие фронтенд, могли сосредоточиться на развитии бизнеса, не обращая внимания на базовая реализация.
Это страница создания в центре приложений. Всего за несколько шагов приложение может быть создано и размещено на нашей облачной платформе:
Управление версиями
После того, как приложение создано, пора приступить к сборке версии. Используя контейнеры, мы упаковываем приложения, конфигурации, зависимости и т. д. в образы кода, а затем сообщаем онлайн-серверу, как заставить их работать в контейнерном режиме. Таким образом, управление версиями включает две части: зеркалирование кода и настройку среды выполнения.
1. Зеркалирование кода
Мы используем Drone на основе Pipeline + Docker в качестве инструмента CI, он очень гибкий и легко расширяемый. Гибкость Drone отражается в конфигурации Pipeline.Процессом построения образов можно управлять в проекте, задав файл .drone.yml.
Чтобы лучше поддерживать приложения корпоративного уровня, мы добавляем в образ некоторые часто используемые пакеты для создания общего базового образа. Во время сборки будут выполняться некоторые CI, такие как модульное тестирование, обнаружение уязвимостей и т. д.
2. Конфигурация во время выполнения
Конфигурация среды выполнения разделена на две части: конфигурация Nginx и конфигурация среды выполнения развертывания.
(1) Конфигурация Nginx
Конфигурация Nginx в основном предназначена для интерфейсных проектов Node. Есть несколько преимуществ предоставления конфигурации Nginx приложениям:
-
Студенты начального уровня могут пройти самиНастроить режим истории, не нужно идти на сервер, чтобы сотрудничать.
-
Настроить несколько местоположенийн. В случае многостраничных приложений вы можете настроить Nginx для пересылки запроса в указанный файл записи для достижения указанного маршрута.
-
Стратегия кеширования пользовательского кэша. Выбор стратегий кэширования стал более гибким, что улучшает взаимодействие с пользователем и снижает нагрузку на сервер при обработке запросов.
(2) Разверните текущую конфигурацию
Конфигурация запуска развертывания сообщает системной платформе, как запускать пакет выпуска. На самом деле существуют расширения для последующего развертывания на различных платформах, таких как KVM-хосты Kubernetes.
Таким образом, в части управления версиями мы достигли следующих возможностей:
-
Конфигурационный файл, несколько копий одного приложения являются гибкими и расширяемыми
-
Конфигурация Nginx и т. д. открыты для приложений, следуют идеям DevOps и обеспечивают эффективное расширение возможностей.
-
Продукты со стандартизированными версиями: создайте один раз, работайте везде
Управление развертыванием
Далее нам нужно развернуть пакет собранной версии в кластере для запуска.
В сети может быть много машин, V1, V2, V3 относятся к различным версиям. Эта версия может иметь несколько экземпляров. В случае сбоя сервиса мы в основном обеспечиваем стабильную и высокую активность двумя способами:
-
Эффективное планирование: Запланируйте запуск указанного контейнера на наиболее подходящий узел, отвечающий требованиям к ресурсам, и наиболее подходящий узел с помощью планировщика Kubernetes.
-
Поддержка нескольких копий: автоматическое развертывание нескольких копий приложения-контейнера и их постоянный мониторинг. Автоматически запускать реплики, если контейнер умирает
В сочетании с упомянутым ранее примером белой домашней страницы мы продолжим мониторинг контейнера на контейнерной платформе, и если сервис зависнет, он будет быстро запущен на других узлах. Здесь следует отметить, что "множественность копий" не означает, что она называется множественной копией, если она запущена на двух машинах.Если обе машины находятся в одном шкафу, или даже в одном машинном зале, то бессмысленно запускать несколько копий.
На данный момент мы развернули сервис онлайн и добились стабильной работы. Но завершение развертывания не означает, что пользователи могут получить доступ, а также не означает, что они могут получить доступ к правильной версии, поэтому следующим шагом является управление услугами.
Служба управления
Управление службами — относительно обширная концепция, которая может применяться во многих сценариях. Одним из его элементов является предоставление пользователям доступа к указанной онлайн-версии.
Технические решения
Во-первых, вводится принцип реализации:
Мы используем шлюз, поддерживающий протокол xds. Когда новая конфигурация передается на шлюз через протокол xds, она автоматически обновляется в горячем режиме, перезагружается в горячем режиме, а затем адаптируется к новой конфигурации. Например, начальный шлюз указывает на версию V1. Если теперь мы хотим указать на версию V2, нам нужно только отправить последнюю конфигурацию на шлюз через протокол xds, и он применит новую конфигурацию. Таким образом , указанная версия может быть развернута в сети.
Push Здесь мы используем компонент Pilot, оптимизированный для скорости push. Компонент Pilot будет постоянно отслеживать данные и извлекать их при обнаружении изменений.
Сценарии применения
Для этого дизайна мы в основном применяем его в трех сценариях: откат, шунт и ABTest.
1. Откат
Так называемый откат — это фактически управление потоком, например, шлюз в начале указывает на версию V2:
Если я обнаружу проблему, мне просто нужно отправить новую конфигурацию на шлюз, и она может очень быстро указать на предыдущую версию:
2. Диверсия
Диверсия в основном используется в тестовых сценариях, упомянутых в начале статьи. В прошлом использовались виртуальные машины.Поскольку разные виртуальные машины имеют разные доменные имена, студенты, работающие с интерфейсом, либо модифицируют код, чтобы адаптироваться к виртуальной машине во время тестирования, либо им нужно протестировать студентов или студентов, изучающих продукт, для изменения своего собственного хоста. неудобно.
Используя контейнерный метод, например, версия V2 теперь доступна по умолчанию, но теперь нам нужно протестировать версию V1 или V3, мы можем запустить конфигурацию шлюза и сказать ему, что если cookie в запросе содержит идентификатор V=V1, затем перенаправьте запрос на версию V1; также, если файл cookie содержит V=V3, перенаправьте запрос на версию V3, вся переадресация выполняется на уровне шлюза.
Чтобы упростить использование сервиса, мы предоставляем плагин для автоматической идентификации сервиса и версии, развернутой на облачной платформе. Когда тестируют QA и студенты, изучающие продукт, им нужно только выбрать версию, и система автоматически завершит внедрение файлов cookie. Затем при отправке запроса на сервер шлюз обнаружит, что этот файл cookie содержит определенную версию, и автоматически завершит переадресацию:
3. ABTest
По тому же принципу мы можем контролировать пользователя для доступа к различным версиям в ABTest, настроив UID указанного пользователя.Здесь поддерживается множество способов, таких как внедрение файлов cookie, разные заголовки, разные методы запроса и т. д., которые очень гибкий.
Вышеизложенное является содержанием управления услугами. В целом, мы можем автоматизировать развертывание правил доступа, для этого может потребоваться, чтобы фронтенд-студенты выполнили операцию git-push tag, а версия была подготовлена и развернута в среде разработки или даже в производственной среде, и в целом процесс очень важен для пользователей платформы, говорят, что он незаметен:
-
Автоматическое развертывание правил доступа, полная CI/CD
-
Гибкая стратегия шунтирования, обеспечивающая откат второго уровня, оттенки серого, абтест и другие функции.
-
В сочетании с плагином для хрома работа становится гладкой.
Выше описано, какие возможности мы можем предоставить интерфейсу на основе контейнерной облачной платформы. После некоторого времени исследования наш процесс прошел относительно гладко, но неизбежно будут некоторые проблемы.
404 мы встретили в те годы
1. После выхода в интернет обнаруживается, что js обращается к 404
Эта ситуация очень плоха для пользовательского опыта. После расследования мы обнаружили, что проблема заключалась в том, что для достижения высокой доступности наши шлюзы были настроены с несколькими.
Так как конфигурация переадресации шлюза доставляется принудительно, между несколькими шлюзами будет разница во времени. Некоторые шлюзы получают новые push-уведомления первыми, а другие — позже. Когда запрос пользователя достигает одного из шлюзов и получает html, он сообщит ему, к какому хэшу js он должен получить доступ. Но если, к сожалению, хешированный js обращается к другому шлюзу, а затем пробрасывает его на другую версию, то есть другой контейнер, то значение хеш-функции должно быть другим, и соответствующий файл не может быть найден, что приводит к 404.
Эта проблема существует не только в облачных платформах, но и в решениях для распределенного развертывания. Наше решение состоит в том, чтобы все шлюзы были подключены к одному и тому же пилоту. Поскольку количество шлюзов ограничено, в настоящее время компонент отвечает за отправку всех шлюзов для доставки конфигурации.Поскольку сам протокол xds реализован на основе GRPC, это длительная операция подключения, поэтому скорость очень высокая. При нажатии узлом разница во времени между всеми шлюзами, получающими конфигурацию, может контролироваться в пределах миллисекунд, что практически не оказывает влияния. То есть, когда шлюз A получает новую конфигурацию, по сути, новую конфигурацию получает и шлюз B. В это время все запросы будут указывать на одну и ту же версию независимо от того, на какой шлюз они отправлены. На линии 404. спрашивайте.
2. Среда в градациях серого, js-доступ 404
Как упоминалось ранее, наше решение в оттенках серого заключается в использовании подключаемых модулей для создания файлов cookie.Теоретически, если файл cookie настроен правильно, его можно перенаправить на указанную версию. Итак, поскольку мой html больше не проблема, почему js все еще отображается 404?
После расследования было обнаружено, что, поскольку при использовании запроса js используется тег под названием «анонимный тег», если мы используем анонимный тег при использовании js, браузер не будет нести никакой идентификации личности при отправке запроса js, и шлюз будет Считается, что обращение к версии по умолчанию, то есть к онлайн-версии, в это время, если запрос идет к версии V2, будет 404.
краткосрочное планирование
1. Максимально освободите конвейер сборки
В настоящее время мы собираем образы в основном с помощью команд npm install и npm run build Two. После этого мы максимально выпустим Pipeline, включая базовый образ, версию Node и т. д., чтобы студенты, работающие с интерфейсом, могли выполнять более индивидуальные требования.
2. Оптимизируйте время сборки и развертывания
Наше текущее решение для создания образов плохо использует механизм кэширования Docker, поэтому это повлияет на время сборки. В настоящее время мы также занимаемся оптимизацией, чтобы максимально сократить или даже исключить большую часть времени установки и сборки npm.
3. Отпустите возможности мониторинга и сигнализации
В настоящее время мы завершили создание части возможностей мониторинга и оповещения, которые в основном используются командой обслуживания платформы для контроля состояния QPS, стабильной работы службы, наличия перезапуска и т. д. Команда также получать много сигналов тревоги. Тем не менее, мы считаем, что этот вид тревоги должен быть отправлен ответственному за службу, позже мы будем постепенно выпускать эту часть возможности и продолжать улучшать и оптимизировать правила тревоги.
Суммировать
Краткое содержание в конце:
Что именно контейнеризация расширяет возможности интерфейса?
-
Повышение эффективности тестирования
-
Более стабильное обслуживание и эффективная эксплуатация и техническое обслуживание
Как облачная платформа Mafengwo расширяет возможности внешнего интерфейса?
-
Центр приложений: перейдите к облаку за один шаг, наслаждайтесь услугами, предоставляемыми облачной платформой, без каких-либо различий
-
Управление версиями: применяйте идеи DevOps, расширяйте возможности конфигурации Nginx; управление на основе конфигурации, гибкость и простота расширения
-
Управление развертыванием: интеллектуальное планирование, стабильная и высокая активность
-
Управление услугами: откат второго уровня, восстановление второго уровня, доступ в оттенках серого, ABTest и многие другие функции.
В настоящее время у нас есть некоторые исследования того, как помочь интерфейсу завершить разработку приложений с помощью контейнеризации и дальнейшего расширения возможностей с помощью облачной платформы, надеясь вдохновить вас на техническое мышление.
Автор этой статьи: Чжоу Лэй, инженер по исследованиям и разработкам базовой платформы Mafengwo Travel Network.
(Заглавная картинка взята из интернета)