Действительно ли контейнеры полезны для интерфейсной разработки? Ответ-да.
Когда я впервые рассказал передовым одноклассникам Amway о контейнерных технологиях, многие люди сказали бы: “Контейнер? Разве это не базовая технология? Я не понимаю, и интерфейсная разработка не может быть использована. “
Но на самом деле “интерфейс”, который мы обсуждаем сегодня, больше не является “интерфейсом” в традиционном смысле. Во-первых, это отражает разнообразие типов терминалов, таких как iOS, Android, небольшие программы и т.д. Кроме того, с подъемом узла. JS и другие технологии, границы интерфейсной разработки постепенно расширяются в сторону обслуживания. В эпоху большого переднего плана, как разрабатывать приложения в области проектирования, обслуживания и автоматизации для достижения непрерывной итерации, высокой доступности и высокой параллельности бизнеса, является постоянным исследованием каждого успешного интернет-продукта, и постепенно зрелая контейнерная технология значительно повышает эффективность этого процесса.
В этой статье будет представлен принцип проектирования и реализации всей платформы, некоторые полученные результаты и схема оптимизации задачи, основанная на практическом опыте построения приложения Сотовой контейнерной платформы, позволяющей использовать интерфейс.
Точка соединения контейнера и переднего конца
Вообще говоря, процесс разработки переднего плана заключается в следующем: создание сервисов/проектов локальная разработка тестирование среды разработки тестирование производственной среды производство в сером масштабе онлайн.
Преимущество интерфейсной разработки на основе контейнерной платформы заключается в том, что интерфейс и серверная часть полностью разделены. Нам нужно сосредоточиться только на создании интерфейсного проекта, а не на упаковке с внутренним кодом. Каждая версия сборки и каждое правило доступа также независимы, и сбой одной сборки не влияет на построение и доступ к другим версиям.
Итак, где находится соединение между контейнером и передней частью? Какова роль преимуществ контейнеров в разработке интерфейсных приложений? Мы можем видеть это на трех этапах разработки, тестирования и производства.
Ссылка на Разработку
Контейнеры устраняют экологические различия между онлайн и оффлайн и обеспечивают стандартизацию экологической согласованности в жизненном цикле приложения. Для интерфейсной разработки задача часто состоит в том, чтобы завершить презентацию контента и реагировать на вводимые пользователем данные. Он имеет дело с HTML, JS, CSS и другими статическими ресурсами. Файлы отправляются непосредственно клиенту без рабочей среды. Похоже, здесь нет контейнера.
А как насчет сборки? В конце концов, разные проекты создаются с разными версиями узлов, и разные контейнеры могут вводить разные версии узлов, чтобы не загрязнять среду локального узла. Но на самом деле контейнера нет, интерфейс также может использовать NVM для управления версией узла, переключение очень произвольное, то есть можно выполнить одну или две строки команды. И локальная разработка очень удобна, кажется действительно ненужным использовать контейнеры.
Можно сказать, что сам контейнер не помогает интерфейсу стать более удобным на этапе разработки. Поэтому, если вы не знакомы с контейнерной технологией, нет необходимости использовать контейнер на стадии разработки.
Ссылка для тестирования
В прошлом распространенным решением для тестирования с виртуальными машинами было то, что интерфейсные исследования и разработки загружали свой код в каталог виртуальных машин, и контроль качества можно было тестировать непосредственно через доменные имена. Но проблема в том, что у компании много продуктовых линеек, и может быть много проектов, которые нужно протестировать одновременно. Виртуальные машины потребляют большое количество системных ресурсов и их трудно расширить, что влияет на эффективность тестирования.
Если вы используете контейнерную платформу, такой проблемы не возникнет. Поскольку контейнер очень легкий, низкое потребление, быстрый запуск, может быстро расширяться, не беспокойтесь о проблеме недостаточного использования.
Производственное Звено
Еще одним преимуществом контейнеров является то, что они позволяют управлять версиями приложений. Например, мы обнаруживаем, что версия имеет проблемы и нуждается в откате. Это неизбежно. Традиционный способ-откат через Git или SVN. Как только входящий код хочет быть откатан или разделен, им трудно управлять, а повторное использование занимает много времени.
Основываясь на контейнерной платформе, мы можем сократить поток до старой версии непосредственно с помощью управления потоком. Это занимает несколько секунд, и эффективность отката значительно повышается.
Опять же, важным показателем производительности интерфейса является время загрузки страницы. Если на главной странице появится белый экран, это очень сильно испортит пользовательский интерфейс. Особенно когда мы выполняем какие-либо действия, мы направляем почти весь трафик на активную страницу. Будет очень неприятно, если появится белый экран. После проверки работы и технического обслуживания мы обнаружили, что произошел сбой сервера, который можно решить только перезапуском. Но при перезапуске машины существует много неопределенностей. Очень часто машина не запускается.
Но если контейнер работает на контейнерной платформе, это процесс. Если машина выходит из строя, кластер быстро вызовет службу с другого узла, и это второй уровень. Нет необходимости беспокоиться о проблемах с доступом пользователя.
Таким образом, основные преимущества контейнера по сравнению с виртуальной машиной заключаются в том, что он может обеспечить быстрое расширение, второй откат и стабильное обслуживание. Поэтому для интерфейсной разработки контейнеризация более важна для обеспечения быстрой итерации сервисов и стабильности онлайн-сервисов.
Точки знаний о контейнерах Должны быть известны на переднем конце
Благодаря приведенному выше введению я полагаю, что у вас есть некоторые представления об изменениях, которые контейнерная технология внесла в разработку интерфейсов. Поэтому, чтобы лучше применять эту технологию, студенты-интерфейсники также должны овладеть некоторыми базовыми знаниями о контейнерах.
Что такое контейнер?
Во-первых, давайте посмотрим, что такое контейнер и почему он легкий и высокопроизводительный. На следующем рисунке мы можем провести более интуитивное сравнение виртуальных машин и контейнеров:
Виртуальная машина улучшает возможности и пропускную способность сервера за счет запуска аппаратной системы моделирования гипервизора на верхнем уровне физического сервера. Каждая виртуальная машина имеет ядро, которое работает под управлением другой операционной системы и выполняет управление процессами, управление памятью и так далее после загрузки. Но для создания интерфейсных приложений может потребоваться только Nginx в качестве статического сервера, что слишком сложно для использования виртуальных машин в этом сценарии.
Контейнеры имеют малый вес, поскольку в них нет уровней гипервизора и ядра, и каждый контейнер совместно использует ядро хоста и системные вызовы. Таким образом, контейнер содержит только минимальные файлы, необходимые для запуска программы. Запуск контейнера означает запуск процесса, который требует меньших затрат ресурсов и более простого обслуживания.
Зеркала, контейнеры и докеры
Это три слова, которые вы часто упоминаете, когда говорите о контейнерных технологиях. Вот их соответствующие концепции и ссылки.
изображение Его можно просто понимать как набор многоуровневых файловых систем или набор каталогов. Например, для нашего интерфейсного кода нижний каталог может быть двоичным файлом, необходимым для запуска Nginx, а затем добавить в него слой каталога-это наш код, например индекс. HTML. Эта иерархия изображений доступна только для чтения после создания всех слоев, и каждый слой файла не может быть изменен.
контейнер На самом деле он предназначен для добавления слоя каталога в указанный выше каталог. Но на самом деле это пустой каталог, разница в том, что верхний слой контейнера доступен для чтения и записи, то есть уровень + чтение и запись.
Например, если я хочу изменить предыдущий индекс. html, я добавляю новую версию к предыдущему изображению. То есть, после создания контейнера все изменения происходят в верхнем слое зеркального слоя, доступного для записи, который не разрешается записывать в нижнем слое, но может накапливаться, как стопка блоков, всегда добавляемых, и исходное зеркало не будет изменено контейнером, что также является причиной того, что зеркало может использоваться совместно несколькими контейнерами.
Докер Контейнерная технология существует уже давно. Docker-это инструмент для реализации контейнерной технологии. Это также самый распространенный способ в отрасли помочь нам создавать зеркала, а затем помещать их в контейнеры и управлять ими.
Как включить переднюю часть контейнерной платформы
После представления простых концепций мы рассмотрим общую архитектуру контейнерной платформы Honeycomb, как мы можем расширить возможности интерфейса и какие возможности мы можем расширить.
Мы создаем контейнерную облачную платформу на основе Docker и Kubernetes. Мы обобщаем возможности разработки приложений, развертывания, планирования ресурсов, управления приложениями и предоставляем услуги научно-исследовательскому персоналу для повышения стабильности и эффективности онлайн-сервисов. На следующем рисунке показан жизненный цикл интерфейсных приложений на контейнерных платформах с точки зрения приложений:
Центр приложений
Приложение является основным объектом работы контейнерной облачной платформы. Одним из больших преимуществ облачных платформ является то, что они защищают типы проектов, независимо от интерфейса или бэкенда. Таким образом, в оболочке приложения, будь то внешний код или внутренний код, вы можете пользоваться одной и той же услугой. Например, в традиционном смысле способность к ограничению тока, объединению и управлению услугами в бэк-энде может быть передана переднему концу, чтобы студенты переднего плана сосредоточились на развитии бизнеса, не обращая внимания на реализацию нижней части.
Это страница создания центра приложений. Для создания и размещения приложения на нашей облачной платформе требуется всего несколько шагов.
управление версиями
После того, как вы создали приложение, вам нужно начать создание версии. Используя контейнеры, мы упаковываем приложения, конфигурации, зависимости и так далее в зеркала кода, а затем сообщаем онлайн-серверам, как заставить их работать в контейнерах. Таким образом, управление версиями включает в себя зеркальное отображение кода и настройку среды выполнения.
1. Кодовое зеркало
Мы используем Drone на основе Pipeline + Docker в качестве инструмента CI, который очень гибок и прост в расширении. Гибкость дрона воплощена в конфигурации трубопровода, который может управлять процессом создания зеркал в проекте путем настройки. трутень. Файлы YML.
Чтобы лучше поддерживать приложения на уровне компании, мы вводим некоторые часто используемые внутренние пакеты в образ для создания общего базового образа. В то же время будут созданы некоторые CI, такие как модульное тестирование, обнаружение уязвимостей и так далее.
2. Конфигурация среды выполнения
Конфигурация среды выполнения разделена на две части: конфигурация Nginx и конфигурация среды выполнения развертывания.
(1) Конфигурация Nginx
Конфигурация Nginx предназначена в основном для интерфейсного проекта узла. Открытие конфигураций Nginx для приложений имеет ряд преимуществ:
- Студенты первого курса могут пойти сами. Настройка режима истории Нет необходимости заходить на сервер для сотрудничества.
- Настройка нескольких местоположений N. В случае многостраничных приложений запрос может быть перенаправлен в указанный файл ввода путем настройки Nginx для достижения указанной маршрутизации.
- Пользовательская политика кэширования кэша . Выбор стратегии кэширования является более гибким, улучшает пользовательский интерфейс и снижает нагрузку на обработку запросов сервером.
(2) Конфигурация развертывания и эксплуатации
Конфигурация среды выполнения развертывания должна указывать системной платформе, как запускать пакеты версий. Фактически, существуют расширения для последующего развертывания на хостах Kubernetes KVM и других платформах.
Таким образом, мы достигли следующих возможностей в управлении версиями:
- Драйвер конфигурационного файла, гибкий и масштабируемый для нескольких приложений
- Конфигурация Nginx и другие открытые приложения, следуйте идее DevOps, эффективно позволяя
- Продукты стандартизированной версии, одна сборка, работают везде
Управление развертыванием
Затем нам нужно развернуть встроенные пакеты версий в кластере для запуска.
В сети может быть много машин, V1, V2 и V3 относятся к различным версиям. Эта версия может иметь несколько экземпляров. В случае сбоя службы есть два основных способа обеспечить стабильность и высокую активность:
- Эффективное планирование Планирование назначенных запущенных контейнеров на наиболее подходящий узел с необходимыми ресурсами с помощью планировщика Kubernetes
- Поддержка нескольких копий Автоматическое развертывание нескольких копий контейнерного приложения и непрерывный мониторинг его. Если контейнер зависает, копия автоматического запуска
В сочетании с примером белой страницы домашней страницы, о которой мы упоминали ранее, мы продолжим наблюдать за контейнером на контейнерной платформе, и если служба зависнет, она быстро запустится на других узлах. Здесь следует отметить, что “несколько копий” – это не просто запуск нескольких копий на двух машинах. Если обе машины находятся в одном шкафу или даже в компьютерном зале, бессмысленно запускать несколько копий.
На данный момент мы развернули сервис в режиме онлайн и добились стабильной работы. Однако завершение развертывания не означает, что пользователи могут получить доступ, а также не означает, что они могут получить доступ к правильной версии, поэтому следующим шагом является ссылка на управление службами.
Управление услугами
Управление услугами-это относительно обширная концепция, которая может применяться во многих сценариях. Одним из его содержимого является предоставление пользователям доступа к указанной онлайн-версии.
Техническая схема
Во-первых, вводится принцип реализации.
Мы используем шлюз, поддерживающий протокол XDS. Когда новая конфигурация передается шлюзу по протоколу XDS, она автоматически обновляется, перезапускается и адаптируется к новой конфигурации. Например, шлюз начинается с версии V1. Если мы хотим указать версию V2 сейчас, нам просто нужно отправить последнюю конфигурацию на шлюз через протокол XDS, и он применит новую конфигурацию. Таким образом, мы можем развернуть указанную версию в Интернете.
Нажмите здесь мы используем пилотный компонент и оптимизируем скорость нажатия. Пилотные компоненты постоянно прослушивают данные и извлекают их при обнаружении изменений.
Сценарии применения
Для этой конструкции мы в основном применяем ее в трех сценариях: откат, шунтирование и тест B.
1. Откат
Так называемый откат на самом деле является управлением потоком, таким как шлюз, указывающий на версию V2 в начале:
Если я обнаружу проблему, мне просто нужно очень быстро отправить новую конфигурацию на шлюз, которая может указывать на предыдущую версию:
2. Отвлекающий маневр
Отвлечение в основном используется в сценариях, упомянутых в начале этой статьи. В прошлом при использовании виртуальных машин, поскольку разные виртуальные машины имеют разные доменные имена, студенты-интерфейсники в тесте должны либо адаптироваться к виртуальной машине для изменения кода, либо им нужно тестировать студентов или студентов продукта для изменения собственного хоста, что очень неудобно.
Используя контейнеризацию, например, доступ по умолчанию-версия V2, но теперь нам нужно протестировать версию V1 или V3, мы можем запустить конфигурацию для шлюза и сообщить ему, чтобы он перенаправил запрос на версию V1, если файл cookie в запросе содержит идентификатор; аналогично, если файл cookie содержит, пожалуйста, запросите пересылку на V3, вся пересылка завершена на уровне шлюза.
Чтобы упростить использование сервисов, мы предоставляем плагин для автоматической идентификации сервисов и версий, развернутых на облачных платформах. Студентам, изучающим вопросы качества и продукты, нужно только выбрать версию при тестировании, и система автоматически завершит ввод файлов cookie. Когда запрос отправляется на сервер, шлюз обнаружит, что файл cookie содержит версию файла cookie, и автоматически завершит пересылку:
3. ABTest
Таким же образом мы можем настроить UID указанного пользователя для управления доступом пользователя к различным версиям теста. Существует множество способов поддержки этого, таких как ввод файлов cookie, разных заголовков, разных запросов и так далее. Он очень гибкий.
Таково содержание управления услугами. Вообще говоря, мы можем автоматически развертывать правила доступа. Возможно, нам нужны только интерфейсные студенты для выполнения операции с тегами git-push, и мы уже создали версию и развернули ее в среде разработки или даже в производственной среде. Весь процесс нечувствителен к пользователям платформы.
- Правила доступа к автоматическому развертыванию, полный CI/CD
- Гибкая стратегия шунтирования, обеспечивает второй откат, уровень серого, abtest и другие функции
- Плавно работайте с подключаемыми модулями chrome
Выше описано, какие возможности мы можем предоставить интерфейсу на основе контейнерной облачной платформы. После некоторого времени исследований наш процесс прошел относительно гладко, но неизбежно возникнут некоторые проблемы.
404 мы встречались в те годы
1. В режиме онлайн был найден JS – доступ 404
Эта ситуация очень плохо сказывается на пользовательском опыте. После расследования мы обнаружили, что проблема возникла из-за того, что для достижения высокой доступности наша конфигурация шлюза является более чем одной.
Поскольку конфигурация пересылки шлюза отключена, перед несколькими шлюзами возникнет задержка по времени. Некоторые шлюзы сначала получают новый толчок, другие-позже. Когда запрос пользователя попадает в один из шлюзов и получает 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 для создания образов. После этого мы выпустим как можно больше конвейеров, включая базовое зеркало, версию узла и так далее, чтобы студенты-интерфейсники могли выполнять более индивидуальные потребности.
2. Оптимизация времени сборки и развертывания
В настоящее время наша схема построения зеркал не позволяет эффективно использовать механизм кэширования Docker, поэтому это повлияет на время создания. Мы также оптимизируем, чтобы минимизировать или даже исключить большую часть времени установки и сборки NPM.
3. Освободите возможность мониторинга и предупреждения
В настоящее время мы завершили часть создания возможностей мониторинга и сигнализации, в основном используемой командой обслуживания платформы, для мониторинга состояния QPS, стабильности обслуживания, перезапуска и т.д. Команда будет получать много сигналов тревоги. Но мы считаем, что такого рода сигнал тревоги на самом деле должен быть отправлен лицу, ответственному за обслуживание. Позже мы должны постепенно высвободить эту часть способности и постоянно улучшать и оптимизировать правила сигнализации.
резюме
Наконец, приводится краткое резюме.
Что на самом деле дает контейнеризация переднему концу?
- Повышение Эффективности Тестирования
- Более стабильное обслуживание, эффективная эксплуатация и техническое обслуживание
Как облачная платформа Honeycomb может еще больше расширить возможности интерфейса?
- Центр приложений: Переходите в облако шаг за шагом и без разбора наслаждайтесь услугами, предоставляемыми облачной платформой
- Управление Версиями: Практикуйте Разработку DevOps, Включите Конфигурацию Nginx, Драйвер Конфигурации, Гибкое Расширение
- Управление развертыванием: Интеллектуальное планирование, Стабильная и высокая активность
- Управление услугами: второй откат, второе восстановление, серый доступ, ABTest и многие другие функции
В настоящее время у нас есть определенное исследование о том, как помочь исследованиям и разработке интерфейсных приложений контейнерным способом и расширить возможности с помощью облачной платформы, надеясь вдохновить вас на технологическое мышление.
Эта статья Человек: Чжоу Лэй Инженер по исследованиям и разработкам базовой платформы сети путешествий Horse honeycomb.
(Карты вопросов взяты из Интернета)
Сосредоточьтесь на технологии Honeycomb и найдите Больше Того, что Вам нужно