Не создавайте микросервисы, стремитесь к слабой связи

Sep 01, 2023

Автор: Крис Бертинато, 29 августа 2023 г.

Учитывая, что спрос на надежную работу приложений постоянно растет, неудивительно, что многие компании создают свои системы с учетом будущего расширения. Многие отраслевые эксперты указывают на микросервисы как на лучший способ обеспечить безопасность системы в будущем, но, возможно, вместо этого лучше использовать термин «услуги подходящего размера», поскольку не существует единой стратегии, которая работала бы для каждой фирмы в любой момент времени. . Вместо того, чтобы думать о том, какую из последних тенденций принять в качестве стратегии, командам следует признать и сосредоточиться на основополагающем факторе взаимодействия. Системы становятся более гибкими и динамичными, если между компонентами, которые с наибольшей вероятностью изменятся, существует слабая связь.

В контексте системы связь означает, как соединяются компоненты системы. Интерфейсы необходимы для слабой связи. Для электрических систем эти интерфейсы реализованы в виде физических разъемов с контактами и разъемами, а протоколы описываются с точки зрения уровней напряжения. Аналогией программных систем с электрическим разъемом является интерфейс прикладного программирования (API), который может быть реализован, среди прочего, как набор функций или ресурсов на основе HTTP. Но одного интерфейса недостаточно для слабой связи. Этот интерфейс также должен быть в некоторой степени стабильным, то есть пользователь может рассчитывать на то, что этот интерфейс будет присутствовать, а его входные данные останутся неизменными в течение длительного времени или, по крайней мере, будут предсказуемо меняться.

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

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

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

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

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

Архитектурный выбор зависит не только от человеческого фактора создания и эксплуатации программных систем, но и от технических проблем, таких как масштабируемость и производительность. А человеческий компонент — это то, в чем микросервисы могут потерпеть неудачу.