объектно-ориентированным программистам должны понравиться микросервисы

Если вы похожи на большинство знакомых мне ИТ-специалистов, услышав термин «микросервисы», вы закатите глаза. Либо вы думаете, что это просто часть чьей-то игры в Buzz-Word Bingo, либо вы думаете: «Я уже слышал все это раньше». Какими бы популярными и широко распространенными ни были архитектуры микросервисов, они по-прежнему сталкиваются с большим количеством скептицизма и цинизма.

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

«Почему, — слышу я ваши мысли, — я должен вас слушать?»

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

Это также поможет нам быть на одной волне. Скептицизм Buzz-Word Bingo понятен, поэтому вот определение архитектуры микросервисов, которое я использую. Из Википедия:

Микросервисы — это метод разработки программного обеспечения — вариант архитектурного стиля сервис-ориентированной архитектуры (SOA), который структурирует приложение как набор слабо связанных сервисов. В микросервисной архитектуре сервисы детализированы, а протоколы легковесны. Преимущество разбиения приложения на различные более мелкие службы заключается в улучшении модульности. Это упрощает понимание, разработку и тестирование приложения, а также делает его более устойчивым к эрозии архитектуры.[1] Он распараллеливает разработку, позволяя небольшим автономным группам разрабатывать, развертывать и масштабировать свои соответствующие службы независимо друг от друга.[2] Это также позволяет создавать архитектуру отдельного сервиса посредством непрерывного рефакторинга.[3] Архитектуры на основе микросервисов обеспечивают непрерывную доставку и развертывание.[4]

Учитывая это, я думаю, что могу подытожить микросервисы таким образом, чтобы они казались немного менее загадочными и несколько развеяли скептицизм. Готовый? Вот оно…

Микросервисы — это принципы объектно-ориентированного программирования SOLID, применяемые к архитектуре вашей системы.

Это все. Не верите мне? Давайте взглянем. Каковы принципы SOLID? Единая ответственность, открытость/закрытость, замена Лискова, разделение интерфейсов и инверсия зависимостей.

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

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

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

Для сценариев общего использования может потребоваться обслуживание или изменение службы. Если у нас есть какая-то общая логика в микросервисе, которую нужно изменить, конечно, мы ее меняем. Специализированная бизнес-логика — другое дело.

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

Как правило, если услуга не предлагает нужной вам функциональности, вы не меняете услугу; вы пишете другой, который опирается на первый.

Производный класс должен иметь возможность использоваться как есть вместо его родителя.

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

Как это применимо к микросервисам, немного менее ясно, чем к другим, так что потерпите меня.

Говоря о принципе Open/Closed, я кратко упомянул об использовании мостов, фасадов, адаптеров или прокладок для добавления новых специализированных функций к существующей службе. С точки зрения моей службы, это достаточно хорошо.

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

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

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

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

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

Это еще один принцип, вызывающий споры в мире ООП. Означает ли это, что я никогда не должен программировать конкретные классы? Означает ли это, что код, от которого зависит мой класс, не должен создавать экземпляр моего класса? Последнее очевидно (здесь я чувствую, как вы съеживаетесь), но первое менее очевидно.

К счастью, микросервисы намного проще. Программа для контрактов. Учитывая контракт, я должен иметь возможность вызывать заданную функциональность. Клиенту не нужно заботиться о том, изменилась ли предоставляющая услуга, была ли вставлена прокладка или фасад между ними, или обрабатывает ли какая-либо совокупная служба расширенную функциональность. Что касается клиента, то у него есть контракт IDoStuff и адрес IStuffDoerService. Учитывая эти два требования, он может ожидать, что «материал» будет «сделан».

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

Вы действительно будете жаловаться в своей монадной системе на то, что остальная часть вашей системы должна синхронизироваться с критическими изменениями в компоненте? Конечно нет. А с микросервисами у нас есть варианты управления версиями и обнаружения сервисов, которые позволяют нам быть еще более снисходительными.

Вы бы пожаловались на написание кода обработки ошибок в ваших монадных классах? Конечно, нет, так зачем жаловаться на то, что вы делаете то же самое для своих микросервисов?

Я мог бы продолжить, но, думаю, вы уловили суть. Микросервисы так много дают на стол, что в какой-то момент вы будете работать в среде микросервисов. Если вы сомневаетесь, я надеюсь, что смог помочь вам немного изменить вашу точку зрения. Микросервисы не сложнее и не сложнее в обслуживании, чем монады. Они по-разному сложны и по-разному обслуживаются.