Как я перешел от монолитного стиля разработки к использованию микросервисов

Как я перешел от монолитного стиля разработки к использованию микросервисов

Переход от монолитного стека Wordpress к архитектуре микросервисов с Nuxt, Vuetify и WP API.

После долгой разработки веб-сайтов с CMS с открытым исходным кодом и под влиянием последних событий в мире JavaScript я решил обновить свой рабочий процесс разработки и производственный стек. Я начну с описания производственного стека, который я использовал, и перейду к новому стеку, исследуя положительные и отрицательные черты обоих.

Короче говоря, я преобразовал свой существующий стек Wordpress, чтобы он служил в качестве REST API для передачи развязанного интерфейса во Vue.

Часть 1. Что я использовал в прошлом?

Вкратце: VPS, CentOS, Apache, MySQL, PHP, cPanel / WHM, WP, премиум-темы

Инфраструктура
Более 10 лет я полагался на стек cPanel / WHM для предоставления полного набора услуг веб-хостинга для моих клиентов веб-разработки.

Использование различных хостинговых компаний, таких как Rackspace, ServInt, Contabo, а в последнее время и облачных сервисов, таких как AWS и Heroku, аренда серверов или сборка инфраструктуры были недоступны. Запуск WHM после того, как все причуды устранены, не требует особого внимания, за исключением регулярных обновлений и миграции систем. Некоторое неожиданное время было посвящено всплескам трафика или проблемам безопасности в публичных библиотеках.

Серверная часть
Первым шагом было рассмотрение вертикальной совместимости функций и служб ОС в пользу требований приложений. В большинстве случаев я выбрал RedHat / CentOS в качестве готового к производству стека. Второй частью и моим предпочтительным инструментом был Web Host Manager (WHM). Первоначальная конфигурация предназначена для базового использования, включая обновления, резервное копирование и мониторинг. После развертывания рабочих приложений была произведена более точная настройка PHP, Apache, MySQL и DNS. В целях обеспечения безопасности и иногда параноидального уровня защиты я использовал такие инструменты, как CSF, LFD, CXS и т. Д. Два основных преимущества этого подхода - измерение враждебных IP-адресов / подсетей и защита, даже если уязвимости нулевого дня были обнаружены на уровне приложений, которых программного обеспечения PHP было немало за последние 10 лет. Я должен упомянуть, что MySQL сыграл большую роль, и такие инструменты, как SQLyog, помогли получить представление о точной настройке.

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

Плюсы: из-за того, что на сервере обрабатывается и доставляется клиентам большой процент неиспользуемого кода, использовались различные методы кэширования и оптимизации PHP, такие как минификация HTML / CSS / JS, конкатенация, отложенная загрузка. Вместе с хорошей оптимизацией Apache и MySQL стек был настроен для обеспечения впечатляющей производительности на скромных серверах.

Минусы: масштабируемость ограничивается только вертикальным масштабированием из-за особенностей работы WHM.

Отладка проблем в стеке часто может занять много времени из-за наличия нескольких уровней безопасности.

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

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

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

На данный момент все модификации и настраиваемая логика были выполнены в рамках спецификаций хорошо протестированного стека.

Плюсы: Создание поверх премиальных тем с самоуверенными, готовыми элементами пользовательского интерфейса и четко определенными и протестированными фреймворками - огромная экономия времени!

Минусы: эти готовые темы часто содержат приличный объем служебного кода, поскольку они ориентированы на универсальные варианты использования. Устранение ошибок внешнего интерфейса из-за несовместимости JS, вызванной кодом различных разработчиков, отнимает много времени.

Заключение

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

Часть 2. На что я переехал?

вкратце: AWS, EC2, Linux2, Docker, NginX, NodeJS, Vue, Nuxt, WP API, GraphQL.

Стек разработки: VScode, Github, TravisCI, EC2

Я начал разрабатывать одностраничные приложения javascript с рендерингом на стороне сервера и поддержкой запроса и анализа внешних API. Как правило, на целевых страницах рендеринг на стороне сервера выполняется с помощью NodeJS за обратным SSL-прокси NginX с поддержкой HTTP2.

Экспериментируя, я разработал приложение, размещенное на EC2, которое извлекает данные из 3 разных API и использует CDN. Я разработал следующие серверные службы для поддержки приложения:

• Портфолио WP REST API, экземпляр Wordpress на cPanel VPS.
• Currency Exchange REST API, Dockerized приложение Python на EC2.
• Новости WP REST API, экземпляр Wordpress на cPanel VPS.
• Медиа CDN, простой файловый хостинг на cPanel VPS.

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

Пример AWS:

Введите Nuxt.JS

Основные преимущества новых клиентских функций во Vue основаны на Nuxt и предоставляются сразу же после установки, что позволяет использовать такие функции, как:

• Универсальное / изоморфное приложение

По своей природе одностраничные JS-приложения извлекают контент после загрузки всех частей или оболочки приложения. Такой подход создает проблемы для поисковых систем, поскольку сканеры ожидают статического HTML-содержимого. Чтобы решить эту проблему, Nuxt может включить режим универсального приложения, который использует NodeJS для предоставления предварительно обработанного HTML-содержимого для любого запрошенного URL-адреса. Для любого последующего запроса выполняются только запросы контента API.

• Постраничное разделение кода

Обычно приложения JS отправляют код для всех страниц, даже если они не используются на запрошенной странице. Используя Webpack, код можно разделить для каждой страницы и отправить только для запрошенной страницы.

• Прогрессивные веб-приложения

Модули PWA Nuxt обеспечивают полную поддержку автономного использования, уведомлений, доступа к оборудованию устройства и других функций, создавая взаимодействие с пользователем, аналогичное нативным приложениям. Благодаря последним достижениям Chromium, PWA можно установить прямо из браузера Chrome. Впоследствии это приложение ведет себя как классическое нативное приложение и может быть установлено на любое устройство и ОС.

• Асинхронные компоненты

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

Обертывание импорта в функции будет использоваться Webpack как обещание для асинхронной загрузки частей кода.

• Предварительная загрузка

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

• Разделение кода обнаружения устройства

Код доставки только для определенного типа устройства и типа ОС.

• Обнаружение офлайн

Простые уведомления о статусе сети

• Архитектура Nuxt

Заключение

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

Новый стек обеспечивает невероятно быстрое взаимодействие с пользователем. При использовании SSR начальная нагрузка составляет менее секунды. Все последующие загрузки с помощью сервис-воркеров и хорошо оптимизированных API составляют около 50 мс. Для всех вернувшихся пользователей этот опыт будет казаться естественным, поскольку приложение оболочки извлекается из локального кеша, а содержимое предварительно загружается из постоянного состояния. Свежий контент из API и изображения из CDN будут загружаться и отображаться менее чем за 400 мс, что с точки зрения человеческого восприятия считается бесшовным взаимодействием.

Одним словом, это сбывшаяся мечта. Собственный опыт, предоставляемый через Интернет, с плавными обновлениями с использованием технологий совместной работы с открытым исходным кодом.