WEBVTT

00:00:00.200 --> 00:00:07.200
[이 번역은 Bing번역에 의해 제공됩니다.]


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
또한 일부 고급 지원
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
2013 Visual Studio에서 지 원합니다
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
있는 경우를 고려 하십시오.
여러 끝 점 두 인스턴스입니다.

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
볼 수 있는 내가 어떻게 note
너무 많은 활성 메시지가

00:05:21.780 --> 00:05:26.340
큐, 큐가 있는 경우
만들 뿐

00:05:27.860 --> 00:05:32.940
최대와 같은 중요 한 값
배달 횟수와 최대

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
내 새 큐를 사용할 수
없는 메시지는 볼 수 있습니다 나

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
0.

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
창을 선택 하고자 하는
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
Note 여기 있는 간단한 추적
어떤 메시지를 작성

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 하위 시나리오
정말 만들 수 있습니다.

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
Visual Studio 내의 설비 Azure
2013에서는 매우 쉽습니다.

00:09:58.990 --> 00:10:01.210
이 배로 드립니다
분리 된 응용 프로그램입니다.