Распределенные приложения и Azure Service Bus

Post on 14-Jun-2015

285 Views

Category:

Technology

1 Downloads

Preview:

Click to see full reader

DESCRIPTION

Когда приложения перестают быть монолитными и разделяются на подсистемы, возникает много нюансов. Как спроектировать распределенную систему так, чтобы она оставалась управляемой? Как добиться того, чтобы процессы, в которых задействованы несколько подсистем, остаавалить прозрачными, а данные - согласованными? Какие принципы, технологии и инструменты могут нам помочь? Я расскажу о том, какие задачи мы решаем в одном из внутренних проектов 2ГИС, и почему мы остановились на Azure Service Bus как на инструменте обеспечения взаимодействия подсистем приложения.

Transcript

Распределенные приложения и Azure Service Bus

Денис Иванов

@denisivanov

Класс приложений

-Enterprise

-Важна предметная область

-Автоматизация бизнес-процессов

-Многоэтапные бизнес-операции

Эволюция

Эволюция

-Клиент-серверные, синхронное выполнение

Эволюция

-Фоновые операции

Эволюция

-Декомпозиция бек-энда

Эволюция

-Несколько фронт-эндов

Проблема

Проблема

Проблема

Подходы к проектированию приложений

-Эволюционный/легаси-система

-На основе прошлого опыта

-По примеру существующего приложения

-DDD

Message driven architecture

-Bounded contexts

-Aggregates/aggregate roots

-Commands and events

Демо-приложение

Продажа рекламы- Подбор параметров заказа

- Создание заказа

- Жизненный цикл заказа

2 bounded contexts

Демо-приложение

Производство рекламы- Валидация заказа

- Оформление рекламных материалов

2 bounded contexts

Топология демо-приложения

Используемые технологии

-OWIN

-SignalR

-Service Bus For Windows 1.1

http://devday-net-demo.azurewebsites.net/

Возможности Service Bus For Windows/

Azure Service Bus

-Namespaces

-Brokered/relayed messaging

-Queues/topics

-Subscriptions/routing

-Poison messages (dead letter queue)

Возможности Service Bus For Windows/

Azure Service Bus

-Batching

-Duplicate detection

-Retries, delivery delay, message expires

-AMQP

-REST API

Профиты

-Независимое изменение разных частей приложения

-Отказоустойчивость и динамическая балансировка

-Синхронное или асинхронное выполнение

-Легко реализуемый Task-based UI (wizards)

Напоследок

-Повышение гибкости ведет к усложнению инфраструктуры

-Выберите подходящий способ проектирования

-Определите цели и этапы

-Используйте наиболее удобные инструменты

Вопросы?

Денис Иванов@denisivanovhttps://github.com/denisivan0v

Спасибо

https://github.com/denisivan0v/devday-demo

top related