Андрей Трушкин - Архитектура цифрового мира

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

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

• Фиксация событий. События отражают уже случившиеся изменения в микросервисах или системах, а не являются отложенными командами на исполнение.

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

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

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

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

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

• Возможность самопотребления. Микросервисы могут сами реагировать на опубликованные ими события. Такая возможность должна обеспечиваться при реализации.

Пример решения, выстроенного в соответствии с концепциями микросервисной архитектуры, продуктового подхода и EDA, представлен на Рисунке 10.

Рисунок 10. Пример продуктовой микросервисной архитектуры в сочетании с EDA

На Рисунке 10 показаны два банковских продукта, автоматизируемых в соответствии с принципами микросервисной архитектуры и EDA. Основной интеграционный поток осуществляется посредством публикации событий, управление которыми осуществляет платформа событийного обмена, представляющая собой внешний по отношению к микросервисам технический компонент. Отличие указанной платформы от ESB-решений эпохи SOA заключается в строго техническом характере решения и «пассивном» положении платформы в ИТ-ландшафте – она не оказывает непосредственного концептуального влияния на интегрируемые микросервисы. При этом прямые интеграционные взаимодействия между микросервисами также присутствуют, но минимизированы.

Сочетание микросервисной архитектуры, продуктового подхода и EDA позволило многих компаниям провести кардинальную трансформацию своего ИТ-ландшафта, осуществив новый революционный переход, и значительно повысить качество предлагаемых услуг, обеспечить высокую скорость внесения изменений и вывода продуктов на рынок. При этом на новый качественный уровень вышли производительность и надежность их решений. Соответствующие архитектурные подходы используются в LinkedIn, Uber, Netflix, Monzo Bank и других технологических лидерах современности.

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

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

Многие компании, активно развивающиеся в различных направлениях человеческой деятельности, имеют давнюю по меркам ИТ историю, что непосредственно сказывается на уровне их автоматизации. В России крупнейшие корпорации осуществляют автоматизацию своей деятельности 25—30 лет, в США и Западной Европе этот процесс даже более длителен. По ходу развития возникает ситуация сосуществования ИТ-решений различных поколений: рядом сосуществуют монолитные решения, многие из которых разработаны с использованием устаревших технологических стеков, сервис-ориентированные решения, есть наработки с использованием микросервисной архитектуры. Нередко в профессиональном экспертном сообществе поднимается вопрос, зачастую инициируемый и заказчиками решений по автоматизации, который заключается в том, какой путь выбрать в части архитектурных преобразований: эволюционный или революционный. В случае перехода организации, обладающей большим объемом унаследованного (legacy) ИТ-ландшафта вопрос можно конкретизировать следующим образом: стоит ли дробить системы предыдущего поколения на микросервисы, либо стоит создавать новый ИТ-ландшафт фактически с нуля.