WEBVTT

00:00:00.200 --> 00:00:07.200
[Následující překlad vyhotovila služba Bing Translator]


00:00:09.000 --> 00:00:10.900
Hi. Abhishek Lal jsem.

00:00:11.400 --> 00:00:15.360
Jsem Správce programů systému Windows
Azure a v dnešní době má

00:00:15.460 --> 00:00:17.670
hovořit o systému Windows
Azure Service Bus.

00:00:18.530 --> 00:00:23.350
Service Bus umožňuje vytváření aplikací
a připojit různé

00:00:23.400 --> 00:00:25.990
pravidla mezi úrovní webu a pracovníka.

00:00:26.620 --> 00:00:31.190
Tímto způsobem můžete pro vyrovnání málo
nebo oddělení, kde vaše

00:00:31.240 --> 00:00:34.780
Webová vrstva odesílá zprávy do fronty
a vaše pracovní vrstvy si

00:00:34.830 --> 00:00:36.040
zprávy mimo ně.

00:00:36.620 --> 00:00:41.350
Podporováno je také některé velmi pokročilé
scénáře sub pub kde vydavatelů

00:00:41.400 --> 00:00:46.100
zprávy lze odesílat do témat a potom
Máte několik účastníků

00:00:46.450 --> 00:00:50.130
se zprávami. Dnes přejdeme
Podívejte se na některé z nových nástrojů

00:00:50.180 --> 00:00:54.920
v aplikaci Visual Studio 2013, který podporuje
vývoj s Azure Service Bus.

00:00:56.000 --> 00:00:59.980
S Azure vědět, zda je možné
vytváření aplikací měřítko cloud

00:01:00.370 --> 00:01:01.470
pro rozlehlou síť.

00:01:02.240 --> 00:01:07.320
Jedním z klíčových aspektů a jeden
klíčové služby v Azure

00:01:07.370 --> 00:01:09.190
je sběrnice služeb Windows Azure.

00:01:10.090 --> 00:01:14.650
To umožňuje zasílání zpráv a přenos
Služba pomáhá Opravdu

00:01:14.700 --> 00:01:19.070
Odemknout podnikových dat
a obchodní logiku.

00:01:22.580 --> 00:01:27.040
S Azure Service Bus dnes bude
Zaměřte se na bezpečné zpracování zpráv

00:01:27.090 --> 00:01:33.330
schopnosti a jak to umožňují
k vytvoření volně vázaném řešení.

00:01:37.680 --> 00:01:41.330
Kromě toho budeme v tématu
jak lze dosáhnout některých rich

00:01:41.380 --> 00:01:45.060
publikování scénáře odběru
pomocí sběrnice služby Azure.

00:01:48.700 --> 00:01:52.570
Kdy můžeme hovořit o úzce spolu
aplikace se stává

00:01:52.620 --> 00:01:57.020
kdy může být úložiště front end
mluvíte přímo do expedice

00:01:57.070 --> 00:02:01.790
služby, které pak přímo pojednává
možná odeslání nebo

00:02:01.840 --> 00:02:03.090
skladové služby.

00:02:04.400 --> 00:02:09.600
Tento druh přímé systému
Chyba který po jedné konkrétní

00:02:09.650 --> 00:02:14.290
komponenta není k dispozici, že
odeslání jedné, jsou chyby

00:02:14.340 --> 00:02:18.560
šíří směrem zpět, protože
neexistuje žádný vnitřní

00:02:18.830 --> 00:02:22.030
oddělení pro ochranu
z těchto chyb.

00:02:22.080 --> 00:02:28.470
Další volně vázaném systému
vidíme, že jsou chyby

00:02:29.710 --> 00:02:32.950
decoupled z přední a
serverová část vložením do fronty

00:02:33.000 --> 00:02:33.980
ve středu.

00:02:35.450 --> 00:02:40.340
V takovém případě jsou odeslány všechny požadavky
jako zprávy do fronty objednávce.

00:02:41.280 --> 00:02:44.580
Pak táhnout systém sledování
Tyto zprávy a odešlete

00:02:44.630 --> 00:02:45.890
po dodání.

00:02:48.000 --> 00:02:52.090
Pokud z nějakého důvodu systém sledování
není k dispozici, ne - nejsou slyšitelná -

00:02:52.140 --> 00:02:55.910
zprávy z přední
Chcete-li přejít do fronty objednávku

00:02:56.540 --> 00:02:59.080
a tím systém
pokračuje v práci.

00:02:59.640 --> 00:03:02.840
Tyto objednávky nebudou zpracovány.
do systému sledování

00:03:02.890 --> 00:03:07.210
je zpět do režimu online, ale v daném okamžiku
budete moci načíst

00:03:07.260 --> 00:03:10.120
tyto objednávky a proces
jejich dodání.

00:03:11.430 --> 00:03:14.990
Tento čas, jak jste již viděli s volným
aplikace, spolu

00:03:15.040 --> 00:03:18.590
Klientská část zůstala k dispozici při
Sledování systému

00:03:18.640 --> 00:03:21.040
být přijata offline pro inovace.

00:03:24.680 --> 00:03:28.550
Zvažte situaci, ve které máte
několik instancí storefront konec.

00:03:29.590 --> 00:03:33.400
Může být generování zatížení ve špičce
jsou-li velké množství zpráv

00:03:33.450 --> 00:03:36.950
a objednávky, je generována, které
systém sledování nelze zachovat.

00:03:37.000 --> 00:03:41.140
s nahoru a tento bod tím, že
spuštění fronty pořadí ve středu

00:03:41.190 --> 00:03:43.220
Některé zátěže lze dosáhnout.

00:03:44.630 --> 00:03:48.900
To je, pokud máte více instancí
Sledování systému

00:03:48.950 --> 00:03:50.740
vytažení z jedné fronty pořadí.

00:03:51.680 --> 00:03:56.290
Klíčovou předností je, že
máte více přijímačů

00:03:56.340 --> 00:04:01.230
na stejné fronty a jsou
soutěžící zpráv proto

00:04:01.280 --> 00:04:05.930
stejná zpráva je nikdy neuvidí dvě
instancemi Sledování systému

00:04:07.180 --> 00:04:10.830
ale jste schopni dosáhnout některých
Služba Vyrovnávání zatížení zvýšením

00:04:10.880 --> 00:04:14.830
počet pracovních pravidel, které máte
služby námořní dopravy.

00:04:14.880 --> 00:04:20.900
S tímto manuální přepnutí na
Visual Studio a ukázat vám některé

00:04:20.950 --> 00:04:25.320
Vývojář nástrojů máme povolení
vývoj v tomto scénáři.

00:04:26.740 --> 00:04:30.480
Co jsem nainstaloval sem je
Nástroje Windows Azure Cloud

00:04:31.080 --> 00:04:34.880
a zde na levé straně v
Stříbrná Explorer je možné

00:04:34.930 --> 00:04:38.550
Chcete-li zjistit, že mám Moje služby
Uvedené prostory název sběrnice.

00:04:39.350 --> 00:04:43.530
Pokud jste přihlášení a nejsou
obor názvů k dispozici zde hlavy

00:04:43.580 --> 00:04:48.540
v systému Windows Azure portálu
v WindowsAzure.com a z

00:04:48.590 --> 00:04:53.160
Zde bude možné snadno vytvořit.
Nový obor názvů tak, že vyberete

00:04:53.210 --> 00:04:55.290
které oblasti je umístěn v.

00:04:58.510 --> 00:05:02.460
Můj název mezerami uvedeny zde
I mohou snadno vyčíslovat

00:05:02.510 --> 00:05:05.800
fronty a témata
které jsem vytvořil.

00:05:07.570 --> 00:05:11.330
Můžeme vám poskytnout některé další
tak ladicí informace

00:05:11.380 --> 00:05:14.380
můžete přejít konkrétní
frontě a zobrazit jeho vlastnosti.

00:05:18.170 --> 00:05:21.730
Všimněte si, jak jsem schopen vidět, že jsou
hodně aktivní zprávy v této

00:05:21.780 --> 00:05:26.340
fronty, kdy byla fronta
vytvořili, stejně jako

00:05:27.860 --> 00:05:32.940
důležité hodnoty, jako maximální
Počet doručení a max

00:05:32.990 --> 00:05:34.090
velikost fronty.

00:05:34.780 --> 00:05:38.240
Tak je vidět všechny různé
vlastnosti, které jsou nezbytné

00:05:38.290 --> 00:05:39.200
pro tuto frontu.

00:05:40.050 --> 00:05:44.720
Vpravo jsou z aplikace Visual Studio
schopnost vytvářet nové objekty

00:05:49.960 --> 00:05:53.800
stejně jako všechny upravit
vlastnosti tohoto klíče.

00:05:57.790 --> 00:06:02.020
Jakmile mé nové fronty je k dispozici
Vidím, že nemá žádné zprávy I

00:06:02.070 --> 00:06:07.210
ve skutečnosti můžete odeslat zkušební zprávu
Chcete-li jej a zjistíte, že

00:06:07.260 --> 00:06:11.150
vlastnosti jsou aktualizovány a
Zobrazit všechny nejnovější

00:06:11.200 --> 00:06:14.640
vlastnosti fronty s
Zvýšit počet aktivních zpráv

00:06:14.690 --> 00:06:15.160
1.

00:06:16.610 --> 00:06:19.910
Nezapomeňte, že zobrazuje při
byl čas poslední fronta

00:06:19.960 --> 00:06:24.710
bylo přistupováno. Příjem můžete přejít
zpráva zde

00:06:26.020 --> 00:06:30.080
a že znovu zobrazíte aktivní
Počet zpráv zpět

00:06:30.130 --> 00:06:30.780
na nulu.

00:06:33.320 --> 00:06:38.990
Tyto nástroje skutečně pomoci při ladění
a velmi bohaté

00:06:39.040 --> 00:06:42.290
do aktivní subjekty
s Service Bus.

00:06:44.120 --> 00:06:47.570
Nyní používat to kliknu
Chcete-li vytvořit nový projekt

00:06:50.260 --> 00:06:55.410
ve kterém kliknu zvolte Windows
Projekt služby Azure Cloud.

00:06:57.630 --> 00:07:01.160
Několik šablon, které jsou
pro mě jeden z nich k dispozici.

00:07:01.210 --> 00:07:04.380
je pravidlo pracovníka k této frontě sběrnice.

00:07:07.740 --> 00:07:10.600
Který přidám k projektu
a klepněte na možnost vytvořit.

00:07:14.450 --> 00:07:19.170
Co to dává mi je veškerý kód
potřeby pro mě přejít seznam

00:07:19.220 --> 00:07:23.850
na určité fronty zpráv a poté
zpracovat tyto konkrétní zprávy.

00:07:23.900 --> 00:07:28.250
Nyní jste zde načíst kód.
Manuální vás provedou některé

00:07:28.300 --> 00:07:30.700
z různých částí zde.

00:07:31.990 --> 00:07:36.120
Na začátku vytvoříme konkrétní
Název fronty, Řekněme zpracování

00:07:36.170 --> 00:07:36.690
fronty, a

00:07:37.920 --> 00:07:43.410
v tomto okamžiku jsme se v běhu
Metoda, jen jednu metodu.

00:07:43.460 --> 00:07:45.340
client.on zprávy.

00:07:46.060 --> 00:07:50.890
Klienta fronty je inicializován.
v metodě na start

00:07:52.910 --> 00:07:56.880
a používá určité fronty.
název, který jste zadali dříve.

00:07:58.370 --> 00:08:02.000
Bude to změna
Moje fronty zpracování.

00:08:03.390 --> 00:08:08.520
Pokud provedete zprávu o každém volání
zprávy, které jsou k dispozici

00:08:08.570 --> 00:08:13.780
na tento koncový bod jsou potom odeslány
Chcete-li funkce zpracování.

00:08:15.820 --> 00:08:21.120
Poznámka: Zde že jsou jednoduché trasování
psaní, jaká chybová zpráva

00:08:21.170 --> 00:08:22.120
byla přijata.

00:08:23.050 --> 00:08:26.520
Takže v ukázku jste viděli, jak lze
snadno vytvořit pravidlo pracovního

00:08:26.570 --> 00:08:30.190
projekt a přijímat na
zprávy z fronty.

00:08:31.590 --> 00:08:34.870
Jeden další pojem, který má
zobrazení je téma.

00:08:35.890 --> 00:08:39.550
V tomto případě odesílání obchody
zprávy na jedno téma

00:08:40.200 --> 00:08:44.190
ale může být více odběry
které přijímají

00:08:44.240 --> 00:08:45.820
Tyto zprávy.

00:08:46.440 --> 00:08:49.570
Považovat případ, kdy máte
skript - nejsou slyšitelná - systému

00:08:49.620 --> 00:08:54.660
a oddělené sledování systému.
Zde má stejnou zprávu.

00:08:55.030 --> 00:08:59.710
e i a že je přesně
Co se děje v tomto

00:08:59.760 --> 00:09:01.820
konkrétní scénář.

00:09:02.730 --> 00:09:06.190
Při vytvoření předplatného je
můžete přidat filtry k nim, které

00:09:06.240 --> 00:09:08.840
rozhodnout, které zprávy přejít
na které předplatné

00:09:10.130 --> 00:09:14.310
a tyto zprávy můžete duplikovat.
mezi odběry nebo

00:09:14.360 --> 00:09:18.040
Můžete mít vzájemně se vylučujících
Pokud jedna zpráva filtry

00:09:18.090 --> 00:09:19.620
Přejde na jeden odběr.

00:09:20.720 --> 00:09:25.420
Tyto scénáře sub pub druh formátu RTF
ve skutečnosti umožňuje vytvořit

00:09:25.470 --> 00:09:29.780
Oddělení propojených systémů
váš front-endy stejně jako vaše

00:09:29.830 --> 00:09:36.370
úrovně pracovníků a dosáhnout velmi
škálovatelné a spojené služby.

00:09:36.420 --> 00:09:41.360
S Azure Service Bus jsme viděli dnes
jak se tak snadno vytvářet

00:09:41.410 --> 00:09:46.420
vícevrstvých aplikací pomocí webových
vrstvy a vrstvy pracovníka

00:09:46.470 --> 00:09:51.020
připojené prostřednictvím fronty nebo pomocí
Publikovat odběru vzorků

00:09:51.070 --> 00:09:53.060
témata a odběry.

00:09:53.730 --> 00:09:58.940
Azure nástroje aplikace Visual Studio
2013 je skutečně snadné

00:09:58.990 --> 00:10:01.210
Abyste tyto double up
oddělený aplikací.

