WEBVTT

00:00:00.200 --> 00:00:07.200
[Переведено системой Bing Translator]


00:00:09.000 --> 00:00:10.900
Здравствуйте. Я Abhishek Lal.

00:00:11.400 --> 00:00:15.360
Я работаю руководителем программы в Windows
Хотите Azure и сегодня я

00:00:15.460 --> 00:00:17.670
поговорим о Windows
Шины служб Azure.

00:00:18.530 --> 00:00:23.350
Шины служб позволяет создавать приложения
и подключить другой

00:00:23.400 --> 00:00:25.990
между уровнями веб-приложений и рабочих правил.

00:00:26.620 --> 00:00:31.190
Это можно использовать для выравнивания низкий
или для разделения где ваш

00:00:31.240 --> 00:00:34.780
веб уровня отправляет сообщения в очередь
и выталкивает уровня вашего работника

00:00:34.830 --> 00:00:36.040
сообщения из них.

00:00:36.620 --> 00:00:41.350
Мы также поддерживает некоторые очень расширенные
сценарии sub pub где издатели

00:00:41.400 --> 00:00:46.100
сообщения можно отправлять на разделы, а затем
имеется несколько подписчиков

00:00:46.450 --> 00:00:50.130
с сообщениями. Сегодня мы перейдем
Рассмотрим некоторые из новой инструментарий

00:00:50.180 --> 00:00:54.920
в Visual Studio 2013, который поддерживает
Разработка с использованием шины служб Azure.

00:00:56.000 --> 00:00:59.980
С Azure вы знаете, что можно
Построение облачных приложений

00:01:00.370 --> 00:01:01.470
для предприятия.

00:01:02.240 --> 00:01:07.320
Одним из ключевых аспектов и один
из ключевых служб в Azure

00:01:07.370 --> 00:01:09.190
представляет собой шину службы Windows Azure.

00:01:10.090 --> 00:01:14.650
Это обеспечивает обмен сообщениями и ретрансляции
что действительно помогает служб

00:01:14.700 --> 00:01:19.070
Разблокирование данных предприятия
а также бизнес-логику.

00:01:22.580 --> 00:01:27.040
С шиной служб Azure сегодня мы будет
сосредоточиться на безопасного обмена сообщениями

00:01:27.090 --> 00:01:33.330
возможности и как их можно включить
для построения решений слабо.

00:01:37.680 --> 00:01:41.330
Кроме того мы можем увидеть
как можно получить некоторые многофункциональные

00:01:41.380 --> 00:01:45.060
Опубликуйте сценарии подписки
с помощью шины служб Azure.

00:01:48.700 --> 00:01:52.570
Когда мы говорим о тесно связаны.
бывает так, приложения

00:01:52.620 --> 00:01:57.020
где возможно, конец магазина
обращение отгрузки

00:01:57.070 --> 00:02:01.790
службы, говорящий непосредственно затем
Для возможно диспетчеризации или

00:02:01.840 --> 00:02:03.090
складские услуги.

00:02:04.400 --> 00:02:09.600
Этот вид прямой системы имеет
Дефект, когда одного конкретного

00:02:09.650 --> 00:02:14.290
Компонент недоступен, скажем
отправлять одно, ошибки

00:02:14.340 --> 00:02:18.560
распространяется способом, поскольку
нет никаких промежуточных

00:02:18.830 --> 00:02:22.030
Отделение для защиты
из этих ошибок.

00:02:22.080 --> 00:02:28.470
В системе более разобщенными
мы видим, что ошибок

00:02:29.710 --> 00:02:32.950
отдельно от переднего плана и
серверной части путем помещения в очередь

00:02:33.000 --> 00:02:33.980
в середине.

00:02:35.450 --> 00:02:40.340
В этом случае все запросы, отправляемые
как сообщения в очереди.

00:02:41.280 --> 00:02:44.580
Затем можно запрашивать системы отслеживания
Эти сообщения и отправлять их

00:02:44.630 --> 00:02:45.890
по для доставки.

00:02:48.000 --> 00:02:52.090
Если для какой-либо причине системы отслеживания
недоступен, не - едва слышимые -

00:02:52.140 --> 00:02:55.910
сообщения от переднего плана
Чтобы перейти в порядке очереди

00:02:56.540 --> 00:02:59.080
и тем самым системы
продолжает работать.

00:02:59.640 --> 00:03:02.840
Эти заказы не будут обработаны.
пока система отслеживания

00:03:02.890 --> 00:03:07.210
обратно в оперативный режим, но на данный момент
Вы сможете получить

00:03:07.260 --> 00:03:10.120
Эти заказы и процесса
их для доставки.

00:03:11.430 --> 00:03:14.990
Все это время как можно было увидеть со свободным
приложения, в сочетании

00:03:15.040 --> 00:03:18.590
Осталось доступно переднего плана
системы отслеживания может

00:03:18.640 --> 00:03:21.040
использоваться автономно для обновления.

00:03:24.680 --> 00:03:28.550
Рассмотрим ситуацию, когда имеется
несколько экземпляров storefront end.

00:03:29.590 --> 00:03:33.400
Может Создание пиковых нагрузок
При наличии большого количества сообщений

00:03:33.450 --> 00:03:36.950
и заказы, из которых создается которой
не удается сохранить системы отслеживания

00:03:37.000 --> 00:03:41.140
Этот момент, задав и вверх с
очереди в середине,

00:03:41.190 --> 00:03:43.220
можно добиться некоторых балансировки нагрузки.

00:03:44.630 --> 00:03:48.900
Это происходит при наличии нескольких экземпляров
системы отслеживания

00:03:48.950 --> 00:03:50.740
Извлечение из одной очереди.

00:03:51.680 --> 00:03:56.290
Главным отличием здесь является то, что
имеется несколько приемников

00:03:56.340 --> 00:04:01.230
на том же очереди и они не
конкуренция для сообщений, поэтому

00:04:01.280 --> 00:04:05.930
одинаковые сообщения никогда не видел на два
экземпляров системы отслеживания

00:04:07.180 --> 00:04:10.830
но вы можете получить некоторые
Балансировка нагрузки, увеличивая

00:04:10.880 --> 00:04:14.830
число рабочих правил, вы можете
службы доставки.

00:04:14.880 --> 00:04:20.900
С этим позвольте мне перейти
Visual Studio и покажу некоторые

00:04:20.950 --> 00:04:25.320
средства для разработчиков, нам нужно включить
в этом случае разработки.

00:04:26.740 --> 00:04:30.480
Является то, что я установил здесь
Сервис Windows Azure облака,

00:04:31.080 --> 00:04:34.880
и здесь на левой стороне в
Серебристая обозревателя, можно

00:04:34.930 --> 00:04:38.550
Чтобы узнать у моей службы
Перечисленные пространства имен шины.

00:04:39.350 --> 00:04:43.530
Если войти в систему и не отображаются
пространства имен доступны здесь, головной

00:04:43.580 --> 00:04:48.540
по для Windows Azure портала
в WindowsAzure.com и обратно

00:04:48.590 --> 00:04:53.160
там вы сможете легко создавать
новое пространство имен, выбрав

00:04:53.210 --> 00:04:55.290
область, которая он находится в.

00:04:58.510 --> 00:05:02.460
С моего пространства имен, перечисленных ниже
Я легко можно перечислить через

00:05:02.510 --> 00:05:05.800
очереди и темы
что создали.

00:05:07.570 --> 00:05:11.330
Необходимо предоставить некоторые дополнительные
Поэтому отладочной информации

00:05:11.380 --> 00:05:14.380
можно перейти к определенной
очереди и просмотрите его свойства.

00:05:18.170 --> 00:05:21.730
Обратите внимание, как я смог увидеть, что у меня есть
большое количество активных сообщений в данном

00:05:21.780 --> 00:05:26.340
очереди, когда очередь
создан, а также

00:05:27.860 --> 00:05:32.940
важные значения как максимум
количество поставки и max

00:05:32.990 --> 00:05:34.090
размер очереди.

00:05:34.780 --> 00:05:38.240
Так можно увидеть все разные
свойства, которые необходимы

00:05:38.290 --> 00:05:39.200
для этой очереди.

00:05:40.050 --> 00:05:44.720
Прямо из Visual Studio имеется
возможность создания новых объектов

00:05:49.960 --> 00:05:53.800
также как и все изменения
ключевые свойства для этого.

00:05:57.790 --> 00:06:02.020
После моей новой очереди
Видите сообщения не имеет I

00:06:02.070 --> 00:06:07.210
фактически можно отправить тестовое сообщение
и можно заметить,

00:06:07.260 --> 00:06:11.150
свойства обновляются и
можно просмотреть все последние новости

00:06:11.200 --> 00:06:14.640
свойства очереди с
Увеличить число активных сообщений

00:06:14.690 --> 00:06:15.160
1.

00:06:16.610 --> 00:06:19.910
Обратите внимание, что он показывает при
Настало время последней очереди

00:06:19.960 --> 00:06:24.710
получен. Я могу получать
сообщение здесь

00:06:26.020 --> 00:06:30.080
и, еще раз принесет активной
Количество сообщений обратно вниз

00:06:30.130 --> 00:06:30.780
нулевое значение.

00:06:33.320 --> 00:06:38.990
Эти средства действительно помогают отладки
и очень, очень богатые подробное

00:06:39.040 --> 00:06:42.290
в активных объектов
с шиной службы.

00:06:44.120 --> 00:06:47.570
Теперь я буду использовать этот
Чтобы создать новый проект

00:06:50.260 --> 00:06:55.410
в котором я собираюсь выбрать Windows
Проект Azure облачного сервиса.

00:06:57.630 --> 00:07:01.160
Несколько шаблонов, которые
для меня, один из них

00:07:01.210 --> 00:07:04.380
Это правило работника с этой очереди шины.

00:07:07.740 --> 00:07:10.600
Который будет добавлен к проекту
и нажмите Создать.

00:07:14.450 --> 00:07:19.170
Что это дает мне является весь код
необходимые для меня список

00:07:19.220 --> 00:07:23.850
на определенной очереди сообщений, а затем
обработать данные конкретного сообщения.

00:07:23.900 --> 00:07:28.250
Теперь у меня есть код загрузки здесь.
Позвольте мне с пошаговыми руководствами для некоторых

00:07:28.300 --> 00:07:30.700
в различных разделах здесь.

00:07:31.990 --> 00:07:36.120
В начале мы создаем определенный
Имя очереди, скажем обработки

00:07:36.170 --> 00:07:36.690
очереди, и

00:07:37.920 --> 00:07:43.410
на этом этапе мы будет, во время выполнения
метод, называемый один метод

00:07:43.460 --> 00:07:45.340
client.on сообщения.

00:07:46.060 --> 00:07:50.890
Инициализация клиента очереди
в методе на начало

00:07:52.910 --> 00:07:56.880
и использует определенной очереди
имя, указанное ранее.

00:07:58.370 --> 00:08:02.000
Я хочу изменить
Моя очередь обработки.

00:08:03.390 --> 00:08:08.520
При внесении сообщение на любой вызов
сообщения, которые становятся доступными

00:08:08.570 --> 00:08:13.780
в этой конечной точке, затем отправляются
функции обработки.

00:08:15.820 --> 00:08:21.120
Здесь следует отметить, что простой трассировки
записи, какие сообщения

00:08:21.170 --> 00:08:22.120
было получено.

00:08:23.050 --> 00:08:26.520
Поэтому в демонстрации показано, как можно
легко создать правило для работника

00:08:26.570 --> 00:08:30.190
проекта и получения
сообщения из очереди.

00:08:31.590 --> 00:08:34.870
Один дополнительные концепции, как требуется
Чтобы показать это раздел.

00:08:35.890 --> 00:08:39.550
В этом случае отправляется по магазинам
сообщений в одной теме

00:08:40.200 --> 00:08:44.190
но они могут быть несколько подписок
что вы получаете

00:08:44.240 --> 00:08:45.820
Эти сообщения.

00:08:46.440 --> 00:08:49.570
Представить себе случай, когда имеется
сценарий - едва слышимые - системы

00:08:49.620 --> 00:08:54.660
и отдельной системы отслеживания.
Здесь будет то же самое сообщение

00:08:55.030 --> 00:08:59.710
для отправки оба и что именно
что происходит в этой

00:08:59.760 --> 00:09:01.820
определенный сценарий.

00:09:02.730 --> 00:09:06.190
При создании подписки можно
можно добавить фильтры к ним которой

00:09:06.240 --> 00:09:08.840
решить, какие сообщения проходят
на какие подписки

00:09:10.130 --> 00:09:14.310
и эти сообщения могут дублироваться.
между ними или

00:09:14.360 --> 00:09:18.040
имеется взаимно исключают друг друга
фильтры, где одно сообщение

00:09:18.090 --> 00:09:19.620
Переход на одну подписку.

00:09:20.720 --> 00:09:25.420
Эти сценарии форматированного типа pub sub
действительно позволяет создавать

00:09:25.470 --> 00:09:29.780
подключенных систем посредством разделения
на интерфейсы, а также к

00:09:29.830 --> 00:09:36.370
уровни работника и достижения очень, очень
масштабируемые и связанных служб.

00:09:36.420 --> 00:09:41.360
С шиной служб Azure мы видели сегодня
как это так просто для построения

00:09:41.410 --> 00:09:46.420
многоуровневые приложения с веб-
уровень и уровни работника

00:09:46.470 --> 00:09:51.020
подключения по очереди или с помощью
Публикация шаблонов подписаться

00:09:51.070 --> 00:09:53.060
разделы и подписки.

00:09:53.730 --> 00:09:58.940
Azure, инструментарию для работы в Visual Studio.
2013 делает очень простым

00:09:58.990 --> 00:10:01.210
для вас эти два раза вверх
раздельное приложения.