tgoop.com/emacsway_log/1388
Last Update:
Наткнулся на интересный набор паттернов обмена сообщениями от Microsoft Azure. Так как это паттерны, реализовать их можно на любых технологиях.
Так сказать, следующий уровень проектирования интеграций, когда вы уже уверенно владеете нюансами REST и представляете, как работают очереди и брокеры, и готовы принимать более тонкие архитектурные решения.
Всего там 42 паттерна, они достаточно произвольно объединены в три категории:
— управление данными,
— архитектура и реализация
— обмен сообщениями.
Это "китайская классификация" по Борхесу; мне, например, сложно понять, почему CQRS — это "архитектура", а хореография — "обмен сообщениями". В любом случае, паттерны интересные, а ещё есть анти-паттерны, как делать не надо — тоже полезно знать при проектировании решения; и архитектурные принципы. Повторюсь, что это довольно общие вещи, относящиеся не только к продуктам на основе Azure — они в том или ином виде реализованы и в AWS, и в других системах.
Все паттерны имеет смысл изучить, если вы собираетесь расти в архитекторы, или хотя бы хотите понимать, о чём они говорят. Но некоторые, связанные с интеграциями и API, встречаются и при проработке решений аналитиками, даже без всяких архитектурных глубин. Я вытащил три штуки, с которыми сталкивался недавно сам или к которым мы приходили с моими менти.
Итак, паттерны:
* Асинхронный запрос-ответ.
В общем, простая идея про запросы, длительность обработки которых на сервере может занять больше, чем 100 мс, а очереди/брокера у вас нет или вы не хотите их использовать — и вы используете поллинг. Первым запросом запускаете процесс на сервере, а сервер возвращает 202 (Accepted) и ссылку, которую нужно поллить. Клиент регулярно ходит по этой ссылке и проверяет — выполнился ли запрос. Пока он не выполнен — сервер возвращает 200 (OK). Когда результат готов — 302 (Found) и переадресует на место, где лежит результат.
Как вариант, тут можно было бы использовать WebHook, но далеко не все клиенты поддерживают вызовы к ним — технически или по соображениям безопасности.
* Квитанция (claim-check).
Если вы собираетесь передавать большой объем данных, имеет смысл не загружать систему передачи (например, брокера или очередь), а выслать "квитанцию" с токеном, по которому клиент сможет забрать ответ из хранилища статических данных. Также паттерн можно использовать, когда нужна дополнительная защита, чтобы чувствительные данные не проходили через брокер/очередь/прокси и т.п. Ну и в принципе неплохо бы защищать статику каким-нибудь токеном, чтобы не было ситуаций с утечкой документов, доступных по прямым адресам без всякой проверки — про это следующий паттерн.
* Valet Key — не знаю, как перевести на русский, видел автоматический перевод "ключ камердинера", но не встречал такого употребления в живой среде. Это как раз токен из предыдущего паттерна: когда вы получаете статический ресурс, если он не должен быть общедоступным — защищайте его токеном. То есть, клиент сначала запрашивает ресурс у приложения, приложение отдает ссылку на ресурс + токен (либо токен зашит прямо в URL), и передает токен хранилищу. Хранилище обрабатывает запрос к ресурсу только с токеном — так гарантируется, что запросивший клиент — именно тот, кому выдали разрешение, а ещё можно ограничить действие токена по времени.
Этот паттерн также описан в книге O'Reilly 'Cloud Architecture Patterns' — хотя остальные паттерны в ней в основном низкоуровневые.
Где можно использовать эти паттерны? Например, при запросе большого отчета, который относительно долго формируется. "Заказать" формирование мы можем через асинхронный запрос и поллинг, либо через очередь запросов, потом получим "квитанцию" с токеном доступа, а сам сформированный отчет ляжет в файловое хранилище. Файловое хранилище отдаст готовый отчет только клиенту, предъявившему квитанцию с токеном. Про истечении времени жизни токена отчет будет удален.
BY emacsway-log: Software Design, Clean Architecture, DDD, Microservice Architecture, Distributed Systems, XP, Agile, etc.
Share with your friend now:
tgoop.com/emacsway_log/1388