Покажу вам эволюцию упрощенного веб-сайта электронной коммерции (привет Ozon). Архитектура которого идет от монолитной конструкции на одном сервере к сервис-ориентированной/микросервисной архитектуре.
Предположим, у нас есть два сервиса: сервис инвентаризации (Inventory Service) и сервис управления пользователями (User Service).
Шаг 1. С ростом базы пользователей один сервер больше не может обрабатывать трафик. Мы размещаем сервер приложений и сервер базы данных на двух отдельных серверах.
Шаг 2. Бизнес продолжает расти, и одного сервера приложений уже недостаточно. Мы разворачиваем кластер серверов приложений.
Шаг 3. Теперь входящие запросы должны направляться на несколько серверов приложений. Как мы можем обеспечить равномерную нагрузку на каждый сервер приложений? Балансировщик нагрузки прекрасно с этим справляется.
Шаг 4. Поскольку бизнес продолжает расти, база данных может стать узким местом. Чтобы избежать этого, мы разделяем операции чтения и записи таким образом, чтобы частые запросы на чтение передавались репликам чтения (другими словами, мы организовываем репликацию БД).
Шаг 5. Предположим, что бизнес продолжает расти. Одна база данных не может справиться с нагрузкой одновременно на таблицу инвентаризации (Inventory Table) и таблицу пользователей (User Table). У нас есть несколько вариантов:
1. Вертикальное масштабирование БД. Увеличение мощности (ЦП, ОЗУ и т. д.) сервера базы данных. Все мы понимаем, что рано или поздно мы упремся в потолок.
2. Горизонтальное масштабирование БД путем добавления дополнительных серверов баз данных (шардинг).
3. Добавление уровня кэширования для разгрузки запросов на чтение.
Шаг 6. Теперь мы можем объединить бизнес-функции в различные сервисы. Архитектура становится сервис-ориентированной/микросервисной.
P.S. Что еще нам нужно для поддержки сайта электронной коммерции в масштабах Ozon?
