Микросервисная архитектура Семенов Илья НПФ «Хеликс» Дир. деп. ИТ

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

Работает, не трогай! Если вы работаете в организации среднего размера или крупной, то, скорее всего, знаете, что такое большая, противная, унаследованная от прошлых времен система, стоящая где-то в углу. Никто не хочет к ней даже прикасаться. Но ваша компания не может без нее работать, несмотря на то что она написана на каком- то странном варианте Фортрана и работает только на оборудовании, которое следовало бы списать лет 25 назад. Почему же никто эту систему не заменил? Вы знаете почему: это слишком объемная и рискованная работа.

План Архитектуры Монолиты Гибкие системы Микросервисная архитектура Типы микро сервисной архитектуры Пример Инструменты CQRS

План Архитектуры Монолиты Гибкие системы Микросервисная архитектура Типы микро сервисной архитектуры Пример Инструменты CQRS

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

Архитектура, определение В стандарте IEEE 1471 дается следующее определение: «Архитектура – это базовая организация системы, которая описывает связи между компонентами этой системы (и внешней средой), а также определяет принципы её проектирования и развития». Однако многие другие определения архитектуры признают не только структурные элементы, но и их композиции, а также интерфейсы и другие соединительные звенья. Общепринятого определения «архитектуры программного обеспечения» не существует. Так, сайт Software Engineering Institute приводит более 150 определений этого понятияSoftware Engineering Institute

Монолитные приложения и их проблемы 2-звенная/3-звенная

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

Три измерения масштабирования В книге The Art of Scalability есть понятие «куб масштабирования» (scale cube). По этому кубу мы видим, что существует три ортогональных способа увеличения производительности приложения: Sharding («шардинг», «разбиение»); Mirrorring («зеркалирование») ; Microservices (микро сервисы).

Теорема CAP Если мы хотим развивать систему, придется решать следующие вопросы: Как сделать систему доступной из разных регионов? При условии, что система распределена, как обеспечить согласованность данных? И как при этом еще и ускорить систему в N раз? Эти вопросы приводят нас к CAP-теореме, сформулированной Брюером в 2000 г.

Теорема CAP Теорема CAP эвристическое утверждение о том, что в любой реализации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств: согласованность данных (англ. consistency) во всех вычислительных узлах в один момент времени данные не противоречат друг другу; доступность (англ. availability) любой запрос к распределённой системе завершается корректным откликом; устойчивость к разделению (англ. partition tolerance) расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций.

Теорема CAP CA consistency + availability Яркий пример CA ACID- транзакции, присутствующие в классических монолитах. CP – consistency + partitioning Такое поведение характерно для тех монолитов, которым пришлось масштабироваться, несмотря на древность. AP availability + partitioning Яркий пример классические DNS-системы, которые синхронизируются с задержкой

Гибкие приложения - развитее

Архитектура, управляемая событиями (EDA) Это популярный адаптивный паттерн, широко используемый для создания масштабируемых систем. Если говорить о программном обеспечении, то в этой схеме существует два варианта событий: инициализирующее событие и событие, на которое реагируют обработчики. Обработчики являются изолированными независимыми компонентами, отвечающими (в идеале) за какую-нибудь одну задачу, и содержат бизнес-логику, необходимую для работы. Посредник может быть реализован несколькими способами. Самый просто способ – это воспользоваться фреймворками для интеграции Apache Camel, Spring Integration или Mule ESB. Для больших приложений, которым требуется более сложные функции управления, вы можете реализовать посредника, используя концепцию управления бизнес-процессами (например движок jBPL). Архитектура, управляемая событиями – это относительно сложный паттерн. Причиной тому – его распределенная и асинхронная природа. Вам придется решать проблемы фрагментации сети, обрабатывать ошибки очереди событий и так далее. Плюсами этой архитектуры могут служить высокая производительность, легкость развертки и поразительные возможности масштабирования. Однако возможно усложнение процесса тестирования системы.

Микроядерная архитектура Паттерн состоит из двух компонентов: основной системы (ядра) и плагинов. Ядро содержит минимум бизнес-логики, но руководит загрузкой, выгрузкой и запуском необходимых плагинов. Таким образом, плагины оказываются несвязанным и друг с другом. Поскольку плагины могут разрабатываться независимо друг от друга, такие системы обладают очень высокой гибкостью и, как следствие, легко тестируются. Производительность приложения, построенного на основе такой архитектуры, напрямую зависит от количества подключенных и активных модулей. Возможно самым лучшим примером микроядерной архитектуры будет Eclipse IDE. Скачивая Eclipse без надстроек, вы получаете совершенно пустой редактор. Однако с добавлением плагинов пустой редактор начнет превращаться в полезный и легко настраиваемый продукт. Еще один хороший пример – это браузер: дополнительные плагины позволяют расширить его функциональность.

План Архитектуры Монолиты Гибкие системы Микросервисная архитектура Типы микро сервисной архитектуры Пример Инструменты CQRS

Серебряная пуля? Amazon (Microservices -> IAAS, PAAS) – лидеры (AWS родился, как результат внедрения микро сервисного подхода) Netflix (Java, написали lots of tools –> circuit bracker, rpc, dataanalyse, много для тестирования, много специальных плановых аварий) Uber

Истоки идеи Unix way Нужен подход, который хорошо масштабируется на независимые команды Нужен подход, который позволяет командам работать независимо

Microservices & SOA Микросервисная архитектура всего лишь набор более строгих правил и соглашений, как писать все те же сервисы SOA Что такое микро сервисы? Это архитектурный шаблон, в котором сервисы: маленькие; сфокусированные; слабосвязанные; высоко согласованные.

Характеристики микро сервисов Разделение на компоненты (сервисы). Группировка по бизнес-задачам. Сервисы имеют бизнес-смысл. Умные сервисы и простые коммуникации. Децентрализованное управление. Децентрализованное управление данными. Автоматизация развертывания и мониторинга. Design for failure.

Характеристика: Разделение на компоненты (сервисы) Компоненты бывают двух видов: библиотеки и сервисы, которые взаимодействуют по сети. Мартин Фаулер определяет компоненты как независимо заменяемые и независимо развертываемые. Т. е., если вы можете взять что-то и спокойно заменить на новую версию, это компонент. А если что-то связано с другим и их независимо заменить нельзя (нужно учитывать контракты, сборки, версии…) они вместе образуют один компонент. Если что-то нельзя развернуть независимо, и требуется логика откуда-то еще, это тоже не компонент

Характеристика: Группировка по бизнес-задачам (сервисы имеют бизнес-смысл) Стандартная компоновка монолита Для повышения эффективности разработки вы также зачастую вынуждены делить по этим слоям и команды разработки: команда UI; команда ядра; команда БД. Если же вы переходите к микро сервисной архитектуре, сервисы и команды делятся по бизнес-задачам:

Характеристика: Умные сервисы и простые коммуникации Есть разные варианты взаимодействия сервисов. Бывает, что берут очень умную шину, которая знает и про роутинг, и про бизнес- правила (допустим, какой-нибудь BizTalk), и к сервисам прилетают уже готовые объекты. Тогда получается очень умный middleware и глупые endpointы. Это, на самом деле, анти шаблон. Как показало время (на примере того же интернета), у нас очень простая и незатейливая среда передачи данных ей абсолютно все равно, что вы передаете, она ничего не знает про ваш бизнес. Все мозги же сидят в сервисах. Это важно понимать. Если же вы будете все складывать в среду передачи, у вас получится умный монолит и тупые сервисы-обертки баз данных.

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

Характеристика: Децентрализованное хранение Единственный вариант взаимодействия сетевое взаимодействие между сервисами

Характеристика: Автоматизация развертывания и мониторинга Нанять DevOps-инженера. Автоматическое развертывание. Непрерывная интеграция и поставка. Непрерывный мониторинг. Централизовать логирование.

Характеристика: Design for Failure С самого первого этапа, начиная строить микросервисную архитектуру, вы должны исходить из предположения, что ваши сервисы не работают. Другими словами, ваш сервис должен понимать, что ему могут не ответить никогда, если он ожидает каких-то данных. Таким образом, вы сразу должны исходить из ситуации, что что-то у вас может не работать. Например, для этого компания Netflix разработала Chaos Monkey инструмент, который ломает сервисы, хаотически их выключает и рвет соединения. Этот нужно, чтобы оценить надежность системы.

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

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

План Архитектуры Монолиты Гибкие системы Микросервисная архитектура Типы микро сервисной архитектуры Пример Инструменты CQRS

Типы микро сервисной архитектуры Service Discovery (RPC Style) сервисы знают друг о друге и общаются напрямую. Message Bus (Event-driven) если вы используете шаблон «издатель подписчик», и ни «подписчик» не знает тех, кто на него подписан, ни «издатель» не знает, откуда приходит содержимое. Они заинтересованы только в содержимом определенного типа они подписываются на сообщения. Это и называется message-driven- или event-driven-архитектура. Hybrid смешанный вариант, когда для одних случаев мы применяем RPC, а для других message bus.

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

Server-Side Service Discovery

Message Bus Достоинства Message Bus: Message Bus определяет, какая у вас будет архитектура. Он позволяет легко добавлять сервисы, т. к. одни сервисы не знают про другие. Message Bus изначально построен так, чтобы все системы скалировались.

План Архитектуры Монолиты Гибкие системы Микросервисная архитектура Типы микро сервисной архитектуры Пример Инструменты CQRS

Общая схема микросервиса

Пример

План Архитектуры Монолиты Гибкие системы Микросервисная архитектура Типы микро сервисной архитектуры Пример Инструменты CQRS

Инструменты Инструменты, которые позволяют развертывать такую систему и следить за ней, например, ZooKeeper, который решает проблему конфигурирования за нас. CI – TC (.NET), Jenkins Service discovery – nginx/consul Logging – ELK (Logstash, Kibana, Elastic) Быстрое развертывание - ? (скрипты, Octopus) Контейнеры, стандартизация поставки - ? (Docker, Kubernates –управление запуском контейнеров) Сбор метрик - ? Healthcheck - проверка сервиса, проверка хранилища Zabbix (InfluxDB + Graphana) circuite braker у каждого сервиса jepsen - чтобы шатать, имитирует сетевые ошибки.

План Архитектуры Монолиты Гибкие системы Микросервисная архитектура Типы микро сервисной архитектуры Пример Инструменты CQRS (*бонус)

CQRS (Command Query Responsibility Segregation ) + Event Sourcing Пример: Тинькофф банк

Итог Закон Конвея (Conway's law) - структура вашего приложения повторяет структуру вашей организации. Если ваша организация построена на технологических иерархиях, построить микросервисную архитектуру будет очень трудно. Организации, проектирующие системы, … производят их, копируя структуры коммуникации, сложившиеся в этих организациях, Конвей, 1968

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

Микросервисы vs Монолит МИКРОСЕРВИСЫМОНОЛИТ Командоемкий Независимые релизные циклы Независимое масштабирование Можно взять и переписать Быстрая начальная разработка Понятная последовательность выполнения Быстрые внутренние вызовы Простая эксплуатация Согласованное состояние системы Согласованность в итоге Сложнее безопасность Радикальное усложнение ops Распределенная среда Распределенные транзакции Усложнение инфраструктуры Плохо масштабируется на команды Единые релизы Быстро внедряемся Малый time to market Развитие команды Большой time to market При работе с крупными монолитными системами у людей меньше возможностей получить повышение и чем-нибудь овладеть.

Спасибо! SpbCioClub в Telegram: