Эта статья представляет собой неявную версию статьи Вы снова ошиблись в микросервисах.
Религии, законы и обычаи были созданы для решения социальных проблем точно так же, как новые технологии создаются для решения технологических проблем. Архитектура микросервисов — это новое технологическое развитие технологической проблемы. К сожалению, эта концепция остается спорной среди сообщества разработчиков программного обеспечения из-за отсутствия понимания истории микросервисов.
Когда разработчики не понимают историю микросервисов, они тратят время и деньги на их реализацию. Это приводит к созданию многочисленных статей, в которых проклинается архитектура микросервисов и ее контейнеры (например, Docker и Podman), оркестраторы (например, Kubernetes и Nomad) и системы управления виртуальными вычислениями. (облачные вычисления). Конечно, проблемы, с которыми сталкиваются инженеры при использовании этих инструментов, можно устранить, если понять назначение микросервисов.
Концептуализация микросервисов
Архитектура микросервисов — это решение физических ограничений компьютера. Другими словами, Законы физики — наряду со скоростью света — физически ограничивают скорость, с которой может работать отдельный компьютер.Что происходит, когда вам нужно запустить программное обеспечение, превышающее физические ограничения отдельного компьютера?
Масштабируемость — это возможность увеличить количество операций, которые может выполнять служба. Например, программное обеспечение веб-сервера отправляет (обслуживает) страницы клиенту пользователя. Он делает это, обрабатывая пользовательские запросы (операция) и затем отправляя страницу пользователю (другая операция). Масштабирование этого веб-сервера означает увеличение количества страниц, которые он может обслуживать за заданный период времени (т.е. в секунду).
Когда компьютер, на котором работает веб-сервер, нуждается в масштабировании, один из способов сделать это — обновить компьютер. Это обновление, называемое вертикальным масштабированием, увеличивает скорость компьютера, что увеличивает ограничение скорости веб-сервера. Однако в какой-то момент обновление компьютера становится НЕВОЗМОЖНЫМ. В результате мы должны масштабировать веб-сервер, запуская его на нескольких компьютерах.
Добавление другого компьютера для масштабирования называется горизонтальным масштабированием и используется в горизонтальной архитектуре (HA).
Подобно клеткам человеческого тела, компьютеры должны обмениваться информацией, используя сигналы для выполнения одной и той же операции на нескольких компьютерах. Этот процесс обмена информацией известен как связь и используется в компьютерной сети для координации каждой службы. К сожалению, за связь приходится платить скоростью обработки, которая называется задержка. Оптимальная реализация архитектуры микрослужб позволяет разработчику увеличить мощность службы с помощью другого компьютера, сохраняя при этом низкую задержку.
Следующие вопросы можно использовать для разъяснения концепции микросервисов.
Когда следует использовать микросервисы?
Если ваша программа еще не создана, вы должны подумать, стоит ли внедрять микросервисы. Станет ли ваша служба одновременно
- Узкое место из-за физических ограничений компьютера.
- Невозможно масштабировать по горизонтали с помощью балансировки нагрузки «активный-активный» (т. е. клонирования монолита).
Если да, то внедрение микросервисов — объективно правильное решение. В противном случае, если ваша программа уже существует (хотя и не соответствует указанным выше критериям), архитектура микросервисов просто не нужна.
Как я должен структурировать свой код?
Это не имеет значения. Микросервисы — это не про код. Это про архитектуру.
Должен ли я использовать один репозиторий или несколько?
Это также не имеет значения. Микросервисы — это не про код. Это про архитектуру.
При этом…
Должна ли одна служба зависеть от другой?
Допустим, вы разделили веб-сервер на две микрослужбы для обработки запросов и отправки страниц. Когда пользователь отправляет запрос, он будет отправлен в службу отправки, которая взаимодействует с службой обработки ДОзагрузки страницы клиентом пользователя (из контента службы отправки). В этом случае служба отправки зависит от службы обработки.
Что происходит, когда служба обработки выходит из строя?
В худшем варианте пользователи перестают получать страницы, потому что ничего не обрабатывается. Однако это можно исправить, добавив в службу отправки логику для отправки пользователю страницы «проблемы с сервером» (когда служба обработки не работает). . Это позволяет пользователю получать страницы, даже когда служба обработки не работает. Таким образом, линейная зависимость — это не конец света в архитектуре микросервисов.
Но когда отправляющая служба требует информацию от обрабатывающей службы, возникает следующий сценарий.
SRE будет пейджинг посреди ночи. Пользователи не будут получать страницы, потому что служба обработки не работает, хотя служба отправки работает и… Служба отправки также отключится. Что произошло? Вы создали циклическую зависимость со своими службами.
Не делайте этого.
Использование архитектуры микросервисов требует, чтобы вы управляли своими зависимостями аналогично своему коду. К счастью, программисты создали инструменты, которые управляют зависимостями между несколькими контейнерами сервисов(например, Docker и Podman). Эти инструменты, такие как Kubernetes и Nomad, называются оркестраторами контейнеров, потому что они управляют контейнерами.
Значение контейнера и оркестратора контейнеров заключается в том, что они представляют собой технологические разработки, решающие сложности, связанные с архитектурой микросервисов. Этих сложностей нельзя избежать, если только вы не сможете разработать компьютер, который можно бесконечно обновлять. Однако на этом развитие микросервисных технологий не остановилось.
Контейнер (служб) относится к компьютеру так же, как компьютер к кластеру. Например, компьютерный кластер управляет несколькими компьютерами (называемыми серверами). Программисты используют облачные вычисления для виртуального управления компьютерами в этих кластерах. Языки с отслеживанием состояния, такие как Terraform, были созданы для управления состоянием облака. Вот почему облачные вычисления предназначены для масштабирования.
Так что насчет базы данных?
Ваша база данных — это сервис. Так что имеет смысл следовать правилам, установленным выше. Не применяйте циклические зависимости, даже если для этого требуется использование нескольких баз данных и/или дублирование данных. На практике вы НЕвероятно окажетесь с одной и той же схемой для двух отдельных служб. Следовательно, база данных по сервисной рекомендации.
Нет необходимости в спорах
Споры вокруг микросервисов можно разрешить, обучая разработчиков их концептуализации и проявляя осторожность при их реализации. Архитектура микросервисов — еще один инструмент, который разработчики могут использовать для решения технологических проблем: ее НЕ следует применять к каждому существующему проекту. В дальнейшем мы должны побуждать разработчиков узнавать о причине существования той или иной технологии, а не сосредотачиваться исключительно на том, как она работает.
