Архитектура Highload проекта

Терминология

Backend — обеспечивает обработку запросов от Frontend'a. Он реализует API в виде функций. Получает запрос от клиента, отправляет запрос в БД, формирует и возвращает ответ клиенту, обычно в виде данных. Сборкой HTML кода бэкенд не занимается. Примеры API: CRUD запросы, поисковые запросы.

Frontend — то, что отвечает за генерацию HTML кода, динамический HTML и реализует концепцию MV*. Он отправляет запросы на бэкенд, получает от него данные и на основе этих данных формирует HTML код страницы или динамически ее изменяет.

Data Exchange Protocol — протокол обмена данными между различными участниками системы: между фронендом и бэкендом, между двумя разными бэкендами.

MV*  — Model-View-WhatEver концепция динамической реализации интерфейсов. Существует несколько подходов: MVC, MVP, MVVM. Более подробно о них в этом видео. Очень часто ее считают технологии бэкенда, где контролер обрабатывает маршруты, модель — это запись в БД, а View это шаблон. Это представление неверно. MV* это технология исключительно фронтенда и работает она в основном в браузере клиента. К базе данных фронтенд обращается через бэкенд, посредством вызова API функций.

Service Discovery — технология определения адреса и местоположения бэкенда, чтобы к нему можно было обратиться.

Метрика — показатели системы: количество ошибок 404 и 502, время загрузки страницы и т.п.

Supervision — контроль за работой различных компонентов системы

Automatization — Автоматическое развертывание/обновление системы

Auto Scaling — автоматическое масштабирование при увеличении нагрузки

Continuous Integration — непрерывная интеграция. Ежедневный merge веток разработок в основную develop ветку с последующие сборкой всего проекта. Создается так называемая ночная сборка проекта, которая сразу же проходит Unit тестирование. Ночные сборки используются разработчиками и тестерами, для обкатки программы, поиска багов, дефектов, проверки различных задач интеграции и т.п.

Continuous Delivery — непрерывная поставка ПО. После того, как ночная сборка проходит все этапы Unit и Stage тестирования, она автоматически релизится в продакшн.

Технологии

Олег Бунин — Пошаговый алгоритм разработки высоконагруженной системы

  Название Технологии
1 Data Exchange Protocol gRPC, RabbitMQ, WebSocket, HTTP + JSON, SOAP, WSDL, OData, DCOM, Corba, Rest API, AMPQ и т.д.
2 Service Discovery Consul, DNS,Avahi, Apache ZooKeeper, etcd
3 Logging Syslog
4 Metrika Zabbix
5 Supervision Consul
6 Automatization Ansible, Chef
7 Auto Scaling  
8 CI/CD  

Аспекты разработки высоконагруженных проектов

  1. Простое решение – лучшее решение, сложное решение – плохое решение.
  2. Использовать модели SOA (Service-Oriented Architecture) или MSA (Micro Service Architecture), а также концепцию толстого клиента, фронтенда, бэкенда.
  3. Не хранить состояния, сессии в бэкендах.
  4. Спроектировать архитектуру, таким образом, чтобы падение и выход из строя различных компонентов, серверов не влиял на всю систему в целом. Рекомендуется проводить профилактику: отключать случайным образом компоненты и сервера системы, чтобы устранять те моменты, когда отключение компонентов влияет на работу всей системы.
  5. Найти допущения в своем проекте, которые можно использовать, чтобы легче спроектировать архитектуру. 
    Примеры допущений:
    — Чтение в 10 раз больше чем запись.
    — Запросы на чтение новостей за сутки на 90% больше чем запросы на все остальные новости.
    и т.п.
  6. Использовать async/await или green thredes.

Архитектурная схема Highload проекта

Чтобы лучше обеспечить горизонтальное масштабирование проекта, его следует разбить на составляющие части: Backend и Frontend. При этом backend и fronend также разбить на слабо связанные части. В идеале, конечно, связи между бэкендами лучше свести к минимуму, чтобы они друг на друга не влияли.

Связь между частями системы осуществляется через брокер сообщений. Это может быть RabbitMQ, Apache Kafka или другой брокер.

Схема работы следующая:

  1. Пользователь открывает вкладку браузера и набирает адрес сайта. 
  2. Браузер пользователя отправляет первый (холодный)  запрос на сервер.
  3. Этот холодный запрос встречает фронтенд. Это может быть NodeJS, Java или C#. Задача фронтенда собрать Html страницу, на основе запроса пользователя, а также отдать необходимую статику. Фронтенд может заниматься также серверным рендером, либо отдать эту задачу клиенту, передав ему html шаблон. Фронтенд, при необходимости, при рендере Html страницы, может вызвать через RPC команды бэкенда, и получить результат из его БД.
  4. После того, как необходимые данные получены, фронтенд передает Html страницу браузере. Html страница может передаваться уже готовой, либо может быть передан шаблон Html, который браузер должен сам собрать.
  5. После того, как Html страница собрана и отображена, браузер переходит в режим толстого клиента. Это означает, что новые запросы будут отправлены на сервер к бэкендам через Ajax или вебсокеты. А собирать Html страницу, будет сам браузер. При этом фронтенд играет теперь роль посредника между браузерам и бэкендами.

При таком подходе, можно соединить бэкенды с фронтендом, написанные на разных языках программирования. Масштабируется данная схема просто: достаточно увеличить число бэкендов и фронтендов. Т.к. используется брокер сообщений, то он может реализовать логику маршрутизации свободным бэкендам при RPC вызовах.

Читать также

  1. Олег Бунин — Пошаговый алгоритм разработки высоконагруженной системы
  2. Разработка и проектирование высоконагруженных систем 1, Олег Бунин Онтико
  3. Разработка и проектирование высоконагруженных систем 2, Олег Бунин Онтико
  4. Разработка и проектирование высоконагруженных систем 3, Олег Бунин Онтико