Привет, Хабр!
Пока у нас продолжается распродажа на самые взыскательные вкусы, мы обратим ваше внимание на еще одну тему нашего творческого поиска: событийно-ориентированную архитектуру (EDA). Под катом вас ожидают красивые блок-схемы и рассказ о том, как данная инновационная парадигма помогает при разработке веб-приложений.
В этой статье будут рассмотрены некоторые проблемы, подстегивающие развитие инноваций в современной веб-разработке. Далее мы погрузимся в тему событийно-ориентированной архитектуры (EDA), призванной решить эти проблемы, по-новому трактуя архитектуру серверной части.
Веб-приложения прошли долгий путь с тех времен, когда контент, оформленный в виде статических HTML-страниц, подавался с сервера. Сегодня веб-приложения стали гораздо сложнее, в их работе используются разнообразные фреймворки, датацентры и технологии. В последние пару лет можно отметить две тенденции, определяющие развитие IT-рынка:
Эти идеи во многом определяют, как сегодня проектируется и создается программное обеспечение. Можно сказать, что сегодня мы строим уже не приложения, а платформы. Приложения более не занимают общего вычислительного пространства. Вместо этого им приходится обмениваться друг с другом информацией по легковесным коммуникационным протоколам, в частности, REST API или вызовы удаленных процедур (RPC). Эта модель позволила создать такие замечательные продукты как Facebook, Netflix, Uber и многие другие.
В этой статье будут рассмотрены некоторые проблемы, подстегивающие развитие инноваций в современной веб-разработке. Далее мы погрузимся в тему событийно-ориентированной архитектуры (EDA), призванной решить эти проблемы, по-новому трактуя архитектуру серверной части.
Любая веб-технология должна справляться с теми вызовами, которым должны отвечать современные многопользовательские асинхронные приложения, рассчитанные на бесперебойную работу:
Теперь мы работаем не с одним приложением, а с многими – десятками или даже сотнями – связанными сервисами, и каждый из них должен решать свои задачи круглосуточно, семь дней в неделю. Как этого добиться? Чаще всего сервис горизонтально масштабируют на множество инстансов, которые могут быть распределены в нескольких датацентрах – так обеспечивается высокая доступность. Все запросы, поступающие на данный конкретный сервис, маршрутизируются и равномерно распределяются по всем инстансам. В некоторых инструментах развертывания предоставляются возможности самовосстановления, поэтому при отказе одного инстанса создается другой, заступающий на его место.
Масштабируемость во многом сродни доступности. Суть доступности – обеспечить, что как минимум один экземпляр сервиса активен и работает, готов обслуживать входящие запросы. Масштабируемость, в свою очередь, связана, прежде всего, с производительностью. Если какое-либо приложение перегружено, то создаются новые экземпляры этого приложения, чтобы подстроиться к возросшему количеству запросов. Но вертикальное масштабирование приложений – нетривиальная задача, в особенности если речь идет о приложениях с сохранением состояния.
До появления микросервисов такая задача решалась довольно просто. Все данные располагались в одном местоположении, как правило, это была та или иная реляционная база данных. Но, когда множество сервисов совместно используют базу данных, могут создаваться такие проблемы, как возникающие между разными командами зависимости, касающиеся изменений схемы или проблем с производительностью. Обычно эта проблема решалась выделением своей базы данных на каждый сервис. Распределенный источник истины очень хорошо помогает соблюдать чистую архитектуру, но в такой ситуации приходится иметь дело с распределенными транзакциями и сложностью, сопряженной с поддержкой множественных баз данных.
При реализации типичного сценария вида «запрос-отклик» клиент дожидается, пока ответит сервер; он блокирует все действия, пока не получит ответ, либо пока не истечет заданная задержка. Если взять такое поведение и внедрить его в микросервисную архитектуру при помощи цепочек вызовов, пронизывающих всю систему, то можно легко оказаться в так называемом «микросервисном аду». Все начинается с вызова всего одного сервиса, назовем его «сервис А». Но затем сервис A должен вызвать сервис B, и начинается самое интересное. Проблема с данным поведением такова: если сам сервис связан с заблокированными ресурсами (например, висит поток), то задержки растут экспоненциально. Если у нас разрешена задержка в 500 мс на сервис, а в цепочке пять вызовов сервисов, то первому сервису понадобится задержка в 2500 мс (2,5 секунды), а последнему – 500 мс.
Вызовы современного веба
В классических трехуровневых приложениях ядром системы является база данных. В EDA фокус смещается на события и на то, как они просачиваются через систему. Такая смена акцентов позволяет полностью изменить подход к проектированию приложений и решению вышеупомянутых проблем.
Прежде, чем рассмотреть, как именно это делается в EDA, рассмотрим, что же такое «событие». Событие – это действие, инициирующее либо некоторое уведомление, либо изменение в состоянии приложения. Свет включился (уведомление), термостат отключил обогревательную систему (уведомление), у пользователя изменился адрес (изменение состояния), у кого-то из ваших друзей изменился номер телефона (изменение состояния). Все это — события, но еще не факт, что мы должны добавлять их в событийно-ориентированное решение. Предполагается, что в архитектуру добавляются лишь события, важные с точки зрения бизнеса. Событие «пользователь оформляет заказ» важно с точки зрения бизнеса, а «пользователь съедает заказанную пиццу или обед» — нет.
Если подумать над некоторыми событиями, то по поводу некоторых сразу понятно, что они важны для бизнеса, а по поводу некоторых – нет. Особенно по поводу тех, что происходят в ответ на другие события. Для выявления событий, идущих через систему, применяется техника под названием «событийный штурм». Созываются участники разработки приложения (от программистов до разработчиков бизнес-логики и экспертов в предметной области) и общими силами картируют все бизнес-процессы, представляя их в виде конкретных событий. Когда такая карта будет готова, результат работы формулируется в виде требований, которые должны выполняться при разработке приложений.
Пример приложения для бронирования, описанного методом событийного штурма
Выявив интересующие нас события и определившись, как их идентифицировать, давайте рассмотрим, как при помощи данной парадигмы можно решить типичные проблемы, упомянутые выше.
Поток событий является однонаправленным: от производителя к потребителю. Сравните данную ситуацию с вызовом REST. Производитель событий в принципе не ожидает отклика от потребителя, тогда как в случае REST-вызова отклик будет всегда. Нет отклика – значит не необходимости блокировать выполнение кода, пока не произойдет что-то еще. В таком случае события становятся асинхронными по природе своей, что полностью исключает риск увязнуть в задержках.
События происходят в результате действия, поэтому целевой системы здесь нет; нельзя сказать, что сервис A инициирует события в сервисе B; но можно сказать, что сервис B интересуют события, порождаемые сервисом A. Правда, в этой системе могут быть и другие «заинтересованные стороны», например, сервисы C или D.
Как же нам убедиться, что событие, инициированное в некоторой системе, достигнет всех «заинтересованных» сервисов? Как правило, подобные системы решаются при помощи брокеров сообщений. Брокер – это просто приложение, действующее в качестве посредника между генератором события (приложением, создавшим это событие) и потребителем события. Таким образом, приложения удается аккуратно открепить друг от друга, позаботившись о проблеме доступности, речь о которой шла выше в этом посте. Если именно в данный момент приложение недоступно, то, вернувшись в онлайн, оно начнет потреблять события и обрабатывать их, наверстав все те события, которые успели произойти за период, пока оно оставалось недоступным.
Что насчет хранилища данных? Можно ли хранить события в базе данных, либо вместо базы данных требуется что-то иное? Определенно, события можно хранить в базах данных, но в таком случае утрачивается их «событийная» сущность. Как только событие произошло, скорректировать его мы уже не можем, поэтому события по сути своей неизменяемы. Базы данных, в свою очередь… изменяемы, после занесения данных в базу их вполне можно изменить.
Лучше хранить события в логах событий. Логи событий – не что иное, как централизованное хранилище данных, где каждое событие записано в виде последовательности неизменяемых записей, так называемого «лога». Лог можно сравнить с журналом, где каждое новое событие добавляется в конец списка. Всегда можно воссоздать наиболее актуальное состояние, воспроизведя все события лога от начала до настоящего момента.
Итак, мы затронули все вопросы, кроме масштабируемости. Сервисы, создаваемые в событийно-ориентированном ключе, всегда рассчитаны на развертывание во множестве инстансов. Поскольку состояние как таковое хранится в логе событий, сам сервис будет без сохранения состояния, что обеспечивает хирургически точное масштабирование любого интересующего нас сервиса.
Единственным исключением из этого принципа являются сервисы, предназначенные для создания материализованных представлений. В сущности, материализованное представление – это состояние, описывающее лог событий в определенный момент времени. Такой подход используется, чтобы было проще запрашивать данные. Возвращаясь к проблеме масштабирования, скажем, что материализованное представление – это просто совокупное представление событий, напоминающее по форме таблицу; но где мы храним эти таблицы? Чаще всего приходится видеть такие агрегации в памяти, и при этом наш сервис автоматически превращается в сохраняющий состояние. Быстрое и легкое решение – снабдить локальной базой данных каждый сервис, создающий материализованные представления. Таким образом, состояние хранится в базе данных, и сервис работает без сохранения состояния.
Хотя, событийно-ориентированная архитектура существует уже более 15 лет, она лишь недавно снискала серьезную популярность, и это неслучайно. Большинство компаний проходят этап «цифровой трансформации», сопровождаемый дикими требованиями. Из-за сложности этих требований инженерам приходится осваивать новые подходы к проектированию ПО, предполагающие, в частности, ослабление связанности сервисов друг с другом и снижение издержек на обслуживание сервисов. EDA — одно из возможных решений этих проблем, но не единственное. Также не рассчитывайте, что все проблемы решатся, стоит только перейти на EDA. Для реализации некоторых фич по-прежнему могут потребоваться надежные дедовские REST API или хранение информации в базе данных. Выберите наиболее подходящий для вас вариант и спроектируйте его как следует!
Пока у нас продолжается распродажа на самые взыскательные вкусы, мы обратим ваше внимание на еще одну тему нашего творческого поиска: событийно-ориентированную архитектуру (EDA). Под катом вас ожидают красивые блок-схемы и рассказ о том, как данная инновационная парадигма помогает при разработке веб-приложений.
В этой статье будут рассмотрены некоторые проблемы, подстегивающие развитие инноваций в современной веб-разработке. Далее мы погрузимся в тему событийно-ориентированной архитектуры (EDA), призванной решить эти проблемы, по-новому трактуя архитектуру серверной части.
Веб-приложения прошли долгий путь с тех времен, когда контент, оформленный в виде статических HTML-страниц, подавался с сервера. Сегодня веб-приложения стали гораздо сложнее, в их работе используются разнообразные фреймворки, датацентры и технологии. В последние пару лет можно отметить две тенденции, определяющие развитие IT-рынка:
- Перенос приложений в облако;
- Внедрение микросервисной архитектуры.
Эти идеи во многом определяют, как сегодня проектируется и создается программное обеспечение. Можно сказать, что сегодня мы строим уже не приложения, а платформы. Приложения более не занимают общего вычислительного пространства. Вместо этого им приходится обмениваться друг с другом информацией по легковесным коммуникационным протоколам, в частности, REST API или вызовы удаленных процедур (RPC). Эта модель позволила создать такие замечательные продукты как Facebook, Netflix, Uber и многие другие.
В этой статье будут рассмотрены некоторые проблемы, подстегивающие развитие инноваций в современной веб-разработке. Далее мы погрузимся в тему событийно-ориентированной архитектуры (EDA), призванной решить эти проблемы, по-новому трактуя архитектуру серверной части.
Актуальные проблемы современного веба
Любая веб-технология должна справляться с теми вызовами, которым должны отвечать современные многопользовательские асинхронные приложения, рассчитанные на бесперебойную работу:
Доступность
Теперь мы работаем не с одним приложением, а с многими – десятками или даже сотнями – связанными сервисами, и каждый из них должен решать свои задачи круглосуточно, семь дней в неделю. Как этого добиться? Чаще всего сервис горизонтально масштабируют на множество инстансов, которые могут быть распределены в нескольких датацентрах – так обеспечивается высокая доступность. Все запросы, поступающие на данный конкретный сервис, маршрутизируются и равномерно распределяются по всем инстансам. В некоторых инструментах развертывания предоставляются возможности самовосстановления, поэтому при отказе одного инстанса создается другой, заступающий на его место.
Масштабируемость
Масштабируемость во многом сродни доступности. Суть доступности – обеспечить, что как минимум один экземпляр сервиса активен и работает, готов обслуживать входящие запросы. Масштабируемость, в свою очередь, связана, прежде всего, с производительностью. Если какое-либо приложение перегружено, то создаются новые экземпляры этого приложения, чтобы подстроиться к возросшему количеству запросов. Но вертикальное масштабирование приложений – нетривиальная задача, в особенности если речь идет о приложениях с сохранением состояния.
Единый источник истины
До появления микросервисов такая задача решалась довольно просто. Все данные располагались в одном местоположении, как правило, это была та или иная реляционная база данных. Но, когда множество сервисов совместно используют базу данных, могут создаваться такие проблемы, как возникающие между разными командами зависимости, касающиеся изменений схемы или проблем с производительностью. Обычно эта проблема решалась выделением своей базы данных на каждый сервис. Распределенный источник истины очень хорошо помогает соблюдать чистую архитектуру, но в такой ситуации приходится иметь дело с распределенными транзакциями и сложностью, сопряженной с поддержкой множественных баз данных.
Синхронность
При реализации типичного сценария вида «запрос-отклик» клиент дожидается, пока ответит сервер; он блокирует все действия, пока не получит ответ, либо пока не истечет заданная задержка. Если взять такое поведение и внедрить его в микросервисную архитектуру при помощи цепочек вызовов, пронизывающих всю систему, то можно легко оказаться в так называемом «микросервисном аду». Все начинается с вызова всего одного сервиса, назовем его «сервис А». Но затем сервис A должен вызвать сервис B, и начинается самое интересное. Проблема с данным поведением такова: если сам сервис связан с заблокированными ресурсами (например, висит поток), то задержки растут экспоненциально. Если у нас разрешена задержка в 500 мс на сервис, а в цепочке пять вызовов сервисов, то первому сервису понадобится задержка в 2500 мс (2,5 секунды), а последнему – 500 мс.
Вызовы современного веба
Знакомство с событийно-ориентированной архитектурой
Событийно-ориентированная архитектура (EDA) – это парадигма программной архитектуры, способствующая порождению, обнаружению, потреблению событий и реакции на них.
В классических трехуровневых приложениях ядром системы является база данных. В EDA фокус смещается на события и на то, как они просачиваются через систему. Такая смена акцентов позволяет полностью изменить подход к проектированию приложений и решению вышеупомянутых проблем.
Прежде, чем рассмотреть, как именно это делается в EDA, рассмотрим, что же такое «событие». Событие – это действие, инициирующее либо некоторое уведомление, либо изменение в состоянии приложения. Свет включился (уведомление), термостат отключил обогревательную систему (уведомление), у пользователя изменился адрес (изменение состояния), у кого-то из ваших друзей изменился номер телефона (изменение состояния). Все это — события, но еще не факт, что мы должны добавлять их в событийно-ориентированное решение. Предполагается, что в архитектуру добавляются лишь события, важные с точки зрения бизнеса. Событие «пользователь оформляет заказ» важно с точки зрения бизнеса, а «пользователь съедает заказанную пиццу или обед» — нет.
Если подумать над некоторыми событиями, то по поводу некоторых сразу понятно, что они важны для бизнеса, а по поводу некоторых – нет. Особенно по поводу тех, что происходят в ответ на другие события. Для выявления событий, идущих через систему, применяется техника под названием «событийный штурм». Созываются участники разработки приложения (от программистов до разработчиков бизнес-логики и экспертов в предметной области) и общими силами картируют все бизнес-процессы, представляя их в виде конкретных событий. Когда такая карта будет готова, результат работы формулируется в виде требований, которые должны выполняться при разработке приложений.
Пример приложения для бронирования, описанного методом событийного штурма
Выявив интересующие нас события и определившись, как их идентифицировать, давайте рассмотрим, как при помощи данной парадигмы можно решить типичные проблемы, упомянутые выше.
Поток событий является однонаправленным: от производителя к потребителю. Сравните данную ситуацию с вызовом REST. Производитель событий в принципе не ожидает отклика от потребителя, тогда как в случае REST-вызова отклик будет всегда. Нет отклика – значит не необходимости блокировать выполнение кода, пока не произойдет что-то еще. В таком случае события становятся асинхронными по природе своей, что полностью исключает риск увязнуть в задержках.
События происходят в результате действия, поэтому целевой системы здесь нет; нельзя сказать, что сервис A инициирует события в сервисе B; но можно сказать, что сервис B интересуют события, порождаемые сервисом A. Правда, в этой системе могут быть и другие «заинтересованные стороны», например, сервисы C или D.
Как же нам убедиться, что событие, инициированное в некоторой системе, достигнет всех «заинтересованных» сервисов? Как правило, подобные системы решаются при помощи брокеров сообщений. Брокер – это просто приложение, действующее в качестве посредника между генератором события (приложением, создавшим это событие) и потребителем события. Таким образом, приложения удается аккуратно открепить друг от друга, позаботившись о проблеме доступности, речь о которой шла выше в этом посте. Если именно в данный момент приложение недоступно, то, вернувшись в онлайн, оно начнет потреблять события и обрабатывать их, наверстав все те события, которые успели произойти за период, пока оно оставалось недоступным.
Что насчет хранилища данных? Можно ли хранить события в базе данных, либо вместо базы данных требуется что-то иное? Определенно, события можно хранить в базах данных, но в таком случае утрачивается их «событийная» сущность. Как только событие произошло, скорректировать его мы уже не можем, поэтому события по сути своей неизменяемы. Базы данных, в свою очередь… изменяемы, после занесения данных в базу их вполне можно изменить.
Лучше хранить события в логах событий. Логи событий – не что иное, как централизованное хранилище данных, где каждое событие записано в виде последовательности неизменяемых записей, так называемого «лога». Лог можно сравнить с журналом, где каждое новое событие добавляется в конец списка. Всегда можно воссоздать наиболее актуальное состояние, воспроизведя все события лога от начала до настоящего момента.
Итак, мы затронули все вопросы, кроме масштабируемости. Сервисы, создаваемые в событийно-ориентированном ключе, всегда рассчитаны на развертывание во множестве инстансов. Поскольку состояние как таковое хранится в логе событий, сам сервис будет без сохранения состояния, что обеспечивает хирургически точное масштабирование любого интересующего нас сервиса.
Единственным исключением из этого принципа являются сервисы, предназначенные для создания материализованных представлений. В сущности, материализованное представление – это состояние, описывающее лог событий в определенный момент времени. Такой подход используется, чтобы было проще запрашивать данные. Возвращаясь к проблеме масштабирования, скажем, что материализованное представление – это просто совокупное представление событий, напоминающее по форме таблицу; но где мы храним эти таблицы? Чаще всего приходится видеть такие агрегации в памяти, и при этом наш сервис автоматически превращается в сохраняющий состояние. Быстрое и легкое решение – снабдить локальной базой данных каждый сервис, создающий материализованные представления. Таким образом, состояние хранится в базе данных, и сервис работает без сохранения состояния.
Хотя, событийно-ориентированная архитектура существует уже более 15 лет, она лишь недавно снискала серьезную популярность, и это неслучайно. Большинство компаний проходят этап «цифровой трансформации», сопровождаемый дикими требованиями. Из-за сложности этих требований инженерам приходится осваивать новые подходы к проектированию ПО, предполагающие, в частности, ослабление связанности сервисов друг с другом и снижение издержек на обслуживание сервисов. EDA — одно из возможных решений этих проблем, но не единственное. Также не рассчитывайте, что все проблемы решатся, стоит только перейти на EDA. Для реализации некоторых фич по-прежнему могут потребоваться надежные дедовские REST API или хранение информации в базе данных. Выберите наиболее подходящий для вас вариант и спроектируйте его как следует!
