WEBVTT

00:00:01.460 --> 00:00:02.340
Dzień dobry.

00:00:04.930 --> 00:00:05.880
Jak robisz ludzi?

00:00:08.810 --> 00:00:14.600
Dobry? Wy sprawiły, że prawie
do końca konferencji.

00:00:15.630 --> 00:00:17.150
W jaki sposób doświadczenia
zostały do tej pory?

00:00:17.160 --> 00:00:19.360
[Oklaski]

00:00:19.520 --> 00:00:20.120
>> Dobre.

00:00:20.170 --> 00:00:24.940
Awesome. Dobrze, jak mówią, że
Zawsze zapisuj najlepiej ostatnio.

00:00:26.240 --> 00:00:32.190
Mam więc nadzieję I nie zawiedzie
WAS. Naprawdę docenia

00:00:32.240 --> 00:00:34.450
za co po południu.

00:00:35.200 --> 00:00:40.360
Jestem Abhishek Lal. Menedżer programów
z zespołem platformy Azure.

00:00:41.090 --> 00:00:45.840
Jest to zespół, który tworzy PaaS
usługi takie jak telefon komórkowy usługi

00:00:45.890 --> 00:00:48.550
Magistrala usług, Azure pamięci podręcznej.

00:00:49.240 --> 00:00:51.080
I usług multimedialnych.

00:00:51.720 --> 00:00:54.320
Usługi te są co
zespół jest właścicielem.

00:00:54.830 --> 00:00:58.940
A w szczególności pracuję
dla ostatnich trzech plus lat

00:00:58.990 --> 00:01:05.100
na tworzenia pośredniczonych wiadomości
kawałki. Tak jest to kolejki,

00:01:05.150 --> 00:01:08.720
Tematy, są typu pub sub,
kawałki tego.

00:01:09.470 --> 00:01:15.150
Dziś będziemy mówić o
Obsługa wiadomości w skali.

00:01:17.010 --> 00:01:22.030
Kolejki i tematy. Teraz są ludzie
zaznajomieni z magistrali usługi.

00:01:22.840 --> 00:01:26.920
To objąć przekazywania. Robi
obejmują powiadomienie koncentratora

00:01:27.780 --> 00:01:29.010
kolejki i tematy.

00:01:29.560 --> 00:01:34.840
Tak jest swego rodzaju całej szerokości
usług związanych z wiadomości.

00:01:35.710 --> 00:01:39.560
Będzie to konkretnej sesji
Aby skoncentrować się głównie na kolejek

00:01:39.610 --> 00:01:46.260
i tematów, tak że podstawowy
obszar. Ale jeśli masz pytania

00:01:46.310 --> 00:01:50.120
lub cokolwiek chcieliby wiedzieć
konkretne informacje na temat przekazywania lub

00:01:50.170 --> 00:01:55.150
Koncentratory powiadomienia cieszę się
odpowiedzieć na to lub przynajmniej punkt

00:01:55.200 --> 00:01:57.410
Możesz w odpowiednim kierunku.

00:01:58.820 --> 00:02:00.930
Istnieje wiele rzeczy
Chcę, aby obejmować dzisiaj.

00:02:01.710 --> 00:02:04.730
Porozmawiaj o różnych aspektach
skali. Chcę mówić

00:02:04.780 --> 00:02:08.490
o nadawcy i odbiorcy oraz
przepływność, wszystkie różne

00:02:08.540 --> 00:02:11.630
desenie, jak również
Charakterystyka kodu.

00:02:12.390 --> 00:02:14.870
Tego, jak osiągnąć skali.

00:02:15.810 --> 00:02:19.040
Spróbuję tak dobry Nadążanie.

00:02:19.640 --> 00:02:24.190
Pytania są wielkie. Jeśli widzisz mnie
Uruchamianie wyciąć krótkie pytania

00:02:24.240 --> 00:02:27.780
nieco później, po prostu tak, że mogę
mogą obejmować wszystkich rzeczy, które chcę

00:02:27.830 --> 00:02:31.490
na pokrycie. I będzie dostępna po
Sesja i można zawsze

00:02:31.540 --> 00:02:36.200
dotrzeć do mnie, ale zachować interaktywne.
Coś, co masz,

00:02:36.250 --> 00:02:41.270
mikrofony są tutaj.
Po prostu podejść i zadzwonię.

00:02:43.930 --> 00:02:48.720
Zaczniemy mówić o tym, co od 's
nowe. Tak jakby aktualizacji

00:02:48.770 --> 00:02:51.210
na co będziemy już ogłoszone 2.3 SDK.

00:02:52.250 --> 00:02:56.290
My przejść do mówić o
Wymiary skali.

00:02:56.340 --> 00:03:00.420
Będziemy rozmawiać o nadawcy i odbiorcy,
przepływność, jak osiągnięcia tego.

00:03:01.800 --> 00:03:05.770
A następnie będziemy spędzić trochę czasu na
Uwagi dotyczące dostępności.

00:03:05.820 --> 00:03:07.850
Dostępność tylko, co oznacza szeroko

00:03:09.190 --> 00:03:14.340
odporności, lepiej SLA i w jaki sposób
do projektowania aplikacji

00:03:14.390 --> 00:03:19.520
należy zawsze, zawsze, systemem
tam więc możemy poświęcić trochę

00:03:19.570 --> 00:03:20.510
czas w tej sprawie.

00:03:22.060 --> 00:03:25.780
Tak SDK 2.3.

00:03:26.330 --> 00:03:28.310
Co tylko udostępniamy?

00:03:29.070 --> 00:03:32.540
Na sesji wiadomość. Członka itd.
jury są push

00:03:32.590 --> 00:03:36.970
Styl interfejsu API. Zasadniczo trwa
od ciężkiej pracy od Ciebie

00:03:37.020 --> 00:03:42.960
pisanie pętli C lub nic
że złożoności i go

00:03:43.010 --> 00:03:46.420
daje bardzo zdarzeń inne
model do spożywania wiadomości.

00:03:46.470 --> 00:03:50.110
Jest to interfejs API po stronie odbiorcy. Tak
Mamy który dla sesji.

00:03:50.160 --> 00:03:52.680
Zdecydowanie zajmiemy się że
dziś bardziej szczegółowo.

00:03:53.890 --> 00:03:58.440
Łączność tryb Autowykrywanie.
Tak jak już wiadomo, jednym z rzeczywistym

00:03:58.490 --> 00:04:02.520
wartość klucza została magistrali usług Azure
który po podłączeniu

00:04:02.950 --> 00:04:07.700
do kolejki i tematy w chmurze
zza zapory z

00:04:07.750 --> 00:04:11.450
własne centrów danych lub z sieci
dane klientów, gniazd produkcyjnych, które

00:04:11.500 --> 00:04:16.230
są siedzieć tyle jest bardzo dobrze chroniony
rodzaju zapory, usługi

00:04:16.280 --> 00:04:19.660
Magistrala ma możliwość nawiązywać połączenia wychodzące nie tylko na porcie TCP

00:04:19.710 --> 00:04:22.110
ale port 83 i 443


00:04:23.670 --> 00:04:25.860
podczas gdy porty TCP są zablokowane.


00:04:26.700 --> 00:04:30.790
Ten obiekt będzie nadal jest teraz dostępny
tylko wtedy, gdy bezpośrednio ustawić

00:04:30.840 --> 00:04:34.230
katalog z tryb TCP,
więc nigdy nie miał do wyboru.

00:04:34.910 --> 00:04:38.730
Teraz w kodzie można tylko ustawić
wykrywa go na auto, a my

00:04:38.780 --> 00:04:42.910
automatycznie sprawdzić, czy TCP port
dostępne, będziemy używać który.

00:04:42.960 --> 00:04:48.410
Jeśli Zapora blokuje go, będziemy
upuść go HTTP. Tak SDK

00:04:48.460 --> 00:04:51.560
2.3, która jest dostępna
również wiadomości.

00:04:54.390 --> 00:04:57.980
Obsługuje CORS. Jak wielu ludzi
wie, co to jest CORS?

00:05:00.360 --> 00:05:04.200
Większość ludzi wiesz. To zasadniczo
Umożliwia łatwe wysyłanie/odbieranie

00:05:04.250 --> 00:05:09.370
z przeglądarek. Pomysł jest użytkownik
zawsze można mieć zrobione, masz

00:05:09.420 --> 00:05:14.320
STPI z SCTP. Można zrobić Wyślij
wiadomości, komunikaty

00:05:14.370 --> 00:05:18.920
ale z CORS teraz to sprawia, że wiele
łatwiejsze dla przeglądarek i witryn sieci Web

00:05:18.970 --> 00:05:23.650
Aby zintegrować pion Wstecz, a my
do tego szczegółowo dzisiaj.

00:05:25.010 --> 00:05:29.530
Podobnie rodzaju pomocą w
wydajność, a także skalę

00:05:29.580 --> 00:05:34.760
dla nadawców HTTP mamy
Tworzenie pakietów wsadowych teraz dostępne.

00:05:35.200 --> 00:05:43.980
A następnie para perf po stronie klienta
liczniki, które jest, gdy jesteś

00:05:44.030 --> 00:05:46.900
naprawdę przełączenie aplikacji
który jest skomplikowany lub jesteś

00:05:46.950 --> 00:05:50.450
będzie ono działać w różnych środowiskach,
konieczne może być

00:05:50.500 --> 00:05:53.340
zdebuguj go, i może być konieczne do profilu
to więc dodaliśmy klienta

00:05:53.390 --> 00:05:57.890
liczniki wydajności po stronie wiadomości wysłanych
na drugim, litery na sekundę

00:05:57.940 --> 00:06:01.460
i rzeczy, jak to, co może naprawdę,
naprawdę pomóc profilu

00:06:01.510 --> 00:06:05.250
w przypadku wiadomości jest warstwa
robienie ogólnie jesteś przeciwny

00:06:05.300 --> 00:06:09.020
robi okazji. Tak będzie tych
następnie manifest dla tych perf

00:06:09.070 --> 00:06:14.230
liczniki jako część pakietu NuGet
w tak naprawdę umożliwia

00:06:14.280 --> 00:06:17.550
Podczas wykonywania niektórych dobre debugowania.

00:06:20.550 --> 00:06:23.340
I wreszcie, Mistyczne
dla kolejki utraconych wiadomości.

00:06:23.880 --> 00:06:27.380
Deadlettering jest bardzo zaawansowane
Funkcja gdzie chroni

00:06:27.430 --> 00:06:30.820
jesteś wstecz kończy się, jeśli istnieją poison
wiadomości. Są to zazwyczaj

00:06:30.870 --> 00:06:34.620
nazywane kolejkami poison, gdzie możesz spróbować
Aby komunikat o błędzie i

00:06:34.670 --> 00:06:38.600
komunikat nie został utworzony lub jest
Błąd w kodzie gdzieś

00:06:38.650 --> 00:06:42.080
w w civilizer de gdzieś
Jeżeli nie możesz otworzyć

00:06:42.130 --> 00:06:44.560
wiadomość i awarie sieci wewnętrznej bazy danych.

00:06:45.780 --> 00:06:50.390
Usługa magistrali daje możliwość
ustawienia dostarczania max

00:06:50.440 --> 00:06:54.420
Liczba, której wartością domyślną jest 10, a także co
oznacza to, że jeśli widzimy

00:06:54.470 --> 00:06:57.660
że mamy wydana wiadomości
do Ciebie 10 razy i masz

00:06:57.710 --> 00:07:01.310
nie pomyślnie ukończona
wiadomość, możemy spowoduje przeniesienie go z

00:07:01.360 --> 00:07:03.240
kolejki głównej do
Kolejka utraconych wiadomości.

00:07:03.870 --> 00:07:07.930
Dzięki temu dosłownie aplikacji
być odporne domyślnie

00:07:08.190 --> 00:07:12.840
bez konieczności pisania pojedynczy
wiersz kodu i ochrony

00:07:12.890 --> 00:07:18.660
Serwery back-end. Tak Mistyczne
jest to zdolność do kanału

00:07:18.710 --> 00:07:23.810
wiadomości automatycznie tworzyć bogate
przepływy wiadomości a teraz

00:07:23.860 --> 00:07:30.000
można wykonać aplikację, który może mieć
6, 8, 10 kolejek i Mistyczne

00:07:30.050 --> 00:07:34.450
dla tej kolejki utraconych wiadomości do
pojedynczej kolejki, co oznacza

00:07:34.500 --> 00:07:38.530
Teraz masz najlepszy teraz
odbierać wiadomości poison

00:07:38.980 --> 00:07:42.340
niezależnie od tego, jak wiele kolejek
lub tematy lub subskrypcji możesz

00:07:42.390 --> 00:07:46.280
używasz, tak że
Funkcja dodać zbyt.

00:07:47.180 --> 00:07:49.910
Omówimy, który w
bardziej szczegółowo.

00:07:51.740 --> 00:07:57.570
Chcę szybko podsumować co
Zrobiliśmy od ostatniego kwietnia

00:07:57.620 --> 00:08:01.400
Dlatego, gdy jest mowa o dziś w
względem skali i wydajności

00:08:01.450 --> 00:08:05.780
i przepustowość widać dużo
te funkcje, do którego nastąpiło odwołanie

00:08:06.180 --> 00:08:08.570
więc chciałem wyróżnić je
do terminów, czy są one

00:08:08.620 --> 00:08:12.370
już dostępne dziś i oni już
została na jakiś czas, ale

00:08:12.420 --> 00:08:16.250
mają one nadal tam.

00:08:18.520 --> 00:08:22.290
Działa jako jedno, aby zobaczyć tutaj
poniżej linii pierwszy

00:08:22.340 --> 00:08:26.310
do magistrali usługi na obietnicy tak ostatni
rok zrobiliśmy Service Bus

00:08:26.360 --> 00:08:28.900
1.1 dla wersji systemu Windows server.

00:08:29.580 --> 00:08:33.210
Jest to całkowicie symetrycznego dla
Kolejka i tematy, co oznacza

00:08:33.260 --> 00:08:37.450
Jeśli wybierze się SDK 2.1, na przykład
ostatni zestaw SDK, który był

00:08:38.470 --> 00:08:42.010
użytkownik będzie mógł albo trafienie
usługi lub na założeniu wszystkie

00:08:42.060 --> 00:08:45.070
Funkcje, które są dostępne.

00:08:46.760 --> 00:08:51.600
Ten rytm sortowania dopuszczenia chmury
co trzy miesiące możesz

00:08:51.650 --> 00:08:55.290
można zobaczyć co trzy do czterech miesięcy
i na założeniu Zwolnij w

00:08:55.340 --> 00:08:59.520
co najmniej raz w roku jest co spróbujemy
Aby zachować, a następnie doprowadzić zarówno

00:08:59.570 --> 00:09:02.680
Funkcja ustawia do parzystości.

00:09:05.540 --> 00:09:08.740
Tak jest dostępne dla
Odwołanie później pod względem:

00:09:08.790 --> 00:09:10.010
funkcje.

00:09:12.110 --> 00:09:13.310
Pytania do tej pory?

00:09:15.820 --> 00:09:16.720
Tak, proszę.

00:09:16.730 --> 00:09:19.730
[Indiscernible]

00:09:19.950 --> 00:09:23.560
>> Tak było pytanie: kiedy będzie
być Następna aktualizacja i gdzie

00:09:23.610 --> 00:09:28.920
najnowsze zwróci 2.3,
Brak funkcji.

00:09:28.970 --> 00:09:33.240
W tej chwili nie mam żadnych terminów
Aby udostępnić dla następnego serwisu

00:09:33.290 --> 00:09:36.320
Magistrala wydania, ale nie będzie
być 2.2 lub 1.2.

00:09:37.800 --> 00:09:42.620
Ale zwykle można to traktować
konkretnej wersji tej daty

00:09:43.340 --> 00:09:46.900
dopasowane wydania systemu Windows Server
więc większość czasu

00:09:46.950 --> 00:09:51.580
Aby wyrównać z wersjami serwera tak
Będziemy mieć maksymalną platformy

00:09:51.630 --> 00:09:55.010
korzyści, więc upewnić się że mamy
największe serwera z najnowszymi

00:09:55.060 --> 00:09:59.310
klastrowanie z najnowszych zarządzania
i defaces i wszystko.

00:09:59.360 --> 00:10:03.610
Założono więc zazwyczaj tylko wskazówki
który tego samego rodzaju rytm

00:10:03.660 --> 00:10:05.820
nastąpi. Dobre pytanie.

00:10:08.920 --> 00:10:13.130
Skalowanie na nadawcy. Zacznijmy od
to pod względem pierwszego

00:10:13.180 --> 00:10:14.210
aspekt skali.

00:10:15.570 --> 00:10:18.650
Więc nadawców nie jest niczym, ale
gdzieś gdzie one

00:10:18.660 --> 00:10:20.040
[Indiscernible]

00:10:20.000 --> 00:10:22.830
Można wyobrazić sobie wiele scenariuszy
w tym miejscu. Możesz myśleć o urządzenia

00:10:22.880 --> 00:10:24.970
telemetrii, akcje użytkownika.

00:10:26.630 --> 00:10:31.030
I systemy generowania zdarzeń
i B i B rodzaju scenariusza.

00:10:31.080 --> 00:10:32.910
Zdarzenia generowane.

00:10:33.640 --> 00:10:37.660
Jak dbasz scenariuszy
Jeżeli masz wiele z tych

00:10:37.710 --> 00:10:41.620
lub może być kilka z nich z wieloma
zdarzenia lub partii nadawców

00:10:41.670 --> 00:10:45.250
wiele zdarzeń? Wszystkie te
są możliwe scenariusze.

00:10:46.830 --> 00:10:50.480
Tak więc zrobimy to konkretne. Będziemy
Rozpocznij z rzeczywistego scenariusza

00:10:50.530 --> 00:10:54.510
których klienci są używane także do dziś
który jest, gdzie trzeba

00:10:54.560 --> 00:10:58.850
Gromadź zdarzenia do analizy z
duża liczba urządzeń.

00:11:00.370 --> 00:11:05.900
Urządzenia te mogą wyglądać znajomo
ale to przypadek który

00:11:05.950 --> 00:11:11.000
Będę ani potwierdzić ani odmówić.
Dlatego może być dowolnego urządzenia.

00:11:11.050 --> 00:11:12.350
Może to być dowolnego urządzenia.

00:11:13.160 --> 00:11:18.850
Teraz wszystko to zaczyna się od
urządzenie jest w stanie do kolejek

00:11:18.900 --> 00:11:24.250
wiadomości móc zastosować kilka
Tematy lub jeden temat i wypychania

00:11:24.300 --> 00:11:28.090
w dużej ilości informacji
do tego kanału

00:11:29.520 --> 00:11:33.640
Po uzyskaniu w temacie wiadomości
uważasz, że możesz

00:11:34.710 --> 00:11:39.370
mają kilka scenariuszy, w którym
konieczne jest ograniczenie zużycia go.

00:11:39.420 --> 00:11:43.330
W czasie rzeczywistym analytics lub to, co
zrobić z własnego kodu jest

00:11:43.380 --> 00:11:48.570
naprawdę staje się znacznie bardziej rozpowszechniony
i popularne. Czy aby ludzie

00:11:48.620 --> 00:11:53.840
do sesji Orleanu który
wczoraj została wykonana? Dobrze, jeśli

00:11:53.890 --> 00:11:57.080
zrobiłeś awesome, awesome kawałek
technologii bo stara

00:11:57.130 --> 00:12:02.580
Aby rozwiązać ten problem pracy użytkownika
kod w skali w Rozproszony

00:12:02.630 --> 00:12:06.190
moda, czy masz do czynienia z
zdarzenia, które są generowane

00:12:06.240 --> 00:12:10.830
przez dużą liczbę nadawców i są
skorelowane w co w jaki sposób.

00:12:12.020 --> 00:12:15.930
W jaki sposób upewnić się że te
systemy back-end są rozdzielone?

00:12:15.980 --> 00:12:18.590
Jak należy upewnić się, że te
systemami zaplecza są w stanie

00:12:18.640 --> 00:12:24.640
zużywają wiadomości po tym kursie i działać
sposoby są wytrzymałe?

00:12:25.950 --> 00:12:29.560
I że tematy można umieścić w
środek. Nie tylko tematy tak

00:12:29.610 --> 00:12:33.440
daje buforowania, podobnie jak
czy kolejki, co oznacza

00:12:33.490 --> 00:12:35.950
back-end można zrobić dla
kilka godzin i nie

00:12:36.000 --> 00:12:39.060
utratę wszelkich zdarzeń. Zdarzenia
nadal istnieje w obiekcie, ale

00:12:39.110 --> 00:12:40.490
również daje pub sub.

00:12:41.470 --> 00:12:45.530
Co oznacza, że jeśli masz inne
systemy, które nie robi

00:12:45.580 --> 00:12:51.310
Stan śledzenia, powiedzmy, że wprowadzenie
wartości do kabli Azure, lub

00:12:51.360 --> 00:12:56.520
robią analytics partii z
łącze, strukturę pliku w

00:12:56.570 --> 00:13:00.330
HDFS, a następnie uruchom Hadoop
zadania na nim.

00:13:01.400 --> 00:13:05.850
Lub ich wysokość być stawiając gracza jest
dane do magazynu danych SQL

00:13:05.900 --> 00:13:09.170
i uruchamianie kwerend BI
do tego.

00:13:09.790 --> 00:13:13.980
Wszystkie te systemy można go sprawdzić
w strumieniu zdarzenia.

00:13:15.280 --> 00:13:18.350
I nie tylko tym samym zdarzenie strumień,
mogą wyglądać na to zdarzenie

00:13:18.400 --> 00:13:21.780
Stream, zbyt. Być może BI działa magazynu,
nie chcesz korzystać z

00:13:21.830 --> 00:13:25.870
wszystkie zdarzenia. Dowolne działanie związane z
zdarzenia nie powinny znajdować się tam.

00:13:25.920 --> 00:13:29.420
Należą wyłącznie do rzeczy kodu.
Możesz podzielić strumieni

00:13:29.470 --> 00:13:30.210
w ten sposób.

00:13:32.750 --> 00:13:36.990
A następnie z sieci wewnętrznej, czy
czytasz swoje Azure

00:13:37.040 --> 00:13:41.730
tabele lub SQL magazynu danych
można wygenerować Twojej imprezie

00:13:41.780 --> 00:13:43.200
tablice i analiz.

00:13:44.750 --> 00:13:45.750
To jeden z głównych

00:13:46.970 --> 00:13:49.340
punkty projektu w tym pakiecie.

00:13:50.180 --> 00:13:52.920
Najpierw używa tematy
wentylatora w.

00:13:53.960 --> 00:13:57.730
Wentylator w niezbędne oznacza, że mają mniej
Tematy niż można mieć urządzenia.

00:13:57.780 --> 00:13:59.900
Prawo? Co to są który
Relacja może być.

00:14:01.080 --> 00:14:03.820
Prawdopodobnie nie będzie się
jeden. To nie będzie mieć wartość

00:14:03.870 --> 00:14:07.660
temat dotyczący wszystko. Jest to prawdopodobnie
nie będzie będzie pozwala N.

00:14:07.710 --> 00:14:12.220
być gdzieś pomiędzy nimi i jako
mówimy o jak wymyślić

00:14:12.270 --> 00:14:13.860
z tym odpowiedni numer.

00:14:14.410 --> 00:14:18.960
Masz zamiar załadowania równowagi między
centra danych z kilku powodów.

00:14:19.320 --> 00:14:22.490
Jeśli myślisz o tym tych urządzeń
są faktycznie geograficznie

00:14:23.190 --> 00:14:26.300
rozłożone, więc chcesz wprowadzić
pewien, że urządzenie używa

00:14:26.350 --> 00:14:30.740
najmniejszą ilość energii, najniższa
czas oczekiwania na połączenie ma być możliwe

00:14:30.790 --> 00:14:33.770
Aby dotrzeć i jego dane w kolejce.

00:14:35.480 --> 00:14:39.640
Tak jest równoważone w danych
gniazd produkcyjnych. Dzięki tej magistrali jest dostępna

00:14:39.690 --> 00:14:45.690
we wszystkich regionach Azure gniazd produkcyjnych wszystkich danych.
Istnieje więc możliwość

00:14:45.740 --> 00:14:50.730
Aby rozmieścić tematy wokół. Na teraz,
nie oznacza to back-end

00:14:50.780 --> 00:14:53.890
systemy muszą zostać przeniesiona
we wszystkich tych miejsc zbyt.

00:14:54.880 --> 00:14:58.000
W przypadku faktów, jeśli myślisz o Hadoop
klastry, jest zazwyczaj

00:14:58.050 --> 00:15:01.860
coś nie będą replikowane w
każdy region w każdym centrum danych.

00:15:01.910 --> 00:15:05.890
Ale daje krótki czas oczekiwania
punkt końcowy. Stamtąd możesz

00:15:05.940 --> 00:15:10.490
zbieranie danych, do których jest on
generowane. A następnie pociągnij go

00:15:10.540 --> 00:15:14.310
z sieci wewnętrznej. Osiągnięcia przez
do tych regionów i

00:15:14.360 --> 00:15:18.450
Subskrypcje w różnych regionach
i korelacji tych danych.

00:15:20.910 --> 00:15:23.690
Filtr wartość true dla subskrypcji wszystkich z wyjątkiem jednego,
tak więc w tym pionowe

00:15:23.740 --> 00:15:27.550
sprawy klienta one faktycznie Dlaczego
spożywanie ich danych i

00:15:27.600 --> 00:15:31.700
Kod śledzenia stanu i partii
Analytics, ale nie w BI.

00:15:31.750 --> 00:15:35.900
Więc te trzy były rzeczywiście prawdziwe
filtry, ale jeden subskrypcja

00:15:35.950 --> 00:15:39.960
miał filtr redukcji. Miał on
Filtr, który powiedział, jeśli jest to gra

00:15:40.010 --> 00:15:45.060
zdarzenia, musimy nie dbają o
że i oczywiście można zrobić

00:15:45.110 --> 00:15:47.360
czasu rzeczywistego i instancja analytics.

00:15:49.410 --> 00:15:53.110
Tak więc w tym scenariuszu dla mnie się zdawało
Firma Microsoft będzie skoczyć szybkie demo.

00:15:54.270 --> 00:15:59.080
I pokazać salę te
obsługuje aspekt to.

00:16:00.290 --> 00:16:05.680
Ponieważ umożliwiają dużo klienta
z punktu widzenia osiągnięcia

00:16:05.730 --> 00:16:11.600
o możliwość w kolejce
wiadomości tylko przy użyciu czystego

00:16:13.270 --> 00:16:15.140
HTTP i rzeczy.

00:16:15.730 --> 00:16:21.550
Mam skonfigurować witryny sieci Web. Wy
można nacisnąć to zbyt Jeśli masz

00:16:21.600 --> 00:16:25.950
urządzenie lub czegoś. O nazwie
Uwaga plik użytkownika czy Azure

00:16:26.000 --> 00:16:28.260
witryny sieci Web platformy .NET.

00:16:29.750 --> 00:16:40.510
Wszystko co mam tutaj jest bardzo prosty
JavaScript, który będzie

00:16:40.560 --> 00:16:41.160
pokazać.

00:16:41.880 --> 00:16:43.280
I co robi

00:16:48.770 --> 00:16:53.470
pobiera się wartości klucza podstawowego
Co to jest jej nazwa wartości

00:16:53.520 --> 00:16:58.790
przestrzeń nazw, jaka jest nazwa kolejki
poproszę reguły władz akredytacji bezpieczeństwa,

00:16:58.840 --> 00:17:02.140
Współdzielony dostęp autoryzacji podpisu,
to, co to za pomocą

00:17:02.190 --> 00:17:03.800
a także klucz władz akredytacji bezpieczeństwa.

00:17:04.950 --> 00:17:07.970
I na podstawie wysłać wiadomość.

00:17:14.280 --> 00:17:18.140
Wiadomość wysłana. To jest
to. Więc można sprawdzić, czy użytkownik

00:17:18.190 --> 00:17:21.380
mają wiele, wiele przeglądarek klientów
lub innego klienta lub

00:17:21.430 --> 00:17:25.940
urządzenie, które można po prostu zrobić czystego HTTP
nie ma tu nie SOAP. Ma nie...

00:17:26.900 --> 00:17:31.300
kodowanie. Można umieścić wiadomości
właściwości w formacie JSON a następnie

00:17:31.350 --> 00:17:35.930
bardzo prosty sposób uzyskać wiadomości
w kolejce. Pozwól mi pokazać

00:17:35.980 --> 00:17:38.170
Możesz kod dla tej witryny sieci Web.

00:17:47.070 --> 00:17:52.110
Tutaj można zobaczyć, czy jesteś
robienie dowolne właściwości sformatowanego

00:17:52.730 --> 00:17:55.220
lub nawet tylko bardzo, bardzo podstawowe właściwości

00:17:58.440 --> 00:18:05.280
Ten kod można łatwo wysłać. I
w rzeczywistości, biblioteka kodu JavaScript

00:18:05.330 --> 00:18:09.370
który jest używany w tym miejscu, Niech
mi pokazują, że do Ciebie także.

00:18:16.200 --> 00:18:22.410
Co to jest strona sieci web co
wykazało, a Ty można zobaczyć jak

00:18:35.560 --> 00:18:40.400
proste naprawdę wysyłania i
otrzymują dla tej wiadomości.

00:18:40.450 --> 00:18:44.840
HTTP, delete jest rzeczywiście
Odbierz scenariusza.

00:18:45.430 --> 00:18:47.500
Które zobaczymy nieco później.

00:18:48.120 --> 00:18:56.600
I umieścić jest scenariusz Wyślij wiadomość,
Niestety, jeśli chodzi o wysyłanie scenariusza.

00:18:58.510 --> 00:19:02.420
Niech tak

00:19:03.620 --> 00:19:05.210
Wyślij mi kilka więcej wiadomości.

00:19:05.810 --> 00:19:09.220
I tak, aby wyświetlał wiadomości
widać, w tym miejscu co mam serwer

00:19:09.270 --> 00:19:12.280
Explorer załadowany z...

00:19:21.330 --> 00:19:25.310
podłączony do mojego obszaru nazw. A ja
proste kolejki, ale w którym

00:19:25.360 --> 00:19:28.770
widać teraz istnieją dwa
wiadomości w kolejce. Jeśli nie

00:19:28.820 --> 00:19:35.430
odświeżanie, wyświetlane są komunikaty 14. Tak
jak w przypadku wiadomości pochodzą w ich

00:19:35.480 --> 00:19:37.840
pojawią się w danej kolejce.

00:19:48.480 --> 00:19:53.620
Zajmiemy się scenariusz odbierania
nieco później pod względem:

00:19:53.670 --> 00:19:56.920
Klient protokołu HTTP. Tak to klienta HTTP.

00:19:57.510 --> 00:20:02.200
Ale Zależało mi się mówić specjalnie
o protokołach.

00:20:02.820 --> 00:20:06.840
Jakie są okoliczności że
należy dokonać przy podejmowaniu decyzji

00:20:06.890 --> 00:20:11.460
Czy za pomocą protokołu HTTP
AMQP. Jak już wiadomo usługi

00:20:11.510 --> 00:20:13.930
BUS obsługuje kilka protokołów.

00:20:15.060 --> 00:20:21.750
HTTP jest po prostu naszych RKDPI jest AMQP
Standardowy protokół, który będę

00:20:21.800 --> 00:20:27.620
mówić więcej o i SBMP jest innych naszych
zastrzeżony protokół nad .NET.

00:20:29.320 --> 00:20:35.000
Teraz każdy z nich ma uwagi dotyczące wydajności
i zagadnienia.

00:20:35.710 --> 00:20:39.950
Dlatego jeśli korzystasz z urządzenia, na którym
jest bardzo niskie zasilanie, może być

00:20:40.000 --> 00:20:44.810
niepokoją który protokół
wdrożenie można umieścić

00:20:44.860 --> 00:20:49.590
na nie. Jeśli masz scenariuszy gdzie
chcesz być producentów niezależnych,

00:20:50.070 --> 00:20:54.160
może mieć zasięg zagadnienia
tutaj nie będę kupować w

00:20:54.210 --> 00:20:57.830
wszelkie konkretnego protokołu lub interfejsu API
u jednego dostawcy. Zamierzam

00:20:57.880 --> 00:21:00.060
Użyj otwarty standard jak AMQP.

00:21:01.900 --> 00:21:04.390
Czasami funkcje zależne od protokołu.

00:21:05.130 --> 00:21:08.000
A część, którą chcę podkreślić
pobiera który stracił na wiele

00:21:08.050 --> 00:21:11.300
ludzie jest głównie jest
otrzymują funkcji po stronie.

00:21:11.950 --> 00:21:13.290
Istnieją pewne strony wysyłania

00:21:14.560 --> 00:21:19.100
konsekwencje, zbyt, większość
czas jest włączone odbieranie gdzie

00:21:19.150 --> 00:21:23.270
protokoły naprawdę są odroczone
Partia i zobaczymy, dlaczego tak jest

00:21:23.320 --> 00:21:24.240
sprawa.

00:21:25.950 --> 00:21:28.810
Ogólnie rzecz biorąc istnieją także niektóre
przydział różnic warunków

00:21:28.860 --> 00:21:32.360
jak wiele połączeń można
Utwórz z AMQP i SBMP.

00:21:32.410 --> 00:21:35.550
To są również ważne zagadnienia związane z
Kiedy myśli, Hej,

00:21:35.600 --> 00:21:38.980
który protokół czy zamierzam użyć
dla mojego dużą skalę dużą liczbą

00:21:39.030 --> 00:21:50.090
nadawców? Protokoły tak binarne
w stosunku do protokołu HTTP, dlaczego jest tak ważne

00:21:50.140 --> 00:21:53.280
do obsługi wiadomości? Jakie są kluczowe
zagadnienia dotyczące obsługi wiadomości?

00:21:53.810 --> 00:21:56.350
Chciałem wyróżnić klucz
gdzie to sprawia, że scenariusze

00:21:56.400 --> 00:21:59.380
Różnica tak, możesz wybrać
i zdecydować, czy ma ona znaczenie

00:21:59.430 --> 00:22:02.780
lub nie na konkretnym przypadku.

00:22:04.210 --> 00:22:08.070
Przypadku HTTP, każdym wprowadzeniu
wywołanie się, masz zamiar być

00:22:08.120 --> 00:22:11.480
dostęp do jednego podmiotu. Tak, że 's
jeden punkt końcowy czy

00:22:11.530 --> 00:22:13.850
punkt końcowy Wyślij lub punkt końcowy Odbierz.

00:22:14.850 --> 00:22:16.820
Można wykonać jedną operację oczekującą.

00:22:17.560 --> 00:22:21.540
Tylko pojedynczy wysłać wywołanie lub
Wywołanie pojedynczego Odbierz.

00:22:22.370 --> 00:22:26.300
I w większości przypadków, operacja
okres istnienia nie może być więcej niż

00:22:26.350 --> 00:22:30.940
60 sekund lub niezależnie od obciążenia
Usługa równoważenia pozwala na cokolwiek

00:22:31.480 --> 00:22:33.060
Dostawca, które są uruchomione na.

00:22:34.490 --> 00:22:41.480
Tak że wprowadzą w rodzaju
sprawa scenariuszy, gdzie chcesz

00:22:41.530 --> 00:22:43.390
rozmawiać z wielu punktów końcowych.

00:22:44.040 --> 00:22:47.590
Wiele razy w kupić kierunkowe
jesteś scenariusze komunikacji

00:22:47.640 --> 00:22:51.230
będzie można wysłać do kolejki i
odbiera z subskrypcji.

00:22:52.080 --> 00:22:55.730
Lub wysłać powiadomienie przejdź
koncentrator. Wszystkie tego rodzaju z

00:22:55.780 --> 00:22:57.060
scenariusze mogą tam być.

00:22:57.640 --> 00:23:01.320
Za pomocą protokołu binarnego zostanie faktycznie
można utworzyć jedno połączenie,

00:23:01.370 --> 00:23:08.270
raz, jednym gniazdem
i wszystkie łącza w

00:23:08.320 --> 00:23:13.320
Kontekst AMQP to łącza multiflexed
przez jedno połączenie HTTP.

00:23:14.500 --> 00:23:18.740
Dzięki temu uzyskać wiele korzyści przez
nie mających do czynienia uścisk dłoni

00:23:18.790 --> 00:23:22.680
i nie ma potrzeby ustanowienia tego gniazda
i rzeczy na każdy pojedynczy

00:23:22.730 --> 00:23:26.880
jednostki porównaniu robi... płacenia, który
Koszt raz, a następnie wielokrotne używanie

00:23:26.930 --> 00:23:29.460
że kiedy mówisz
Aby kilka podmiotów.

00:23:30.290 --> 00:23:33.900
Pamiętać tego scenariusza. Czasami
Podczas wpisywania polu bram

00:23:33.950 --> 00:23:37.240
lub niestandardowych bram, gdzie jesteś
fronting wiele urządzeń, to

00:23:37.290 --> 00:23:40.690
będzie bardzo ważnym zagadnieniem.

00:23:43.280 --> 00:23:48.250
Drugiej strony jest długa, ciągnięcie.
Tak jest to coś stała

00:23:48.300 --> 00:23:51.400
o ciągnięcie w kolejkach, prawo,
z Hej, czy wiadomość?

00:23:51.450 --> 00:23:55.160
Czy wiadomość? Czy
wiadomość? Tutaj, ponieważ jest on

00:23:55.210 --> 00:24:01.040
połączenia protokołu AMQP
Możemy utrzymania połączenia.

00:24:01.090 --> 00:24:04.370
Nie trzeba robić żadnych operacji
inne niż mają oczekujące

00:24:04.420 --> 00:24:09.120
otrzymywać, mogą być ustawione dla
limit czasu nieskończoności. Było to możliwe

00:24:09.170 --> 00:24:12.110
Rozlicz go na dzień tygodnia. Ogólnie
nie będzie rozliczać

00:24:12.160 --> 00:24:16.090
do nieskończoności. Ustawi niezależnie od
swoje cechy zamknięcia systemu

00:24:16.140 --> 00:24:19.560
wyglądać, być może 20 minut lub
coś w tym stylu. Ale Ty

00:24:19.610 --> 00:24:24.920
może mieć długie replikacji ściąganej, do czasu przyjęcia
i nie musisz się martwić o

00:24:24.970 --> 00:24:27.640
ubijania cykle Procesora i rzeczy

00:24:29.370 --> 00:24:33.080
pobieranie o tym. Będziemy na bieżąco
przy życiu przez połączenie

00:24:33.130 --> 00:24:37.040
pakiety ping lub cokolwiek równoważenia obciążenia
jest potrzebny i firma Microsoft udostępni

00:24:37.090 --> 00:24:41.640
Możesz krótkie czasy reakcji
gdy wiadomość pojawia się.

00:24:42.360 --> 00:24:45.820
Tak więc to staje się bardzo ważnym
uwagę w kategoriach

00:24:45.870 --> 00:24:50.380
Koszt, jak również wpływ na
urządzenia. Protokoły tak binarne

00:24:50.430 --> 00:24:53.310
dokonać zmian w warunkach
scenariuszy.

00:24:56.240 --> 00:24:59.820
Inne wynagrodzenie, które protokoły
przynosi są w zestawy SDK.

00:24:59.870 --> 00:25:03.520
Chcesz uzyskać produkcyjnych. Chcesz
Aby użyć stałych core. Chcesz

00:25:03.570 --> 00:25:08.220
Aby użyć stałych bibliotek. Tak więc możesz naprawdę
Aby mieć możliwość wyboru

00:25:08.270 --> 00:25:11.010
prawo protokołu
prawo SDK.

00:25:12.880 --> 00:25:13.950
Tak dla magistrali usługi

00:25:15.670 --> 00:25:19.750
Jeśli używasz .NET, a następnie domyślnego
SBMP protokół jest ustawieniem domyślnym.

00:25:19.800 --> 00:25:24.130
To, co jest używany. Można przełączyć
Aby AMQP w dowolnym momencie i

00:25:24.180 --> 00:25:25.170
znajdującymi się.

00:25:25.850 --> 00:25:28.980
Istnieją pewne rekomendowane obrony
w tej chwili, ale jesteś zamknięcia

00:25:29.030 --> 00:25:33.730
tej luki wkrótce. Ale jeśli jesteś
za pomocą .NET, następnie SBMP jest

00:25:33.780 --> 00:25:36.010
rodzaju danego domyślne scenariusza dzisiaj.

00:25:37.560 --> 00:25:42.400
Jeśli używasz protokołu HTTP, jeśli 's
przypadku mamy otoki HTTP na wiele

00:25:42.450 --> 00:25:46.160
dostępnych systemów operacyjnych i
wiele dostępnych bibliotek.

00:25:47.010 --> 00:25:50.510
A następnie z AMQP są rozpoczęcie
Aby wyświetlić wiele Wspólnoty

00:25:50.560 --> 00:25:51.700
pochodzić bibliotek.

00:25:52.940 --> 00:25:59.670
AMQP jest otwartym standardem był
zaprojektowany i stworzony wszystko z

00:26:00.690 --> 00:26:05.690
mając na uwadze energooszczędnych, niezawodnych,
są przenośne sortowania danych

00:26:05.740 --> 00:26:10.310
Reprezentacja i elastyczność
w uwadze. Elastyczność w kategoriach

00:26:10.360 --> 00:26:13.470
czy jest klienta
biblioteki lub klientowi broker

00:26:13.520 --> 00:26:15.120
lub złamał złamał bibliotek.

00:26:16.680 --> 00:26:20.260
Tak więc zaczynasz Zobacz z AMQP
przesuwając normalizacji...

00:26:20.310 --> 00:26:26.370
przy okazji AMQP był OASIS standardowe ostatnio
W październiku. Po prostu usunięte ISO/IEC.

00:26:27.560 --> 00:26:32.950
Jest więc teraz uznane międzynarodowe
Standard, zbyt. Tak, że 's

00:26:33.210 --> 00:26:35.180
świeże z prasy.

00:26:36.990 --> 00:26:41.560
Ale co to znaczy Ci jest, że użytkownik
będzie zobaczyć kilka bibliotek

00:26:42.230 --> 00:26:47.750
opracowany przez bibliotekę Apache Qpid
zestaw lub biblioteki protonów

00:26:47.800 --> 00:26:51.010
Klienci w kilku językach.

00:26:51.890 --> 00:26:55.240
C, Java, istnieje wykonania JMS.

00:26:56.110 --> 00:27:00.670
PHP. Wszystkie te będą dostępne
do Ciebie społeczności

00:27:00.720 --> 00:27:05.970
Biblioteka Otwórz źródło obsługę za pomocą
i rozwój i przyczyniając się

00:27:06.020 --> 00:27:06.740
Aby i

00:27:07.970 --> 00:27:12.310
z usługą plus lub w każdym innym
Dostawca, który obsługuje

00:27:12.360 --> 00:27:14.070
Portal AMQP tam.

00:27:14.820 --> 00:27:18.400
Więc Jeśli starasz się dostępu do usługi magistrali
można zobaczyć różne protokoły.

00:27:18.450 --> 00:27:22.940
Masz wiele możliwości wyboru co
Używane zestawy SDK i jakie bibliotek

00:27:22.990 --> 00:27:34.850
Możesz używać i nie muszą być
ograniczone w jakikolwiek sposób.

00:27:34.900 --> 00:27:36.150
Synchronizacja, komunikacji asynchronicznej, w stosunku do partii.

00:27:37.150 --> 00:27:40.650
Teraz, że rozumiemy, jakie są więc
drobne protokołu myślę

00:27:40.700 --> 00:27:45.840
powinniśmy mówić o tym, kiedy należy
piszemy kod synchronizacji, asynchroniczne

00:27:45.890 --> 00:27:49.170
Kod, a kod partii i jakie są
rzeczywiste różnice w warunkach

00:27:49.220 --> 00:27:54.100
dla wydajności, który można zobaczyć
w tych różnych scenariuszy.

00:27:55.890 --> 00:27:58.710
Tworzenie pakietów wsadowych wyraźnie zwiększa przepustowość.

00:27:59.460 --> 00:28:04.620
Zawsze jest to bardzo dobra praktyka
pod względem tego, czy ma

00:28:04.670 --> 00:28:09.260
na stronie Odbierz lub nawet na
Strona Wysyłanie umożliwia tworzenie pakietów wsadowych.

00:28:09.310 --> 00:28:13.190
Dotyczą tylko ujemne dla ludzi
Czasami z tym jest czas oczekiwania

00:28:13.240 --> 00:28:17.490
i zobaczymy, jak to może być
wpływ, ale nie za dużo.

00:28:17.540 --> 00:28:18.880
Będziemy rozmawiać o tym.

00:28:21.250 --> 00:28:24.830
Asynchroniczne w ogóle jest zawsze
najlepsze praktyki. Zawsze ma

00:28:24.880 --> 00:28:28.620
Aby użyć to tylko możliwe. Z wyjątkiem
Czy chcesz powiązane

00:28:28.670 --> 00:28:31.760
Liczba wywołań od strony. Użytkownik
po prostu nie chcą mieć mocno

00:28:31.810 --> 00:28:34.720
Pętla nieskończona liczba sprawia, że
wywołań i zobaczymy, jak

00:28:34.770 --> 00:28:37.660
Usługa magistrali pomaga z tego scenariusza.

00:28:40.160 --> 00:28:44.110
A następnie końcu zobaczyć plik binarny
protokoły znacznie wyższe

00:28:44.160 --> 00:28:47.980
przepustowość jest w stanie osiągnąć
tylko dlatego, że te protokoły

00:28:48.030 --> 00:28:54.290
został opracowany protokół AMQP
z konstruowane z

00:28:55.260 --> 00:28:58.750
Sterowanie przepływem i to wszystko
wbudowane w warstwie protokołu

00:28:58.800 --> 00:29:03.950
sam Zobacz wiele korzyści
wyświetlane. Więc Pozwól mi faktycznie

00:29:04.000 --> 00:29:08.550
Pokaż niektórych liczb. Niektóre uruchomiony
numery można więc porównać

00:29:08.600 --> 00:29:10.090
te dla siebie.

00:29:20.030 --> 00:29:24.820
Czy mam jakiś kod, który jest tu
będzie próbować wysyłać wiadomości.

00:29:26.190 --> 00:29:28.970
I widać, że mam już podzielona
w górę na trzy części.

00:29:29.850 --> 00:29:32.930
Pierwszy z nich robi Wyślij synchronizacji.

00:29:33.690 --> 00:29:38.660
Oto wierszy kluczy. Dla każdego
wiadomości, czy qClient i Wyślij

00:29:38.710 --> 00:29:44.060
Wyłączanie komunikatu. Jest to bardzo synchronizacji
wywołanie. Odważniki z nich ma wykonać.

00:29:44.110 --> 00:29:48.030
Oczekuje na potwierdzenie do kontaktu
z serwera osiągnąć

00:29:48.080 --> 00:29:51.200
Wstecz od klienta, pełne
Pętla, a potem przenosi.

00:29:52.910 --> 00:29:56.650
Drugi to
w sposób komunikacji asynchronicznej.

00:29:57.900 --> 00:30:02.780
Gdzie zasadniczo jest tworzenie
Zadania asynchronicznego dla wszystkich tych

00:30:03.350 --> 00:30:04.470
Wyślij operacji.

00:30:05.700 --> 00:30:09.150
A następnie czekają na wszystkie
zadania do wykonania.

00:30:11.410 --> 00:30:15.170
I wreszcie, to wsadowej
Wyślij i nazwać zamówione

00:30:15.220 --> 00:30:19.430
Wyślij partii, ponieważ z komunikacji asynchronicznej, ogólnie
ludzie pochodzić z

00:30:19.480 --> 00:30:22.840
Scenariusz, w którym mówią, Hej, z
Asynchroniczne, utracona zamówienia. I nie

00:30:22.890 --> 00:30:25.800
wiedzieć, który z nich nastąpi wcześniej,
który z nich będzie dalej.

00:30:26.300 --> 00:30:29.430
I dlatego ma wysłać partii
który jest obecny lepszy

00:30:29.480 --> 00:30:32.300
w obu przypadkach ponieważ zachowuje
wszystkie... albo cały

00:30:32.350 --> 00:30:35.920
partia jest przez lub całości
Partia wraca i będziesz

00:30:35.970 --> 00:30:38.910
Zobacz ile po wydajności
może to mieć wpływ.

00:30:40.310 --> 00:30:45.300
Tak więc wszystkie te wskazując polecenie mam
proste na próbki wiad.

00:30:45.350 --> 00:30:47.900
Można zobaczyć już teraz
Liczba kolejek jest równa zero.

00:30:48.910 --> 00:30:52.560
I ustawiam mój numer wiadomości
na niewielką liczbę 100.

00:30:53.660 --> 00:30:54.780
Warto więc go uruchamiać.

00:30:57.310 --> 00:30:59.530
I zobaczyć, jak daleko możemy uzyskać.

00:31:00.250 --> 00:31:04.670
A więc najpierw robi, Wyślij używając
Synchronizacja. Dokonywanie tak synchronicznie

00:31:04.720 --> 00:31:09.020
100 połączeń z laptopa wszystkie
sposób do usługi i z powrotem.

00:31:09.550 --> 00:31:13.970
Miała około dziesięciu sekund w kategoriach
tego. I po prostu pokazać,

00:31:14.020 --> 00:31:18.360
Możemy zawsze wrócić, sprawdzanie
Liczba wiadomości, a powinien

00:31:18.410 --> 00:31:21.860
teraz wynosić 100. Wszystkie STU
wiadomości sprawiły, że w tym miejscu.

00:31:23.160 --> 00:31:26.940
Teraz zobaczmy, co się dzieje, gdy
Zrobić to samo z komunikacji asynchronicznej.

00:31:29.190 --> 00:31:30.590
To samo z komunikacji asynchronicznej.

00:31:31.940 --> 00:31:36.120
I nie ma różnicy w kategoriach
wiadomości bo

00:31:37.540 --> 00:31:40.460
wiadomości wszystkich sprawiły, że
w tym miejscu. Obecnie jest 200 wiadomości.

00:31:41.250 --> 00:31:46.450
Zajęło 3 sekund. Dla wszystkich tych
komunikaty się tam dostać.

00:31:50.260 --> 00:31:52.620
Z partii to jeszcze szybciej.

00:31:53.370 --> 00:31:54.990
To faktycznie jeszcze szybciej.

00:31:56.080 --> 00:31:58.880
I dlatego jest ponownie, ponieważ
pod osłoną, Service Bus

00:31:58.930 --> 00:32:04.440
jest za pomocą protokołu binarnego tak podczas
Możesz nam asynchronicznie, wiadomości

00:32:04.490 --> 00:32:09.600
Jesteśmy tabeli, aby je ze sobą bryłkach i
wysyła je przez z niejawna dozowania.

00:32:10.260 --> 00:32:13.630
Możesz ustawić tej wartości. Z
interwał opróżniania partii, co Ty

00:32:13.680 --> 00:32:17.710
Ustaw na factory komunikacji, pozwala
można ustawić tego okna.

00:32:18.310 --> 00:32:21.010
Można ustawić do szerszego okna.
Zobaczysz więcej opóźnienie,

00:32:21.060 --> 00:32:23.690
ale zobaczysz dużo lepiej
Przepływność end-to-end. Możesz

00:32:23.740 --> 00:32:27.310
Ustaw ją na znacznie mniejszym oknie
a zobaczysz lepszy czas oczekiwania

00:32:27.360 --> 00:32:32.110
i może trochę mniej przepustowości.
Ale można zobaczyć

00:32:32.160 --> 00:32:36.660
wielkości różnica w tym miejscu to
sprawia, że jeśli chodzi o wykorzystywanie synchronizacji

00:32:36.710 --> 00:32:38.410
w porównaniu do komunikacji asynchronicznej porównaniu partii.

00:32:45.080 --> 00:32:49.310
Warto więc szybko zobaczyć, teraz że
w tym miejscu mamy naszych 300 wiadomości

00:32:49.360 --> 00:32:51.110
co możemy zrobić po stronie odbioru

00:33:02.730 --> 00:33:06.700
W otrzymywać, w tym miejscu należy zauważyć, że nie jestem
za pomocą wiadomości na interfejsów API.

00:33:08.710 --> 00:33:12.460
To jest tylko, aby pokazać, jabłek
Porównanie jabłek co

00:33:12.510 --> 00:33:15.560
Synchronizacja wygląda jakby interfejsów API
a następnie pokaże Ci jak

00:33:15.610 --> 00:33:18.370
na wiadomość API nie wszystkie
to dla Ciebie.

00:33:20.100 --> 00:33:23.620
Jest to synchronizacji odbierania.

00:33:24.300 --> 00:33:28.740
Co mam wyraźnie dwa wywołuje samopoczucia
z serwerem tej tak

00:33:28.790 --> 00:33:33.600
jest w kategoriach przetwarzania wiadomości.
Nigdy nie stracisz

00:33:33.650 --> 00:33:38.280
wiadomość umieszczonego w sieci lub w tranzycie
ponieważ aż nie wywołuj

00:33:38.330 --> 00:33:41.950
wykonać na nim, wyślemy
kopii tej samej wiadomości.

00:33:43.810 --> 00:33:48.260
Następny jest asynchroniczne i tutaj możesz
można zobaczyć, co robię

00:33:49.430 --> 00:33:56.230
jest to zadanie z Kontynuuj z do
następnie przeprowadzono rozmowę na nie.

00:34:01.730 --> 00:34:05.290
I ponownie będzie czekać dla wszystkich tych
rzeźba zadań do wykonania

00:34:05.340 --> 00:34:07.770
przed wywołaniem Mój stoper Sporządzono.

00:34:09.300 --> 00:34:10.660
I wreszcie istnieje partii.

00:34:11.330 --> 00:34:12.950
Przetwarzanie wsadowe jest nieco bardziej interesujące.

00:34:13.890 --> 00:34:19.030
W tym miejscu jest jeszcze łatwiejsze Bo ja
Przyjęcie partii, należy zwrócić uwagę przepustki

00:34:19.080 --> 00:34:21.370
Liczba wiadomości
to, co jest 100.

00:34:22.040 --> 00:34:24.860
Teraz po wywołaniu odbierać partii
ze STU nie możemy oznacza

00:34:24.910 --> 00:34:28.830
otrzymasz komunikaty STU
z powrotem. To zrobimy cokolwiek

00:34:28.880 --> 00:34:32.660
jest najbardziej optymalny dla drutu oparte
konkurować z bycia konsumenta,

00:34:32.710 --> 00:34:35.970
oparte na liczbę innych węzłów
mieć ciągnięcie komunikat, aby wyświetlić

00:34:36.020 --> 00:34:38.800
Budowanie optymalnego partii
i Wyślij, który.

00:34:39.610 --> 00:34:43.320
I dlatego Zobacz mam
zewnętrzna pętla, która śledzi wywołania

00:34:43.370 --> 00:34:47.620
otrzymywać partii, dopóki nie było dotrzeć do
Moje kilkaset wiadomości. Chcę

00:34:47.670 --> 00:34:51.430
Aby zrobić to łączenia we wsady obliczeń do czasu
Dojde sto wiadomości.

00:34:53.920 --> 00:34:59.030
I w tym przypadku, zamierzam
tylko trzymać się jego zablokowanych token.

00:34:59.080 --> 00:35:01.160
To wszystko, co robię w komunikacie.
Nie mam zachować

00:35:01.210 --> 00:35:04.440
cała wiadomość. Mam już zużyty
wiadomości, I zostały przetworzone

00:35:04.490 --> 00:35:07.710
to, jest tylko należy utrzymać
token blokady a potem Zadzwoń

00:35:07.760 --> 00:35:12.940
pełną partia Async ze wszystkimi
zablokowane tokeny tam.

00:35:14.060 --> 00:35:16.940
I robię to na zasadzie partii
tak więc nie czekam

00:35:16.990 --> 00:35:19.490
aż do końca do
zakończyć wszystkie wiadomości?

00:35:19.500 --> 00:35:21.500
[Indiscernible]


00:35:21.660 --> 00:35:22.750
.. .subset tam?


00:35:23.510 --> 00:35:24.840
>> Niestety jakie było pytanie?


00:35:24.890 --> 00:35:28.400
>> Jeżeli może przetworzyć niektórych osób
wiadomości, można ukończyć

00:35:28.450 --> 00:35:30.520
tego badania, prowadzenia podzbiór?

00:35:30.860 --> 00:35:34.510
>> Absolutnie. Absolutnie.
Partia tak kompletne komunikacji asynchronicznej.

00:35:35.250 --> 00:35:39.040
Można połączyć z jednym tokeny zablokowane
dwa zablokowanych tokeny, niezależnie od

00:35:39.090 --> 00:35:42.720
zestaw jest. To jest tak, że będzie
Wyślij te tokeny zablokowane

00:35:42.770 --> 00:35:46.250
w partii i można odzyskać
wyniki w partii. Tak ma

00:35:46.300 --> 00:35:50.010
oszczędzając tym czas oczekiwania i że
dla wszystkich, że robi w obie strony

00:35:50.060 --> 00:35:52.540
i dokonywania bardzo wydajny.

00:35:54.300 --> 00:35:56.070
Warto więc zobaczyć, co dodaje do.

00:35:58.400 --> 00:36:03.230
Mam więc o tej samej sprawie. Jestem
najpierw będzie korzystać synchronizacji i

00:36:03.280 --> 00:36:07.440
próbę odebrania wszystkich sto...
pierwsze sto wiadomości

00:36:07.490 --> 00:36:11.190
tam. Teraz notatki, która będzie gorzej
wydajność niż wysłać, ponieważ

00:36:11.240 --> 00:36:14.080
robi dwa razy liczba operacji
tak, chcę otrzymać

00:36:14.130 --> 00:36:16.460
Każda wiadomość wykonania każdej wiadomości.
Każdy komunikat,

00:36:16.510 --> 00:36:20.110
zakończenie każdej wiadomości. I
następnie przejdź na. Tak 18 sekund.

00:36:20.160 --> 00:36:24.220
Zamiast dziesięciu wysyła widzieliśmy
dla operacji wysyłania trwa 18 sekund

00:36:24.270 --> 00:36:28.760
do tych wiadomości i kompletne
ich. Tak na pewno nie dobrze.

00:36:30.090 --> 00:36:35.330
Z Async ponieważ robisz kilka
z nich równolegle teraz dostać się do

00:36:35.380 --> 00:36:38.880
około 2,8 sekundy. Teraz,
numery te są po prostu...

00:36:39.410 --> 00:36:43.230
Weź je z ziarna soli,
pracujący w sieci, w tym miejscu, są

00:36:43.940 --> 00:36:47.470
ale widać tylko wielkość
Różnica. Można zobaczyć

00:36:47.520 --> 00:36:49.620
ile poprawa robi.

00:36:50.830 --> 00:36:52.580
A teraz Zobaczmy, co
Dzieje się z partii.

00:36:55.730 --> 00:37:00.720
Jesteśmy z powrotem. Jesteśmy w stanie wykonać takie same
prawie cechy jako

00:37:00.770 --> 00:37:04.590
0,1 sekundy dla wszystkich STU
operacje, które miały...

00:37:05.410 --> 00:37:07.930
tylko dlatego, używamy
Partia tam.

00:37:11.380 --> 00:37:16.640
Nie tylko spowoduje wyświetlenie wszystkich tych
zalety w tym miejscu, ale usługi

00:37:16.690 --> 00:37:21.680
Magistrala faktycznie sprawia, że bardzo łatwo
do Ciebie napisać tego szczególnego kodu.

00:37:21.730 --> 00:37:26.700
Kod, który Państwu, nie jest bardzo
kompleks, ale faktycznie pobrane

00:37:26.750 --> 00:37:29.280
to krok dalej i my
się jeszcze łatwiejsze.

00:37:30.200 --> 00:37:33.470
Tak więc na... na drodze, po prostu
chciał pokazać tutaj na

00:37:33.520 --> 00:37:37.280
wiadomości Zobacz wiadomości te 300
tam, jeśli on odświeżania, to

00:37:37.330 --> 00:37:41.920
należy wrócić do wskazujące zerowe
Nie leżę. Te 300

00:37:41.970 --> 00:37:43.380
wiadomości zostały przetworzone.

00:37:47.270 --> 00:37:54.910
W porządku. Tak więc przyjrzymy na wiadomość
Interfejsy API, ale w interesie

00:37:54.960 --> 00:37:57.880
czas zamierzam prędkości
w górę trochę tutaj.

00:38:00.480 --> 00:38:04.820
Tak więc zobaczył różnicę między
Synchronizacja, asynchroniczne i partii, i

00:38:04.870 --> 00:38:10.330
Mam nadzieję, że [Indiscernible] zawsze użycia dozowania. Następną rzeczą o przepływności.

00:38:10.380 --> 00:38:14.100
Kolejki podzielonym na partycje i tematy.
Dlatego firma Microsoft opublikowała SDK 2.2.

00:38:15.680 --> 00:38:19.590
Zasadniczo partycji kolejek i tematy
Weź jednej kolejki i partycji

00:38:19.640 --> 00:38:21.830
to kilka węzłów przetwarzania.

00:38:23.240 --> 00:38:26.950
To nie tylko daje Ci dużo bardziej
wydajność pod względem:

00:38:27.000 --> 00:38:31.900
jest w stanie przetwarzać więcej wiadomości, ale
to daje większe możliwości magazynowania.

00:38:32.410 --> 00:38:35.820
Daje to możliwość posiadania
znacznie większe kolejki. To daje

00:38:35.870 --> 00:38:38.170
Możesz być bardziej elastyczne możliwości.

00:38:39.270 --> 00:38:42.290
Jeśli jedna partycja jest niedostępny,
można kontynuować innej partycji

00:38:42.340 --> 00:38:43.580
do przetwarzania wiadomości.

00:38:44.640 --> 00:38:49.270
Tak partycji kolejek, przy znacznie
dla większości scenariuszy da

00:38:49.320 --> 00:38:52.990
można znacznie większa przepustowość
dostępność i odporność

00:38:53.040 --> 00:38:58.570
Zobacz cecha. Z pola.
Jest tak łatwo tworzyć i

00:38:58.620 --> 00:39:02.700
Użyj kolejki partycji, które jest
tylko zalecenia w odniesieniu do

00:39:02.750 --> 00:39:06.470
Zawsze używaj tych. Po prostu zawsze używać
te. W rzeczywistości w ciągu następnych

00:39:06.520 --> 00:39:11.000
Wydania SDK, jesteśmy na torze, aby
to domyślne który domyślnie

00:39:11.050 --> 00:39:13.380
Podczas tworzenia kolejki będziesz
Pobierz kolejkę podzielonym na partycje.

00:39:15.690 --> 00:39:20.650
Teraz musisz być świadomy
co się dzieje, gdy robisz

00:39:20.700 --> 00:39:22.590
kolejki i partycji to całej.

00:39:24.060 --> 00:39:26.530
Jeśli nie używasz sesje, będziemy
dużo mówić o sesjach

00:39:26.580 --> 00:39:30.340
szczegółowo, ale jeśli nie używasz
sesje a następnie zasadniczo,

00:39:31.060 --> 00:39:33.050
Musisz być...

00:39:34.220 --> 00:39:38.380
trzeba pamiętać, że Twoje wiadomości
może pokazać się poza kolejnością

00:39:38.430 --> 00:39:41.830
teraz bo zasadniczo mogą
przejść do różnych partycji

00:39:41.880 --> 00:39:46.770
a jeśli partycja jest niedostępny,
następnie wyświetli komunikat

00:39:46.820 --> 00:39:47.720
poza kolejnością.

00:39:48.460 --> 00:39:51.270
To jedno zdawać sobie sprawę z
ale jeśli używasz sesji,

00:39:51.320 --> 00:39:54.720
której będziemy mówić teraz, a następnie
wszystkie semantykę zamawiania

00:39:54.770 --> 00:39:56.100
całkowicie są zachowywane.

00:39:57.120 --> 00:40:02.330
I zobaczymy, jak. Tak, aby pokazać
Kod tutaj, wrócisz

00:40:02.380 --> 00:40:05.590
Tworzenie kolejki jest jeden pojedynczy
Właściwość EnablePartitioning.

00:40:05.640 --> 00:40:08.720
Dziś jest wartość false domyślnie.
Jak powiedział w ciągu następnych

00:40:08.770 --> 00:40:10.040
Zestaw SDK to będzie prawdziwe.

00:40:10.780 --> 00:40:13.750
Tak więc należy tylko ustawić który. Przez
sposób nie wiem, jak możesz

00:40:13.800 --> 00:40:18.770
ludzie zwykle zrobić, ale Moja filozofia
na ogół nigdy nie jest kopia

00:40:18.820 --> 00:40:20.730
Kod, który można wyświetlić w programie PowerPoint.

00:40:21.330 --> 00:40:24.470
Nie wiem, czy działa dla
WAS. Nigdy nie skopiować

00:40:24.520 --> 00:40:28.150
Kod, który widzisz w programie PowerPoint, ponieważ
jest najbardziej uproszczony

00:40:28.590 --> 00:40:32.710
i które ktoś kod rodzaju basic
można umieścić tam. W tym

00:40:32.760 --> 00:40:35.500
sprawa jest w porządku. Po prostu ustawiasz
Właściwość, są więc to świetnie.

00:40:35.550 --> 00:40:38.540
Ale jeśli I kiedykolwiek wykazano, że kod
w programie PowerPoint nie należy kopiować.

00:40:40.650 --> 00:40:46.660
Tak przepustowość połączenia. Mówiliśmy
o nadawców. Widzieliśmy

00:40:46.710 --> 00:40:50.290
jak binarnych połączenia są naprawdę,
bardzo ważne. Istnieją

00:40:50.340 --> 00:40:55.090
niektóre przypadki, gdzie użytkownik może wysyłać również
przy użyciu tłuszczu bardzo potoku.

00:40:55.660 --> 00:40:58.340
Go traktować jako back-end więc jesteśmy
stara się w kolejce wiadomości.

00:40:58.390 --> 00:41:03.370
Masz mnóstwo dzienniki, które mają
push up i takie rzeczy.

00:41:04.400 --> 00:41:08.450
Również w pewnym momencie tworząc więcej
może fizycznego połączenia protokołu TCP

00:41:08.500 --> 00:41:12.630
rzeczywiście być dobrze i można
to łatwo zrobić. Każdej wiadomości

00:41:12.680 --> 00:41:16.220
w fabryce wystąpienie klasy
wystąpienie programu factory komunikacji

00:41:16.270 --> 00:41:18.390
odnosi się do jednego połączenia PCP.

00:41:19.390 --> 00:41:22.550
Im więcej liczby klientów kolejki
i rzeczy, które tworzysz

00:41:22.600 --> 00:41:25.680
wyłączanie tej samej fabryki, jak I pokazał
Użytkownik, w przypadku wszystkich Multipleksowanie

00:41:25.730 --> 00:41:31.430
połączenia przez samego gniazda TCP.
Więc utworzyć fabrykach więcej wiadomości.

00:41:31.480 --> 00:41:33.700
A jeśli tworzysz więcej wiadomości
fabryk, możesz po prostu lepiej więcej

00:41:33.750 --> 00:41:38.720
rury i więcej danych może zostać przesunięta.
za pomocą tak kluczowa

00:41:38.770 --> 00:41:42.540
do tego celu. Poziom odporności połączenia
jest wbudowany. Można więc jeden raz

00:41:42.590 --> 00:41:46.140
Tworzenie wiadomości fabryki, użytkownik
nigdy nie musiał odrzucić je.

00:41:46.190 --> 00:41:49.320
Jeśli zerwania połączenia, będziemy
Odbuduj go. Jeśli Twoje połączenie zostanie zerwane

00:41:49.370 --> 00:41:52.740
do kolejki będzie to odbudować. Cokolwiek
jest to będzie odbudować

00:41:52.790 --> 00:41:54.860
z takim tak nigdy nie
trzeba to zrobić...

00:41:55.370 --> 00:41:58.030
trzeba wyrzucić tego obiektu
i ponowne utworzenie tego obiektu.

00:41:58.310 --> 00:42:02.780
Tylko jedna z nich utworzyć i ponowne wykorzystanie
ich tyle ile się konieczne.

00:42:05.910 --> 00:42:07.540
Tak, że prowadzi NAS do sesji.

00:42:08.520 --> 00:42:11.670
Ponieważ mówię Ci do podjęcia
wszystkie te nadawców dużą liczbą

00:42:11.720 --> 00:42:14.910
nadawców i Multipleksowanie je wszystkie
na bardzo małą liczbę

00:42:14.960 --> 00:42:17.850
kolejek jak idziesz
Aby właściwie tego procesu?

00:42:17.900 --> 00:42:21.110
Widzieliśmy Orleanu rodzaju framework
i rzeczy, które są wszystkie

00:42:21.160 --> 00:42:23.460
próby demultiplex strumienia,

00:42:24.720 --> 00:42:26.530
demultiplex strumienia.

00:42:28.490 --> 00:42:33.070
Sesje to niesamowite wbudowane
Funkcja w usłudze magistrali, który

00:42:33.120 --> 00:42:37.130
zasadniczo tworzy podkolejek.
Tak więc każdej sesji można traktować

00:42:37.180 --> 00:42:40.290
z jako podkolejki przy pełnej kolejki.

00:42:41.480 --> 00:42:44.860
I oryginalny charakter tylko
ma ustawić identyfikator sesji.

00:42:44.910 --> 00:42:46.840
To jest jednej właściwości pojedynczego
mają ustawiony.

00:42:48.090 --> 00:42:51.240
To jest odbiornik gdzie
paradygmat naprawdę zmienia.

00:42:52.050 --> 00:42:56.090
Odbiornik teraz już idzie i
mówi Hej, podanie następnej wiadomości.

00:42:56.140 --> 00:42:59.670
Odbiornik mówi Poproszę następnego
sesja. Poproszę następnego

00:42:59.720 --> 00:43:02.690
podkolejki, który ma kilka wiadomości
a ja go przetworzyć je w

00:43:02.740 --> 00:43:06.760
kolejności, w jakiej będą go przetworzyć je z
Niektóre Państwa, które może przechowywać

00:43:06.810 --> 00:43:10.600
dla tego odbiorcy. Tak, jeśli myślisz
o milionów urządzeń,

00:43:10.650 --> 00:43:13.290
Teraz można uważasz, że w jednym
kolejki, możesz mieć wszystkie te

00:43:13.340 --> 00:43:18.620
milionów podkolejki i sklepu
stan na podkolejki. Tak bardzo,

00:43:18.670 --> 00:43:20.410
bardzo wydajne w tym sensie.

00:43:21.050 --> 00:43:24.400
Można zrobić pracy ustaw ustawić przypinanie pracy.
Co oznacza, że można powiedzieć

00:43:24.450 --> 00:43:29.230
odbiornik jedną, chcę, aby przetłumaczyć
urządzenia od 1 do 100. Tak to

00:43:29.280 --> 00:43:32.810
pójdzie i poprosić o sesjach 1
przez 100 i zostanie przypięty

00:43:32.860 --> 00:43:33.440
do tego celu.

00:43:35.000 --> 00:43:39.680
A wtedy oczywiście można przechowywać
Stan. Więc pokaże Ci

00:43:39.730 --> 00:43:43.490
Kod tego. Służyć głównie do
na true, kiedy sesji syste

00:43:43.540 --> 00:43:45.270
tworzenia kolejki.

00:43:45.790 --> 00:43:49.670
Na tej stronie Wyślij po prostu trzeba
ustawić jedną właściwość identyfikator sesji.

00:43:50.530 --> 00:43:55.720
A następnie otrzymać z boku, wszystkie
zastosowanie samego rodzaju parametrów

00:43:55.770 --> 00:43:59.840
jak I pokazał, Zaakceptuj komunikatu
Sesja, można zaakceptować

00:43:59.890 --> 00:44:03.730
komunikat z Identyfikatorem sesji lub teraz
co firma Microsoft wydała

00:44:03.780 --> 00:44:08.760
jest to bardzo prosty sposób
można zrobić

00:44:11.810 --> 00:44:13.010
sesji odbiorników.

00:44:14.920 --> 00:44:18.080
Więc będzie otworzyć nadawcy sesji.

00:44:18.970 --> 00:44:21.810
Możemy sobie już sprawę, że tworzenie pakietów wsadowych
jest to najlepszy sposób wysyłania

00:44:21.860 --> 00:44:25.740
co robi to wszystkie nadawcy
dla każdej sesji ID to będzie

00:44:25.790 --> 00:44:30.240
Aby wysłać dowolną liczbę wiadomości jako
Identyfikator sesji plus jeden. Tak, jeśli ma ona

00:44:30.290 --> 00:44:33.480
Identyfikator sesji, mam zamiar wysłać
dwa komunikaty. Jeśli jest to sesja

00:44:33.530 --> 00:44:36.070
ID dwa, mam zamiar wysłać
trzy wiadomości i tak dalej.

00:44:37.350 --> 00:44:38.920
Tak więc po prostu zaczniemy nadawcy.

00:44:39.880 --> 00:44:43.910
I tutaj, jeśli spojrzeć na tej kolejki
na próbce kolejki wiadomości,

00:44:44.580 --> 00:44:49.140
Po utworzeniu tej kolejki
tylko jedną właściwość dodatkowych I ustawić

00:44:49.190 --> 00:44:55.090
było to, wymagają właściwości sesji.
To jedyna różnica.

00:44:55.670 --> 00:44:59.940
Teraz po przejściu do tej konkretnej
kolejki i zobaczyć, czy ma on

00:44:59.990 --> 00:45:02.440
właściwości, będziesz

00:45:08.230 --> 00:45:09.410
zobaczyć, że...

00:45:11.710 --> 00:45:16.480
wymaga jest właściwość sesji
wartość false. To nie jest dobry.

00:45:16.530 --> 00:45:20.780
W porządku. Pozwól mi następnie usunąć tę kolejkę.

00:45:24.670 --> 00:45:34.390
Utwórz na próbce sesji wiadomość.

00:45:37.280 --> 00:45:38.780
Wymagają sesji.

00:45:45.040 --> 00:45:47.020
Będzie czytać w moich nadawcy.

00:45:51.490 --> 00:45:53.840
Więc rozpocznie wysyłanie wiadomości.

00:46:09.430 --> 00:46:18.880
Myślę, że nie jest znalezienie który
Nazwa kolejki już teraz.

00:46:18.890 --> 00:46:20.800
[Indiscernible]

00:46:20.870 --> 00:46:27.580
>> Och nie mogę? Na sesji wiadomość...
Niestety można przejść.

00:46:29.640 --> 00:46:36.750
Doskonałe. Więc Pozwól mi zmienić
na próbce sesji wiadomość.

00:46:39.450 --> 00:46:40.630
Dziękuję.

00:46:42.100 --> 00:46:43.360
Teraz uruchom tego gościa.

00:46:46.770 --> 00:46:49.710
Można przejść. Wysyłanie wszystkich tych powiedział
wiadomości. Teraz Pozwól mi pokazać

00:46:49.760 --> 00:46:54.350
Możesz kod odbioru
wygląda na to.

00:46:55.510 --> 00:46:59.710
Jest to nowy interfejs API który
Firma Microsoft wydała, na

00:46:59.760 --> 00:47:02.010
Interfejs API przetwarzania wiadomości.

00:47:03.430 --> 00:47:07.500
Tak więc w swojej roli Pracownik Azure
Pozwól mi za to zmienić.

00:47:10.890 --> 00:47:14.690
W swojej roli Pracownik Azure na
na start metoda chcesz zrobić

00:47:14.740 --> 00:47:19.540
tym samym, wystarczy sprawdzić czy istnieje kolejka
i Utwórz qClient.

00:47:20.250 --> 00:47:24.120
W regule wykonywania, można zauważyć, sieci
kod pobiera jeszcze prostsze.

00:47:25.610 --> 00:47:29.270
Wszystko, co robisz to jest
wywołanie jeden rejestr.

00:47:29.900 --> 00:47:32.770
Aby powiedzieć zarejestrować obsługi sesji.

00:47:33.670 --> 00:47:36.500
I to wszystko. Nie podstępu
pętle pisać.

00:47:37.120 --> 00:47:38.950
Nie okresu istnienia do zarządzania.

00:47:39.580 --> 00:47:43.920
To wszystko jest pod opieką przez
Biblioteka klienta dla Ciebie.

00:47:43.970 --> 00:47:48.540
Po prostu trzeba hermetyzacji wszystkie
jak masz zamiar Twój logiki

00:47:48.590 --> 00:47:53.790
do przetwarzania pojedynczego strumienia w jednym
Klasa o nazwie Moja obsługi sesji.

00:47:54.700 --> 00:47:57.450
Przeanalizujmy tej klasy
i zobacz, co robię tutaj.

00:47:58.700 --> 00:48:02.660
Pierwszą rzeczą, to, co należy zrobić po
Faktycznie pojawia się komunikat?

00:48:05.430 --> 00:48:09.430
Dla wiadomości po prostu drukuję
Czy mam ten komunikat i

00:48:09.480 --> 00:48:10.870
Zwiωkszam Moje wizytówki.

00:48:11.610 --> 00:48:15.320
To wszystko, co robię w tej klasie.
Liczba jest członek prywatny

00:48:15.370 --> 00:48:19.860
w tym miejscu i mamy tylko zapisać tę wartość.

00:48:21.090 --> 00:48:22.960
Tak więc możemy Ustawianie liczby

00:48:24.710 --> 00:48:28.550
równa zero i możemy tylko przechowuje licznika
jest w taki sposób, aby wszystkie moje przetwarzania.

00:48:29.270 --> 00:48:34.550
Na posiedzeniach zamkniętych zamknięcia sesji
jest wywoływane, gdy istnieją nie

00:48:34.600 --> 00:48:38.750
więcej dostępnych dla tej wiadomości
Osiągnięto sesja lub użytkownik

00:48:38.800 --> 00:48:42.360
liczba maksymalna waluty. Rozmawialiśmy
o ile jednocześnie

00:48:42.410 --> 00:48:43.630
użytkownik chce posiadać.

00:48:44.260 --> 00:48:48.230
W takim przypadku osiągnęła swój maksymalny
ile licznik współbieżności

00:48:48.280 --> 00:48:53.040
sesje, aby przetwarzać, będziemy nazywać
Zamknięcie tej sesji i Otwórz

00:48:53.090 --> 00:48:57.610
Nowa sesja w zależności od tego, jakie wiadomości
są dostępne. Więc zamknięcie

00:48:57.660 --> 00:49:00.700
możliwość powiedzieć, że mam
zdobyć zestaw komunikatów, już

00:49:00.750 --> 00:49:03.900
przetworzenia ich na tym konkretnym
Sesja, a teraz należy

00:49:03.950 --> 00:49:05.580
Zapisz ten stan.

00:49:07.140 --> 00:49:10.730
I w tym miejscu można zobaczyć wszystko, co robię
dzwoni, Ustaw stan i get

00:49:10.780 --> 00:49:15.250
Państwo, które jest do sprzeciwu sesji.
Są zasadniczo strumieni.

00:49:16.050 --> 00:49:20.770
I przechowywanie od wartości opcji Liczba
gdy sesja jest zamknięta.

00:49:21.780 --> 00:49:26.130
A następnie ostateczne jest błąd
w przypadku gdy sesja zostanie przerwane.

00:49:27.420 --> 00:49:31.050
Teraz należy pamiętać, że powodem, dla którego jesteś w stanie
Aby skorelować te wiadomości

00:49:31.100 --> 00:49:34.310
ponieważ możemy zablokować sesji dla
użytkownik. Mamy pewność, że jesteś

00:49:34.360 --> 00:49:38.790
tylko odbiornika, który jest coraz
komunikaty dla tego podkolejki

00:49:38.840 --> 00:49:40.510
że subsession.

00:49:41.190 --> 00:49:43.780
I zawsze można stracić blokady.
Blokada zostałyby utracone, ponieważ

00:49:43.830 --> 00:49:47.660
awarii na serwerze. Było to możliwe
zostać utracone z powodu połączenia

00:49:47.710 --> 00:49:51.410
problemy lub może być używany procesor
po prostu zawieszony i stracił on blokady

00:49:51.460 --> 00:49:55.290
ponieważ następnie wykonaj operację
tam, dzięki czemu możesz zawsze uzyskać

00:49:55.340 --> 00:49:58.940
Ten błąd jest wywoływana. W tym przypadku,
wszystko będzie zrobić, to abandon

00:49:58.990 --> 00:50:03.500
Lokalne ustawianie zmian i Przenieś
na serwerze. Pod względem.

00:50:04.870 --> 00:50:07.150
Zobaczmy więc to wygląda.

00:50:07.670 --> 00:50:08.790
Rzeczywistej pracy.

00:50:10.210 --> 00:50:10.800
Było pytanie?

00:50:10.850 --> 00:50:11.930
>> Działa taki sam?


00:50:13.740 --> 00:50:17.500
>> Tak było pytanie: to będzie działać tak samo dla subskrypcji? Sto procent.

00:50:17.550 --> 00:50:21.170
To jest całkowicie symetryczny. Czy
otrzymujesz z kolejki

00:50:21.220 --> 00:50:24.130
lub otrzymujesz z subskrypcji.

00:50:25.440 --> 00:50:28.920
Oto moja rola Pracownik teraz. Niech
mi faktycznie szybko sprawdzić co

00:50:28.970 --> 00:50:30.850
Liczba kolejek wyglądał
jak po

00:50:32.060 --> 00:50:36.390
rola została wykonana wysyłającego. Wygląda jak
jest jeszcze prawo 3700 wiadomości

00:50:36.440 --> 00:50:40.610
teraz 33, wygląda jak przetwarzania
rozpoczęła się.

00:50:41.650 --> 00:50:56.690
Pozwól mi skoczyć tam...
rozszerzana. To zbliża się.

00:50:56.740 --> 00:51:03.350
Dobre. Tak więc teraz są na moim komputerze
przepracować i

00:51:03.400 --> 00:51:06.090
można zobaczyć przetwarzania tysięcy
i tysięcy wiadomości.

00:51:06.890 --> 00:51:10.740
I był kod, który napisał
bardzo uproszczony sposób myślenia

00:51:10.790 --> 00:51:15.170
o tylko proste sesji, pojedynczy
Sesja i nie mam

00:51:15.220 --> 00:51:18.800
Aby zapisać pętli odbioru pojedynczej. Po prostu
musiał zarejestrować obsługi potoku.

00:51:19.200 --> 00:51:23.370
Program obsługi, który I pokazał, to
uproszczone przypadek gdzie możesz

00:51:23.420 --> 00:51:28.420
może mieć to tworzone wystąpienia i
nie robisz żadnych inicjowania.

00:51:28.450 --> 00:51:32.020
Mamy fabryki kopii zapasowych który
jest też dostępny. Można zrobić

00:51:32.070 --> 00:51:36.960
Fabryka obsługi rejestru oraz że
sposób można kontrolować, tworzenie

00:51:37.010 --> 00:51:38.700
Semantyka tej również.

00:51:40.370 --> 00:51:43.560
Ale w tym miejscu można zobaczyć utrzymują się
Stan i zamkniętej sesji.

00:51:44.420 --> 00:51:48.340
Pozwól mi powiększyć, tutaj więc ludzie mogą
wyraźnie zobaczyć, co się stało z tutaj.

00:51:49.070 --> 00:51:54.740
Jeśli widzisz każdej sesji sesji
Państwo było 22 dla sesji 21.

00:51:54.790 --> 00:51:57.810
Stan sesji był 46
dla sesji 45.

00:51:58.620 --> 00:52:03.770
Ponieważ tej klasy, ale tylko wiadomości
które należały do tej sesji.

00:52:04.200 --> 00:52:08.320
Wszystko, co zostało multipleksacji odwrotnej ponad i muksowania
łatwe i wszystko obsłużono

00:52:08.370 --> 00:52:12.410
Usługi autobusowe dla Ciebie. Tak podczas
myślisz o Multipleksowanie

00:52:12.460 --> 00:52:15.990
duża liczba nadawców do
znać niewielką liczbę kolejek,

00:52:16.040 --> 00:52:19.260
nie Zgubiłeś prostota
jest w stanie przetworzyć

00:52:19.310 --> 00:52:23.800
je przy użyciu back-end
Te indywidualne strumieni

00:52:30.570 --> 00:52:34.260
tam.

00:52:37.740 --> 00:52:41.000
Stan sesji rozmawialiśmy.
Korelacji przy użyciu sesji.

00:52:41.350 --> 00:52:46.020
Więc tylko do podsumowywania faktycznie
Zanim będziemy podsumowywać dostęp.

00:52:46.590 --> 00:52:49.230
Dlatego kolejne zagadnienie klucza
Kiedy masz te bardzo

00:52:49.280 --> 00:52:52.530
duża liczba nadawców, co jest
auth model? Co to jest zabezpieczenie

00:52:52.580 --> 00:52:55.750
model, który masz zamiar użyć?
Więc mogę powiedzieć współdzielony dostęp

00:52:55.800 --> 00:52:58.420
Podpis jest zdecydowanie
Zaleca się model uwierzytelniania.

00:52:59.010 --> 00:53:02.150
Istnieje o wiele więcej szczegółów. W rzeczywistości
pokładu ma więcej szczegółów

00:53:02.200 --> 00:53:08.190
jak ustawić podpisy dostępu współdzielonego.
Można przejść do portalu

00:53:08.540 --> 00:53:10.040
i zarządzać swoimi kolejek.

00:53:10.910 --> 00:53:15.270
W tym miejscu mam IOT, który możesz w kolejce
zawieraniu umowy korzystasz z serwisu WWW.

00:53:16.050 --> 00:53:18.850
I może po prostu przejdź tutaj i skonfigurować.

00:53:19.420 --> 00:53:23.650
Należy zauważyć, że Oh...

00:53:23.660 --> 00:53:23.720
[Indiscernible]

00:53:23.700 --> 00:53:25.290
>> Tak mi Przykro. Przykro tak.

00:53:28.330 --> 00:53:33.790
Tak skacze do portalu Azure
a po wybraniu moich IOT kolejki.

00:53:34.890 --> 00:53:38.340
I w tym, kiedy przejdź do konfiguracji
Karta, zobaczysz mój udostępnionych

00:53:38.390 --> 00:53:42.420
dostęp w tym miejscu nazwy zasad. Tak więc w
Ten przykład witryny sieci Web co

00:53:42.470 --> 00:53:45.240
wykazało, jeśli I o nazwie odbioru,
są to to rzeczywiście

00:53:45.290 --> 00:53:49.650
nie działać, ponieważ już teraz tylko
zezwolenie na to jest wysłać.

00:53:50.890 --> 00:53:54.310
Ale można łatwo go i dodać słuchać
upoważnienie do tej zasady.

00:53:55.730 --> 00:53:56.440
Zapisz.

00:53:57.340 --> 00:53:58.640
Mówiąc aktualizacji kolejki.

00:53:59.190 --> 00:54:00.050
A teraz dowolny

00:54:01.700 --> 00:54:06.780
token, który został wygenerowany dla tego
Reguła będzie posiadać zdolność

00:54:06.830 --> 00:54:11.480
zarówno wysyłać i odbierać. Więc teraz
I można go tutaj i kliknij wyświetlony,

00:54:12.880 --> 00:54:15.660
Cóż można przejść. Wygląda jak ludzie
wysyłają wiadomości.

00:54:15.710 --> 00:54:18.320
Teraz przejdź do sesji czatu będzie,
WAS może pozostać w kontakcie

00:54:18.370 --> 00:54:20.210
ze sobą online.

00:54:21.490 --> 00:54:24.220
Tak udostępnionych podpis dostępu, są pod tym względem,
bardzo lekki, są bardzo

00:54:24.270 --> 00:54:28.290
łatwy w obsłudze model. Jeśli zachodzi konieczność
skoczyć SDS rodzaju modelu,

00:54:28.340 --> 00:54:35.540
są to usługi ACS jest w pełni obsługiwany. Jest ACS
nadal prawo opcję nie.

00:54:35.590 --> 00:54:37.660
Tylko widziałem z kolejek.


00:54:39.580 --> 00:54:43.390
Tak więc podsumować, widzieliśmy protokołów.
Dlaczego są one odpowiednie.

00:54:43.650 --> 00:54:47.970
Przeszedł korelacji strumienia
Dlaczego nie jest wymagane który

00:54:48.020 --> 00:54:50.860
utworzyć kolejkę na urządzenie.
Nie chcesz zarządzać

00:54:50.910 --> 00:54:53.980
milion kolejki. Ale nie
Aby być pisania kodu, który

00:54:54.030 --> 00:54:57.760
musi być za bardzo złożonych. Tak
obie te są bardzo, bardzo

00:54:57.810 --> 00:55:00.840
łatwo jest obsługiwane z usługą
Obsługa wiadomości magistrali.

00:55:01.900 --> 00:55:05.320
Kolejki, tematy, subskrypcji.
Symetryczne w każdym z nich.

00:55:05.370 --> 00:55:08.990
Wszystko I pokazał, w kategoriach
co działa z kolejkami dla

00:55:09.040 --> 00:55:12.280
sesje działa dokładnie tak samo
Tematy i subskrypcji

00:55:12.330 --> 00:55:16.290
i filtry. Podczas tworzenia subskrypcji,
Wystarczy powiedzieć wymaga

00:55:16.340 --> 00:55:18.360
Sesja na nim równa TRUE lub nie.


00:55:21.680 --> 00:55:22.910
Skalowanie odbiorników.


00:55:27.210 --> 00:55:30.850
Program Visual Studio miał to wyzwanie
gdzie można uruchomić mnóstwo

00:55:30.900 --> 00:55:34.520
wystąpień z IDE, a następnie
można go i zmienić swoje

00:55:34.570 --> 00:55:37.840
profil na jednym z nich i użytkownik
potrzeba, wszystkie z nich w celu ich zsynchronizowania.

00:55:38.640 --> 00:55:41.980
Jak zamierzasz przejść komunikowania się
do wszystkich tych wystąpień?

00:55:42.490 --> 00:55:45.600
I są dynamiczne wystąpienia
zbyt ponieważ liczba VS

00:55:45.650 --> 00:55:49.910
zmienia się wystąpienia, które jest już uruchomiony
w zależności od dnia tygodnia.

00:55:49.960 --> 00:55:53.530
Mamy rzeczywiście statystyki
Aby pokazać, że, przy okazji.

00:55:53.580 --> 00:55:57.170
Osoby otwierają sposób więcej wystąpień w środę
nie otwierają się w piątek.

00:55:57.220 --> 00:56:04.740
Wydajność jest więc tankowania na piątek. 
 Tak czy inaczej problem może ponownie

00:56:04.790 --> 00:56:07.440
być rozwiązane z tematów gdzie możesz
mieć miliony

00:56:07.490 --> 00:56:11.110
punkty końcowe. I chcesz, aby wszystkie
im słuchanie własne jeden

00:56:11.160 --> 00:56:14.070
pojedynczy subskrypcja dla wiadomości.

00:56:15.150 --> 00:56:19.140
Od tego, czy te komunikaty są generowane
przez back-end oparta

00:56:19.190 --> 00:56:22.840
Niektóre zmiany w systemie lub
jak chcesz wysłać coś

00:56:22.890 --> 00:56:26.270
powiadomienie do użytkownika, ma
Aby powiadamiać o nich w systemie Windows

00:56:26.320 --> 00:56:30.510
pole 7, gdzie masz żadnego powiadomienia
Usługa. Chcesz powiadomić

00:56:30.560 --> 00:56:34.520
je i powiedzieć hej tam jest nowa aktualizacja
dostępne w programie Visual Studio

00:56:34.570 --> 00:56:39.970
Przejdź go pobrać. Lub co ważniejsze
Nadaj im sortowania krótki czas oczekiwania

00:56:40.020 --> 00:56:43.890
z potoku where, jeżeli dokonają zmian
na jedno wystąpienie VS, inne

00:56:43.940 --> 00:56:45.430
Synchronizowanie VS wystąpień.

00:56:46.140 --> 00:56:48.340
Można pozywa tematy i
Subskrypcje w tym.

00:56:49.760 --> 00:56:52.470
Więc myśleć o tym koncepcyjnie
jako użytkownik-VS tematu.

00:56:53.200 --> 00:56:58.800
Wystąpienie-VS subskrypcji
zawsze połączone za pomocą MQP.

00:56:58.850 --> 00:57:03.260
Dzięki MQP daje nam mnóstwo połączenia
wydajność, gdzie masz

00:57:03.310 --> 00:57:07.830
na nas miliony
Współbieżne sekcje z bardzo,

00:57:07.880 --> 00:57:12.350
bardzo niskie wymagania organizacyjne, czekają
dla pozarozkładowych powiadomień.

00:57:12.380 --> 00:57:14.840
To różnica dotyczące powiadomień.
Są one bardzo sporadyczne

00:57:14.890 --> 00:57:18.080
w naturze. Jak często są ludzie
zmienić ich kolor profilu?

00:57:19.770 --> 00:57:20.260
Dzień?

00:57:20.310 --> 00:57:22.960
Tydzień? Mam nadzieję, że nie każdy dzień.

00:57:23.790 --> 00:57:25.160
Zależy od Twojego nastroju chyba.

00:57:26.260 --> 00:57:29.100
Ale nie zdarza się bardzo często.
Jak często mają aktualizacje

00:57:29.150 --> 00:57:33.660
wypchnąć? Nie bardzo często. Ale
Masz jeszcze tego typu BNS

00:57:33.710 --> 00:57:38.290
dostępne dla infrastruktury
Możesz tam gdzie masz połączenia

00:57:38.340 --> 00:57:41.780
Trwa oczekiwanie na powiadomienia, ponieważ
gdy powiadomienie

00:57:41.830 --> 00:57:45.170
staje się dostępne, która będzie
natychmiast. Ma on prawo

00:57:45.220 --> 00:57:46.040
wtedy i tam.

00:57:51.000 --> 00:57:54.990
Więc trzeba myśleć naprawdę
temat i trzeba myśleć

00:57:55.040 --> 00:57:59.320
temat wiadomości przepływów. Ponieważ dzisiaj
Tematy pozwalają maksymalnie 2000

00:57:59.370 --> 00:58:03.170
Subskrypcje i kiedy masz na myśli
skali na numer

00:58:03.220 --> 00:58:07.420
odbiorników 2000 może wystarczyć
lub 2000 może być za mało.

00:58:07.980 --> 00:58:10.910
Jeśli myślisz o Visual Studio
jedna osoba mające więcej

00:58:10.960 --> 00:58:13.700
Liczba wystąpień 2000 z
IDE uruchomiony jest

00:58:16.030 --> 00:58:20.210
prawie niemożliwe. Nie wiem, może
jest możliwe, ale nie zdarza się to.

00:58:20.520 --> 00:58:24.520
Tak dla nich użytkownika-VS tematu
jest w porządku, ale dla Ciebie, może to być

00:58:24.570 --> 00:58:27.660
być każdy prowadzi nasłuch
do jednego kanału. Chcesz

00:58:27.710 --> 00:58:30.790
być w stanie wysłać wszystkim wysyłania...
pojedynczy wiadomość i wyślij ją

00:58:30.840 --> 00:58:34.790
szerokie oddanych do wszystkich osób. No i następnie
chcesz połączonych w łańcuch tematy.

00:58:35.250 --> 00:58:38.680
I że za pomocą auto przesyłania dalej.

00:58:39.850 --> 00:58:43.350
Nie zamierzam skoczyć kilka
te szczegóły wzór w

00:58:43.400 --> 00:58:45.280
warunki jak ustawić filtry.

00:58:45.800 --> 00:58:48.520
Wszystkie one są próbki na MSDN.com.

00:58:49.130 --> 00:58:55.380
Nazywa się to dana próbka
Lista. Jest to próbka o nazwie

00:58:55.430 --> 00:58:58.720
Publikowanie subskrypcji. Pełny kod
na takie jest dostępne.

00:58:58.770 --> 00:59:02.570
Zachęcają do was wrócić, podjąć
wygląd, ale z tych tematów

00:59:02.620 --> 00:59:06.190
naprawdę można rozliczyć się tych bogatych
gdzie są przepływy każdej wiadomości

00:59:06.240 --> 00:59:09.930
nie musi uzyskać kierowane do wszystkich
2 miliony ludzi a następnie

00:59:09.980 --> 00:59:14.280
tracone zawsze. Można uzyskać
kierowane do jednej osoby do wielu

00:59:14.330 --> 00:59:18.680
osób, lub w nieskończonej rodzaju przypadku
Jeżeli po prostu napisać adres.

00:59:18.730 --> 00:59:19.660
Podobnie jak wiadomości e-mail.

00:59:20.190 --> 00:59:23.130
W tym przypadku jest jak mówi
co mogę powiedzieć, po pierwsze, wiadomości

00:59:23.180 --> 00:59:24.230
przecinek, drugie.

00:59:25.130 --> 00:59:27.850
I zwracam dwa urządzenia,
pierwszym urządzeniem, a drugi

00:59:27.900 --> 00:59:30.770
urządzenie lub dwa subskrypcji
pierwszy i drugi.

00:59:30.820 --> 00:59:35.390
Ponieważ mają reguł ustawionych, np.
najpierw i jak drugi tam.

00:59:36.390 --> 00:59:40.470
Tak naprawdę spojrzeć na te
sub pub (indiscernible)

00:59:42.610 --> 00:59:47.050
automatyczne przesyłanie dalej. Bardzo łatwe
Aby użyć. Zasadniczo tworzenie

00:59:47.100 --> 00:59:52.150
miejsca docelowego w kolejce po raz pierwszy i
następnie w źródłowej kolejce użytkownik

00:59:52.200 --> 00:59:55.970
dodać jedną właściwość. Pojedynczej właściwości
nosi nazwę źródła.Mistyczne,

00:59:57.220 --> 01:00:00.600
do kolejki docelowej i tak
to. Wszystkich wiadomości przychodzących

01:00:00.650 --> 01:00:03.280
do kolejki źródłowej przejdź do
do kolejki docelowej.

01:00:03.330 --> 01:00:10.030
Źródła mogą być subskrypcje i
kolejki. Audyty mogą być tematy

01:00:10.080 --> 01:00:10.960
i kolejki.

01:00:13.190 --> 01:00:16.800
Całkowicie symetryczny, ustanowionego tyle
czy Przeprosiny czcionki jako użytkownik

01:00:16.850 --> 01:00:18.810
jak i zobaczyć, że.

01:00:19.400 --> 01:00:22.540
Jeśli masz przemijające przypadków gdzie
masz subskrypcji który

01:00:22.590 --> 01:00:23.390
wyjeżdżasz,

01:00:24.660 --> 01:00:28.430
Umożliwia automatyczne usuwanie na biegu jałowym. Tak
jest to również bardzo miłe, funkcję.

01:00:28.480 --> 01:00:32.570
Niech zarządzanie dużą liczbą
przemijające połączeń. W rzeczywistości

01:00:32.620 --> 01:00:35.640
jeden ze scenariuszy klucza, to jest
używany jest przez SignalR i

01:00:35.690 --> 01:00:38.590
Gniazda We/Wy. Są one bardzo,
bardzo przemijające.

01:00:38.640 --> 01:00:40.200
Połączenia pochodzą, przejdź połączeń.

01:00:41.380 --> 01:00:43.700
Dodane ładunków i węzły zostaną usunięte.

01:00:44.600 --> 01:00:48.680
Używają magistrali usługi jako kopię
Odtwórz gdzie, zasadniczo są one

01:00:48.730 --> 01:00:52.540
Zapisywanie subskrypcji na węzeł przy każdym
pochodzi nową subskrypcję

01:00:52.590 --> 01:00:56.160
nowe połączenia pojawia się
nowy węzeł pojawia się, kiedy one

01:00:56.210 --> 01:00:57.260
Dodaj serwery.

01:00:58.320 --> 01:01:03.210
A następnie użyć tematy i subskrypcji
jako rura wstecz do

01:01:03.260 --> 01:01:05.970
Transfer wiadomości między węzłami
i uzyskać szerszą skalę.

01:01:07.010 --> 01:01:10.090
I wtedy kiedy węzeł odchodzi,
subskrypcja wygaśnie, tych

01:01:10.140 --> 01:01:17.490
wiadomości są już nie. Oba
te kodu są otwarte kodu.

01:01:17.540 --> 01:01:20.240
Obie funkcje są dostępne, jeśli chcesz
możliwość skalowania, sygnał się lub Socket

01:01:20.290 --> 01:01:24.720
We/Wy ponieważ potrzebne trwałe obsługi wiadomości
rury na końcu, usługi

01:01:24.770 --> 01:01:27.980
Implementacje ma magistrali
dla obu tych.

01:01:29.920 --> 01:01:33.050
Chcę mówić trochę wbudowane
o dostępności więc Pozwól mi

01:01:33.100 --> 01:01:36.780
szybko pokrycia. Wiem
Jesteśmy prawie w czasie

01:01:38.830 --> 01:01:42.440
Kod musi być odporny na działanie
awarie, jak również podłączone

01:01:42.490 --> 01:01:43.470
z problemami.

01:01:43.990 --> 01:01:46.750
Kolejki utraconych wiadomości, jak I powiedział
naprawdę pomóc Ci. Pomagają one

01:01:46.800 --> 01:01:50.790
przy stosowaniu poziom gdzie
decivilization wiadomość lub

01:01:50.840 --> 01:01:51.830
coś może się nie powieść.

01:01:52.980 --> 01:01:57.440
Każda wiadomość, która zgłasza Service Bus
w właściwość przejściowe

01:01:57.490 --> 01:01:58.020
na nim

01:01:59.480 --> 01:02:02.780
jasno i prosto ułatwia
Aby wiedzieć czy użytkownik

01:02:02.830 --> 01:02:04.350
Aby ponowić próbę wykonania lub nie mają.

01:02:05.090 --> 01:02:08.560
Domyślnie faktycznie jesteśmy automatycznie
ponowiona. Tak ja zawsze mówię

01:02:08.610 --> 01:02:12.090
o przekroczenia limitów czasu w zasadzie operacji
limity czasu. Domyślnie

01:02:12.140 --> 01:02:15.190
limity czasu operacji są ustawione na
60 sekund, co oznacza, jeśli użytkownik

01:02:15.240 --> 01:02:19.720
Aby wywołać wysyłania, mogą nie działać po raz,
spróbujemy go ponownie po

01:02:19.770 --> 01:02:22.980
trzy sekundy. Może ona złożyć dwa razy. Będziemy
Spróbuj ponownie po dziesięć sekund.

01:02:23.030 --> 01:02:27.840
W tym 60 sekund możesz nam, będziemy
Spróbuj się, że połączenie powiodła się.

01:02:27.890 --> 01:02:29.740
A jeśli nie, wyślemy
to powrót do.

01:02:31.320 --> 01:02:33.650
Jeśli masz inne miejsce
Aby utrwalić to, że jest w porządku.

01:02:33.700 --> 01:02:36.920
W przeciwnym przypadku sprawdź jako przejściowe i
następnie można wysłać go z powrotem, odgadnąć.

01:02:38.160 --> 01:02:42.430
A kolejek partycji i tematy
znacznie zwiększoną dostępność.

01:02:43.080 --> 01:02:48.230
Poprawa rzędu. Tak
Zdecydowanie zdecydowanie zaleca się przy użyciu

01:02:48.280 --> 01:02:49.710
Ta funkcja.

01:02:51.830 --> 01:02:55.280
Ponów próbę wykonania zasad na domyślnie.
Nie należy go wyłączyć, proszę.

01:02:57.200 --> 01:02:59.970
Obszary nazw sparowany. Ostatni
rzeczą omówię dzisiaj.

01:03:00.490 --> 01:03:03.540
Jeśli masz Service Bus o nazwie miejsca,
ładnie płyną wiadomości

01:03:03.590 --> 01:03:08.210
za pośrednictwem i następnie cały danych
Centrum prowadzi głowę lub przynajmniej

01:03:08.260 --> 01:03:13.570
Ten obszar nazw całego idzie głowę.
Zła nazwa miejsca spowoduje utworzenie

01:03:13.620 --> 01:03:15.790
kopię zapasową obszaru nazw. Tworzenia
kopię zapasową obszaru nazw.

01:03:15.840 --> 01:03:19.190
Po prostu zapewnić do nas, a my będziemy
Start, przechowywanie wiadomości w

01:03:19.240 --> 01:03:23.440
kopię zapasową obszaru nazw. Tak więc każdy
komunikat, który nie wchodząc

01:03:24.140 --> 01:03:25.350
wzrośnie do tyłu.

01:03:26.210 --> 01:03:29.450
W pewnym momencie rozpocznie wiadomości
Zamalowywanie. System

01:03:29.500 --> 01:03:30.340
wróci.

01:03:31.350 --> 01:03:35.150
I w tym momencie mamy syfon
podejmie wiadomości od tych

01:03:35.200 --> 01:03:39.110
kolejki transferu i reenqueue
im oryginalną kolejkę.

01:03:40.650 --> 01:03:43.590
Tak na wszystkie te kod nadawcy
nie powoduje zmiany odbiornika

01:03:43.640 --> 01:03:46.370
kod nie jest zmieniany. Twój nadawcy
a odbiorcą, tak jakby znajdowały się one

01:03:46.420 --> 01:03:48.470
zawsze mówić do usługi
Obszar nazw magistrali.

01:03:49.240 --> 01:03:54.700
Jesteśmy pod przykryciem, tworzenie
kolejki transferu, przenoszenie

01:03:54.750 --> 01:03:57.870
a następnie ciągnięcie wiadomości
je z powrotem dla Ciebie.

01:03:58.720 --> 01:04:03.160
I jest to jedyna
Kod, który należy zmodyfikować.

01:04:03.740 --> 01:04:06.070
To nie tylko pracę, którą masz
Aby to zrobić. Będziemy mówić

01:04:06.120 --> 01:04:08.520
Uwagi dotyczące ale to
tylko fragment kodu, który trzeba

01:04:08.570 --> 01:04:13.330
Modyfikowanie, który jest to, że podczas tworzenia
fabryki, która jest Twój

01:04:13.380 --> 01:04:17.690
Uruchom czas wysyłania i odbierania kodu
klasy, można powiązać go z nazwą

01:04:17.740 --> 01:04:21.230
miejsca, można powiedzieć hej tam jest drugi
fabryka, drugi obszar nazw

01:04:21.280 --> 01:04:24.130
Menedżer, z którą chcesz
Aby być połączone z.

01:04:24.660 --> 01:04:28.600
I wszystko odbywa się poprzez
po stronie klienta. Żadna zmiana nadawcy.

01:04:28.650 --> 01:04:31.470
Brak odbiornika zmian. Kod
pozostaje taki sam.

01:04:36.210 --> 01:04:41.520
Teraz nadawca dostępny jest obsługiwany.
Jak przedstawiono na diagramie

01:04:41.570 --> 01:04:44.590
Odbiornik nie otrzyma wiadomość
aż do oryginalnej nazwy

01:04:44.640 --> 01:04:45.760
wraca miejsca.

01:04:46.330 --> 01:04:49.340
Jest to więc więcej od dostępności wysyłania.
W tej chwili dlatego

01:04:49.390 --> 01:04:54.000
nazywamy to opcje dostępności wysyłania.
Zamówienia mogą zostać utracone ponieważ

01:04:54.050 --> 01:04:57.910
wiadomości, które są w przeniesieniu
Kolejka nie będą wyświetlane.

01:04:58.630 --> 01:05:02.360
A następnie koniec kończy się otrzymać czas oczekiwania
Oczywiście mogą być wysokie.

01:05:02.410 --> 01:05:06.420
Tak więc istnieją pewne kwestie
ale naprawdę myśleć o tym, jak

01:05:06.470 --> 01:05:10.730
klucz scenariusz tworzenia
rodzaju odzyskiwania systemu po awarii

01:05:12.070 --> 01:05:14.770
kiedykolwiek scenariuszy.

01:05:15.810 --> 01:05:18.710
Piła tak tylko do zamykania, firma Microsoft Azure
Naprawdę można skalować usługi magistrali

01:05:18.760 --> 01:05:21.870
we wszystkich wymiarach. Wiele nadawcy.
Wiele przepustowość.

01:05:21.920 --> 01:05:23.080
Wiele odbiorników.

01:05:23.730 --> 01:05:27.420
A może poprawić niezawodność
zarówno nowym funkcjom się

01:05:27.470 --> 01:05:31.950
pola jak partycja kolejek
i połączone obszary nazw lub według

01:05:32.000 --> 01:05:37.320
dokonywanie kodzie używać deseni jak
Asynchroniczne oraz partia i rzeczy.

01:05:38.100 --> 01:05:41.750
Ton łącza. Mnóstwo zasobów.
Użytkownik ma dostęp do wszystkich, że.

01:05:41.800 --> 01:05:44.130
Dziękuję. Przepraszam
niezależnie od.