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

Давайте перейдем к истокам, с чего действительно началась шумиха вокруг архитектуры микросервисов, и к причинам, по которым она возникла в первую очередь. Когда у нас были большие монолитные приложения, где внесение изменений требовало переговоров между разными командами и достижения общего соглашения, чтобы сделать хотя бы один шаг вперед. Изменения в монолитных приложениях сделали процесс медленнее и более разочаровывающим, что привело к идее: «Что, если мы поместим эти компоненты в изолированный контекст, где разные команды владеют разными контекстами разработки от начала до конца?» Вот где начала появляться концепция микросервисов.

Состояния микросервисов, масштабируемость и потоки

Но что такое монолиты, что они медленные, что такое микросервис и чем он может помочь?

Без лишних слов, давайте начнем с основ.

Переход от монолита к микросервисам

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

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

Read: Why Microservices Architecture

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

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

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

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

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

Read: Event Sourcing and Saga Pattern in Microservices Architecture

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

Проблемы в микросервисах

Как известно, все сервисы должны работать вместе и общаться друг с другом. Что мы сделали, так это начали использовать REST API с JSON в качестве формата обмена данными. Это звучало просто, потому что кто не знает, как работать с REST и отправлять JSON. Кроме того, JSON поддерживается почти всем, а если нет, можно сказать: «Я запишу его в течение выходных» (конечно, вы это сделаете, но это может занять от месяцев до лет).

Read: What are the Top best Tools for Monitoring Microservices

И эту идею подхватили все разработчики по всему миру. Как выяснилось позже, этот паттерн во многих отношениях заставляет нас всех снова впадать в тесную связь, которую мы пытались преодолеть. Все это привело к тому, что архитектура микросервисов получила шутливое прозвище: «распределенный монолит», где у вас есть только проблемы микросервисов, но почему-то нет их преимуществ, что делает отладку еще более сложной, и вам все равно приходится согласовывать каждое изменение.

Вот некоторые из других серьезных проблем, с которыми столкнулись разработчики при использовании микросервисов:

  • Если вы не примете меры предосторожности, ваша бизнес-логика может просочиться повсюду, и клиенты будут много знать о внутренней работе.
  • С ростом сложности архитектуры внесение изменений может стать более рискованным, требуя от вас одновременного запуска непрерывных тестов этих служб, если вы не будете осторожны.
  • Самая большая проблема, с которой может столкнуться разработчик и которая также замедляет разработку во многих компаниях, — это необходимость убедить других присоединиться к ним, если у них есть что добавить к приложению.
  • Еще одна самая раздражающая проблема, с которой можно столкнуться, — это необходимость сериализовать и десериализовать JSON на каждом переходе, а также открывать и закрывать HTTP-соединения практически на чем угодно, что увеличивает задержку.

Что мы можем улучшить в микросервисах?

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

Read: How to Deploy Microservices Using Serverless Architecture

Мы упомянули способы, которые могут сделать разработчиков более эффективными.

  • Шлюз API

Большинство из вас должно быть знакомо с идеей шлюза API, который представляет собой инструмент управления API, находящийся между клиентом и коллекцией серверных сервисов. Он действует как обратный прокси-сервер, который принимает все вызовы API, объединяет необходимые службы и возвращает ожидаемый ответ.

Read: What is Container Security and How to Secure Containers

Ограничение скорости, аутентификация и статистика управляются шлюзами API. В случае приложений микросервисов, где один вызов может потребовать вызова десятков сервисов, API Gateway выступает в качестве единой точки входа для каждого клиента. Он также обеспечивает маршрутизацию запросов, трансляцию протоколов, безопасность и компоновку микросервисов в приложении. Шлюз API останавливает внутреннюю работу внешних клиентов, объединяет протоколы связи, снижает сложность микросервисов, отделяет внешние API от API микросервисов для визуализации тестирования дизайна и повышает эффективность приложения.

  • Сервисная сетка

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

Read: API VS Web Services VS Microservices

При использовании сервисной сетки микросервис не будет взаимодействовать с другими микросервисами, вместо этого все взаимодействие будет происходить поверх сервисной сетки (или дополнительного прокси-сервера). Среди встроенной поддержки, которую предлагает Service Mesh, — обнаружение сервисов, маршрутизация, безопасность, возможность наблюдения, развертывание контейнеров, контроль доступа, отказоустойчивость и протоколы межсервисного взаимодействия, такие как gRPC, HTTP 1.x или HTTP2.

Более того, сервисная сетка не зависит от языка, то есть не зависит ни от какого языка программирования. Таким образом, вы можете написать свой микросервис, используя любую технологию, и он все равно будет работать с сервисной сеткой. Двумя популярными платформами с открытым исходным кодом для реализации сервисной сетки являются Istio и Linkerd.

  • Дополнительный прокси-сервер

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

Дополнительный прокси-сервер управляет потоком трафика между микрослужбами, собирает данные телеметрии (журналы, метрики и трассировки) и устанавливает политики. Короче говоря, sidecar-прокси сводит к минимуму избыточность кода, снижает сложность кода и слабую связь между службами микросервисного приложения.

  • Kafka для потоков данных

Клиентская библиотека Kafka Streams используется для создания микросервисов, где входные и выходные данные хранятся в кластерах Kafka. Apache Kafka — это распределенная потоковая передача событий, которая отличается высокой масштабируемостью и отказоустойчивостью. Kafka Streams сочетает в себе простоту написания и развертывания Java-приложений на стороне клиента с преимуществами серверного кластера Kafka.

Read: Key Benefits of Service Oriented Architecture

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

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

  • Система управления событиями

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

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

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

Read: Microservices vs API

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

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

Потоковая передача с отслеживанием состояния в микросервисах

Каждый микросервис может быть как с отслеживанием состояния, так и без него. Хотя, когда речь заходит о микросервисах, многие из нас думают о сервисах без сохранения состояния, которые взаимодействуют друг с другом через HTTP (REST API), иногда это может создавать проблемы, как упоминалось выше. Поэтому, чтобы избежать этого, здесь мы собираемся обсудить микросервисы с отслеживанием состояния, реализованные с помощью управляемой событиями (потоковой) системы.

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

Тем не менее, перед внедрением управляемых событиями архитектур необходимо ознакомиться с некоторыми шаблонами: Saga, Разделение ответственности за выполнение команд и запросов (CQRS), Источник событий и Публикация-подписка.

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

Read: What are the Pros and Cons of Microservices

Обычно микросервис с отслеживанием состояния используется в системах, которым требуется обновление данных и событий в режиме реального времени. Вы можете использовать Apache Kafka или Amazon Kinesis, которые представляют собой распределенные системы, предназначенные для потоковой передачи, отказоустойчивые, горизонтально масштабируемые и часто описываемые как архитектуры потоковой передачи событий.

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

Схема в микросервисах

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

Сообщения, которые отправляются из одной службы в другую, находятся в формате JSON и содержат множество полей, таких как идентификаторы социальных сетей или свойств, а также множество метаданных обо всем, что происходит. Но проблема, о которой мы узнали в самом начале блога, заключается в том, что HTTP и JSON могут быть смехотворно медленными. Хотя это не может быть решено мгновенно, популярным выбором здесь, который можно использовать для решения проблемы, являются gRPC и HTTP/2, которые могут значительно ускорить работу.

Read: Benefits of Microservices Architecture

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

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

Тем не менее, если вы используете REST или gRPC или даже пишете событие, вам нужны контракты (API) о том, как выглядят коммуникации и сообщения. Итак, тестирование и проверка API. Если у вас есть Kafka в событийно-ориентированной системе в виде большой очереди сообщений — используются реестры схемы.

Read: SOA vs. Microservices

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

Бессерверные микросервисы

Развертывание, мониторинг сервисов и обеспечение их легкого масштабирования требует больших усилий. Вот где возникает концепция без сервера. При бессерверной разработке разработчикам не нужно управлять серверами для создания и запуска приложений. Хотя серверы все еще существуют, они абстрагированы от среды разработки. Всеми настройками, обслуживанием и масштабированием управляет облачный провайдер. Все, что нужно сделать разработчикам, — это упаковать код в контейнеры для развертывания, а веб-сайт или веб-приложение автоматически масштабируются вверх и вниз в соответствии с требованиями. Некоторые из бессерверных поставщиков на рынке — это AWS Lambda, IBM Cloud Functions, Microsoft Azure Functions, Parse и KNative.

Read: Advantages of Using Docker for Microservices

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

Заключение

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

Read: Microservices vs Web Services

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

Read: Observability for Monitoring, Alerting & Tracing Lineage in Microservices

Если у вас тоже есть идея проекта, который вы хотите разработать, наймите разработчиков из ведущих компаний-разработчиков программного обеспечения, таких как Decipher Zone Technologies. И так, чего же ты ждешь? Свяжитесь с нами сейчас!