WEBVTT 00:00:01.460 --> 00:00:02.340 Dobré odpoledne. 00:00:04.930 --> 00:00:05.880 Jak provádíte TWAIN 00:00:08.810 --> 00:00:14.600 Dobrý? Že provedení je téměř na konec konference. 00:00:15.630 --> 00:00:17.150 Jak se zkušenosti bylo doposud? 00:00:17.160 --> 00:00:19.360 [Potlesk] 00:00:19.520 --> 00:00:20.120 >> Dobré. 00:00:20.170 --> 00:00:24.940 Super. Dobře, jak se říká, že vždy uložte nejlepší pro poslední. 00:00:26.240 --> 00:00:32.190 I tak Doufáme, že nebude disappoint jste že. Velice rádi 00:00:32.240 --> 00:00:34.450 váš takže toto odpoledne. 00:00:35.200 --> 00:00:40.360 Abhishek Lal jsem. Správce programů s týmem Azure platformu. 00:00:41.090 --> 00:00:45.840 To je tým, který je založen na PaaS služby jako jsou mobilní služby 00:00:45.890 --> 00:00:48.550 Service Bus, Azure mezipaměti. 00:00:49.240 --> 00:00:51.080 A media services. 00:00:51.720 --> 00:00:54.320 Jaké jsou tyto služby vlastní tým. 00:00:54.830 --> 00:00:58.940 A konkrétně I jste práci poslední tři plus let 00:00:58.990 --> 00:01:05.100 na budování brokered zasílání zpráv kousky. Tak to je front, 00:01:05.150 --> 00:01:08.720 témata jsou pub sub kusy. 00:01:09.470 --> 00:01:15.150 Dnes jsme se mluví o zasílání zpráv v měřítku. 00:01:17.010 --> 00:01:22.030 Fronty a témata. Nyní jsou TWAIN znáte servisní sběrnice. 00:01:22.840 --> 00:01:26.920 To zahrnuje předávání. Ano zahrnuje oznámení rozbočovač 00:01:27.780 --> 00:01:29.010 fronty a témata. 00:01:29.560 --> 00:01:34.840 Je tedy sort z celé šíře služby týkající se zasílání zpráv. 00:01:35.710 --> 00:01:39.560 Tento konkrétní relace bude Zaměřte se především na fronty 00:01:39.610 --> 00:01:46.260 a témata tak, aby se primární oblast. Ale pokud máte otázky 00:01:46.310 --> 00:01:50.120 nebo cokoliv, co byste chtěli vědět konkrétně o přenosu nebo 00:01:50.170 --> 00:01:55.150 oznámení rozbočovače, jsem rád, že k Odpovězte, nebo alespoň bod. 00:01:55.200 --> 00:01:57.410 se správným směrem. 00:01:58.820 --> 00:02:00.930 Existuje mnoho věcí Chci dnes pokrytí. 00:02:01.710 --> 00:02:04.730 Hovořit o různých aspektech stupnice. Chci hovořit 00:02:04.780 --> 00:02:08.490 o odesílatel a příjemce a propustnost všech různých 00:02:08.540 --> 00:02:11.630 vzorky, jakož Popis kódu. 00:02:12.390 --> 00:02:14.870 O jak můžete dosáhnout měřítko. 00:02:15.810 --> 00:02:19.040 Zkusím to udržovat správné tempo. 00:02:19.640 --> 00:02:24.190 Otázky jsou výborné. Pokud mě vidíte Počáteční vyjmout krátké otázky 00:02:24.240 --> 00:02:27.780 o něco později, právě tak, aby I může zahrnovat všechny položky, které mají být 00:02:27.830 --> 00:02:31.490 k pokrytí. I budou k dispozici po relace a je vždy možné 00:02:31.540 --> 00:02:36.200 oslovujete mne, ale ponechat interaktivní. Cokoliv, co máte, 00:02:36.250 --> 00:02:41.270 mikrofony jsou tady. Stačí Procházet a I budete volat. 00:02:43.930 --> 00:02:48.720 Jsme začnete tím, že mluví o tom, co je Nový. Řazení pouze aktualizace 00:02:48.770 --> 00:02:51.210 na co jsme jste oznámila jako SDK 2.3. 00:02:52.250 --> 00:02:56.290 Můžeme přepínat na mluví o rozměry měřítka. 00:02:56.340 --> 00:03:00.420 Jsme budete hovořit o odesílatele, příjemce, propustnost, jak můžete toho dosáhnout. 00:03:01.800 --> 00:03:05.770 A pak jsme budete trávit nějaký čas důležité informace o dostupnosti. 00:03:05.820 --> 00:03:07.850 Dostupnost pouze veřejně tj. 00:03:09.190 --> 00:03:14.340 odolnost, lepší SLA a jak Chcete-li navrhnout aplikaci tak, aby 00:03:14.390 --> 00:03:19.520 být vždy nahoru, stále, systémem že proto jsme některé budete trávit 00:03:19.570 --> 00:03:20.510 čas na tomto. 00:03:22.060 --> 00:03:25.780 2.3 to SDK. 00:03:26.330 --> 00:03:28.310 Co právě uvolníme? 00:03:29.070 --> 00:03:32.540 Na zprávu relaci. Člena atd. jsou push juries 00:03:32.590 --> 00:03:36.970 Styl rozhraní API. V podstatě trvá okamžitě tvrdé práce od vás 00:03:37.020 --> 00:03:42.960 vytváření smyček C nebo nic. Tato složitost a 00:03:43.010 --> 00:03:46.420 umožňuje velmi události jiné model zpracovávat zprávy. 00:03:46.470 --> 00:03:50.110 Jedná se o rozhraní API straně přijímače. Tak zde máme, pro relace. 00:03:50.160 --> 00:03:52.680 Jednoznačně jsme bude vztahovat podrobněji dnes. 00:03:53.890 --> 00:03:58.440 Režim připojení, automatické rozpoznání. Tak jak víte, jeden z reálné 00:03:58.490 --> 00:04:02.520 Hodnota klíče byl Azure Service Bus že pokud se připojujete 00:04:02.950 --> 00:04:07.700 fronty a témata v cloudu zpoza brány firewall z 00:04:07.750 --> 00:04:11.450 vlastní datová centra nebo z vašeho Zákazníci datová centra, které 00:04:11.500 --> 00:04:16.230 budou sedět vzadu velmi dobře chráněn sort z bran firewall Service 00:04:16.280 --> 00:04:19.660 Sběrnice má schopnost provádět odchozí připojení na portu TCP nejen 00:04:19.710 --> 00:04:22.110 ale port 83 a 443 00:04:23.670 --> 00:04:25.860 zatímco porty TCP jsou blokovány. 00:04:26.700 --> 00:04:30.790 Toto zařízení bude nyní dostupné pouze v případě, že nastavíte přímo 00:04:30.840 --> 00:04:34.230 adresář s režimem protokolu TCP, takže nikdy neměli výběr. 00:04:34.910 --> 00:04:38.730 Nyní ve svém kódu můžete pouze nastavit tak, aby automaticky rozpoznat a bude 00:04:38.780 --> 00:04:42.910 automaticky zjistit, zda je TCP port k dispozici, použijeme. 00:04:42.960 --> 00:04:48.410 Pokud je brána firewall blokuje ji, bude Umístěte jej na protokolu HTTP. Ano SDK 00:04:48.460 --> 00:04:51.560 2.3, který je k dispozici pro zasílání zpráv. 00:04:54.390 --> 00:04:57.980 CORS podporu. Kolik TWAIN víte, co je CORS? 00:05:00.360 --> 00:05:04.200 Většina TWAIN o tom nevíte. Je v podstatě umožňuje snadné odesílání a přijímání 00:05:04.250 --> 00:05:09.370 z prohlížečů. Takže myšlenka je Můžete mít vždy provést, máte 00:05:09.420 --> 00:05:14.320 STPI s SCTP. Stačí odeslat zprávy, zprávy 00:05:14.370 --> 00:05:18.920 ale s CORS nyní umožňuje mnohem usnadňuje prohlížečů a webových stránek 00:05:18.970 --> 00:05:23.650 Chcete-li integrovat zpět a budeme se potápět. na který je dnes podrobně. 00:05:25.010 --> 00:05:29.530 Podobně druh pomoci s výkon, jakož i měřítka 00:05:29.580 --> 00:05:34.760 HTTP odesílatelům zde máme dávkování nyní k dispozici. 00:05:35.200 --> 00:05:43.980 A pak pár perf straně klienta čítače, které je při práci 00:05:44.030 --> 00:05:46.900 ve skutečnosti přepnutí aplikace což je složité nebo si 00:05:46.950 --> 00:05:50.450 Chcete-li spustit v různých prostředích bude pravděpodobně nutné 00:05:50.500 --> 00:05:53.340 ladění a možná budete potřebovat k profilu je tak jsme přidali klienta 00:05:53.390 --> 00:05:57.890 čítače výkonu straně odeslaných zpráv za druhé, písmen za sekundu 00:05:57.940 --> 00:06:01.460 a věci, které lze ve skutečnosti, Opravdu vám profil 00:06:01.510 --> 00:06:05.250 Co jsou zprávy je vrstva Tím jste celkově opačné 00:06:05.300 --> 00:06:09.020 dělá se příležitosti. Takže ty, které budou potom manifest pro ty perf 00:06:09.070 --> 00:06:14.230 čítače jako součást balíčku NuGet v něm tak skutečně umožňuje 00:06:14.280 --> 00:06:17.550 nemusíte dělat dobré ladění. 00:06:20.550 --> 00:06:23.340 A nakonec ForwardTo fronty nedoručených zpráv. 00:06:23.880 --> 00:06:27.380 Deadlettering je velmi výkonné Funkce, které chrání 00:06:27.430 --> 00:06:30.820 Jsi zpět končí, pokud jsou poškozená zprávy. Zpravidla se jedná o 00:06:30.870 --> 00:06:34.620 jen poškozená fronty, kde se můžete pokusit příjem zprávy a 00:06:34.670 --> 00:06:38.600 zpráva není vytvořena, nebo je chyby v kódu někde 00:06:38.650 --> 00:06:42.080 na v někde de civilizer Pokud si nejste schopni otevřít 00:06:42.130 --> 00:06:44.560 zpráva a dojde k chybě v back-end. 00:06:45.780 --> 00:06:50.390 Service Bus poskytuje možnost Nastavení maximální dodávky 00:06:50.440 --> 00:06:54.420 počet, který je ve výchozím nastavení je 10 a jaké znamená to, že pokud vidíme 00:06:54.470 --> 00:06:57.660 že jste můžeme doručit zprávy Chcete-li je 10 krát a mít 00:06:57.710 --> 00:07:01.310 není úspěšně dokončena zpráva, jsme se přesunout z 00:07:01.360 --> 00:07:03.240 hlavní fronty do fronta nedoručených zpráv. 00:07:03.870 --> 00:07:07.930 Tak to doslova pomáhá aplikace být odolné ve výchozím nastavení 00:07:08.190 --> 00:07:12.840 aniž by bylo nutné napsat jediný řádek kódu a chránit 00:07:12.890 --> 00:07:18.660 vaše servery back-end. Tak ForwardTo je schopnost kanálu 00:07:18.710 --> 00:07:23.810 zprávy automaticky vytvořit ve formátu RTF zpráva toky a nyní 00:07:23.860 --> 00:07:30.000 aplikace, které by mohly získat 6, 8, 10 fronty a ForwardTo 00:07:30.050 --> 00:07:34.450 do fronty nedoručených zpráv do jediné fronty, což znamená 00:07:34.500 --> 00:07:38.530 Nyní budete mít jedno místo, chcete-li přejít nyní přijímání nechtěných zpráv 00:07:38.980 --> 00:07:42.340 bez ohledu na to, kolik front nebo témata nebo odběry je 00:07:42.390 --> 00:07:46.280 používáte tak to je potřebujete funkce Přidat příliš. 00:07:47.180 --> 00:07:49.910 Jsme v pokryje trochu podrobněji. 00:07:51.740 --> 00:07:57.570 Chcete rychle na co recap jsme provedli od posledního dne 00:07:57.620 --> 00:08:01.400 vzhledem k tomu, že když budeme hovořit o dnes v podmínky výkonu a měřítko 00:08:01.450 --> 00:08:05.780 a propustnost uvidíte velké množství Tyto funkce je odkazováno 00:08:06.180 --> 00:08:08.570 to právě chci volat jim do podmínek, zda jsou 00:08:08.620 --> 00:08:12.370 jste již k dispozici dnes a jejich byl po nějakou dobu ale 00:08:12.420 --> 00:08:16.250 v ní jsou stále relevantní. 00:08:18.520 --> 00:08:22.290 Jedna věc, viz zde slouží pod řádkem první 00:08:22.340 --> 00:08:26.310 Bus Service na promise to poslední rok, kterou jsme provedli Service Bus 00:08:26.360 --> 00:08:28.900 1.1 pro vydání systému Windows server. 00:08:29.580 --> 00:08:33.210 Toto je zcela symetrické pro fronty a témata, což znamená 00:08:33.260 --> 00:08:37.450 Pokud například vyskladnění nahoru SDK 2.1 která byla poslední SDK 00:08:38.470 --> 00:08:42.010 by mohli na obou přístupů služby nebo na premise všechny 00:08:42.060 --> 00:08:45.070 Funkce, které jsou k dispozici. 00:08:46.760 --> 00:08:51.600 Tento cadence řazení vydání cloud každé tři měsíce je 00:08:51.650 --> 00:08:55.290 můžete vidět každé tři až čtyři měsíce. a na místní verzi na 00:08:55.340 --> 00:08:59.520 nejméně jednou za rok se můžeme pokusit k údržbě a přepněte oba 00:08:59.570 --> 00:09:02.680 Tato funkce nastaví do parity. 00:09:05.540 --> 00:09:08.740 To je k dispozici referenční později z hlediska 00:09:08.790 --> 00:09:10.010 funkce. 00:09:12.110 --> 00:09:13.310 Případné dotazy, pokud? 00:09:15.820 --> 00:09:16.720 Ano, prosím. 00:09:16.730 --> 00:09:19.730 [Indiscernible] 00:09:19.950 --> 00:09:23.560 >> To byla otázka: kdy bude. být další aktualizace a kde 00:09:23.610 --> 00:09:28.920 můžeme uvést 2.3, nejnovější funkce k dispozici. 00:09:28.970 --> 00:09:33.240 Aktuálně není k dispozici všechna data Chcete-li sdílet další služby 00:09:33.290 --> 00:09:36.320 Bude ale uvolnění sběrnice být 2.2 nebo 1.2. 00:09:37.800 --> 00:09:42.620 Ale obvykle si lze představit to zvláštní vydání tohoto data 00:09:43.340 --> 00:09:46.900 odpovídající verze systému Windows Server takže ve většině případů se pokuste 00:09:46.950 --> 00:09:51.580 Chcete-li zarovnat s verzemi serveru to můžeme získat maximální platform 00:09:51.630 --> 00:09:55.010 výhody tak jsme Ujistěte se, že máme největší server s nejnovější 00:09:55.060 --> 00:09:59.310 s nejnovější správy clusterů a defaces a vše. 00:09:59.360 --> 00:10:03.610 To obvykle stačí pokyny předpokládají že stejný druh cadence 00:10:03.660 --> 00:10:05.820 bude následovat. Dobrou otázku. 00:10:08.920 --> 00:10:13.130 Měřítka na odesílatele. Začněme to z hlediska první 00:10:13.180 --> 00:10:14.210 aspekt měřítko. 00:10:15.570 --> 00:10:18.650 Takže odesílatelů je nic, ale jiném kde máte 00:10:18.660 --> 00:10:20.040 [Indiscernible] 00:10:20.000 --> 00:10:22.830 Můžete si představit mnoho scénářů v tomto poli. Si lze představit zařízení 00:10:22.880 --> 00:10:24.970 telemetrické, akce uživatele. 00:10:26.630 --> 00:10:31.030 A systémy generování událostí a B-B druh scénáře. 00:10:31.080 --> 00:10:32.910 Probíhá generování události. 00:10:33.640 --> 00:10:37.660 Jak budete starat o scénáře Pokud máte mnoho z těchto 00:10:37.710 --> 00:10:41.620 nebo možná některé z nich s velkým události nebo více odesílatelů 00:10:41.670 --> 00:10:45.250 s velkým množstvím události? Všech těchto jsou možné scénáře. 00:10:46.830 --> 00:10:50.480 Tak my jej dáme betonu. Bude Začněte s skutečný scénář 00:10:50.530 --> 00:10:54.510 kteří zákazníci jsou použití pro dnešní den což je, pokud máte 00:10:54.560 --> 00:10:58.850 shromažďovat události pro analýzu z velký počet zařízení. 00:11:00.370 --> 00:11:05.900 Tato zařízení mohou vypadat známých ale to je shoda, 00:11:05.950 --> 00:11:11.000 I bude potvrdit ani Odepřít. To může být jakékoli zařízení. 00:11:11.050 --> 00:11:12.350 Může být libovolné zařízení. 00:11:13.160 --> 00:11:18.850 Nyní všechny to začíná zařízení bylo možné do fronty v 00:11:18.900 --> 00:11:24.250 zprávy, je možné využít několika témata nebo jedno téma a push 00:11:24.300 --> 00:11:28.090 ve velké množství informací do tohoto kanálu. 00:11:29.520 --> 00:11:33.640 Jakmile máte zprávy v tématu myslíte, že můžete 00:11:34.710 --> 00:11:39.370 mají několik scénářů, ve kterém Chcete ho zpracovat. 00:11:39.420 --> 00:11:43.330 Realtime analytics nebo co by se pomocí vlastního kódu je 00:11:43.380 --> 00:11:48.570 ve skutečnosti převaze mnohem více a Oblíbené. Provedl TWAIN 00:11:48.620 --> 00:11:53.840 tak, aby relace Orléans které bylo včera? Dobře, pokud 00:11:53.890 --> 00:11:57.080 jste Super, Super kus technologie vzhledem k tomu, že se pokusí o 00:11:57.130 --> 00:12:02.580 Chcete-li vyřešit tento problém spuštěním aplikace kód v měřítku v distribuovaná 00:12:02.630 --> 00:12:06.190 zda se zabývají dotazování události, které jsou generovány 00:12:06.240 --> 00:12:10.830 velký počet odesílatelů a jsou Vazba v tom every způsobem. 00:12:12.020 --> 00:12:15.930 Jak tedy se ujistěte se, že tyto systémy back-end se nevrací? 00:12:15.980 --> 00:12:18.590 Jak se ujistěte se, že tyto Serverové systémy jsou schopny 00:12:18.640 --> 00:12:24.640 přijímat zprávy touto rychlostí a jednat způsoby, které jsou odolné? 00:12:25.950 --> 00:12:29.560 A pro který umístíte do témat uprostřed. To není pouze témata 00:12:29.610 --> 00:12:33.440 poskytnout vyrovnávací paměti, stejně jako by do fronty, což znamená 00:12:33.490 --> 00:12:35.950 back-end by mohlo být provedeno pro několik hodin a není 00:12:36.000 --> 00:12:39.060 ke ztrátě událostí. Události stále tam pobyt, ale jejich 00:12:39.110 --> 00:12:40.490 také vám pub sub. 00:12:41.470 --> 00:12:45.530 Což znamená, že pokud máte jiné systémy, které jsou právě tím 00:12:45.580 --> 00:12:51.310 sledování stavu, Řekněme, že uvedení hodnoty do Azure kabely nebo 00:12:51.360 --> 00:12:56.520 dělají analytics dávky s propojení strukturu souboru v 00:12:56.570 --> 00:13:00.330 HDFS a potom spusťte Hadoop práce na něm. 00:13:01.400 --> 00:13:05.850 Nebo jejich výška se uvedení je právě data do datového skladu SQL 00:13:05.900 --> 00:13:09.170 a spouštění dotazů BI v horní části daného. 00:13:09.790 --> 00:13:13.980 Všechny tyto systémy lze přejít hledat při stejném proudu událostí. 00:13:15.280 --> 00:13:18.350 A ne pouze jednoho proudu událostí, vypadají na jeho události 00:13:18.400 --> 00:13:21.780 datový proud, příliš. Možná pracovat BI skladu, nechcete využívat 00:13:21.830 --> 00:13:25.870 všechny události. Žádné akce související s události zde nepatří. 00:13:25.920 --> 00:13:29.420 Náleží pouze pro kód položky. Můžete rozdělit datové proudy 00:13:29.470 --> 00:13:30.210 Tímto způsobem. 00:13:32.750 --> 00:13:36.990 A pak z vašeho back-end, zda Při čtení vašeho Azure 00:13:37.040 --> 00:13:41.730 tabulky nebo SQL datového skladu, můžete vygenerovat vaše flám 00:13:41.780 --> 00:13:43.200 desky a analytics. 00:13:44.750 --> 00:13:45.750 Tak jeden klíč 00:13:46.970 --> 00:13:49.340 bodů v tomto paketu. 00:13:50.180 --> 00:13:52.920 Nejdříve je pomocí témata pro ventilátor v. 00:13:53.960 --> 00:13:57.730 Ventilátor v základní znamená, že mají méně témata, než budete mít zařízení. 00:13:57.780 --> 00:13:59.900 Doprava? Co je který může být mohutnosti. 00:14:01.080 --> 00:14:03.820 Bude pravděpodobně třeba jeden. Není umístěna na jednu 00:14:03.870 --> 00:14:07.660 téma pro všechno. Je to pravděpodobně Ne, bude jednat, N. umožňuje přechod 00:14:07.710 --> 00:14:12.220 Chcete-li být někde mezi nimi a jako Můžeme hovořit o tom, jak přijít 00:14:12.270 --> 00:14:13.860 s tímto číslem vpravo. 00:14:14.410 --> 00:14:18.960 Chcete-li načíst zůstatek přes datová centra, z několika důvodů. 00:14:19.320 --> 00:14:22.490 Pokud si myslíte o těchto zařízení jsou ve skutečnosti zeměpisně 00:14:23.190 --> 00:14:26.300 rozložit, tak má být jisti, že zařízení používá 00:14:26.350 --> 00:14:30.740 nejmenší množství energie, nejnižší Čekací doba připojení, aby bylo možné 00:14:30.790 --> 00:14:33.770 oslovení a jeho data do fronty. 00:14:35.480 --> 00:14:39.640 Je tedy rozloženy do data centra. Tato sběrnice je k dispozici 00:14:39.690 --> 00:14:45.690 ve všech oblastech Azure všechna datová centra. Tak máte možnost 00:14:45.740 --> 00:14:50.730 k šíření témata kolem. Na teď neznamená back-end 00:14:50.780 --> 00:14:53.890 systémy musí být abdicated ve všech těch příliš místa. 00:14:54.880 --> 00:14:58.000 Pokud skutečnost, pokud si myslíte o Hadoop clustery, je obvykle 00:14:58.050 --> 00:15:01.860 není něco, co by v replikaci každý region v každém datovém centru. 00:15:01.910 --> 00:15:05.890 Ale to vám s nízkou latencí. koncový bod. Odtud lze 00:15:05.940 --> 00:15:10.490 kde probíhá sběr dat Generovat. A pak ho vytáhněte 00:15:10.540 --> 00:15:14.310 z vašeho back-end. Dosáhnout přes k těmto regionům a 00:15:14.360 --> 00:15:18.450 odběry v různých oblastech a srovnávací data. 00:15:20.910 --> 00:15:23.690 Filtr platí pro všechny, ale jeden odběr tak v této svislé 00:15:23.740 --> 00:15:27.550 případ zákazníka, jsou ve skutečnosti proč využívat všech svých dat a 00:15:27.600 --> 00:15:31.700 Kód sledování stavu a dávkové úlohy Analytics, ale ne v BI. 00:15:31.750 --> 00:15:35.900 Tak byly skutečně splněny tyto tři Filtry však jedno předplatné 00:15:35.950 --> 00:15:39.960 bylo snížení filtru. Bylo filtr, který řekl, pokud to je hra 00:15:40.010 --> 00:15:45.060 o není důležité události, pak můžeme můžete provést a samozřejmě 00:15:45.110 --> 00:15:47.360 analytics Realtime a dávkové úlohy. 00:15:49.410 --> 00:15:53.110 Takže v tomto scénáři mi jsme se přejít na rychlé demo. 00:15:54.270 --> 00:15:59.080 A ukázat vám, CORS podporují ji aspekt. 00:16:00.290 --> 00:16:05.680 Protože umožňuje velké množství klientů z hlediska dosažení 00:16:05.730 --> 00:16:11.600 moci ve frontě zprávy pouze pomocí čistého 00:16:13.270 --> 00:16:15.140 Protokol HTTP a položky. 00:16:15.730 --> 00:16:21.550 Mám nastavit web. Že je můžete vyrazit příliš máte 00:16:21.600 --> 00:16:25.950 zařízení nebo něco. S názvem Poznámka: soubor uživatele proveďte Azure 00:16:26.000 --> 00:16:28.260 weby .NET. 00:16:29.750 --> 00:16:40.510 Stačí zde je velmi jednoduchý JavaScript, který bude I 00:16:40.560 --> 00:16:41.160 Ukázat. 00:16:41.880 --> 00:16:43.280 A co dělá 00:16:48.770 --> 00:16:53.470 je přijata hodnoty klíče základní Jaký je její název hodnoty 00:16:53.520 --> 00:16:58.790 název místa, co je název fronty mi dát vaše pravidlo SaaS 00:16:58.840 --> 00:17:02.140 sdílený přístup k ověření podpisu, To je to, co je pomocí 00:17:02.190 --> 00:17:03.800 a SaaS klíč. 00:17:04.950 --> 00:17:07.970 A na základě zprávu můžete odeslat. 00:17:14.280 --> 00:17:18.140 Zpráva úspěšně odeslána. To je ji. Takže můžete vidět, pokud jste 00:17:18.190 --> 00:17:21.380 Máte hodně a velké množství klientů-prohlížečů nebo jiným klientem nebo 00:17:21.430 --> 00:17:25.940 zařízení, které lze provádět pouze čistý HTTP není zde žádná MÝDLA. Neexistuje žádný... 00:17:26.900 --> 00:17:31.300 jakékoli kódování. Můžete umístit zprávu vlastnosti ve formátu JSON a poté 00:17:31.350 --> 00:17:35.930 velmi jednoduchý způsob doručení zprávy v ve frontě. Manuální zobrazit 00:17:35.980 --> 00:17:38.170 je kód pro tento web. 00:17:47.070 --> 00:17:52.110 Proto zde můžete zjistit, zda jsou tím všechny bohaté vlastnosti. 00:17:52.730 --> 00:17:55.220 nebo dokonce jen velmi, velmi základní vlastnosti 00:17:58.440 --> 00:18:05.280 Tento kód lze snadno odeslat. A ve skutečnosti, knihovna JavaScript 00:18:05.330 --> 00:18:09.370 které je zde použit, aby ME prokáží, že pro vás také. 00:18:16.200 --> 00:18:22.410 Tak to je webová stránka, která I ukázalo se a je vidět jak 00:18:35.560 --> 00:18:40.400 jednoduché skutečně odeslat a Zobrazí se tato zpráva. 00:18:40.450 --> 00:18:44.840 HTTP, odstranit je skutečně pro přijímání scénář. 00:18:45.430 --> 00:18:47.500 Které zjistíme, o něco později. 00:18:48.120 --> 00:18:56.600 A put pro odesílání scénář post, Omlouvám se, pokud jde o scénář odeslat. 00:18:58.510 --> 00:19:02.420 To umožní. 00:19:03.620 --> 00:19:05.210 ME poslat několik dalších zpráv. 00:19:05.810 --> 00:19:09.220 A právě zobrazí zprávy ukazující, mám zde Server 00:19:09.270 --> 00:19:12.280 Explorer je zaveden s... 00:19:21.330 --> 00:19:25.310 připojeno k názvu prostoru. A jste I kdy máte jednoduché fronty 00:19:25.360 --> 00:19:28.770 uvidíte nyní existují dva zprávy ve frontě. Postup v případě, 00:19:28.820 --> 00:19:35.430 aktualizace, zobrazují zprávy 14. Tak jako například při zprávy jsou v jejich 00:19:35.480 --> 00:19:37.840 zobrazí na této frontě. 00:19:48.480 --> 00:19:53.620 Jsme bude zahrnovat přijímání scénář o něco později z hlediska 00:19:53.670 --> 00:19:56.920 Klient protokolu HTTP. Tak to je pro klienta protokolu HTTP. 00:19:57.510 --> 00:20:02.200 Ale vy jste opravdu chtěli hovořit konkrétně o protokolech. 00:20:02.820 --> 00:20:06.840 Co jsou důležité informace, je třeba při rozhodování 00:20:06.890 --> 00:20:11.460 zda chcete použít nebo pomocí protokolu HTTP. AMQP. Jak víte, služby 00:20:11.510 --> 00:20:13.930 Sběrnice podporuje několik protokolů. 00:20:15.060 --> 00:20:21.750 HTTP je právě naše RKDPI je AMQP standardní protokol, který bude I 00:20:21.800 --> 00:20:27.620 mluvit o a SBMP je naše druhé proprietární protokol v .NET. 00:20:29.320 --> 00:20:35.000 Nyní každý z nich může mít důležité informace o výkonu a dosáhnout důležité informace. 00:20:35.710 --> 00:20:39.950 Ano, pokud máte zařízení, na kterém je velmi nízké napájení, že můžete 00:20:40.000 --> 00:20:44.810 máte obavy o protokol, který implementace můžete umístit 00:20:44.860 --> 00:20:49.590 na něm. Pokud máte scénáře kde Chcete být dodavatelem nezávislým, 00:20:50.070 --> 00:20:54.160 může obsahovat důležité informace o reach oznamující zde nebude koupím do 00:20:54.210 --> 00:20:57.830 rozhraní API ani určitého protocol s jedním dodavatelem. Přechod do 00:20:57.880 --> 00:21:00.060 Použijte otevřený standard jako AMQP. 00:21:01.900 --> 00:21:04.390 Někdy se funkce mění protokol. 00:21:05.130 --> 00:21:08.000 A část, kterou chcete zvýraznit který získá ztracené na velké množství 00:21:08.050 --> 00:21:11.300 TWAIN je, že je většinou funkce na straně příjmu. 00:21:11.950 --> 00:21:13.290 Existují některé straně odesílání 00:21:14.560 --> 00:21:19.100 důsledky, příliš, většina čas je na příjem kde 00:21:19.150 --> 00:21:23.270 ve skutečnosti odložit protokoly šarže a zobrazí důvod, proč tedy 00:21:23.320 --> 00:21:24.240 případ. 00:21:25.950 --> 00:21:28.810 A obecně jsou některé kvóta rozdíly v číslech 00:21:28.860 --> 00:21:32.360 připojení, kolik může Vytvořte s AMQP a SBMP. 00:21:32.410 --> 00:21:35.550 Proto jsou také důležité faktory Když myslím, Haló, 00:21:35.600 --> 00:21:38.980 protokol, který bude používat pro mé rozsáhlé velké množství 00:21:39.030 --> 00:21:50.090 odesílatelů? Tak binární protokoly oproti protokolu HTTP, proč záleží 00:21:50.140 --> 00:21:53.280 pro zasílání zpráv? Co je klíč důležité informace pro zasílání zpráv? 00:21:53.810 --> 00:21:56.350 Chci pouze upozornila na klíč scénáře, kde nezáleží 00:21:56.400 --> 00:21:59.380 rozdíl, pak můžete zvolit a rozhodnout, zda záležitostech 00:21:59.430 --> 00:22:02.780 nebo není pro váš konkrétní případ. 00:22:04.210 --> 00:22:08.070 Případ HTTP, pokaždé, když volání ven, budete se 00:22:08.120 --> 00:22:11.480 schopné dosáhnout jednu entitu. Tak, aby jeho jeden koncový bod ať už se jedná 00:22:11.530 --> 00:22:13.850 koncový bod odesílání nebo přijímání endpoint. 00:22:14.850 --> 00:22:16.820 Stačí jedno čekající operace. 00:22:17.560 --> 00:22:21.540 Odeslat pouze jediné volání nebo jediný příjem volání. 00:22:22.370 --> 00:22:26.300 A ve většině případů operace Doba platnosti nesmí být více než 00:22:26.350 --> 00:22:30.940 60 sekund nebo jakékoli zatížení Vyrovnávání umožňuje bez ohledu 00:22:31.480 --> 00:22:33.060 zprostředkovatele, který je spuštěn na 00:22:34.490 --> 00:22:41.480 Takže, přenést do sort z případech místo 00:22:41.530 --> 00:22:43.390 ke komunikaci s více koncovými body. 00:22:44.040 --> 00:22:47.590 Koupit spoustu času směrové Jsi scénáře komunikace 00:22:47.640 --> 00:22:51.230 pokračující zaslat přechod fronty a příjem z předplatného. 00:22:52.080 --> 00:22:55.730 Nebo také poslat oznámení, přejděte rozbočovač. Všechny tyto typy z 00:22:55.780 --> 00:22:57.060 scénáře mohou být k dispozici. 00:22:57.640 --> 00:23:01.320 S binární protokol je ve skutečnosti můžete vytvořit jedno připojení 00:23:01.370 --> 00:23:08.270 jedním soustem, jeden soket a všechny ostatní odkazy 00:23:08.320 --> 00:23:13.320 Kontext AMQP je multiflexed odkazy že jediné připojení HTTP. 00:23:14.500 --> 00:23:18.740 Tak získáte mnoho výhod podle bez nutnosti provádět signalizace 00:23:18.790 --> 00:23:22.680 a bez nutnosti stanovit tento soket. a u každé položky 00:23:22.730 --> 00:23:26.880 entity versus... způsobem placení náklady na jednou a pak je opakovaně 00:23:26.930 --> 00:23:29.460 že když se mluví s několika entitami. 00:23:30.290 --> 00:23:33.900 Uvědomte si tuto situaci. V některých případech Při psaní pole brány 00:23:33.950 --> 00:23:37.240 a kde máte vlastní brány Mnoho zařízení, fronting to 00:23:37.290 --> 00:23:40.690 bude velmi důležitým aspektem. 00:23:43.280 --> 00:23:48.250 Na straně druhé je dlouhý, vytažení. Proto je tato věc konstantní 00:23:48.300 --> 00:23:51.400 o vytažení ve frontách, doprava, z Haló, jsou zprávy? 00:23:51.450 --> 00:23:55.160 Mám tu zprávu? Musím zpráva? Zde, protože je 00:23:55.210 --> 00:24:01.040 připojení protokolu AMQP Doporučujeme zachovat připojení alive. 00:24:01.090 --> 00:24:04.370 Nemusíte provádět žádné operace než mít čekající na vyřízení 00:24:04.420 --> 00:24:09.120 příjem, který může být nastaven pro odchod z nekonečna. Budete moci 00:24:09.170 --> 00:24:12.110 Vyrovnejte ji za den, týden. Obecně nebude ji vyrovnat 00:24:12.160 --> 00:24:16.090 pro nekonečno. Nastaví pro cokoliv charakteristiky vaší vypnutí 00:24:16.140 --> 00:24:19.560 vypadat, možná 20 minut nebo něco jako že. Ale 00:24:19.610 --> 00:24:24.920 může mít dlouhé vyžádanou čeká na příjem a nemusíte se obávat 00:24:24.970 --> 00:24:27.640 stloukání cykly procesoru a položky z 00:24:29.370 --> 00:24:33.080 získávání, o který. Společnost Microsoft bude udržovat alive prostřednictvím připojení 00:24:33.130 --> 00:24:37.040 příkazy ping nebo cokoliv, co služba Vyrovnávání zatížení sítě je potřeba a poskytneme 00:24:37.090 --> 00:24:41.640 při reakci s nízkou latencí vždy, když zpráva se zobrazí. 00:24:42.360 --> 00:24:45.820 Tak to se stává velmi důležité jiné posouzení z hlediska 00:24:45.870 --> 00:24:50.380 náklady, jakož i dopad na zařízení. Tak binární protokoly 00:24:50.430 --> 00:24:53.310 Přesvědčte se, rozdíl v číslech scénáře. 00:24:56.240 --> 00:24:59.820 Jiné požitky, které protokoly Zobrazí se v SDK. 00:24:59.870 --> 00:25:03.520 Chcete-li získat produktivní. Chcete, aby Chcete-li použít pevné jádro. Chcete, aby 00:25:03.570 --> 00:25:08.220 Chcete-li použít plnou knihovny. To je ve skutečnosti Chcete mít možnost zvolit 00:25:08.270 --> 00:25:11.010 pravý protokolu právo SDK. 00:25:12.880 --> 00:25:13.950 Tak pro Service Bus 00:25:15.670 --> 00:25:19.750 Pokud používáte .NET a pak naše výchozí Ve výchozím nastavení je protokol SBMP. 00:25:19.800 --> 00:25:24.130 Který se bude používat. Lze přepnout na AMQP kdykoli a 00:25:24.180 --> 00:25:25.170 není to problém. 00:25:25.850 --> 00:25:28.980 Zde jsou některé populární obranu právo nyní ale můžeme při zavírání 00:25:29.030 --> 00:25:33.730 Tato mezera poměrně brzy. Ale pokud si pomocí .NET, SBMP je 00:25:33.780 --> 00:25:36.010 sort z vaší výchozí scénář dnes. 00:25:37.560 --> 00:25:42.400 Pokud používáte protokol HTTP, jestliže je případě máme obálky protokolu HTTP pro velké 00:25:42.450 --> 00:25:46.160 operačních systémů k dispozici a mnoho knihoven, které jsou k dispozici. 00:25:47.010 --> 00:25:50.510 A pak se AMQP při spuštění Chcete-li zobrazit velké množství Společenství 00:25:50.560 --> 00:25:51.700 knihovny přijít. 00:25:52.940 --> 00:25:59.670 AMQP je otevřený standard byl všechny navržené a vyvinuté s 00:26:00.690 --> 00:26:05.690 přičemž mějte efektivní, spolehlivé, jsou přenosné řazení dat 00:26:05.740 --> 00:26:10.310 zastoupení a flexibilitu v paměti. Pružnost v číslech 00:26:10.360 --> 00:26:13.470 zda je klient-klient Klient zprostředkovatel nebo knihovny 00:26:13.520 --> 00:26:15.120 nebo broke rozdělil knihovny. 00:26:16.680 --> 00:26:20.260 Takže začínáte viz AMQP Přesunutí vpřed normalizace... 00:26:20.310 --> 00:26:26.370 tím AMQP poslední byl standard OASIS Října. Vymazat pouze ISO/IEC. 00:26:27.560 --> 00:26:32.950 Takže nyní je uznána mezinárodní Standardní, příliš. Tak, aby jeho 00:26:33.210 --> 00:26:35.180 čerstvé vypnout stisknutím. 00:26:36.990 --> 00:26:41.560 Ale co znamená pro vás je, že je uvidí spoustu knihoven 00:26:42.230 --> 00:26:47.750 vyvinutý společností Apache Qpid knihovny nastavení nebo knihovna kanálem 00:26:47.800 --> 00:26:51.010 klienti v několika různých jazycích. 00:26:51.890 --> 00:26:55.240 C, Java, je implementace JMS. 00:26:56.110 --> 00:27:00.670 Z PHP. Všechny tyto budou k dispozici Chcete-li se s komunitou 00:27:00.720 --> 00:27:05.970 Knihovna otevře zdroj podporu pro použití a rozvoj a přispívá 00:27:06.020 --> 00:27:06.740 Chcete-li a 00:27:07.970 --> 00:27:12.310 plus nebo s jinou službou Zprostředkovatel, který podporuje 00:27:12.360 --> 00:27:14.070 Portál AMQP v něm. 00:27:14.820 --> 00:27:18.400 Ano, pokud se snažíte získat přístup služby sběrnice uvidíte různé protokoly. 00:27:18.450 --> 00:27:22.940 Máte hodně co volba Pomocí sady SDK a jaké knihovny 00:27:22.990 --> 00:27:34.850 použití a nemusíte být omezeno žádným konkrétním způsobem. 00:27:34.900 --> 00:27:36.150 Synchronní, asynchronní versus dávky. 00:27:37.150 --> 00:27:40.650 Takže teď, když jsme si vědomi toho, co jsou protokol detailů, myslím 00:27:40.700 --> 00:27:45.840 jsme měli hovořit o tom, kdy by jsme napsali kód synchronní, asynchronní 00:27:45.890 --> 00:27:49.170 kód a kód dávky a jaké jsou reálné rozdíly v číslech 00:27:49.220 --> 00:27:54.100 výkonu, zobrazí se v těchto různých scénářů. 00:27:55.890 --> 00:27:58.710 Dávkování zřetelně zvyšuje propustnost. 00:27:59.460 --> 00:28:04.620 Je vždy velmi vhodné Pokud jde o tom, zda má 00:28:04.670 --> 00:28:09.260 na straně příjmu nebo dokonce na použití, dávkování na straně odesílání. 00:28:09.310 --> 00:28:13.190 Pouze negativní obavou TWAIN Někdy se je čekací doba 00:28:13.240 --> 00:28:17.490 a uvidíme, jak to může být vliv, ale ne příliš mnoho. 00:28:17.540 --> 00:28:18.880 Jsme budete hovořit o který. 00:28:21.250 --> 00:28:24.830 Asynchronní obecně je vždy nejlepší praxe. Chcete, aby 00:28:24.880 --> 00:28:28.620 Chcete-li použít kdykoli je to možné. S výjimkou Chcete vázán 00:28:28.670 --> 00:28:31.760 Počet volání protilehlé. Je právě nechcete mít těsné 00:28:31.810 --> 00:28:34.720 smyčky, která umožňuje neomezený počet volání a uvidíme jak 00:28:34.770 --> 00:28:37.660 Service Bus pomáhá v tomto scénáři. 00:28:40.160 --> 00:28:44.110 A pak konečně vidíme binárního souboru protokoly, které jsou výrazně vyšší. 00:28:44.160 --> 00:28:47.980 schopnost dosáhnout propustnosti Stačí, protože tyto protokoly, 00:28:48.030 --> 00:28:54.290 byl vyvinut protokol AMQP s účinností, s přihlédnutím 00:28:55.260 --> 00:28:58.750 řízení toku a všechny integrovány do vrstvy protokolu 00:28:58.800 --> 00:29:03.950 sám uvidíte mnoho výhod zobrazovat. Tak manuální skutečně 00:29:04.000 --> 00:29:08.550 Zobrazí se některá čísla. Některé systémem čísla, takže je můžete porovnat 00:29:08.600 --> 00:29:10.090 Tyto sami. 00:29:20.030 --> 00:29:24.820 Tak zde jsou některé kód, který je Chystáte se pokusí odeslat zprávy. 00:29:26.190 --> 00:29:28.970 A vidíte, že I rozdělen až do tří částí. 00:29:29.850 --> 00:29:32.930 První z nich dělá synchronizace odeslat. 00:29:33.690 --> 00:29:38.660 Zde jsou řádky klíče. Pro každou zprávy, proveďte qClient a odeslat 00:29:38.710 --> 00:29:44.060 vypnutí zprávy. To je velmi synchronizace volání. Závaží pro jednu dokončit. 00:29:44.110 --> 00:29:48.030 Čekání na potvrzení přijde zpět ze serveru dosáhnout 00:29:48.080 --> 00:29:51.200 zpět od klienta, úplné Opakovat a pak ji posune. 00:29:52.910 --> 00:29:56.650 Druhý problém je způsobem asynchronní. 00:29:57.900 --> 00:30:02.780 Kde v podstatě vytváření Asynchronní úkoly pro všechny tyto 00:30:03.350 --> 00:30:04.470 Operace odeslání. 00:30:05.700 --> 00:30:09.150 A pak čeká na všechny na dokončení úloh. 00:30:11.410 --> 00:30:15.170 A nakonec je jednu dávkovou odesílání a volat ji objednat 00:30:15.220 --> 00:30:19.430 odesílání dávek, protože se asynchronní, obecně lidí přijít s 00:30:19.480 --> 00:30:22.840 scénář, kde slibují, Haló, se Asynchronní, ztratí objednávku. I není 00:30:22.890 --> 00:30:25.800 vědět, který z nich se stane nejprve který z nich bude následovat. 00:30:26.300 --> 00:30:29.430 A to je důvod, proč je odesílání dávek což je sort z vynikající 00:30:29.480 --> 00:30:32.300 v obou případech, protože zachovává všechny... buď celé 00:30:32.350 --> 00:30:35.920 šarže pochází nebo celé šarže pochází zpět a pomůžete 00:30:35.970 --> 00:30:38.910 v tématu kolik po výkonu To může mít vliv. 00:30:40.310 --> 00:30:45.300 Tak mám všechny tyto přejdete jednoduchá ukázka fronty zprávy. 00:30:45.350 --> 00:30:47.900 Uvidíte nyní počet fronty je 0. 00:30:48.910 --> 00:30:52.560 A nastavili jste Moje číslo zprávy malý počet 100. 00:30:53.660 --> 00:30:54.780 Můžeme ji spustit. 00:30:57.310 --> 00:30:59.530 A uvidíte, jak daleko můžeme získat. 00:31:00.250 --> 00:31:04.670 Tak nejprve funguje pomocí odesílání synchronizace. Takže synchronně provedení. 00:31:04.720 --> 00:31:09.020 100 hovorů z přenosného všechny způsob servisu a zpět. 00:31:09.550 --> 00:31:13.970 Trvalo asi deset sekund v číslech že. A pouze ukazují, 00:31:14.020 --> 00:31:18.360 jsme vždy vrátit, kontrola počet zpráv a měla 00:31:18.410 --> 00:31:21.860 být 100. Na stovku zprávy provedli zde. 00:31:23.160 --> 00:31:26.940 Nyní si ukážeme, co se stane, když Udělat totéž s asynchronní. 00:31:29.190 --> 00:31:30.590 Totéž s asynchronní. 00:31:31.940 --> 00:31:36.120 A žádný rozdíl v číslech zpráv protože 00:31:37.540 --> 00:31:40.460 zprávy všechny došlo v tomto poli. Nyní je 200 zpráv. 00:31:41.250 --> 00:31:46.450 .3 vteřin trvalo. Pro všechny ty Chcete-li získat v něm zprávy. 00:31:50.260 --> 00:31:52.620 S listem je ještě rychlejší. 00:31:53.370 --> 00:31:54.990 Je ve skutečnosti ještě rychlejší. 00:31:56.080 --> 00:31:58.880 A důvod je znovu, protože pod krytem, Service Bus 00:31:58.930 --> 00:32:04.440 používá binární protokol v takovém případě Můžete nám asynchronně, zprávy 00:32:04.490 --> 00:32:09.600 jsme bloku společně dat tabulky a odešlete pomocí s implicitní dávkování. 00:32:10.260 --> 00:32:13.630 Chcete-li nastavit tuto hodnotu získáte. Na vyprázdnění interval dávky, jaký je 00:32:13.680 --> 00:32:17.710 nastavení zasílání zpráv factory, umožňuje můžete nastavit okno. 00:32:18.310 --> 00:32:21.010 Nastavte ji na širší okno. Zobrazí se další zpoždění 00:32:21.060 --> 00:32:23.690 Zobrazí se mnohem více lépe, ale end-to-end propustnost. Je možné 00:32:23.740 --> 00:32:27.310 nastavena na mnohem menší okna a uvidíte lépe čekací doba 00:32:27.360 --> 00:32:32.110 a možná trocha menší propustnost. Ale můžete vidět 00:32:32.160 --> 00:32:36.660 rozdíl velikosti sem ji je z hlediska použití synchronizace 00:32:36.710 --> 00:32:38.410 oproti asynchronní versus dávky. 00:32:45.080 --> 00:32:49.310 Tak rychle podíváme, nyní zde máme naše 300 zprávy 00:32:49.360 --> 00:32:51.110 Co můžeme udělat na straně příjmu? 00:33:02.730 --> 00:33:06.700 V příjmu, Poznámka: Zde že nejsem pomocí zprávy v rozhraní API. 00:33:08.710 --> 00:33:12.460 To je právě vidíte jablka Chcete-li jablka srovnání co 00:33:12.510 --> 00:33:15.560 synchronizace, které vypadají sort z rozhraní API a I potom ukáže vám jak 00:33:15.610 --> 00:33:18.370 zprávy rozhraní API nemá všechny to pro vás. 00:33:20.100 --> 00:33:23.620 Je to synchronní přijímat. 00:33:24.300 --> 00:33:28.740 Tak mám dvě zřetelně volá je na serveru tak tento 00:33:28.790 --> 00:33:33.600 z hlediska zprávy zpracovává. Nikdy, nikdy nebudete moci 00:33:33.650 --> 00:33:38.280 zpráva na lince nebo na cestě protože dokud nemůžete volat 00:33:38.330 --> 00:33:41.950 dokončení, pošleme zpět stejnou zprávu. 00:33:43.810 --> 00:33:48.260 Další je asynchronní a zde je můžete vidět, co to bude 00:33:49.430 --> 00:33:56.230 je úkol s pokračovat s k potom volejte v něm kompletní. 00:34:01.730 --> 00:34:05.290 A opět I všem, kdo bude čekat vyřezávání na dokončení úloh 00:34:05.340 --> 00:34:07.770 Před voláním Moje stopky provést. 00:34:09.300 --> 00:34:10.660 A konečně je dávky. 00:34:11.330 --> 00:34:12.950 Dávka je o něco zajímavější. 00:34:13.890 --> 00:34:19.030 Zde je ještě jednodušší protože I příjem dávky, nezapomeňte do průchodu 00:34:19.080 --> 00:34:21.370 číslo zprávy To je, což je 100. 00:34:22.040 --> 00:34:24.860 Nyní po volání přijímat dávky s set jsme neznamená 00:34:24.910 --> 00:34:28.830 vám nabídne 100 zpráv zpět. To bychom bez ohledu 00:34:28.880 --> 00:34:32.660 je nejvíce optimální pro drát na základě na soutěžit se spotřebiteli, 00:34:32.710 --> 00:34:35.970 podle počtu ostatních uzlů mít vytažení se zobrazí 00:34:36.020 --> 00:34:38.800 sestavit optimální dávky a který můžete odeslat. 00:34:39.610 --> 00:34:43.320 A to je důvod, proč uvidíte mám Vnější smyčka, která udržuje volání 00:34:43.370 --> 00:34:47.620 dokud není dosáhnout I příjem dávky set zprávy. Chci 00:34:47.670 --> 00:34:51.430 Chcete-li tento výpočet dávkování do Po dosažení 100 zpráv. 00:34:53.920 --> 00:34:59.030 A v případě zde kliknu obsahovat pouze jeho uzamčené token. 00:34:59.080 --> 00:35:01.160 To je vše, které to ve zprávě. Z nemám zachovat 00:35:01.210 --> 00:35:04.440 celou zprávu. Jakmile jste I spotřebované Nemohu zpracovat zprávu, 00:35:04.490 --> 00:35:07.710 je pouze nutné zachovat token zámku a poté zavolejte 00:35:07.760 --> 00:35:12.940 Asynchronní dokončení dávky se všemi uzamčené tokenů v něm. 00:35:14.060 --> 00:35:16.940 A to bude to na základě dávky I proto opět nemám čekání 00:35:16.990 --> 00:35:19.490 směrem až do konce na dokončit všechny zprávy? 00:35:19.500 --> 00:35:21.500 [Indiscernible] 00:35:21.660 --> 00:35:22.750 .. .subset že? 00:35:23.510 --> 00:35:24.840 >> Bohužel jaká byla otázka? 00:35:24.890 --> 00:35:28.400 >>-Li by některé z těchto procesů zprávy, může dokončení 00:35:28.450 --> 00:35:30.520 Toto testování provádí dílčí? 00:35:30.860 --> 00:35:34.510 >> Absolutně. Zcela jistě. Dávky tak dokončení asynchronní. 00:35:35.250 --> 00:35:39.040 Můžete volat s jedinou uzamčené tokeny dva uzamčené tokeny, bez ohledu 00:35:39.090 --> 00:35:42.720 Sada je. Je právě že bude Odeslat tyto uzamčené tokeny 00:35:42.770 --> 00:35:46.250 v listu a získat zpět výsledky v dávce. To má 00:35:46.300 --> 00:35:50.010 ušetříte této čekací doby a který požadavkem pro to, že všechny 00:35:50.060 --> 00:35:52.540 a provedení velmi efektivní. 00:35:54.300 --> 00:35:56.070 Můžeme zjistit, jaká přidá až. 00:35:58.400 --> 00:36:03.230 Proto zde mají stejný případ. Jsem Nejprve přejde na synchronizaci a 00:36:03.280 --> 00:36:07.440 došlo k pokusu o přijetí na stovku... první set zpráv 00:36:07.490 --> 00:36:11.190 v něm. Nyní Poznámka: to bude horší výkon, než je odeslat, protože 00:36:11.240 --> 00:36:14.080 činnost dvakrát počet operací takže chcete přijímat 00:36:14.130 --> 00:36:16.460 Každá zpráva dokončení každé zprávy. Každá zpráva 00:36:16.510 --> 00:36:20.110 dokončení každé zprávy. A přejděte. Ano 18 sekund. 00:36:20.160 --> 00:36:24.220 Místo deseti odešle jsme sice zaznamenala pro odeslání trvá 18 sekund 00:36:24.270 --> 00:36:28.760 Tyto zprávy a úplné je. To zcela jistě není dobré. 00:36:30.090 --> 00:36:35.330 S asynchronní vzhledem k tomu, že děláte spoustu z nich současně nyní dostanete dolů na 00:36:35.380 --> 00:36:38.880 o 2,8 sekund. Nyní, Tato čísla jsou pouze... 00:36:39.410 --> 00:36:43.230 berte si je s zrna soli, systém v síti zde, jsou 00:36:43.940 --> 00:36:47.470 ale uvidíte na velikost rozdíl. Uvidíte 00:36:47.520 --> 00:36:49.620 kolik je zlepšení. 00:36:50.830 --> 00:36:52.580 A nyní si ukážeme, co se stane s listem. 00:36:55.730 --> 00:37:00.720 Jsme zpět. Jsme schopni, totéž téměř vlastnosti jako 00:37:00.770 --> 00:37:04.590 0,1 sekundy na stovku operace, která byla přijata... 00:37:05.410 --> 00:37:07.930 jen proto používáme dávky v něm. 00:37:11.380 --> 00:37:16.640 Nyní se pouze zobrazí všechny tyto výhody tohoto místa, ale služba 00:37:16.690 --> 00:37:21.680 Sběrnice skutečně lze velmi snadno Chcete napište tento konkrétní kód. 00:37:21.730 --> 00:37:26.700 Kód, který jsem ukázal, je velmi komplexní, ale skutečně přijata. 00:37:26.750 --> 00:37:29.280 jeho další krok a My provést ještě jednodušší. 00:37:30.200 --> 00:37:33.470 K tomu tak... způsobem, I just Chcete-li zobrazit zde na 00:37:33.520 --> 00:37:37.280 zprávy, že se tyto 300 zprávy Zde, pokud si aktualizovat, je 00:37:37.330 --> 00:37:41.920 musí vrátit nula označuje I nemám ležící. Všechny tyto 300 00:37:41.970 --> 00:37:43.380 zprávy byly zpracovány. 00:37:47.270 --> 00:37:54.910 V pořádku. Tak se budeme zabývat na zprávy Rozhraní API, ale v zájmu 00:37:54.960 --> 00:37:57.880 Doba kliknu na rychlost trochu sem nahoru. 00:38:00.480 --> 00:38:04.820 Abyste viděli rozdíl mezi synchronní, asynchronní a dávky, a 00:38:04.870 --> 00:38:10.330 Doufám, že [Indiscernible] vždy použít dávkování. Další věc, o propustnosti. 00:38:10.380 --> 00:38:14.100 Fronty s více oddíly a témata. Tak vydala společnost Microsoft SDK 2.2. 00:38:15.680 --> 00:38:19.590 V podstatě oddílů fronty a témata jednu frontu a oddíl 00:38:19.640 --> 00:38:21.830 je v několika uzlech zpracování. 00:38:23.240 --> 00:38:26.950 To vám nejen poskytne mnohem více propustnost napájení z hlediska 00:38:27.000 --> 00:38:31.900 je schopen zpracovat více zpráv, ale poskytuje větší kapacitu úložiště. 00:38:32.410 --> 00:38:35.820 Dává možnost, aby mnohem větší fronty. Dává 00:38:35.870 --> 00:38:38.170 Umožňuje odolnější. 00:38:39.270 --> 00:38:42.290 Pokud není k dispozici, jeden oddíl můžete pokračovat v jiném oddílu 00:38:42.340 --> 00:38:43.580 ke zpracování zpráv. 00:38:44.640 --> 00:38:49.270 Takže oddílů fronty a že by daleko pro většinu scénářů 00:38:49.320 --> 00:38:52.990 je mnohem, mnohem lepší propustnost dostupnost a odolnost 00:38:53.040 --> 00:38:58.570 Viz vlastnost. Mimo pole. Je tak snadno vytvářet a 00:38:58.620 --> 00:39:02.700 pomocí oddílu front, které je doporučení, aby 00:39:02.750 --> 00:39:06.470 vždy používejte. Stačí vždy použít. Tyto. Ve skutečnosti v příštích 00:39:06.520 --> 00:39:11.000 Verze SDK, jsme na stopu, aby je ve výchozím nastavení ve výchozím nastavení, které 00:39:11.050 --> 00:39:13.380 Při vytváření fronty pomůžete Získejte rozdělených fronty. 00:39:15.690 --> 00:39:20.650 Nyní je nutné cognizant Co se stane, když vezmete 00:39:20.700 --> 00:39:22.590 fronty a rozdělit jej mezi. 00:39:24.060 --> 00:39:26.530 Pokud nepoužíváte relace, bude hovořit o relacích šarže 00:39:26.580 --> 00:39:30.340 detailů, ale pokud nepoužíváte relace a potom v podstatě 00:39:31.060 --> 00:39:33.050 musíte být... 00:39:34.220 --> 00:39:38.380 je nutné si uvědomit, že vaše zprávy pravděpodobně zobrazí mimo pořadí 00:39:38.430 --> 00:39:41.830 Nyní vzhledem k tomu, že v podstatě mohou Přejít do různých oddílů 00:39:41.880 --> 00:39:46.770 a je-li oddíl je k dispozici, poté se zobrazí zpráva 00:39:46.820 --> 00:39:47.720 mimo pořadí. 00:39:48.460 --> 00:39:51.270 Je třeba si být vědomi ale pokud používáte relace, 00:39:51.320 --> 00:39:54.720 které jsme budete hovořit o nyní, pak objednávání sémantika 00:39:54.770 --> 00:39:56.100 zcela zachovány. 00:39:57.120 --> 00:40:02.330 A uvidíme jak. Chcete-li zobrazit pouze kód zde, kdykoli si 00:40:02.380 --> 00:40:05.590 vytvoření fronty je jeden jediný Vlastnost EnablePartitioning. 00:40:05.640 --> 00:40:08.720 Dnes je nastavena na false ve výchozím nastavení. Jako řekl v příštích 00:40:08.770 --> 00:40:10.040 SDK je true. 00:40:10.780 --> 00:40:13.750 Tak právě nastavte který. Podle tak nevím, jak je 00:40:13.800 --> 00:40:18.770 TWAIN obecně se ale mé filozofii Obecně je nikdy kopie 00:40:18.820 --> 00:40:20.730 kód, který se zobrazí v aplikaci PowerPoint. 00:40:21.330 --> 00:40:24.470 Nevím, který pracuje pro jste že. Nikdy, nikdy kopírování 00:40:24.520 --> 00:40:28.150 kód, který se zobrazí v aplikaci PowerPoint, protože bude nejvíce zneužívající vlastností prohlížeče 00:40:28.590 --> 00:40:32.710 a druh kódu basic, které nikdo můžete umístit provozovně. V tomto 00:40:32.760 --> 00:40:35.500 v případě, kdy je v pořádku. Právě nastavujete vlastnosti, jsou tak, že je v pořádku. 00:40:35.550 --> 00:40:38.540 Ale pokud někdy ukázal, že je kód v aplikaci PowerPoint nelze kopírovat. 00:40:40.650 --> 00:40:46.660 Tak propustnost připojení. Jste mluvili jsme o odesílatelů. Jsme viděli 00:40:46.710 --> 00:40:50.290 jak jsou ve skutečnosti, binární připojení skutečně důležité. Existují 00:40:50.340 --> 00:40:55.090 Některé případy, kde je může odesílání použití velmi fat pipe. 00:40:55.660 --> 00:40:58.340 Považujte to jako back-end, jsme chcete řadit zprávy do fronty. 00:40:58.390 --> 00:41:03.370 Máte tuny protokoly, které chcete Chcete-push up a podobný věci. 00:41:04.400 --> 00:41:08.450 I v určitém okamžiku vytvoření více fyzické připojení TCP může 00:41:08.500 --> 00:41:12.630 ve skutečnosti být vhodné a je možné snadno proveďte. Jednotlivé zprávy 00:41:12.680 --> 00:41:16.220 v případě výroby pro třídu instance factory pro zasílání zpráv 00:41:16.270 --> 00:41:18.390 odpovídá jedno připojení PCP. 00:41:19.390 --> 00:41:22.550 Tak další počet klientů fronty položky, které vytváříte a 00:41:22.600 --> 00:41:25.680 vypnutí téže továrny, jako I ukázalo Můžete si multiplexování všech 00:41:25.730 --> 00:41:31.430 připojení přes stejné soketu TCP. Vytvořte další zasílání továrny. 00:41:31.480 --> 00:41:33.700 A pokud vytvoříte další zasílání zpráv továrny, stejně dostanete více 00:41:33.750 --> 00:41:38.720 potrubí a další data mohou být posunuta až tak důležitým aspektem. 00:41:38.770 --> 00:41:42.540 pro který. Odolnost na úrovni připojení je součástí. Takže jakmile 00:41:42.590 --> 00:41:46.140 vytváření zpráv továrny, je nikdy jste ji zrušit. 00:41:46.190 --> 00:41:49.320 Pokud se připojení přeruší, bude Vytvořte jej znovu. Pokud váš odkaz nefunkčním 00:41:49.370 --> 00:41:52.740 do fronty jsme se jej vytvořte znovu. Bez ohledu je, že jsme se znovu 00:41:52.790 --> 00:41:54.860 z hlediska to tomu tak je nikdy to stačí... 00:41:55.370 --> 00:41:58.030 mít okamžitě vyvolat tento objekt a tento objekt znovu. 00:41:58.310 --> 00:42:02.780 Stačí vytvořit z nich a znovu použít pro méně než je třeba. 00:42:05.910 --> 00:42:07.540 Který nás přenese do relace. 00:42:08.520 --> 00:42:11.670 Vzhledem k tomu, že jsem jej sdělit vám všechny tyto odesílatelů velké množství 00:42:11.720 --> 00:42:14.910 odesílatelů a multiplex je všechny velmi malé číslo. 00:42:14.960 --> 00:42:17.850 front jak budete ve skutečnosti to zpracovat? 00:42:17.900 --> 00:42:21.110 Jsme viděli Orléans druh rámce a položky, které jsou všechny 00:42:21.160 --> 00:42:23.460 Chcete-li demultiplex proudu, 00:42:24.720 --> 00:42:26.530 demultiplex datového proudu. 00:42:28.490 --> 00:42:33.070 Relace je Super součástí funkce v Service Bus, která 00:42:33.120 --> 00:42:37.130 v podstatě vytvoří podfront. Proto každá relace lze považovat 00:42:37.180 --> 00:42:40.290 z jako podfronty po celé frontě. 00:42:41.480 --> 00:42:44.860 A pouze původní charakter má nastavit ID relace. 00:42:44.910 --> 00:42:46.840 To je jednu jedinou vlastnost. je nutné nastavit. 00:42:48.090 --> 00:42:51.240 Přijímač je kde paradigma skutečně změní. 00:42:52.050 --> 00:42:56.090 Přijímač nyní již odkazuje a říká Ahoj, získávat další zprávu. 00:42:56.140 --> 00:42:59.670 Příjemce říká mi dát další relace. Získávat další 00:42:59.720 --> 00:43:02.690 podfronty, který má některé zprávy a budete přejít v jejich zpracování 00:43:02.740 --> 00:43:06.760 pořadí, ve kterém budete přejít s jejich zpracování Některé stavu, který může uložit 00:43:06.810 --> 00:43:10.600 pro tento přijímač. Pokud si myslíte, že tomu tak o miliony zařízení, 00:43:10.650 --> 00:43:13.290 Nyní si můžete představit, v rámci jednoho fronty, můžete mít všechny tyto 00:43:13.340 --> 00:43:18.620 milionů podfronty a úložiště stát na podfrontu. Tak velmi 00:43:18.670 --> 00:43:20.410 v tomto smyslu velmi výkonné. 00:43:21.050 --> 00:43:24.400 Můžete provést práce nastavit pracovní sadu Připnutí. To znamená, že můžete vyslovit. 00:43:24.450 --> 00:43:29.230 přijímač, jednu, chcete lokalizovat zařízení 1 až 100. Tak ho 00:43:29.280 --> 00:43:32.810 bude přejít a požádejte o relacích 1 do 100 a bude držení 00:43:32.860 --> 00:43:33.440 Chcete-li. 00:43:35.000 --> 00:43:39.680 A pak samozřejmě můžete ukládat stav. Tak jsem ukáže vám 00:43:39.730 --> 00:43:43.490 kód pro tento. V podstatě se bezpečené relace na hodnotu true, pokud 00:43:43.540 --> 00:43:45.270 vytváření fronty. 00:43:45.790 --> 00:43:49.670 Na straně odesílání je třeba jen nastavit jednu vlastnost ID relace. 00:43:50.530 --> 00:43:55.720 A poté zobrazí na straně, všechny použít stejný druh parametry 00:43:55.770 --> 00:43:59.840 jako I ukázal, přijmout zprávu relace, můžete přijmout 00:43:59.890 --> 00:44:03.730 zpráva s ID relace nebo nyní co jsme právě vydali 00:44:03.780 --> 00:44:08.760 je velmi jednoduché je možné provádět 00:44:11.810 --> 00:44:13.010 relace přijímače. 00:44:14.920 --> 00:44:18.080 Tak budete otevření relace odesílatele. 00:44:18.970 --> 00:44:21.810 Můžeme mít již realizovaných tímto dávkování je nejlepší způsob odesílání 00:44:21.860 --> 00:44:25.740 která dělá všechny odesílatele pro každou relaci ID jej bude 00:44:25.790 --> 00:44:30.240 k odesílání zpráv tolik jako ID relace plus jedna. Ano, pokud má 00:44:30.290 --> 00:44:33.480 ID relace, bude k odeslání dvě zprávy. Pokud je relace 00:44:33.530 --> 00:44:36.070 ID 2, kliknete na Odeslat tři zprávy a tak dále. 00:44:37.350 --> 00:44:38.920 Takže začnete pouze odesílatel. 00:44:39.880 --> 00:44:43.910 A zde, pokud se podíváte na této frontě na Ukázka fronty zpráv 00:44:44.580 --> 00:44:49.140 Po vytvoření této fronty Navíc pouze jednu vlastnost lze nastavit 00:44:49.190 --> 00:44:55.090 na to, byla vyžadují vlastnost relace. Který byl jediný rozdíl. 00:44:55.670 --> 00:44:59.940 Nyní při návratu na tomto konkrétním fronty a viz, že má 00:44:59.990 --> 00:45:02.440 Zobrazí vlastnosti, 00:45:08.230 --> 00:45:09.410 zjistíte, že... 00:45:11.710 --> 00:45:16.480 vyžaduje, že je vlastnost relace false. To není dobré. 00:45:16.530 --> 00:45:20.780 V pořádku. Manuální odstranění pak tuto frontu. 00:45:24.670 --> 00:45:34.390 Vytvořte zprávu relaci vzorkem. 00:45:37.280 --> 00:45:38.780 Požadovat relace. 00:45:45.040 --> 00:45:47.020 Přechod ke čtení na mé odesílatele. 00:45:51.490 --> 00:45:53.840 Tak to spustí odesílání zpráv. 00:46:09.430 --> 00:46:18.880 Lze odhadnout, že není zjištění, že nyní název fronty. 00:46:18.890 --> 00:46:20.800 [Indiscernible] 00:46:20.870 --> 00:46:27.580 >> Běžte nebyla jsem? Na zprávu relace... Pospěšte si že můžete přejít. 00:46:29.640 --> 00:46:36.750 Perfektní. Manuální proto změnit až na vzorku zprávu relaci. 00:46:39.450 --> 00:46:40.630 Děkuji mnohokrát. 00:46:42.100 --> 00:46:43.360 Nyní chci spustit tento hoch. 00:46:46.770 --> 00:46:49.710 Zde můžete přejít. Řekl odesílání všech těch zprávy. Nyní manuální zobrazit 00:46:49.760 --> 00:46:54.350 je kód příjmu pro to vypadá. 00:46:55.510 --> 00:46:59.710 To je úplně nové rozhraní API které Právě jsme vydali, na 00:46:59.760 --> 00:47:02.010 rozhraní API pro zpracování zpráv. 00:47:03.430 --> 00:47:07.500 Tak ve vaší roli Azure pracovníka Manuální příliš změnit. 00:47:10.890 --> 00:47:14.690 Příslušné role Azure pracovníka na na start metoda provést 00:47:14.740 --> 00:47:19.540 stejné, jen zkontrolovat, pokud tato fronta existuje a vytvořit qClient. 00:47:20.250 --> 00:47:24.120 Spuštění pravidla, zjistíte, vaše Kód získá ještě jednodušší. 00:47:25.610 --> 00:47:29.270 Jediné, co právě děláte je to volání jeden registr. 00:47:29.900 --> 00:47:32.770 Tedy zaregistrovat obslužnou rutinu relace. 00:47:33.670 --> 00:47:36.500 A to je vše. Žádné deceive smyčky k zápisu. 00:47:37.120 --> 00:47:38.950 Chcete-li spravovat žádné životnost. 00:47:39.580 --> 00:47:43.920 Všechny který se stará o Knihovna klient pro vás. 00:47:43.970 --> 00:47:48.540 Je třeba jen zapouzdřit všechny jak budete vaši logiku 00:47:48.590 --> 00:47:53.790 Chcete-li proces, který jeden datový proud v jednom třídy s názvem vlastní obslužnou rutinu relace. 00:47:54.700 --> 00:47:57.450 Podívejme se tato třída a co to zde. 00:47:58.700 --> 00:48:02.660 První věc je, co dělat při Zobrazila se zpráva ve skutečnosti? 00:48:05.430 --> 00:48:09.430 Na zprávu právě tisknu že se zobrazí chybové zprávy a 00:48:09.480 --> 00:48:10.870 I 'm zvýšení mé počet. 00:48:11.610 --> 00:48:15.320 To je vše, které to v této třídě. Soukromý člen je počet 00:48:15.370 --> 00:48:19.860 Zde a právě jsme ukládané touto hodnotou. 00:48:21.090 --> 00:48:22.960 Proto doporučujeme nastavit počet 00:48:24.710 --> 00:48:28.550 nulové a můžeme ponechat pouze počet je tak, aby se všechny mé zpracování. 00:48:29.270 --> 00:48:34.550 Na uzavřené relace ukončení relace je volána, když nejsou žádné 00:48:34.600 --> 00:48:38.750 Další zprávy k dispozici pro danou relace nebo jste dosáhli 00:48:38.800 --> 00:48:42.360 vaše měna maximální počet. Jsme mluvili. o kolik současně 00:48:42.410 --> 00:48:43.630 Chcete mít. 00:48:44.260 --> 00:48:48.230 Ano, pokud jste dosáhli vaší max. kolik počet souběžnosti 00:48:48.280 --> 00:48:53.040 relace pro zpracování, bude nazýváme v této relaci, ukončete a spusťte 00:48:53.090 --> 00:48:57.610 Nová relace podle toho, jaké zprávy jsou k dispozici. Takže zavření 00:48:57.660 --> 00:49:00.700 to znamená, že jste I příležitosti zadán sada zpráv, I jste 00:49:00.750 --> 00:49:03.900 zpracování je tento údaj relace a nyní by měl 00:49:03.950 --> 00:49:05.580 Uložte tento stav. 00:49:07.140 --> 00:49:10.730 A zde můžete vidět všechny stárnu Nastavit stav a get volá 00:49:10.780 --> 00:49:15.250 stát, který je v relaci námitky. Jedná se v podstatě proudy. 00:49:16.050 --> 00:49:20.770 A ukládání hodnoty počet pryč Pokud je relace ukončena. 00:49:21.780 --> 00:49:26.130 A pak konečné je chyba případ, kdy relace je ztraceno. 00:49:27.420 --> 00:49:31.050 Nyní mějte na paměti, budete mít důvod Chcete-li sladit tyto zprávy 00:49:31.100 --> 00:49:34.310 protože jsme uzamčení pro relace jste. Jsme Ujistěte se, že jste 00:49:34.360 --> 00:49:38.790 pouze příjemce, který dostává zprávy podfronty, 00:49:38.840 --> 00:49:40.510 že subsession. 00:49:41.190 --> 00:49:43.780 A vždy ke ztrátě zámku. Zámek bude ztracen, protože 00:49:43.830 --> 00:49:47.660 selhání na serveru. To bylo možné být ztraceny z důvodu připojení 00:49:47.710 --> 00:49:51.410 potíže nebo možná procesor právě zablokovaná a došlo ke ztrátě zámek 00:49:51.460 --> 00:49:55.290 protože proveďte operaci že proto může vždy získat 00:49:55.340 --> 00:49:58.940 Tato chyba se nazývá. V tomto případě vše bude provádět je abandon 00:49:58.990 --> 00:50:03.500 Nastavení místní změny a přesunout na. Z hlediska. 00:50:04.870 --> 00:50:07.150 Tak se podíváme jak to vypadá. 00:50:07.670 --> 00:50:08.790 Skutečné spuštění. 00:50:10.210 --> 00:50:10.800 Byla otázka? 00:50:10.850 --> 00:50:11.930 >> Pracuje stejný? 00:50:13.740 --> 00:50:17.500 >> To byla otázka: bude to funguje stejně pro předplatné? 100 procent. 00:50:17.550 --> 00:50:21.170 Je zcela symetrické. Zda Při příjmu z fronty 00:50:21.220 --> 00:50:24.130 nebo se přijímá z předplatného. 00:50:25.440 --> 00:50:28.920 Tak zde je Moje role pracovníka. Nechť mě skutečně rychle zkontrolovat, co 00:50:28.970 --> 00:50:30.850 Počet front, prohledat Po, například 00:50:32.060 --> 00:50:36.390 role bylo odesílání. Vypadá jako To má potom 3,700 zprávy vpravo 00:50:36.440 --> 00:50:40.610 Nyní 33, vypadá jako zpracování má vykazuje postavu. 00:50:41.650 --> 00:50:56.690 Manuální přejít do ní... Můžeme jít. Je vypracování. 00:50:56.740 --> 00:51:03.350 Dobrý. Tak právě teď, jsou mého počítače procházení a 00:51:03.400 --> 00:51:06.090 můžete zobrazit tisíců zpracování a tisíce zpráv. 00:51:06.890 --> 00:51:10.740 A kód, který jsem vytvořil velmi zneužívající vlastností prohlížeče myšlení 00:51:10.790 --> 00:51:15.170 o pouze jednoduché relace, jeden relace a nebyly k dispozici 00:51:15.220 --> 00:51:18.800 zapisovat smyčku jediný příjem. I just musela zaregistrovat popisovač kanálu. 00:51:19.200 --> 00:51:23.370 Obslužná rutina, kterou jsem ukázal, je v případě zneužívající vlastností prohlížeče kde je 00:51:23.420 --> 00:51:28.420 Můžete mít to vytvořena instance a není provedením jakékoli inicializace. 00:51:28.450 --> 00:51:32.020 Máme tovární zálohu která je k dispozici příliš. Můžete provést 00:51:32.070 --> 00:51:36.960 registrace továrny obslužné rutiny a že způsob, jakým můžete řídit vytváření 00:51:37.010 --> 00:51:38.700 Sémantika, také. 00:51:40.370 --> 00:51:43.560 Zde uvidíte, ale zachovat uzavřené a stavu relace. 00:51:44.420 --> 00:51:48.340 Manuální přiblížení zde tak můžete TWAIN zřetelně rozeznat, co se stalo zde. 00:51:49.070 --> 00:51:54.740 Pokud se zobrazí každé relace session stát byl pro relaci 21 22. 00:51:54.790 --> 00:51:57.810 Stav relace byla 46 pro relaci 45. 00:51:58.620 --> 00:52:03.770 Protože třídy získali pouze zprávy který patřil k této relaci. 00:52:04.200 --> 00:52:08.320 Vše, co bylo demuxing a muxing Easy a vše, co byly zpracovány. 00:52:08.370 --> 00:52:12.410 pomocí sběrnice služeb pro vás. V takovém případě názor multiplexování 00:52:12.460 --> 00:52:15.990 velký počet odesílatelů do malý počet front, vědět 00:52:16.040 --> 00:52:19.260 jednoduchost ještě ke ztrátě je schopen zpracovat 00:52:19.310 --> 00:52:23.800 na back-end using Tyto jednotlivé datové proudy 00:52:30.570 --> 00:52:34.260 v něm. 00:52:37.740 --> 00:52:41.000 Stav relace, které jsme mluvili. Srovnávací použití relací. 00:52:41.350 --> 00:52:46.020 Tak jen pro shrnutí skutečně předtím, než jsme shrnout, přístup. 00:52:46.590 --> 00:52:49.230 Dalším důležitým aspektem je Pokud jsou tyto velmi 00:52:49.280 --> 00:52:52.530 velký počet odesílatelů, co je ověřování modelu? Co je zabezpečení 00:52:52.580 --> 00:52:55.750 model, který chcete použít? To by říci sdílený přístup 00:52:55.800 --> 00:52:58.420 podpis je jednoznačně Doporučujeme ověření modelu. 00:52:59.010 --> 00:53:02.150 Existuje mnohem více podrobností. Ve skutečnosti na palubu se podrobněji 00:53:02.200 --> 00:53:08.190 jak nastavit sdílený přístup podpisy. Můžete přejít na portál 00:53:08.540 --> 00:53:10.040 a spravovat své fronty. 00:53:10.910 --> 00:53:15.270 Zde IOT fronty, které jsou možnost nepřetržitého používání z webu. 00:53:16.050 --> 00:53:18.850 A I právě zde a konfigurace. 00:53:19.420 --> 00:53:23.650 Všimněte si, že jsem měl Oh... 00:53:23.660 --> 00:53:23.720 [Indiscernible] 00:53:23.700 --> 00:53:25.290 >> Jsem tak líto. Mrzí mne to. 00:53:28.330 --> 00:53:33.790 Proto přešli do Azure portálu a I my IOT fronty. 00:53:34.890 --> 00:53:38.340 A v tomto, kdy přejít do konfigurací na kartě zobrazení Mé sdílené 00:53:38.390 --> 00:53:42.420 přístup k názvu zásady. Tak v Tento příklad webu který I 00:53:42.470 --> 00:53:45.240 ukázal, pokud I jen přijmout, je to ve skutečnosti by 00:53:45.290 --> 00:53:49.650 selhat, protože právě teď, pouze autorizace na to je odeslat. 00:53:50.890 --> 00:53:54.310 Ale I snadno vyhledat a přidat naslouchání povolení tohoto pravidla. 00:53:55.730 --> 00:53:56.440 Uložit přístupů. 00:53:57.340 --> 00:53:58.640 Oznámením aktualizace ve frontě. 00:53:59.190 --> 00:54:00.050 A nyní 00:54:01.700 --> 00:54:06.780 token, který byl vytvořen pro tento Pravidlo bude mít možnost 00:54:06.830 --> 00:54:11.480 Chcete-li odesílat i přijímat. Proto nyní Zde můžete přejít a klepněte na tlačítko Přijmout, 00:54:12.880 --> 00:54:15.660 dobře není návratu. Vypadá jako TWAIN mít odesílá zprávy. 00:54:15.710 --> 00:54:18.320 Nyní přejděte přechod, konverzace že můžete ponechat v kontaktu 00:54:18.370 --> 00:54:20.210 vzájemně online. 00:54:21.490 --> 00:54:24.220 Podpis tak sdílený přístup, jsou velmi, velmi lehké jsou velmi 00:54:24.270 --> 00:54:28.290 snadno ovladatelný model. Pokud potřebujete Přejít do SDS druh modelu, 00:54:28.340 --> 00:54:35.540 jsou že ACS je plně podporováno. Služba ACS je stále správnou možnost k dispozici. 00:54:35.590 --> 00:54:37.660 Jste právě viděli ve frontách. 00:54:39.580 --> 00:54:43.390 Stejně tak shrnout, jsme viděli protokoly. Proč jsou důležité. 00:54:43.650 --> 00:54:47.970 Jsme postupovali proudu korelace Proč to není nutné, 00:54:48.020 --> 00:54:50.860 vytvoření fronty na zařízení. Nechcete být Správa 00:54:50.910 --> 00:54:53.980 milión fronty. Ale není má být psaní kódu, která 00:54:54.030 --> 00:54:57.760 musí být velmi složité příliš. Tak ty jsou velmi, velmi 00:54:57.810 --> 00:55:00.840 snadno podporované službou Sběrnice pro zasílání zpráv. 00:55:01.900 --> 00:55:05.320 Fronty, témata, odběry. Symetrické ve všech z nich. 00:55:05.370 --> 00:55:08.990 Vše, co jsem ukázal v číslech co pracuje s front pro 00:55:09.040 --> 00:55:12.280 relace pracuje přesně stejným způsobem. témata a odběry 00:55:12.330 --> 00:55:16.290 a filtry. Při vytváření odběr, Stačí pouze vyslovit vyžaduje 00:55:16.340 --> 00:55:18.360 relaci v něm se rovná true nebo ne. 00:55:21.680 --> 00:55:22.910 Měřítko přijímačů. 00:55:27.210 --> 00:55:30.850 Aplikace Visual Studio měla tato výzva kde je možné spouštět tuny 00:55:30.900 --> 00:55:34.520 instance IDE a pak může vrátit a změnit své 00:55:34.570 --> 00:55:37.840 profil na jednom z nich a má všechny synchronizace nahoru. 00:55:38.640 --> 00:55:41.980 Jak budete přejít komunikovat Chcete-li tyto instance? 00:55:42.490 --> 00:55:45.600 Jsou to dynamické instance příliš protože počet VS 00:55:45.650 --> 00:55:49.910 instance, které jste spustit se liší. v závislosti na dni v týdnu. 00:55:49.960 --> 00:55:53.530 Máme skutečně statistiky Chcete-li zobrazit, tím. 00:55:53.580 --> 00:55:57.170 Uživatelé otevřít tak další instance ve středu než se otevřou v pátek. 00:55:57.220 --> 00:56:04.740 Produktivita je to tanking do pátku. Tak přesto může problém znovu 00:56:04.790 --> 00:56:07.440 řešeny témata kde je miliony a miliony 00:56:07.490 --> 00:56:11.110 Koncové body. A chcete, aby všechny jejich vlastní jeden poslech 00:56:11.160 --> 00:56:14.070 jeden odběr zpráv. 00:56:15.150 --> 00:56:19.140 O tom, zda tyto zprávy jsou generovány v back-end na základě 00:56:19.190 --> 00:56:22.840 na některé změny v systému nebo něco jako chcete odeslat 00:56:22.890 --> 00:56:26.270 Chcete oznámení uživateli, upozornění je v systému Windows 00:56:26.320 --> 00:56:30.510 7 pole, kde je k dispozici žádná oznámení. Služba. Chcete upozornit 00:56:30.560 --> 00:56:34.520 jim a řekněte přece je nová aktualizace k dispozici v aplikaci Visual Studio 00:56:34.570 --> 00:56:39.970 naleznete ji stáhnout. Nebo je ještě důležitější jim s nízkou latencí řazení 00:56:40.020 --> 00:56:43.890 z kanálu kde, pokud tyto změny v jedné instanci VS, ostatní 00:56:43.940 --> 00:56:45.430 VS instance synchronizace nahoru. 00:56:46.140 --> 00:56:48.340 Můžete sues témata a předplatné pro tuto. 00:56:49.760 --> 00:56:52.470 Tak si jej představit koncepčně jako uživatel na VS téma. 00:56:53.200 --> 00:56:58.800 Máte instanci předplatné na VS vždy připojen pomocí MQP. 00:56:58.850 --> 00:57:03.260 Takže MQP nám poskytuje mnoho připojení Pokud mají účinnost 00:57:03.310 --> 00:57:07.830 na nás milióny a milióny sekce souběžně s velmi, 00:57:07.880 --> 00:57:12.350 velmi nízkou režii, pouze čekání Příležitostná oznámení. 00:57:12.380 --> 00:57:14.840 To je rozdíl o oznámení. Jsou to velmi příležitostné 00:57:14.890 --> 00:57:18.080 v přírodě. Jak často dělat TWAIN změnit jejich barvu profilu? 00:57:19.770 --> 00:57:20.260 Den? 00:57:20.310 --> 00:57:22.960 Týden? Zpravidla není každý den. 00:57:23.790 --> 00:57:25.160 Závisí na vaší nálady I odhad. 00:57:26.260 --> 00:57:29.100 Ale nestává často. Jak často se mají aktualizace 00:57:29.150 --> 00:57:33.660 Chcete-li vysunout? Není příliš často. Ale máte tento typ BNS 00:57:33.710 --> 00:57:38.290 infrastruktury, které jsou k dispozici pro Máte kde připojení 00:57:38.340 --> 00:57:41.780 Čekání na oznámení, protože Při oznámení 00:57:41.830 --> 00:57:45.170 bude k dispozici, se bude okamžik. Má právo 00:57:45.220 --> 00:57:46.040 a pak tam. 00:57:51.000 --> 00:57:54.990 Takže zde je třeba přemýšlet o a je třeba zvážit 00:57:55.040 --> 00:57:59.320 o toku zpráv. Protože dnes Témata umožňují až 2000 00:57:59.370 --> 00:58:03.170 odběry a pokud uvažujete stupnice na číslo 00:58:03.220 --> 00:58:07.420 přijímačů 2000 může stačit nebo 2000 nemusí stačit. 00:58:07.980 --> 00:58:10.910 Pokud si myslíte o aplikaci Visual Studio jedna osoba s více 00:58:10.960 --> 00:58:13.700 než 2000 instance rozhraní IDE systémem je 00:58:16.030 --> 00:58:20.210 Další možné. Nevím, možná je možné, ale nejsou provedeny. 00:58:20.520 --> 00:58:24.520 Tak je uživatel na VS téma je dobře, ale pro vás, může být 00:58:24.570 --> 00:58:27.660 být každý poslouchá na stejném kanálu. Chcete 00:58:27.710 --> 00:58:30.790 být schopen odeslat všem uživatelům odeslat... jednu zprávu a odeslat ji 00:58:30.840 --> 00:58:34.790 široký nádech všem uživatelům. Dobře, potom Chcete-li zřetězit dohromady témata. 00:58:35.250 --> 00:58:38.680 A této pomocí automatické předávání. 00:58:39.850 --> 00:58:43.350 Nehodlám přejít do svazku Tyto údaje vzorek v 00:58:43.400 --> 00:58:45.280 podmínky jak nastavit filtry. 00:58:45.800 --> 00:58:48.520 Všechny tyto jsou uvedeny ukázky na MSDN.com. 00:58:49.130 --> 00:58:55.380 Tento konkrétní příklad je volána. seznam. Zde je příklad nazývá 00:58:55.430 --> 00:58:58.720 Publikovat odběru. Celý kód To je k dispozici. 00:58:58.770 --> 00:59:02.570 Opravdu rádi, že přejdete na příkaz přijmout vzhled, ale s Tato témata 00:59:02.620 --> 00:59:06.190 ve skutečnosti můžete vyrovnat se tyto bohaté kde jsou toky všech zpráv 00:59:06.240 --> 00:59:09.930 nemusí získat směrovány všem TWAIN 2 miliony a pak 00:59:09.980 --> 00:59:14.280 pokaždé, když získat zrušen. Můžete získat směrování pro jednu osobu k mnoha 00:59:14.330 --> 00:59:18.680 osoby, nebo v nekonečné typ případu právě píšete adresu. 00:59:18.730 --> 00:59:19.660 Stejně jako e-mail. 00:59:20.190 --> 00:59:23.130 V tomto případě je jako oznamující zprávu, kterou lze říci první, 00:59:23.180 --> 00:59:24.230 čárka, druhé. 00:59:25.130 --> 00:59:27.850 A I 'm adresování dvě zařízení, první zařízení a druhý 00:59:27.900 --> 00:59:30.770 zařízení nebo dva odběry první a druhá. 00:59:30.820 --> 00:59:35.390 Protože pravidla nastavit jako první a jako druhý v něm. 00:59:36.390 --> 00:59:40.470 Takže opravdu podívejte se na tyto sub pub (indiscernible) 00:59:42.610 --> 00:59:47.050 Automatické předávání. Velmi snadno Chcete-li použít. V podstatě vytvořit 00:59:47.100 --> 00:59:52.150 vaše cílové fronty první a na zdrojové fronty je 00:59:52.200 --> 00:59:55.970 přidáte jednu vlastnost. Jedinou vlastností se nazývá zdroj.ForwardTo, 00:59:57.220 --> 01:00:00.600 do cílové fronty a to je ji. Všechny zprávy pocházející 01:00:00.650 --> 01:00:03.280 do zdrojové fronty přejít do cílové fronty. 01:00:03.330 --> 01:00:10.030 Zdroje mohou být odběry a fronty. Audity mohou být témata 01:00:10.080 --> 01:00:10.960 a fronty. 01:00:13.190 --> 01:00:16.800 Zcela symetrické, nastavit tolik by písmo omluvu při 01:00:16.850 --> 01:00:18.810 například, zjistíte, že. 01:00:19.400 --> 01:00:22.540 Pokud máte přechodné případy kde máte předplatné, 01:00:22.590 --> 01:00:23.390 budou pryč, 01:00:24.660 --> 01:00:28.430 můžete odstranit automaticky v nečinnosti. Tak je také velmi úhledný funkce. 01:00:28.480 --> 01:00:32.570 Umožňuje správu velkého počtu dočasné připojení. Ve skutečnosti 01:00:32.620 --> 01:00:35.640 Některé klíčové scénáře, to je používán je SignalR a 01:00:35.690 --> 01:00:38.590 Vstupně-výstupní operace soketu. Jsou velmi, velmi přechodné povahy. 01:00:38.640 --> 01:00:40.200 Přijde připojení, připojení přejít. 01:00:41.380 --> 01:00:43.700 Přidán zatížení a získat odebrat uzly. 01:00:44.600 --> 01:00:48.680 Tak, aby používaly jako zálohování služby sběrnice hrát kde v podstatě jsou 01:00:48.730 --> 01:00:52.540 psaní předplatné na uzlu při každém nový odběr pochází 01:00:52.590 --> 01:00:56.160 vytvořit nové připojení zobrazí nový uzel zobrazí, když se 01:00:56.210 --> 01:00:57.260 Přidejte servery. 01:00:58.320 --> 01:01:03.210 A potom použít témata a předplatné jako zpětné potrubí pro 01:01:03.260 --> 01:01:05.970 přenos zpráv mezi uzly a získat širší měřítko. 01:01:07.010 --> 01:01:10.090 A potom když uzel zmizí, předplatné vyprší, ty 01:01:10.140 --> 01:01:17.490 zprávy jsou pryč zde. Obě Tyto kódu jsou otevřený kód. 01:01:17.540 --> 01:01:20.240 Obě jsou k dispozici, pokud chcete rozšiřování, mimo signál nebo zásuvky 01:01:20.290 --> 01:01:24.720 Vstupně-výstupní protože potřebujete odolný zasílání zpráv kanál na konci služby 01:01:24.770 --> 01:01:27.980 Sběrnice je implementace u obou těchto. 01:01:29.920 --> 01:01:33.050 I chtěli mluvit trochu postaveny o dostupnosti tak manuální 01:01:33.100 --> 01:01:36.780 rychle, pokrytí. Vím, že jsme téměř v čase 01:01:38.830 --> 01:01:42.440 Kód musí být odolné k operaci selhání a připojen 01:01:42.490 --> 01:01:43.470 s problémy. 01:01:43.990 --> 01:01:46.750 Fronty nedoručených zpráv, jako I v aplikaci jste opravdu pomůže. Pomáhají 01:01:46.800 --> 01:01:50.790 kde je v aplikaci na úrovni decivilization zprávu nebo 01:01:50.840 --> 01:01:51.830 něco může selhat. 01:01:52.980 --> 01:01:57.440 Každou zprávu, která vyvolává Service Bus v přechodné vlastnost 01:01:57.490 --> 01:01:58.020 na ní 01:01:59.480 --> 01:02:02.780 jasně a jednoduše je snadné Pokud chcete vědět, zda je 01:02:02.830 --> 01:02:04.350 nutné ji opakovat, nebo ne. 01:02:05.090 --> 01:02:08.560 Ve výchozím nastavení ve skutečnosti jsme automaticky Opakovat. Tak I kontakt 01:02:08.610 --> 01:02:12.090 o časové limity v podstatě operace časové limity. Ve výchozím nastavení 01:02:12.140 --> 01:02:15.190 operace časové limity jsou nastaveny na 60 sekund, což znamená, pokud je 01:02:15.240 --> 01:02:19.720 vytvořit odeslat volání, může dojít k selhání jednou, Pokusíme se ji znovu po 01:02:19.770 --> 01:02:22.980 tři sekundy. Může podat dvakrát. Bude Zkuste jej znovu po deseti sekundách. 01:02:23.030 --> 01:02:27.840 V tom, že bude 60 sekund, které poskytnete, Zkuste toto volání úspěšné. 01:02:27.890 --> 01:02:29.740 A pokud ne, pošleme je na vás. 01:02:31.320 --> 01:02:33.650 Pokud máte na jiném místě zachovat to, že je v pořádku. 01:02:33.700 --> 01:02:36.920 V opačném případě zkontrolujte jako přechodné a pak ji odešlete zpět, uhodnout. 01:02:38.160 --> 01:02:42.430 A oddíl fronty a témata výrazně lepší dostupnost. 01:02:43.080 --> 01:02:48.230 Zlepšení řádově. Tak velmi velmi doporučujeme použití 01:02:48.280 --> 01:02:49.710 Tuto funkci. 01:02:51.830 --> 01:02:55.280 Ve výchozím nastavení opakování zásady na. Nevypínejte jej, prosím. 01:02:57.200 --> 01:02:59.970 Dvojice název prostory. Poslední věc, kterou budete hovořit o dnes. 01:03:00.490 --> 01:03:03.540 Pokud máte Service Bus, s názvem místa, zprávy jsou úhledně zarovnány toku. 01:03:03.590 --> 01:03:08.210 prostřednictvím a pak celou datovou Centrum přejde caput nebo alespoň 01:03:08.260 --> 01:03:13.570 celý název místa přechází caput. Chybný název místa vytvoří. 01:03:13.620 --> 01:03:15.790 zálohovat oboru názvů. Vytvoření zálohovat oboru názvů. 01:03:15.840 --> 01:03:19.190 Stačí poskytnout je pro nás a My se Start ukládání zpráv v 01:03:19.240 --> 01:03:23.440 zálohovat oboru názvů. Takže žádné zpráva, že selže přejít do 01:03:24.140 --> 01:03:25.350 Přejde do zadní. 01:03:26.210 --> 01:03:29.450 V určitém okamžiku začne zprávy protéká. Systém 01:03:29.500 --> 01:03:30.340 bude se vrátit. 01:03:31.350 --> 01:03:35.150 A v tomto okamžiku máme sifonu z těchto zpráv bude trvat. 01:03:35.200 --> 01:03:39.110 přenos fronty a reenqueue jejich původní fronty. 01:03:40.650 --> 01:03:43.590 Tak pro všechny tohoto kódu odesílatele nezmění váš přijímač 01:03:43.640 --> 01:03:46.370 Kód nelze změnit. Vaše odesílatele a příjemce, jako kdyby byly 01:03:46.420 --> 01:03:48.470 vždy mluví služby Obor názvů sběrnice. 01:03:49.240 --> 01:03:54.700 Pod desky vytváříme fronty přenos, přesun 01:03:54.750 --> 01:03:57.870 zprávy k dispozici a poté vytažení. jejich návratu pro vás. 01:03:58.720 --> 01:04:03.160 A to je pouze část kód, který chcete upravit. 01:04:03.740 --> 01:04:06.070 To není jen práce, kterou máte Chcete-li provést. Jsme budete hovořit o 01:04:06.120 --> 01:04:08.520 důležité informace, ale to je pouze část kódu, které je třeba 01:04:08.570 --> 01:04:13.330 Změna, která je, že při vytváření výrobce, který je v 01:04:13.380 --> 01:04:17.690 Spustit čas odesílání a přijímání kód třídy, můžete spárovat jej s názvem 01:04:17.740 --> 01:04:21.230 místo, řeknete přece, že je druhý výroby, druhý obor názvů 01:04:21.280 --> 01:04:24.130 správce, který má Chcete-li bude spárována s. 01:04:24.660 --> 01:04:28.600 A všechno ostatní se provádí na straně klienta. Žádná změna odesílatele. 01:04:28.650 --> 01:04:31.470 Žádná změna příjemce. Kód zůstává stejný. 01:04:36.210 --> 01:04:41.520 Nyní je podporováno odesílatele k dispozici. Jak jste již viděli v diagramu 01:04:41.570 --> 01:04:44.590 příjemce se zobrazí zpráva do původní název 01:04:44.640 --> 01:04:45.760 místo vracejí. 01:04:46.330 --> 01:04:49.340 Tak to je další z dostupnosti odeslat. Právo nyní proto 01:04:49.390 --> 01:04:54.000 nazýváme ji odeslat možnosti dostupnosti. Objednání mohou být ztraceny, protože 01:04:54.050 --> 01:04:57.910 zprávy, které jsou v převodu fronta se nezobrazí. 01:04:58.630 --> 01:05:02.360 A poté zobrazí konec konců čekací doba může samozřejmě být vysoká. 01:05:02.410 --> 01:05:06.420 To jsou některé aspekty ale ve skutečnosti si můžete představit jako 01:05:06.470 --> 01:05:10.730 klíčové scénáře pro výrobu Typ zotavení po havárii 01:05:12.070 --> 01:05:14.770 Někdy scénáře. 01:05:15.810 --> 01:05:18.710 Jen tak zavřít, jsme viděli Azure Ve skutečnosti škálovat Service Bus 01:05:18.760 --> 01:05:21.870 ve všech rozměrech. Velké množství uživatelů. Velké množství propustnost. 01:05:21.920 --> 01:05:23.080 Velké množství přijímačů. 01:05:23.730 --> 01:05:27.420 A zlepšila se spolehlivost pomocí nové funkce 01:05:27.470 --> 01:05:31.950 pole podobně jako oddíl fronty a párový mezery v názvu nebo podle 01:05:32.000 --> 01:05:37.320 provádění kódu používat vzory jako Asynchronní a dávek a doplňky. 01:05:38.100 --> 01:05:41.750 Tuny odkazů. Tun zdrojů. Máte přístup ke všem který. 01:05:41.800 --> 01:05:44.130 Děkuji mnohokrát. Omlouvám pro cokoliv.