WEBVTT 00:00:01.460 --> 00:00:02.340 Boa tarde. 00:00:04.930 --> 00:00:05.880 Como as pessoas estão fazendo? 00:00:08.810 --> 00:00:14.600 BOM? Vocês fizeram dela quase ao final de uma conferência. 00:00:15.630 --> 00:00:17.150 Como é a experiência foi até agora? 00:00:17.160 --> 00:00:19.360 [Aplausos] 00:00:19.520 --> 00:00:20.120 >> Válida. 00:00:20.170 --> 00:00:24.940 Awesome. Bem, como dizem, eles sempre salve o melhor para o final. 00:00:26.240 --> 00:00:32.190 Espero, eu não será desaponta vocês. Realmente estimo 00:00:32.240 --> 00:00:34.450 o que esta tarde. 00:00:35.200 --> 00:00:40.360 Eu sou Abhishek Lal. Gerenciador de programas com a equipe da plataforma Windows Azure. 00:00:41.090 --> 00:00:45.840 Essa foi a equipe que cria PaaS serviços, como serviços de celular 00:00:45.890 --> 00:00:48.550 Barramento de serviço, cache Azure. 00:00:49.240 --> 00:00:51.080 E serviços de mídia. 00:00:51.720 --> 00:00:54.320 Esses serviços são o que a equipe é responsável. 00:00:54.830 --> 00:00:58.940 E especificamente tenho trabalhado para os três últimos mais anos 00:00:58.990 --> 00:01:05.100 sobre a criação de mensagens intermediário peças. Portanto, é filas, 00:01:05.150 --> 00:01:08.720 tópicos, são sub pub, as peças de que. 00:01:09.470 --> 00:01:15.150 Hoje que vamos conversar sobre mensagens em escala. 00:01:17.010 --> 00:01:22.030 Tópicos e filas. Agora são caras conhece o barramento de serviço. 00:01:22.840 --> 00:01:26.920 Ele abrange a retransmissão. Ele faz englobar hub de notificação 00:01:27.780 --> 00:01:29.010 tópicos e filas. 00:01:29.560 --> 00:01:34.840 Portanto, é de uma amplitude de todo de serviços relacionados a mensagens. 00:01:35.710 --> 00:01:39.560 Esta sessão específica será concentrar-se principalmente em filas 00:01:39.610 --> 00:01:46.260 e isso é o principal de tópicos área. Mas se você tiver dúvidas 00:01:46.310 --> 00:01:50.120 ou qualquer coisa que você gostaria de saber especificamente sobre a retransmissão ou 00:01:50.170 --> 00:01:55.150 hubs de notificação, fico feliz em responder ou, pelo menos, ponto 00:01:55.200 --> 00:01:57.410 você na direção certa. 00:01:58.820 --> 00:02:00.930 Há muitas coisas Quero abordar hoje. 00:02:01.710 --> 00:02:04.730 Falar sobre os diferentes aspectos de escala. Eu quero falar 00:02:04.780 --> 00:02:08.490 sobre remetentes e receptores e taxa de transferência, todos os diferentes 00:02:08.540 --> 00:02:11.630 padrões, bem como o informações específicas de código. 00:02:12.390 --> 00:02:14.870 De como você pode obter escala. 00:02:15.810 --> 00:02:19.040 Então, eu tentei manter um bom ritmo. 00:02:19.640 --> 00:02:24.190 Perguntas são excelentes. Se você vir me começando a cortar pequenas questões 00:02:24.240 --> 00:02:27.780 apenas um pouco mais adiante, para que eu pode cobrir todas as coisas que desejo 00:02:27.830 --> 00:02:31.490 para cobrir. Eu ficará disponível após a sessão e você poderá sempre 00:02:31.540 --> 00:02:36.200 Falar comigo, mas mantê-lo interativo. Tudo o que você tem, 00:02:36.250 --> 00:02:41.270 os microfones estão bem aqui. Basta ir até e eu chamarei. 00:02:43.930 --> 00:02:48.720 Vamos começar falando sobre o que do novo. Classificar apenas de uma atualização 00:02:48.770 --> 00:02:51.210 no que nós já anunciou como 2.3 SDK. 00:02:52.250 --> 00:02:56.290 Podemos alternará falando as dimensões de escala. 00:02:56.340 --> 00:03:00.420 Falaremos sobre remetentes, destinatários, taxa de transferência, como você obter. 00:03:01.800 --> 00:03:05.770 E, em seguida, vamos gastar algum tempo no Considerações sobre a disponibilidade. 00:03:05.820 --> 00:03:07.850 Disponibilidade apenas amplamente significando 00:03:09.190 --> 00:03:14.340 resistência, melhor SLA e como para criar seu aplicativo 00:03:14.390 --> 00:03:19.520 estar sempre para cima, sempre, executando lá, portanto, vamos gastar alguns 00:03:19.570 --> 00:03:20.510 tempo nisso. 00:03:22.060 --> 00:03:25.780 Esse SDK 2.3. 00:03:26.330 --> 00:03:28.310 O que estamos apenas liberou? 00:03:29.070 --> 00:03:32.540 Na sessão de mensagem. Do membro etc os jurados são um envio 00:03:32.590 --> 00:03:36.970 estilo de API. Demora essencialmente Embora o trabalho pesado por você 00:03:37.020 --> 00:03:42.960 escrever os loops C ou qualquer coisa dessa complexidade e 00:03:43.010 --> 00:03:46.420 oferece a você um evento-diferentes modelo para consumir mensagens. 00:03:46.470 --> 00:03:50.110 Esta é a API do lado receptor. Então temos que para as sessões. 00:03:50.160 --> 00:03:52.680 Definitivamente abordaremos que mais detalhadamente hoje. 00:03:53.890 --> 00:03:58.440 Modo de conectividade de detecção automática. Então, como você sabe, um o real 00:03:58.490 --> 00:04:02.520 valor da chave de barramento de serviço do Azure foi que quando você estiver se conectando 00:04:02.950 --> 00:04:07.700 filas e tópicos na nuvem atrás de firewalls de 00:04:07.750 --> 00:04:11.450 seus próprios data centers ou de sua centros de dados de clientes que 00:04:11.500 --> 00:04:16.230 são ficam para trás muito bem protegidos classificação de firewalls, serviço 00:04:16.280 --> 00:04:19.660 Barramento tem a capacidade de estabelecer conexões de saída não apenas na porta TCP 00:04:19.710 --> 00:04:22.110 mas a porta 443 e 83 00:04:23.670 --> 00:04:25.860 enquanto as portas TCP são bloqueadas. 00:04:26.700 --> 00:04:30.790 Esse recurso será ainda está agora disponível Se definir diretamente 00:04:30.840 --> 00:04:34.230 o diretório com o modo como o TCP, Portanto, você nunca tinha a chance. 00:04:34.910 --> 00:04:38.730 Agora em seu código pode apenas definir ele automaticamente detectará e daremos 00:04:38.780 --> 00:04:42.910 ver automaticamente se a porta TCP é disponível, usaremos que. 00:04:42.960 --> 00:04:48.410 Se o firewall bloqueia, nós iremos Solte-o para HTTP. Esse SDK 00:04:48.460 --> 00:04:51.560 2.3, que está disponível para mensagens também. 00:04:54.390 --> 00:04:57.980 Suporte a CORS. Quantas pessoas saber qual é a CORS? 00:05:00.360 --> 00:05:04.200 A maioria das pessoas conhecê-la. Ele basicamente permite fácil enviar/receber 00:05:04.250 --> 00:05:09.370 de navegadores. A idéia é que você sempre pode ter feito, você tem 00:05:09.420 --> 00:05:14.320 STPI com SCTP. Você pode fazer enviar mensagens, receber mensagens, 00:05:14.370 --> 00:05:18.920 mas com CORS agora fica muito mais fácil para sites e navegadores 00:05:18.970 --> 00:05:23.650 a integração de voltar e podemos mergulhar Isso detalhadamente hoje. 00:05:25.010 --> 00:05:29.530 Da mesma forma, a classificação de ajudando-out desempenho, bem como em escala 00:05:29.580 --> 00:05:34.760 Remetentes HTTP, nós temos processamento em lotes agora disponível. 00:05:35.200 --> 00:05:43.980 E, em seguida, alguns perf do lado de cliente contadores que é quando você 00:05:44.030 --> 00:05:46.900 realmente colocar um aplicativo que é complicado ou estiver 00:05:46.950 --> 00:05:50.450 para executá-lo em diferentes ambientes Talvez seja necessário 00:05:50.500 --> 00:05:53.340 depurá-lo e talvez seja necessário perfil Ele forma adicionamos cliente 00:05:53.390 --> 00:05:57.890 contadores de perf do lado das mensagens enviadas por segunda, letras por segundo 00:05:57.940 --> 00:06:01.460 e coisas como essas que pode realmente, realmente ajudá-lo a perfil 00:06:01.510 --> 00:06:05.250 o que mensagens é de camada fazendo geral estiver oposta 00:06:05.300 --> 00:06:09.020 ocasião está fazendo. Portanto, aqueles serão em seguida, manifesto para esses perf 00:06:09.070 --> 00:06:14.230 contadores como parte do pacote do NuGet nele para que ele realmente permite que 00:06:14.280 --> 00:06:17.550 você faça alguma boa depuração. 00:06:20.550 --> 00:06:23.340 E finalmente, ForwardTo para filas de mensagens mortas. 00:06:23.880 --> 00:06:27.380 Deadlettering é um muito, muito poderoso recurso onde ele protege 00:06:27.430 --> 00:06:30.820 Você está back-ends se houver suspeita mensagens. Essas são normalmente 00:06:30.870 --> 00:06:34.620 chamadas de filas de inviáveis onde você tentar ao receber uma mensagem e o 00:06:34.670 --> 00:06:38.600 mensagem não está formada ou há um bug no código em algum lugar 00:06:38.650 --> 00:06:42.080 em algum lugar do civilizer de em que você não esteja conseguindo abrir 00:06:42.130 --> 00:06:44.560 a mensagem e as falhas de back-end. 00:06:45.780 --> 00:06:50.390 Barramento de serviço fornece a capacidade definir uma entrega máxima 00:06:50.440 --> 00:06:54.420 contagem que por padrão é 10 e o Isso significa é que se nós vemos 00:06:54.470 --> 00:06:57.660 que fornecermos a mensagem Você tem 10 vezes e você 00:06:57.710 --> 00:07:01.310 não finalizou o mensagem, transferiremos de 00:07:01.360 --> 00:07:03.240 a fila principal para a fila de mensagens mortas. 00:07:03.870 --> 00:07:07.930 Para isso literalmente ajuda seus aplicativos ser resistente por padrão 00:07:08.190 --> 00:07:12.840 sem necessidade de escrever um único linha de código e proteger 00:07:12.890 --> 00:07:18.660 os servidores de back-end. Assim ForwardTo é a capacidade de canal 00:07:18.710 --> 00:07:23.810 mensagens automaticamente criar ricos fluxos de mensagens e agora 00:07:23.860 --> 00:07:30.000 pode levar a um aplicativo que pode ter 6, 8, 10 filas e ForwardTo 00:07:30.050 --> 00:07:34.450 para a fila de mensagens mortas em uma única fila que significa 00:07:34.500 --> 00:07:38.530 Agora, você terá um lugar para ir agora receber todas as mensagens suspeitas 00:07:38.980 --> 00:07:42.340 independentemente de quantos filas ou tópicos ou inscrições você 00:07:42.390 --> 00:07:46.280 estiver usando isso que um recurso necessário adicionar também. 00:07:47.180 --> 00:07:49.910 Abordaremos isso em um pouco mais detalhadamente. 00:07:51.740 --> 00:07:57.570 Eu quis recapitular rapidamente sobre o que fizemos desde abril 00:07:57.620 --> 00:08:01.400 porque quando falamos hoje em termos de dimensionamento e desempenho 00:08:01.450 --> 00:08:05.780 e você verá muita de throughput Esses recursos estão sendo referenciados 00:08:06.180 --> 00:08:08.570 Portanto, eu só queria destacá-los em termos de se eles são 00:08:08.620 --> 00:08:12.370 já disponível atualmente e eles já foi lançado há algum tempo, mas 00:08:12.420 --> 00:08:16.250 elas foram relevantes ainda lá. 00:08:18.520 --> 00:08:22.290 A única coisa para ver aqui está funcionando abaixo da linha, a primeira 00:08:22.340 --> 00:08:26.310 barramento de serviço promessa assim por último Fizemos o barramento de serviço do ano 00:08:26.360 --> 00:08:28.900 1.1 para a versão do Windows server. 00:08:29.580 --> 00:08:33.210 Isso é completamente simétrico para fila e tópicos que significa 00:08:33.260 --> 00:08:37.450 Se você pegar SDK 2.1, por exemplo, qual foi o último SDK, 00:08:38.470 --> 00:08:42.010 Você seria capaz de qualquer impacto o serviço ou em premise todos 00:08:42.060 --> 00:08:45.070 os recursos que estão disponíveis. 00:08:46.760 --> 00:08:51.600 Esta cadência de tipo de lançamento de nuvem a cada três meses você 00:08:51.650 --> 00:08:55.290 pode ver a cada três ou quatro meses e no local de lançamento em 00:08:55.340 --> 00:08:59.520 pelo menos uma vez por ano é o que tentamos para manter e colocar ambos 00:08:59.570 --> 00:09:02.680 o recurso define em paridade. 00:09:05.540 --> 00:09:08.740 Portanto, é disponível para referência mais adiante em termos de 00:09:08.790 --> 00:09:10.010 os recursos. 00:09:12.110 --> 00:09:13.310 Alguma dúvida até agora? 00:09:15.820 --> 00:09:16.720 Sim, por favor. 00:09:16.730 --> 00:09:19.730 [Indiscernible] 00:09:19.950 --> 00:09:23.560 >> Então a pergunta era: quando será a próxima atualização e onde 00:09:23.610 --> 00:09:28.920 daremos 2.3, mais recente existe a funcionalidade. 00:09:28.970 --> 00:09:33.240 Agora, eu não tenho quaisquer datas compartilhar para o próximo serviço 00:09:33.290 --> 00:09:36.320 Versão de barramento, mas haverá ser um 2.2 ou um 1.2. 00:09:37.800 --> 00:09:42.620 Mas você pode considerar isso normalmente Data do release específico 00:09:43.340 --> 00:09:46.900 corresponde o lançamento do Windows Server Portanto, na maioria das vezes eles tentam 00:09:46.950 --> 00:09:51.580 Para alinhar com as versões de servidor assim obtemos a máxima da plataforma 00:09:51.630 --> 00:09:55.010 benefício para garantirmos que temos servidor maior com os mais recentes 00:09:55.060 --> 00:09:59.310 clusters com o gerenciamento mais recente e deforma e tudo. 00:09:59.360 --> 00:10:03.610 Assim, normalmente apenas as diretrizes pressupõem que o mesmo tipo de cadência 00:10:03.660 --> 00:10:05.820 será seguido. Boa pergunta. 00:10:08.920 --> 00:10:13.130 Escala no remetente. Vamos começar com Isso em termos da primeira 00:10:13.180 --> 00:10:14.210 proporção de escala. 00:10:15.570 --> 00:10:18.650 Para remetentes não é nada, mas em algum lugar em que você esteja 00:10:18.660 --> 00:10:20.040 [Indiscernible] 00:10:20.000 --> 00:10:22.830 Você pode pensar em muitos dos cenários aqui. Você pode pensar em dispositivo 00:10:22.880 --> 00:10:24.970 Telemetria, por ações do usuário. 00:10:26.630 --> 00:10:31.030 E os sistemas de geração de eventos e B para B tipo de cenário. 00:10:31.080 --> 00:10:32.910 Os eventos estão sendo gerados. 00:10:33.640 --> 00:10:37.660 Como é cuidar dos cenários onde você tem muitos desses 00:10:37.710 --> 00:10:41.620 ou talvez alguns com muita de eventos ou muitos remetentes 00:10:41.670 --> 00:10:45.250 com uma grande quantidade de eventos? Todas as são cenários possíveis. 00:10:46.830 --> 00:10:50.480 Portanto, podemos tornar concreto. Ela será começar com um cenário real 00:10:50.530 --> 00:10:54.510 quais clientes são usados hoje que é onde você precisa 00:10:54.560 --> 00:10:58.850 coletar eventos para análise de um grande número de dispositivos. 00:11:00.370 --> 00:11:05.900 Esses dispositivos podem parecer familiares mas isso é uma coincidência que 00:11:05.950 --> 00:11:11.000 Eu não confirmar nem negar. Ele pode ser qualquer dispositivo. 00:11:11.050 --> 00:11:12.350 Pode ser qualquer dispositivo. 00:11:13.160 --> 00:11:18.850 Agora tudo isso começa com a dispositivo sendo capaz de fila em 00:11:18.900 --> 00:11:24.250 mensagens, sendo capaz de assumir algumas tópicos ou um tópico e envio 00:11:24.300 --> 00:11:28.090 em muitas informações no canal 00:11:29.520 --> 00:11:33.640 uma vez que uma mensagem em um tópico Você pode pensar que você pode 00:11:34.710 --> 00:11:39.370 ter vários cenários em que você deseja consumi-lo. 00:11:39.420 --> 00:11:43.330 Análise em tempo real ou que você faria com seu próprio código é 00:11:43.380 --> 00:11:48.570 realmente se tornando muito mais predominantes e populares. Pessoal fez 00:11:48.620 --> 00:11:53.840 para a sessão de Orleans que foi feito ontem? Bem, se 00:11:53.890 --> 00:11:57.080 Você fez, peça awesome, awesome tecnologia porque ele tenta 00:11:57.130 --> 00:12:02.580 Para resolver esse problema de executar seu código em escala em distribuído 00:12:02.630 --> 00:12:06.190 modo de se você está lidando com eventos que estão sendo gerados 00:12:06.240 --> 00:12:10.830 por um grande número de remetentes e são correlacionada em vez que forma. 00:12:12.020 --> 00:12:15.930 Então, como ter certeza de que eles sistemas back-end são desassociados? 00:12:15.980 --> 00:12:18.590 Como ter certeza de que eles sistemas back-end são capazes de 00:12:18.640 --> 00:12:24.640 consumir mensagens a essa taxa e agir maneiras em que eles são resistentes? 00:12:25.950 --> 00:12:29.560 E para que você coloque tópicos em no meio. Não apenas os tópicos assim 00:12:29.610 --> 00:12:33.440 fornecer o buffer, como seria uma fila, que significa 00:12:33.490 --> 00:12:35.950 o back-end pode ser feito algumas horas e você não 00:12:36.000 --> 00:12:39.060 perda qualquer um dos eventos. Os eventos ainda estada mas eles 00:12:39.110 --> 00:12:40.490 também lhe sub pub. 00:12:41.470 --> 00:12:45.530 Que significa que se você tiver outras sistemas que estão apenas fazendo 00:12:45.580 --> 00:12:51.310 controle do estado, digamos que colocar valores em cabos Azure, ou 00:12:51.360 --> 00:12:56.520 fazem análises de lote com vincular sua estrutura de arquivos no 00:12:56.570 --> 00:13:00.330 HDFS e executar Hadoop trabalhos nele. 00:13:01.400 --> 00:13:05.850 Ou eles altura estar fazendo com que você estiver dados em um data warehouse SQL 00:13:05.900 --> 00:13:09.170 e execução de consultas de BI Além disso. 00:13:09.790 --> 00:13:13.980 Todos esses sistemas podem ir a aparência no mesmo fluxo de evento. 00:13:15.280 --> 00:13:18.350 E não apenas o mesmo fluxo de evento, eles podem examinar-evento 00:13:18.400 --> 00:13:21.780 fluxo, muito. Talvez o BI trabalhar depósito, Você não deseja consumir 00:13:21.830 --> 00:13:25.870 todos os eventos. Qualquer ação relacionada eventos não deveriam estar lá. 00:13:25.920 --> 00:13:29.420 Eles pertencem somente para as coisas de código. Você pode dividir os fluxos 00:13:29.470 --> 00:13:30.210 Dessa forma. 00:13:32.750 --> 00:13:36.990 E, depois, do seu back-end, se Você está lendo o Azure 00:13:37.040 --> 00:13:41.730 o depósito de dados do SQL, ou de tabelas Você pode gerar sua festa arrasou 00:13:41.780 --> 00:13:43.200 placas e análises. 00:13:44.750 --> 00:13:45.750 Uma da chave 00:13:46.970 --> 00:13:49.340 pontos de design desse pacote. 00:13:50.180 --> 00:13:52.920 Primeiro está usando tópicos para o ventilador. 00:13:53.960 --> 00:13:57.730 Ventilador essenciais significa que você tem menos tópicos do que tem dispositivos. 00:13:57.780 --> 00:13:59.900 Direita? O que são cardinalidade possível. 00:14:01.080 --> 00:14:03.820 Provavelmente não vai ser um. Não vai ser uma 00:14:03.870 --> 00:14:07.660 tópico para tudo. Provavelmente é não vai ser Norte permite passar 00:14:07.710 --> 00:14:12.220 para estar em algum lugar entre e como falamos sobre como descobrir 00:14:12.270 --> 00:14:13.860 com esse número à direita. 00:14:14.410 --> 00:14:18.960 Você vai carregar saldo em os data centers por vários motivos. 00:14:19.320 --> 00:14:22.490 Se você pensar a respeito, esses dispositivos são, na verdade, geograficamente 00:14:23.190 --> 00:14:26.300 espalhar-se assim desejar fazer Se o dispositivo usa a 00:14:26.350 --> 00:14:30.740 mínimo de energia, o menor conexão de latência para poder 00:14:30.790 --> 00:14:33.770 para alcançar e seus dados na fila. 00:14:35.480 --> 00:14:39.640 Portanto, é carga balanceada entre dados centros. Para que esse barramento está disponível 00:14:39.690 --> 00:14:45.690 em todas as regiões Azure, todos os data centers. Portanto, você tem a capacidade 00:14:45.740 --> 00:14:50.730 para difundir tópicos ao redor. Em agora que não significa que o back-end 00:14:50.780 --> 00:14:53.890 os sistemas precisam ser abdicated em todos os demais pontos. 00:14:54.880 --> 00:14:58.000 Se verdade, se você pensar sobre o Hadoop clusters, geralmente, é 00:14:58.050 --> 00:15:01.860 não seja algo que você deseja replicar em todas as regiões em cada data center. 00:15:01.910 --> 00:15:05.890 Mas isso lhe dá uma baixa latência ponto de extremidade. A partir daí, você pode 00:15:05.940 --> 00:15:10.490 coletar dados para onde ele está sendo gerado. E, em seguida, puxe- 00:15:10.540 --> 00:15:14.310 do seu back-end. Chegando em para todas as regiões e 00:15:14.360 --> 00:15:18.450 inscrições em diferentes regiões e correlacionar esses dados. 00:15:20.910 --> 00:15:23.690 Filtro True para inscrição de apenas um, Isso nesta vertical 00:15:23.740 --> 00:15:27.550 caso de cliente, eles realmente por que consumo de todos os seus dados e 00:15:27.600 --> 00:15:31.700 código de estado de acompanhamento e lote análises, mas não no BI. 00:15:31.750 --> 00:15:35.900 Portanto, todos os três foram realmente verdadeiras filtros, mas uma assinatura 00:15:35.950 --> 00:15:39.960 tinha um filtro de redução. Ele tinha um filtro que disse que se trata de um jogo 00:15:40.010 --> 00:15:45.060 evento, então nós não se importa com que e claro que você pode fazer 00:15:45.110 --> 00:15:47.360 análise de lote e em tempo real. 00:15:49.410 --> 00:15:53.110 Portanto, para este cenário, eu pensei Iremos em uma demonstração rápida. 00:15:54.270 --> 00:15:59.080 E mostrar o CORS suporte de seus aspectos. 00:16:00.290 --> 00:16:05.680 Porque ela permite que muito do cliente alcance da perspectiva 00:16:05.730 --> 00:16:11.600 de poder na fila mensagens usando apenas puro 00:16:13.270 --> 00:16:15.140 HTTP e coisas. 00:16:15.730 --> 00:16:21.550 Tenho um site configurado. Vocês possam atingir muito se você tiver 00:16:21.600 --> 00:16:25.950 um dispositivo ou algo parecido. A chamada usuário de arquivo de anotação fazer o Azure 00:16:26.000 --> 00:16:28.260 sites .NET. 00:16:29.750 --> 00:16:40.510 Tudo o que tenho aqui é muito simples JavaScript que eu 00:16:40.560 --> 00:16:41.160 Mostre. 00:16:41.880 --> 00:16:43.280 E o que ele faz 00:16:48.770 --> 00:16:53.470 é obtido os valores de chave básico valores de qual é o seu nome 00:16:53.520 --> 00:16:58.790 o que é o nome da fila, o nome de espaço Dê-me sua regra de SaaS, o 00:16:58.840 --> 00:17:02.140 autorização de assinatura de acesso compartilhado, Isso é o que está usando 00:17:02.190 --> 00:17:03.800 Assim como a chave de SaaS. 00:17:04.950 --> 00:17:07.970 E com base no que ele pode enviar uma mensagem. 00:17:14.280 --> 00:17:18.140 Mensagem enviada com êxito. Isso ele. Para que você possa ver se você 00:17:18.190 --> 00:17:21.380 ter muitos e muitos clientes de navegador ou qualquer outro cliente ou 00:17:21.430 --> 00:17:25.940 dispositivo que pode ser feito apenas HTTP puro, Não há nenhum SOAP aqui. Não há nenhum... 00:17:26.900 --> 00:17:31.300 qualquer codificação. Você pode colocar a mensagem propriedades em JSON e, em seguida, 00:17:31.350 --> 00:17:35.930 uma maneira muito simples obter mensagens na fila. Deixe-me mostrar 00:17:35.980 --> 00:17:38.170 Você tem o código para esse site. 00:17:47.070 --> 00:17:52.110 Aqui você pode ver se você está fazendo quaisquer propriedades avançadas 00:17:52.730 --> 00:17:55.220 ou até mesmo propriedades apenas muito, muito básicas, 00:17:58.440 --> 00:18:05.280 Você pode facilmente enviar esse código. E Na verdade, a biblioteca JavaScript 00:18:05.330 --> 00:18:09.370 que está sendo usado aqui, vamos me mostre que você também. 00:18:16.200 --> 00:18:22.410 Portanto, esta é a página da web que eu mostrei a você e você pode ver como 00:18:35.560 --> 00:18:40.400 simples realmente o envio e o receba para esta mensagem. 00:18:40.450 --> 00:18:44.840 O HTTP, a exclusão é, na verdade para o cenário de recebimento. 00:18:45.430 --> 00:18:47.500 Que veremos um pouco mais adiante. 00:18:48.120 --> 00:18:56.600 E colocar é post, cenário de envio Infelizmente, quanto ao cenário de envio. 00:18:58.510 --> 00:19:02.420 Deixe 00:19:03.620 --> 00:19:05.210 me enviar mais mensagens. 00:19:05.810 --> 00:19:09.220 E apenas para mostrar as mensagens aparecendo, aqui eu tenho Server 00:19:09.270 --> 00:19:12.280 Explorer carregar dados com... 00:19:21.330 --> 00:19:25.310 conectado ao meu espaço de nome. E eu tem uma fila simple no qual 00:19:25.360 --> 00:19:28.770 Você pode ver, agora há duas mensagens na fila. Se devo fazer um 00:19:28.820 --> 00:19:35.430 atualização, vejo 14 mensagens. Então como quando as mensagens chegam, eles 00:19:35.480 --> 00:19:37.840 será exibido nessa fila. 00:19:48.480 --> 00:19:53.620 Vamos abordar o cenário de recebimento um pouco mais recente em termos da 00:19:53.670 --> 00:19:56.920 Cliente HTTP. Essa é para cliente HTTP. 00:19:57.510 --> 00:20:02.200 Mas eu realmente queria falar especificamente sobre protocolos. 00:20:02.820 --> 00:20:06.840 Quais são as considerações que Você deve fazer ao decidir 00:20:06.890 --> 00:20:11.460 Se deseja usar HTTP ou usar o AMQP. Como você sabe que o serviço 00:20:11.510 --> 00:20:13.930 Barramento suporta vários protocolos. 00:20:15.060 --> 00:20:21.750 HTTP é apenas nosso RKDPI é AMQP um protocolo padrão que vou 00:20:21.800 --> 00:20:27.620 falar mais sobre e SBMP é nosso outro protocolo proprietário sobre .NET. 00:20:29.320 --> 00:20:35.000 Agora, cada um deles pode ter considerações de desempenho e alcançar as considerações. 00:20:35.710 --> 00:20:39.950 Portanto, se você tiver um dispositivo no qual é muito baixo com fonte de alimentação, que você pode 00:20:40.000 --> 00:20:44.810 tiver dúvidas sobre qual protocolo implementação você pode colocar 00:20:44.860 --> 00:20:49.590 no local. Se você tiver cenários onde você deseja ser fornecedor independente, 00:20:50.070 --> 00:20:54.160 Você pode ter considerações de alcance dizer com isso não vão comprar em 00:20:54.210 --> 00:20:57.830 qualquer protocolo específico ou uma API com um único fornecedor. Vou 00:20:57.880 --> 00:21:00.060 Use um padrão aberto como AMQP. 00:21:01.900 --> 00:21:04.390 Às vezes, recursos variam de acordo com o protocolo. 00:21:05.130 --> 00:21:08.000 E a parte que quero enfatizar que se perde em uma grande quantidade de 00:21:08.050 --> 00:21:11.300 pessoal é que ele é na maioria das vezes receba recursos de lado. 00:21:11.950 --> 00:21:13.290 Existem alguns lado de envio 00:21:14.560 --> 00:21:19.100 implicações, também, a maioria do é sobre o recebimento de tempo em que 00:21:19.150 --> 00:21:23.270 protocolos realmente são adiados um lote e verá por que isto é 00:21:23.320 --> 00:21:24.240 o caso. 00:21:25.950 --> 00:21:28.810 E, em seguida, em geral há alguns diferenças de cota em termos 00:21:28.860 --> 00:21:32.360 de quantas conexões você pode Crie com AMQP e SBMP. 00:21:32.410 --> 00:21:35.550 Então essas também são considerações importantes Ao pensar, Ei, 00:21:35.600 --> 00:21:38.980 protocolo que vou usar para meu grande escala grande número 00:21:39.030 --> 00:21:50.090 de remetentes? Protocolos para binário em vez de HTTP, por que tem alguma importância 00:21:50.140 --> 00:21:53.280 para mensagens? Quais são os principais Considerações para mensagens? 00:21:53.810 --> 00:21:56.350 Eu só queria destacar a chave cenários onde faz uma 00:21:56.400 --> 00:21:59.380 diferença isso e você pode escolher e decidir se é importante 00:21:59.430 --> 00:22:02.780 ou não para o seu caso específico. 00:22:04.210 --> 00:22:08.070 Caso do HTTP, sempre que você faz uma chamada de saída, você vai estar 00:22:08.120 --> 00:22:11.480 capaz de alcançar uma entidade. Para que do um ponto de extremidade seja 00:22:11.530 --> 00:22:13.850 um ponto de extremidade de envio ou um ponto de extremidade de recepção. 00:22:14.850 --> 00:22:16.820 Você pode fazer uma operação pendente. 00:22:17.560 --> 00:22:21.540 Apenas uma única chamada de enviar ou uma chamada de recebimento único. 00:22:22.370 --> 00:22:26.300 E na maioria das vezes, a operação tempo de vida não pode ser mais de 00:22:26.350 --> 00:22:30.940 60 segundos ou qualquer que seja a carga Balanceador permite que 00:22:31.480 --> 00:22:33.060 provedor que estiver em execução no. 00:22:34.490 --> 00:22:41.480 Assim que trazer para o tipo de um casos onde você deseja 00:22:41.530 --> 00:22:43.390 para se comunicar com vários pontos de extremidade. 00:22:44.040 --> 00:22:47.590 Muitas vezes em comprar direcional cenários de comunicação que você está 00:22:47.640 --> 00:22:51.230 vai ser enviar para ir a uma fila e recebimento de uma assinatura. 00:22:52.080 --> 00:22:55.730 Ou também enviar uma notificação para Hub. Todos esses tipos de 00:22:55.780 --> 00:22:57.060 cenários podem estar lá. 00:22:57.640 --> 00:23:01.320 Com um protocolo binário, você realmente pode criar uma única conexão 00:23:01.370 --> 00:23:08.270 um único atrativo, um único soquete e todos os outros links a 00:23:08.320 --> 00:23:13.320 Contexto AMQP é um multiflexed de links sobre essa ligação HTTP. 00:23:14.500 --> 00:23:18.740 Assim, você obtém muita vantagem por Não há necessidade de fazer o handshake 00:23:18.790 --> 00:23:22.680 e não há necessidade de estabelecer esse soquete e para cada camisa 00:23:22.730 --> 00:23:26.880 pagamento de entidade em vez de fazê-lo... custo uma vez e, em seguida, reutilização 00:23:26.930 --> 00:23:29.460 que quando você está falando para várias entidades. 00:23:30.290 --> 00:23:33.900 Lembre-se desse cenário. Às vezes Quando você escreve gateways de campo 00:23:33.950 --> 00:23:37.240 ou gateways personalizados onde você está voltadas para muitos dispositivos, isso 00:23:37.290 --> 00:23:40.690 será muito importante. 00:23:43.280 --> 00:23:48.250 A outra parte é longa puxando. Portanto, há essa coisa constante 00:23:48.300 --> 00:23:51.400 sobre puxando filas, direitos, de Ei, eu tenho uma mensagem? 00:23:51.450 --> 00:23:55.160 Eu tenho uma mensagem? Eu tenho uma mensagem? Aqui porque é 00:23:55.210 --> 00:24:01.040 uma conexão com o protocolo AMQP podemos manter a conexão ativa. 00:24:01.090 --> 00:24:04.370 Você não precisa fazer qualquer operação Além de ter um pendente 00:24:04.420 --> 00:24:09.120 receber que pode ser definida para um tempo limite infinito. Você poderia 00:24:09.170 --> 00:24:12.110 liquidá-lo para um dia, uma semana. Em geral Você não liquidará-lo 00:24:12.160 --> 00:24:16.090 para o infinito. Você definirá por qualquer outro as características de desligamento 00:24:16.140 --> 00:24:19.560 aparência, talvez 20 minutos ou algo parecido com o que. Mas você 00:24:19.610 --> 00:24:24.920 pode ter uma longa recepção pendente de recebimento e não precisa se preocupar sobre 00:24:24.970 --> 00:24:27.640 Processando ciclos de CPU e coisas do 00:24:29.370 --> 00:24:33.080 Obtendo com isso. Manteremos a conexão através de funcionamento 00:24:33.130 --> 00:24:37.040 pings ou qualquer que seja o balanceador de carga é necessário e forneceremos 00:24:37.090 --> 00:24:41.640 você a resposta de baixa latência sempre que uma mensagem é mostrada. 00:24:42.360 --> 00:24:45.820 Portanto, isso se torna muito importante outro consideração em termos 00:24:45.870 --> 00:24:50.380 de custo, bem como o impacto no o dispositivo. Protocolos para binário 00:24:50.430 --> 00:24:53.310 fazer a diferença em termos de dos cenários. 00:24:56.240 --> 00:24:59.820 A outra consideração da qual protocolos traz no são SDKs. 00:24:59.870 --> 00:25:03.520 Você deseja se tornar produtivos. Você deseja Para usar o núcleo sólido. Você deseja 00:25:03.570 --> 00:25:08.220 Use bibliotecas sólidas. Então você realmente para poder escolher 00:25:08.270 --> 00:25:11.010 o protocolo certo com o SDK certo. 00:25:12.880 --> 00:25:13.950 Isso para o barramento de serviço 00:25:15.670 --> 00:25:19.750 Se você estiver usando o .NET e, em seguida, nosso padrão Protocolo SBMP é o padrão. 00:25:19.800 --> 00:25:24.130 Isso é o que é usado. Você pode alternar para AMQP a qualquer momento e 00:25:24.180 --> 00:25:25.170 Isso também é ótimo. 00:25:25.850 --> 00:25:28.980 Há algumas defesas em destaque neste momento, mas podemos está fechando 00:25:29.030 --> 00:25:33.730 essa lacuna muito em breve. Mas se você estiver usando .NET, em seguida, SBMP é 00:25:33.780 --> 00:25:36.010 classificação de seu padrão cenário hoje. 00:25:37.560 --> 00:25:42.400 Se você estiver usando HTTP, se do caso, temos wrappers HTTP em um lote 00:25:42.450 --> 00:25:46.160 de sistemas operacionais disponíveis e muitas bibliotecas disponíveis. 00:25:47.010 --> 00:25:50.510 E, em seguida, com AMQP você estiver iniciando Para ver uma grande parte da comunidade 00:25:50.560 --> 00:25:51.700 bibliotecas de surgirem. 00:25:52.940 --> 00:25:59.670 Foi AMQP sendo um padrão aberto tudo projetado e desenvolvido com 00:26:00.690 --> 00:26:05.690 tendo em mente, eficiente, confiável, são portáteis classificação de dados 00:26:05.740 --> 00:26:10.310 representação e flexibilidade em mente. Flexibilidade em termos de 00:26:10.360 --> 00:26:13.470 Se ele é para o cliente bibliotecas ou cliente ao broker 00:26:13.520 --> 00:26:15.120 ou quebrou quebrou bibliotecas. 00:26:16.680 --> 00:26:20.260 Então você está começando a ver com o AMQP padronização futuras... 00:26:20.310 --> 00:26:26.370 a propósito, AMQP foi OASIS padrão última Outubro. Ele limpas apenas ISO/IEC. 00:26:27.560 --> 00:26:32.950 Portanto, agora é um internacional reconhecido padrão, muito. Para que do 00:26:33.210 --> 00:26:35.180 nova operação de pressionar. 00:26:36.990 --> 00:26:41.560 Mas o que isso significa para você é que você irá ver um monte de bibliotecas 00:26:42.230 --> 00:26:47.750 desenvolvido pela biblioteca Apache Qpid conjunto ou a biblioteca de massa do próton 00:26:47.800 --> 00:26:51.010 clientes em vários idiomas diferentes. 00:26:51.890 --> 00:26:55.240 C, Java, há uma implementação de JMS. 00:26:56.110 --> 00:27:00.670 Do PHP. Tudo isso estará disponível para você com a comunidade 00:27:00.720 --> 00:27:05.970 biblioteca de origem suporte aberto para uso e desenvolvimento e contribuintes 00:27:06.020 --> 00:27:06.740 para e 00:27:07.970 --> 00:27:12.310 com o serviço mais ou com qualquer outro provedor que oferece suporte a 00:27:12.360 --> 00:27:14.070 Portal AMQP lá. 00:27:14.820 --> 00:27:18.400 Portanto, se você estiver tentando acessar o barramento de serviço Você pode ver os protocolos diferentes. 00:27:18.450 --> 00:27:22.940 Você tem muita escolha do que SDKs que você usa e quais bibliotecas 00:27:22.990 --> 00:27:34.850 Você usa e você não precisa ser limite de qualquer maneira específica. 00:27:34.900 --> 00:27:36.150 Sincronização, assíncrona, em vez de lote. 00:27:37.150 --> 00:27:40.650 Agora que sabemos quais são as nuances de protocolo, acho que 00:27:40.700 --> 00:27:45.840 Vamos falar sobre quando deve podemos escrever um código de sincronização, assíncrono 00:27:45.890 --> 00:27:49.170 código e o código do lote e quais são as diferenças reais em termos 00:27:49.220 --> 00:27:54.100 de desempenho que você pode ver Nesses cenários diferentes. 00:27:55.890 --> 00:27:58.710 Processamento em lotes claramente aumenta o throughput. 00:27:59.460 --> 00:28:04.620 Sempre é uma prática muito boa em termos de se ele tem 00:28:04.670 --> 00:28:09.260 no lado da recepção ou até mesmo em o lado de envio para usar o processamento em lotes. 00:28:09.310 --> 00:28:13.190 A preocupação apenas negativa para pessoal às vezes, com isso é a latência 00:28:13.240 --> 00:28:17.490 e veremos como isso pode ser afetados mas não muito. 00:28:17.540 --> 00:28:18.880 Falaremos sobre isso. 00:28:21.250 --> 00:28:24.830 Assíncrono em geral é sempre o prática recomendada. Sempre 00:28:24.880 --> 00:28:28.620 para usá-la sempre que possível. Exceto Se você quiser vinculado 00:28:28.670 --> 00:28:31.760 o número de chamadas opostas. Você simplesmente não querem ter um forte 00:28:31.810 --> 00:28:34.720 loop que faz com que um número infinito de chamadas e veremos como 00:28:34.770 --> 00:28:37.660 Barramento de serviço ajuda com esse cenário. 00:28:40.160 --> 00:28:44.110 E, em seguida, finalmente vemos o binário protocolos significativamente mais altos 00:28:44.160 --> 00:28:47.980 taxa de transferência seja capaz de alcançar só porque esses protocolos, 00:28:48.030 --> 00:28:54.290 o protocolo AMQP foi desenvolvido com eficiência em mente, com 00:28:55.260 --> 00:28:58.750 o controle de fluxo e tudo criado na camada de protocolo 00:28:58.800 --> 00:29:03.950 Se você ver muita vantagem aparecendo. Deixe-me realmente 00:29:04.000 --> 00:29:08.550 mostra alguns números. Alguns executando números para que possa comparar 00:29:08.600 --> 00:29:10.090 Isso por conta própria. 00:29:20.030 --> 00:29:24.820 Assim, aqui eu tenho um código que é vou tentar enviar mensagens. 00:29:26.190 --> 00:29:28.970 E você pode ver que você dividiu o backup em três partes. 00:29:29.850 --> 00:29:32.930 Primeiro é fazer o envio de sincronização. 00:29:33.690 --> 00:29:38.660 Estas são as principais linhas. Para cada um mensagens, fazer uma qClient e enviar 00:29:38.710 --> 00:29:44.060 desativar a mensagem. Esta é uma sincronização muito Chame. Pesos para uma conclusão. 00:29:44.110 --> 00:29:48.030 Ele espera por uma confirmação no futuro volta do servidor, atingir 00:29:48.080 --> 00:29:51.200 volta do cliente, uma completa loop e, em seguida, prossegue. 00:29:52.910 --> 00:29:56.650 O outro faz de maneira assíncrona. 00:29:57.900 --> 00:30:02.780 Onde ele está criando essencialmente Tarefas assíncronas para todos esses 00:30:03.350 --> 00:30:04.470 operações de envio. 00:30:05.700 --> 00:30:09.150 E então aguardar para todos as tarefas a serem concluídas. 00:30:11.410 --> 00:30:15.170 E, finalmente, há um lote Enviar e posso chamá-lo encomendada 00:30:15.220 --> 00:30:19.430 envio de lote porque com Async, geralmente as pessoas são fornecidos com 00:30:19.480 --> 00:30:22.840 um cenário onde eles dizem, Ei, com Assíncrono, perco ordem. Eu não 00:30:22.890 --> 00:30:25.800 saber o que acontecerá primeiro, qual deles acontecerá em seguida. 00:30:26.300 --> 00:30:29.430 E é por isso que existe o envio em lote qual é o tipo de superior 00:30:29.480 --> 00:30:32.300 em ambos os casos porque preserva todos os a... o todo o 00:30:32.350 --> 00:30:35.920 lote vem por meio ou todo o lote de volta e você 00:30:35.970 --> 00:30:38.910 Consulte quanto o desempenho após Isso pode ter de impacto. 00:30:40.310 --> 00:30:45.300 Então eu tenho todos eles apontando para um simples na fila de exemplo de mensagem. 00:30:45.350 --> 00:30:47.900 Você pode ver agora a Contagem de fila é zero. 00:30:48.910 --> 00:30:52.560 E defini meu número de mensagens para um pequeno número de 100. 00:30:53.660 --> 00:30:54.780 Vamos executá-lo. 00:30:57.310 --> 00:30:59.530 E até que ponto chegamos. 00:31:00.250 --> 00:31:04.670 Primeiro ele está fazendo enviar usando sincronização. Fazer isso de forma síncrona 00:31:04.720 --> 00:31:09.020 100 telefonemas do meu laptop todos os como o serviço e vice-versa. 00:31:09.550 --> 00:31:13.970 Levou cerca de dez segundos em termos isso. E apenas para mostrar a você, 00:31:14.020 --> 00:31:18.360 Estamos sempre pode voltar, verificar a contagem de mensagens e ele deve 00:31:18.410 --> 00:31:21.860 ser 100. Todas as cem mensagens tornaram aqui. 00:31:23.160 --> 00:31:26.940 Agora vamos ver o que acontece quando Posso fazer a mesma coisa com Async. 00:31:29.190 --> 00:31:30.590 Mesma coisa com Async. 00:31:31.940 --> 00:31:36.120 E não há diferença em termos de as mensagens porque 00:31:37.540 --> 00:31:40.460 as mensagens todo fizeram dela aqui. Agora é 200 mensagens. 00:31:41.250 --> 00:31:46.450 Levou.3 segundos. Para todos os mensagens para chegar lá. 00:31:50.260 --> 00:31:52.620 Em lotes, é ainda mais rápida. 00:31:53.370 --> 00:31:54.990 É, na verdade, ainda mais rápido. 00:31:56.080 --> 00:31:58.880 E a razão novamente, é porque embaixo da tampa, barramento de serviço 00:31:58.930 --> 00:32:04.440 está usando um protocolo binário quando for Você nos mensagens de forma assíncrona, 00:32:04.490 --> 00:32:09.600 Estamos tabela divida-os juntos e enviá-las com lotes implícita. 00:32:10.260 --> 00:32:13.630 Você pode definir esse valor. O intervalo de limpeza em lote, que você 00:32:13.680 --> 00:32:17.710 definir em uma fábrica de mensagens, permite você definir essa janela. 00:32:18.310 --> 00:32:21.010 Você pode defini-la em uma janela maior. Você verá mais a latência, 00:32:21.060 --> 00:32:23.690 mas você verá muito mais melhor taxa de transferência de ponta a ponta. Você pode 00:32:23.740 --> 00:32:27.310 defini-la como uma janela muito menor e você verá que a latência melhor 00:32:27.360 --> 00:32:32.110 e talvez um pouco de menor produtividade. Mas você pode ver o 00:32:32.160 --> 00:32:36.660 magnitude da diferença aqui ele faz em termos de sincronização 00:32:36.710 --> 00:32:38.410 em vez de assíncrona em vez de lote. 00:32:45.080 --> 00:32:49.310 Vamos ver rapidamente, agora que aqui, temos nossas 300 mensagens 00:32:49.360 --> 00:32:51.110 o que podemos fazer no lado da recepção? 00:33:02.730 --> 00:33:06.700 No recebimento, observe aqui que não estou usando a mensagem em APIs. 00:33:08.710 --> 00:33:12.460 Isso é apenas para mostrar a você um maçãs a comparação de maçãs do que 00:33:12.510 --> 00:33:15.560 a sincronização de APIs aparência e, em seguida, vou mostrar como o 00:33:15.610 --> 00:33:18.370 na mensagem API faz tudo Isso para você. 00:33:20.100 --> 00:33:23.620 Esta é uma sincronização receber. 00:33:24.300 --> 00:33:28.740 Portanto, eu tenho claramente duas chamadas sendo com o servidor fizer isto 00:33:28.790 --> 00:33:33.600 é em termos de processamento de mensagens. Nunca, nunca perderá 00:33:33.650 --> 00:33:38.280 uma mensagem no meio físico ou em trânsito porque até que não 00:33:38.330 --> 00:33:41.950 Concluir, enviaremos Faça a mesma mensagem. 00:33:43.810 --> 00:33:48.260 O próximo é assíncrona e aqui você pode ver o que estou fazendo 00:33:49.430 --> 00:33:56.230 é uma tarefa com um continue com a em seguida, chame o completo em lá. 00:34:01.730 --> 00:34:05.290 E, novamente, aguardará para todos os entalhada tarefas a serem concluídas 00:34:05.340 --> 00:34:07.770 antes de chamar o cronômetro feito. 00:34:09.300 --> 00:34:10.660 E, finalmente, há em lotes. 00:34:11.330 --> 00:34:12.950 Lote é um pouco mais interessante. 00:34:13.890 --> 00:34:19.030 Aqui, é ainda mais fácil porque eu lote de recebimento, observe uma passagem 00:34:19.080 --> 00:34:21.370 um número de mensagem é que é 100. 00:34:22.040 --> 00:34:24.860 Agora, depois de você chamar receber em lotes com centenas não significa que podemos 00:34:24.910 --> 00:34:28.830 Você terá uma centena de mensagens parte de trás. Ele faremos tudo o que 00:34:28.880 --> 00:34:32.660 é a mais ideal para a transmissão com base ao competir sendo consumidor, 00:34:32.710 --> 00:34:35.970 com base em quantos outros nós ter puxando a mensagem para ver 00:34:36.020 --> 00:34:38.800 criar um lote ideal e enviar essa. 00:34:39.610 --> 00:34:43.320 E é por isso que você ver que tenho um loop externo que mantém chamar 00:34:43.370 --> 00:34:47.620 receber lote até que eu não alcançar Minhas centenas mensagens. Eu quero 00:34:47.670 --> 00:34:51.430 Para fazer esse cálculo lote até Eu alcançar uma centena de mensagens. 00:34:53.920 --> 00:34:59.030 E no caso, eu vou apenas manter seu token bloqueado. 00:34:59.080 --> 00:35:01.160 Isso é tudo o que estou fazendo na mensagem. De que eu não tenho que manter 00:35:01.210 --> 00:35:04.440 toda a mensagem. Depois que eu tenha consumido a mensagem ter processado 00:35:04.490 --> 00:35:07.710 ele, sendo apenas terei de manter o token de bloqueio e, em seguida, chamada 00:35:07.760 --> 00:35:12.940 o lote completo assíncrono com todos os tokens bloqueados lá. 00:35:14.060 --> 00:35:16.940 E estou fazendo isso em uma base de lote então, novamente, eu não estou aguardando 00:35:16.990 --> 00:35:19.490 todo o caminho de gaveta a extremidade concluir todas as mensagens? 00:35:19.500 --> 00:35:21.500 [Indiscernible] 00:35:21.660 --> 00:35:22.750 ... .subset lá? 00:35:23.510 --> 00:35:24.840 >> Desculpe, qual era a pergunta? 00:35:24.890 --> 00:35:28.400 >> Se você pode processar alguns deles mensagens, você pode concluir 00:35:28.450 --> 00:35:30.520 Esse teste, conduzir um subconjunto? 00:35:30.860 --> 00:35:34.510 >> Absolutamente. Claro que Sim. Portanto, faça lote assíncrono. 00:35:35.250 --> 00:35:39.040 Você pode chamar com um único tokens bloqueado dois bloqueados tokens, qualquer 00:35:39.090 --> 00:35:42.720 o conjunto é. É assim que ele irá Enviar todos esses tokens bloqueados 00:35:42.770 --> 00:35:46.250 em um lote e get é fazer o resultados em um lote. Por isso, ele tem 00:35:46.300 --> 00:35:50.010 economizando que a latência e que ida e volta para fazer tudo isso 00:35:50.060 --> 00:35:52.540 e tornando-a muito eficiente. 00:35:54.300 --> 00:35:56.070 Portanto, vamos ver o que adiciona até. 00:35:58.400 --> 00:36:03.230 Assim, aqui eu tenho o mesmo caso. Eu sou primeiro vamos para usar sincronização e 00:36:03.280 --> 00:36:07.440 Tente receber todas as centenas... as mensagens primeiro centenas 00:36:07.490 --> 00:36:11.190 lá. Agora observe que esta será pior desempenho de enviar porque 00:36:11.240 --> 00:36:14.080 ele está fazendo o dobro do número de operações Portanto, eu quero receber 00:36:14.130 --> 00:36:16.460 todas as mensagens, conclua todas as mensagens. Receber todas as mensagens 00:36:16.510 --> 00:36:20.110 Conclua todas as mensagens. E vá. Então 18 segundos. 00:36:20.160 --> 00:36:24.220 Em vez do dez envia nós testemunhou para enviar, leva 18 segundos 00:36:24.270 --> 00:36:28.760 a essas mensagens e completa -los. Isso definitivamente não satisfatório. 00:36:30.090 --> 00:36:35.330 Com Async porque você está fazendo uma série eles em paralelo, agora você precisa para baixo 00:36:35.380 --> 00:36:38.880 sobre os 2,8 segundos. Agora, Esses números são apenas... 00:36:39.410 --> 00:36:43.230 leve-as com cuidado, executando em uma rede aqui, são 00:36:43.940 --> 00:36:47.470 mas você pode ver apenas a magnitude de diferença. Você pode ver 00:36:47.520 --> 00:36:49.620 quanto um aperfeiçoamento que ele faz. 00:36:50.830 --> 00:36:52.580 E agora vamos ver o que como acontece com o lote. 00:36:55.730 --> 00:37:00.720 Nós voltamos. Podemos fazer o mesmo quase características como 00:37:00.770 --> 00:37:04.590 0,1 segundo para todos os de cem operações que haviam levado... 00:37:05.410 --> 00:37:07.930 só porque estamos usando lote de lá. 00:37:11.380 --> 00:37:16.640 Agora, não somente você ver todos esses vantagens em aqui, mas o serviço 00:37:16.690 --> 00:37:21.680 Barramento realmente facilita muito, muito para você escreva esse código específico. 00:37:21.730 --> 00:37:26.700 O código que mostrei não é muito complexo, mas você realmente executada 00:37:26.750 --> 00:37:29.280 -um passo adiante e nós tornou ainda mais fácil. 00:37:30.200 --> 00:37:33.470 Portanto para o... a propósito, eu apenas queria mostrar aqui sobre o 00:37:33.520 --> 00:37:37.280 mensagens que você vir essas 300 mensagens lá, se ele atualizar, ele 00:37:37.330 --> 00:37:41.920 deve voltar para zero indicando Não estou mentindo. Todos esses 300 00:37:41.970 --> 00:37:43.380 as mensagens foram processadas. 00:37:47.270 --> 00:37:54.910 OK. Portanto, vamos examinar a mensagem em APIs, mas os juros 00:37:54.960 --> 00:37:57.880 de tempo, vou velocidade para cima um pouquinho aqui. 00:38:00.480 --> 00:38:04.820 Portanto, você viu a diferença entre sincronização e assíncrono em lotes, e 00:38:04.870 --> 00:38:10.330 Espero que [Indiscernible] sempre usar processamento em lotes. A próxima coisa sobre a taxa de transferência. 00:38:10.380 --> 00:38:14.100 Filas particionadas e tópicos. Então, lançamos 2.2 SDK. 00:38:15.680 --> 00:38:19.590 Particionar filas e tópicos essencialmente Se uma fila e partição 00:38:19.640 --> 00:38:21.830 ele em vários nós de processamento. 00:38:23.240 --> 00:38:26.950 Isso não só proporciona muito mais alimentação de throughput em termos de 00:38:27.000 --> 00:38:31.900 sendo capaz de processar mais mensagens, mas Ele oferece mais capacidade de armazenamento. 00:38:32.410 --> 00:38:35.820 Oferece a capacidade de ter filas muito maiores. Ele oferece 00:38:35.870 --> 00:38:38.170 Você tem a capacidade de ser mais resilientes. 00:38:39.270 --> 00:38:42.290 Se não estiver disponível, uma partição continuar a outra partição 00:38:42.340 --> 00:38:43.580 para processar mensagens. 00:38:44.640 --> 00:38:49.270 Para particionar filas por e por muito para a maioria dos cenários lhe dará 00:38:49.320 --> 00:38:52.990 é uma taxa de transferência, muito melhor disponibilidade e resistência 00:38:53.040 --> 00:38:58.570 Consulte característica. Caixa. É muito fácil criar e 00:38:58.620 --> 00:39:02.700 usar filas de partição é apenas a recomendação para 00:39:02.750 --> 00:39:06.470 sempre usá-los. Use apenas sempre Esses. Na verdade, nos próximos 00:39:06.520 --> 00:39:11.000 Versão do SDK, estamos no caminho certo para fazer ele o padrão que, por padrão, 00:39:11.050 --> 00:39:13.380 Quando você cria uma fila será Obtenha uma fila particionada. 00:39:15.690 --> 00:39:20.650 Agora, você precisa estar ciente o que acontece quando você executa 00:39:20.700 --> 00:39:22.590 uma fila e você particioná-lo em. 00:39:24.060 --> 00:39:26.530 Se você não estiver usando sessões, ela será falamos muito sobre sessões 00:39:26.580 --> 00:39:30.340 em detalhes, mas se você não estiver usando sessões e essencialmente, 00:39:31.060 --> 00:39:33.050 Você tem que ser... 00:39:34.220 --> 00:39:38.380 Você precisa estar ciente de que as suas mensagens pode aparecer fora de ordem 00:39:38.430 --> 00:39:41.830 agora porque essencialmente podem Vá em diversas partições 00:39:41.880 --> 00:39:46.770 e se não estiver disponível, uma partição em seguida, a mensagem será exibida 00:39:46.820 --> 00:39:47.720 fora de ordem. 00:39:48.460 --> 00:39:51.270 Essa é uma coisa estar atento mas se você estiver usando sessões 00:39:51.320 --> 00:39:54.720 qual falaremos sobre agora, em seguida, todos os seu pedida semântica 00:39:54.770 --> 00:39:56.100 completamente são preservados. 00:39:57.120 --> 00:40:02.330 E veremos como. Para mostrar apenas o código aqui, sempre que você estiver 00:40:02.380 --> 00:40:05.590 Criando uma fila há um único propriedade EnablePartitioning. 00:40:05.640 --> 00:40:08.720 Hoje, ela é definida como false por padrão. Como eu disse nos próximos 00:40:08.770 --> 00:40:10.040 SDK será true. 00:40:10.780 --> 00:40:13.750 Portanto, você deve apenas definir que. Por a maneira que eu não sei como você 00:40:13.800 --> 00:40:18.770 pessoas geralmente fazer mas minha filosofia em geral é nunca cópia 00:40:18.820 --> 00:40:20.730 código que você vê no PowerPoint. 00:40:21.330 --> 00:40:24.470 Não sei se isso funciona para vocês. Nunca, nunca copiar 00:40:24.520 --> 00:40:28.150 código que você vê no PowerPoint porque seja o mais simples 00:40:28.590 --> 00:40:32.710 e basic tipo de código que qualquer pessoa pode colocar lá fora. Neste 00:40:32.760 --> 00:40:35.500 caso que isso não tem problema. Você está definindo apenas uma propriedade, são, portanto, tudo bem. 00:40:35.550 --> 00:40:38.540 Mas se já mostrei que código no PowerPoint, não copie. 00:40:40.650 --> 00:40:46.660 Taxa de transferência de conexão assim. Falamos sobre remetentes. Já vimos 00:40:46.710 --> 00:40:50.290 como conexões binários são realmente, realmente importantes. Existem 00:40:50.340 --> 00:40:55.090 alguns casos em que você pode estar enviando usando um pipe muito fat. 00:40:55.660 --> 00:40:58.340 Pense nisso como o back-end para que estamos tentando em mensagens da fila. 00:40:58.390 --> 00:41:03.370 Você tem acesso a uma infinidade de registros que você deseja para envio up e coisas como essas. 00:41:04.400 --> 00:41:08.450 Bem, em algum momento, criando mais as conexões TCP físicas pode 00:41:08.500 --> 00:41:12.630 Na verdade, ser uma boa idéia e você pode facilmente fazer isso. Cada mensagens 00:41:12.680 --> 00:41:16.220 na instância da fábrica para uma classe instância da fábrica de mensagens 00:41:16.270 --> 00:41:18.390 corresponde a uma conexão de PCP. 00:41:19.390 --> 00:41:22.550 Mais assim o número de clientes de fila e o que você está criando 00:41:22.600 --> 00:41:25.680 desativar a mesma fábrica como mostrei Você está multiplexação todos 00:41:25.730 --> 00:41:31.430 as conexões com o mesmo soquete TCP. Portanto, crie mais fábricas de mensagens. 00:41:31.480 --> 00:41:33.700 E se você criar mais de mensagens fábricas, você conseguirá mais 00:41:33.750 --> 00:41:38.720 pipes e mais dados podem ser enviados por meio de modo que uma consideração importante 00:41:38.770 --> 00:41:42.540 Para fazer isso. Resiliência de nível de conexão baseia-se. Dessa maneira, após 00:41:42.590 --> 00:41:46.140 criar uma fábrica de mensagens, você nunca é necessário descartá-lo. 00:41:46.190 --> 00:41:49.320 Se a conexão for interrompida, ela será reconstruí-lo. Se o vínculo for quebrado 00:41:49.370 --> 00:41:52.740 a uma fila, podemos poderá reconstruí-lo. Tudo o que é que será reconstruído 00:41:52.790 --> 00:41:54.860 em termos de assim que você nunca precisa fazer isso... 00:41:55.370 --> 00:41:58.030 preciso descartar este objeto e recriar esse objeto. 00:41:58.310 --> 00:42:02.780 Basta criar mais deles e reutilizar Para tanto quanto necessário. 00:42:05.910 --> 00:42:07.540 Portanto, isso nos traz a sessões. 00:42:08.520 --> 00:42:11.670 Como estou pedindo que você tirar todos esses remetentes grande número 00:42:11.720 --> 00:42:14.910 de remetentes e multiplexar todos eles em um número muito pequeno 00:42:14.960 --> 00:42:17.850 de filas, como você vai para processar, na verdade, isso? 00:42:17.900 --> 00:42:21.110 Já vimos tipo Orleans do framework e coisas, que são todos os 00:42:21.160 --> 00:42:23.460 tentando demultiplex o fluxo 00:42:24.720 --> 00:42:26.530 demultiplex o fluxo. 00:42:28.490 --> 00:42:33.070 Sessões são um excelente incorporada recurso do serviço de barramento que 00:42:33.120 --> 00:42:37.130 Essencialmente, ela cria as subfilas. Para cada sessão que você pode considerar 00:42:37.180 --> 00:42:40.290 de como uma subfila quando uma fila cheia. 00:42:41.480 --> 00:42:44.860 E a natureza original apenas tem de definir a ID de sessão. 00:42:44.910 --> 00:42:46.840 Essa é a única propriedade um eles precisam definir. 00:42:48.090 --> 00:42:51.240 É o receptor onde o paradigma realmente alterada. 00:42:52.050 --> 00:42:56.090 O receptor agora não passa mais e diz Ei, dê-me a próxima mensagem. 00:42:56.140 --> 00:42:59.670 Diz que o receptor envie-me na próxima sessão. Dê-me na próxima 00:42:59.720 --> 00:43:02.690 subfila que tem algumas mensagens e vou pesquisar processá-los em 00:43:02.740 --> 00:43:06.760 ordem, entrarei processá-los com algum estado que eu poderia armazenar 00:43:06.810 --> 00:43:10.600 para que o receptor. Portanto, se você acha que sobre milhões de dispositivos, 00:43:10.650 --> 00:43:13.290 Agora imagine que em um único fila, você pode ter todos esses 00:43:13.340 --> 00:43:18.620 milhões de subfilas e armazenamento estado por subfila. Então muito, 00:43:18.670 --> 00:43:20.410 muito eficiente nesse sentido. 00:43:21.050 --> 00:43:24.400 Você pode fazer trabalho conjunto de fixação do conjunto de trabalho. Que significa que você pode dizer 00:43:24.450 --> 00:43:29.230 receptor de um, desejo localizar dispositivos de 1 a 100. Portanto ele 00:43:29.280 --> 00:43:32.810 será ir e pedir sessões 1 a 100 e será fixado 00:43:32.860 --> 00:43:33.440 Para isso. 00:43:35.000 --> 00:43:39.680 E, em seguida, obviamente você pode armazenar estado. Portanto, vou mostrar o 00:43:39.730 --> 00:43:43.490 código para isso. Essencialmente, você executa a sessão xigir verdadeiro quando 00:43:43.540 --> 00:43:45.270 Você está criando a fila. 00:43:45.790 --> 00:43:49.670 No lado de envio, você só precisa definir uma propriedade, a identificação de sessão. 00:43:50.530 --> 00:43:55.720 E receber ao lado, todos os Aplicar do mesmo tipo de parâmetros 00:43:55.770 --> 00:43:59.840 como lhes mostrei, a mensagem de aceitação sessão, você pode aceitar 00:43:59.890 --> 00:44:03.730 sessão com um ID de mensagem ou agora o que lançamos há pouco tempo 00:44:03.780 --> 00:44:08.760 é uma maneira muito simples ser capaz de fazer 00:44:11.810 --> 00:44:13.010 receptores de sessão. 00:44:14.920 --> 00:44:18.080 Portanto, abrirei um remetente de sessão. 00:44:18.970 --> 00:44:21.810 Nós já tenha percebido esse processamento em lotes é a melhor maneira de enviar 00:44:21.860 --> 00:44:25.740 para que todos os o remetente está fazendo isso para cada sessão de identificação será 00:44:25.790 --> 00:44:30.240 para enviar todas as mensagens como o ID da sessão mais um. Portanto, se ele tem 00:44:30.290 --> 00:44:33.480 ID da sessão, vou enviar duas mensagens. Caso se trate de sessão 00:44:33.530 --> 00:44:36.070 IDENTIFICAÇÃO de dois, vou enviar três mensagens e assim por diante. 00:44:37.350 --> 00:44:38.920 Portanto, vou apenas começar o remetente. 00:44:39.880 --> 00:44:43.910 E aqui, se você examinar esta fila no exemplo de fila de mensagem 00:44:44.580 --> 00:44:49.140 Quando criei essa fila, o apenas uma propriedade extra defini 00:44:49.190 --> 00:44:55.090 Por isso, ele foi o requerem propriedade de sessão. Essa era a única diferença. 00:44:55.670 --> 00:44:59.940 Agora quando você vai nesse determinado fila e você tem de ver 00:44:59.990 --> 00:45:02.440 propriedades, você poderá 00:45:08.230 --> 00:45:09.410 Veja que... 00:45:11.710 --> 00:45:16.480 requer a propriedade session FALSO. Não é bom. 00:45:16.530 --> 00:45:20.780 OK. Deixe-me a excluir essa fila depois. 00:45:24.670 --> 00:45:34.390 Crie amostra de sessão de mensagem. 00:45:37.280 --> 00:45:38.780 Exigem a sessão. 00:45:45.040 --> 00:45:47.020 Vai para ler sobre o remetente. 00:45:51.490 --> 00:45:53.840 Portanto, isso irá iniciar o envio de mensagens. 00:46:09.430 --> 00:46:18.880 Acho que ele não está localizando que nome da fila agora. 00:46:18.890 --> 00:46:20.800 [Indiscernible] 00:46:20.870 --> 00:46:27.580 >> Ah, que eu? Em sessões de mensagens... Ah, início. 00:46:29.640 --> 00:46:36.750 Perfeito. Deixe-me mudar isso como no exemplo de sessão de mensagem. 00:46:39.450 --> 00:46:40.630 Muito obrigado. 00:46:42.100 --> 00:46:43.360 Agora vamos executar este membro da equipe. 00:46:46.770 --> 00:46:49.710 Início. Disse o envio de todos os mensagens. Agora deixe-me mostrar 00:46:49.760 --> 00:46:54.350 é o que o código de recebimento se parece com isso. 00:46:55.510 --> 00:46:59.710 Esta é a nova API que Lançamos há pouco tempo, no 00:46:59.760 --> 00:47:02.010 API de processamento de mensagem. 00:47:03.430 --> 00:47:07.500 Isso na sua função de trabalho do Azure Vamos alterar isso também. 00:47:10.890 --> 00:47:14.690 Na sua função de trabalho do Azure, sobre o no método start você faria 00:47:14.740 --> 00:47:19.540 a mesma, apenas verificar se a fila existe e crie o qClient. 00:47:20.250 --> 00:47:24.120 Na regra de execução, você observa o o código obtém ainda mais simples. 00:47:25.610 --> 00:47:29.270 Tudo o que você está fazendo é isso um registro chamada. 00:47:29.900 --> 00:47:32.770 Quer dizer que registrar um manipulador de sessão. 00:47:33.670 --> 00:47:36.500 E isso é tudo. Nenhum deceive executa um loop para gravar. 00:47:37.120 --> 00:47:38.950 Nenhum tempo de vida para gerenciar. 00:47:39.580 --> 00:47:43.920 Tudo isso é tratado por a biblioteca cliente para você. 00:47:43.970 --> 00:47:48.540 Você só precisa encapsular todos a lógica de como vai 00:47:48.590 --> 00:47:53.790 para processar esse único fluxo em um classe chamada do meu gerenciador de sessão. 00:47:54.700 --> 00:47:57.450 Vamos examinar essa classe e veja o que estou fazendo aqui. 00:47:58.700 --> 00:48:02.660 A primeira coisa é o que eu faço quando Na verdade, recebo a mensagem? 00:48:05.430 --> 00:48:09.430 Na mensagem, estou imprimindo-out apenas que recebi a mensagem e 00:48:09.480 --> 00:48:10.870 Estou aumentando a minha contagem. 00:48:11.610 --> 00:48:15.320 Isso é tudo o que estou fazendo nessa classe. Contagem é um membro particular 00:48:15.370 --> 00:48:19.860 aqui e estamos economizando apenas esse valor. 00:48:21.090 --> 00:48:22.960 Portanto, definimos contagem 00:48:24.710 --> 00:48:28.550 igual a zero e apenas manter uma contagem Isso é todo o meu processamento é. 00:48:29.270 --> 00:48:34.550 Em uma sessão fechada, fechou a sessão é chamado quando há nenhum 00:48:34.600 --> 00:48:38.750 mais mensagens disponíveis para que sessão ou você chegou 00:48:38.800 --> 00:48:42.360 a contagem máxima de moeda. Falamos sobre quantas simultaneamente 00:48:42.410 --> 00:48:43.630 você deseja ter. 00:48:44.260 --> 00:48:48.230 Portanto, se você atingiu o máximo Contagem de simultaneidade de quantos 00:48:48.280 --> 00:48:53.040 sessões para processar, chamaremos Fechar sessão e abrir 00:48:53.090 --> 00:48:57.610 uma nova sessão, dependendo de quais mensagens estão disponíveis. Para fechar 00:48:57.660 --> 00:49:00.700 a oportunidade para dizer que tenho chegado a um conjunto de mensagens, tenho 00:49:00.750 --> 00:49:03.900 processados-los para esse determinado sessão e agora deve 00:49:03.950 --> 00:49:05.580 Salve estado da. 00:49:07.140 --> 00:49:10.730 E aqui você pode ver tudo o que eu estou fazendo chamar o estado do conjunto e get 00:49:10.780 --> 00:49:15.250 estado em dúvida a sessão. Esses são essencialmente fluxos. 00:49:16.050 --> 00:49:20.770 E armazenar o valor de contagem de distância sempre que a sessão for fechada. 00:49:21.780 --> 00:49:26.130 E, em seguida, o final é o erro caso de quando uma sessão é perdida. 00:49:27.420 --> 00:49:31.050 O motivo pelo qual você é capaz de lembrar agora para correlacionar todas as mensagens 00:49:31.100 --> 00:49:34.310 é porque podemos bloquear uma sessão para você. Nos certificamos de que você está 00:49:34.360 --> 00:49:38.790 o receptor único quem está recebendo mensagens para esse subfila 00:49:38.840 --> 00:49:40.510 Esse subsessão. 00:49:41.190 --> 00:49:43.780 E você sempre pode perder um bloqueio. Um bloqueio seriam perdido porque 00:49:43.830 --> 00:49:47.660 de uma falha no servidor. É possível seja perdido devido a conexão 00:49:47.710 --> 00:49:51.410 problemas ou talvez o processador apenas suspenso e ele perdeu o bloqueio 00:49:51.460 --> 00:49:55.290 porque ele, em seguida, executar uma operação lá para que você possa sempre obter 00:49:55.340 --> 00:49:58.940 Este erro é chamado. Nesse caso, tudo o que você fará é abandonar o 00:49:58.990 --> 00:50:03.500 Definir local de alterações e mover em. Em termos do que. 00:50:04.870 --> 00:50:07.150 Portanto, vamos ver como isso aparece. 00:50:07.670 --> 00:50:08.790 Uma execução real. 00:50:10.210 --> 00:50:10.800 Existia uma pergunta? 00:50:10.850 --> 00:50:11.930 >> Funciona o mesmo? 00:50:13.740 --> 00:50:17.500 >> Então a pergunta era: isso funcionam da mesma forma para inscrições? Centenas por cento. 00:50:17.550 --> 00:50:21.170 É completamente simétrico. Se Você está recebendo de uma fila 00:50:21.220 --> 00:50:24.130 ou você estiver recebendo a partir de uma subscrição. 00:50:25.440 --> 00:50:28.920 Esta é minha função de trabalho agora. Permitir que eu verificar o que realmente rapidamente 00:50:28.970 --> 00:50:30.850 a contagem de fila pesquisada Depois, como o 00:50:32.060 --> 00:50:36.390 função foi feita enviando. Aparência ele tem 3,700 mensagens direita 00:50:36.440 --> 00:50:40.610 Agora, 33, parecido com processamento tem entrar em cena. 00:50:41.650 --> 00:50:56.690 Deixe-me saltar para lá... Vamos lá. Ele está chegando. 00:50:56.740 --> 00:51:03.350 Boa. Até agora, meu computador seguir as etapas e você 00:51:03.400 --> 00:51:06.090 pode ver milhares de processamento e milhares de mensagens. 00:51:06.890 --> 00:51:10.740 E o código que escrevi foi pensar muito simplista 00:51:10.790 --> 00:51:15.170 sobre apenas uma sessão simple, um único sessão e eu não tinha 00:51:15.220 --> 00:51:18.800 para criar um loop de recebimento único. Eu apenas tinha que registrar o manipulador de pipe. 00:51:19.200 --> 00:51:23.370 O manipulador que mostrei é o caso simples em que você 00:51:23.420 --> 00:51:28.420 pode ter instâncias deste criado e Você não está fazendo a inicialização. 00:51:28.450 --> 00:51:32.020 Temos uma fábrica de backup que também está disponível. Você pode fazer 00:51:32.070 --> 00:51:36.960 uma fábrica de manipulador do registro e que Você pode controlar a criação de forma 00:51:37.010 --> 00:51:38.700 semântica de que também. 00:51:40.370 --> 00:51:43.560 Mas aqui, você pode ver persistir sessão de estado e fechado. 00:51:44.420 --> 00:51:48.340 Deixe-me a ampliar aqui para que as pessoas possam ver claramente o que aconteceu aqui. 00:51:49.070 --> 00:51:54.740 Se você ver cada sessão, sessão estado era 22 para sessão 21. 00:51:54.790 --> 00:51:57.810 Estado de sessão foi 46 sessão 45. 00:51:58.620 --> 00:52:03.770 Como essa classe tem apenas as mensagens que pertenciam a essa sessão. 00:52:04.200 --> 00:52:08.320 Tudo o que foi demuxing e muxing fácil e tudo foi tratado 00:52:08.370 --> 00:52:12.410 pelo barramento de serviço para você. Quando esse Você pensa multiplexação 00:52:12.460 --> 00:52:15.990 um grande número de remetentes em um pequeno número de filas, saber 00:52:16.040 --> 00:52:19.260 Se você não perdeu a simplicidade ser capaz de processar 00:52:19.310 --> 00:52:23.800 -los no back-end usando Esses fluxos individuais 00:52:30.570 --> 00:52:34.260 lá. 00:52:37.740 --> 00:52:41.000 Falamos sobre o estado da sessão. Correlação usando sessões. 00:52:41.350 --> 00:52:46.020 Isso apenas para resumir, na verdade antes que podemos resumir, acesse. 00:52:46.590 --> 00:52:49.230 Outra consideração importante é Quando você tem essas opções muito, muito 00:52:49.280 --> 00:52:52.530 grande número de remetentes confiáveis, o que é o modelo de autenticação? O que é a segurança 00:52:52.580 --> 00:52:55.750 modelo que você pretende usar? Portanto, eu diria acesso compartilhado 00:52:55.800 --> 00:52:58.420 a assinatura é definitivamente a Recomendamos o modelo de autenticação. 00:52:59.010 --> 00:53:02.150 Há muito mais detalhes. Na verdade o baralho tem mais detalhes em 00:53:02.200 --> 00:53:08.190 como configurar assinaturas de acesso compartilhado. Você pode ir para o portal 00:53:08.540 --> 00:53:10.040 e gerenciar seus filas. 00:53:10.910 --> 00:53:15.270 Aqui tenho o IOT da fila que você equipe está usando no site. 00:53:16.050 --> 00:53:18.850 E posso apenas aqui e configurar. 00:53:19.420 --> 00:53:23.650 Observe que eu tive Oh,... 00:53:23.660 --> 00:53:23.720 [Indiscernible] 00:53:23.700 --> 00:53:25.290 >> Desculpe-me até. Desculpe-me até. 00:53:28.330 --> 00:53:33.790 Então eu entrou no portal do Azure e eu selecionei minha fila IOT. 00:53:34.890 --> 00:53:38.340 E, nesse ponto, quando vou para configurar guia, você verá minha compartilhada 00:53:38.390 --> 00:53:42.420 acessar os nomes de diretiva aqui. Isso na Esse exemplo de site que eu 00:53:42.470 --> 00:53:45.240 mostramos, se chamei um recebimento deverá isso seria realmente 00:53:45.290 --> 00:53:49.650 falhar, pois agora, a única autorização sobre esse for enviado. 00:53:50.890 --> 00:53:54.310 Mas eu posso ir facilmente e adicionar escuta autorização para essa regra. 00:53:55.730 --> 00:53:56.440 Clique em Salvar. 00:53:57.340 --> 00:53:58.640 Informando a atualização na fila. 00:53:59.190 --> 00:54:00.050 E agora todos os 00:54:01.700 --> 00:54:06.780 token que foi gerado para isso regra terão a capacidade 00:54:06.830 --> 00:54:11.480 para enviar e receber. Portanto, agora Posso entrar aqui e clique em receber, 00:54:12.880 --> 00:54:15.660 bem, início. Aparência pessoal tem sido enviar mensagens. 00:54:15.710 --> 00:54:18.320 Agora você vai para sessão de bate-papo vai, vocês podem manter contato 00:54:18.370 --> 00:54:20.210 uns com os outros on-line. 00:54:21.490 --> 00:54:24.220 Assinatura de acesso compartilhada assim, são muito, muito simples, são muito 00:54:24.270 --> 00:54:28.290 modelo fácil de usar. Se você precisar saltar para um tipo SDS do modelo, 00:54:28.340 --> 00:54:35.540 são que ACS é totalmente suportado. ACS é ainda a opção da direita lá. 00:54:35.590 --> 00:54:37.660 Você acabou de ver com filas. 00:54:39.580 --> 00:54:43.390 Só para resumir, vimos protocolos. Por que eles são relevantes. 00:54:43.650 --> 00:54:47.970 Fomos através de correlação de fluxo Por que não é necessário que 00:54:48.020 --> 00:54:50.860 criar uma fila por dispositivo. Você não deseja gerenciar 00:54:50.910 --> 00:54:53.980 um milhão de filas. Mas você não deseja que seja escrito o código que 00:54:54.030 --> 00:54:57.760 tem que ser super complexa demais. Então ambas são muito, muito 00:54:57.810 --> 00:55:00.840 facilmente suportado com serviço Barramento de sistema de mensagens. 00:55:01.900 --> 00:55:05.320 Filas, tópicos, inscrições. Simétrica em todas elas. 00:55:05.370 --> 00:55:08.990 Tudo que mostrei em termos o que funciona com filas para 00:55:09.040 --> 00:55:12.280 sessões funciona exatamente da mesma maneira tópicos e assinaturas 00:55:12.330 --> 00:55:16.290 e filtros. Quando você cria uma assinatura, Você simplesmente dizer requer 00:55:16.340 --> 00:55:18.360 sessão nele é igual a verdadeiro ou não. 00:55:21.680 --> 00:55:22.910 Dimensionar em receptores. 00:55:27.210 --> 00:55:30.850 Visual Studio tinha esse desafio onde você pode iniciar uma tonelada de 00:55:30.900 --> 00:55:34.520 instâncias do IDE e, em seguida, Você pode acessar e alterar seus 00:55:34.570 --> 00:55:37.840 perfil em um deles, e deseja que todos eles para sincronizar. 00:55:38.640 --> 00:55:41.980 Como você vai conseguir se comunicar para essas instâncias? 00:55:42.490 --> 00:55:45.600 E estes são instâncias dinâmicas muito porque o número de VS 00:55:45.650 --> 00:55:49.910 varia de instâncias que você tiver iniciado Dependendo do dia da semana. 00:55:49.960 --> 00:55:53.530 Na verdade, temos estatísticas para mostrar que, a propósito. 00:55:53.580 --> 00:55:57.170 Pessoas abrirem caminho mais instâncias na quarta-feira que abrirem na sexta-feira. 00:55:57.220 --> 00:56:04.740 Para que produtividade é tanking até sexta-feira. Qualquer modo, o problema pode novamente 00:56:04.790 --> 00:56:07.440 ser resolvidos com tópicos onde você ter milhões e milhões de 00:56:07.490 --> 00:56:11.110 pontos de extremidade. E você deseja que todos eles ouvir suas próprias um 00:56:11.160 --> 00:56:14.070 assinatura única para mensagens. 00:56:15.150 --> 00:56:19.140 De se essas mensagens são geradas com o back-end com base 00:56:19.190 --> 00:56:22.840 em alguma alteração no sistema ou algo como você deseja enviar 00:56:22.890 --> 00:56:26.270 uma notificação a um usuário, que você deseja para notificá-los em um Windows 00:56:26.320 --> 00:56:30.510 caixa 7, em não que nenhuma notificação serviço. Você deseja notificar 00:56:30.560 --> 00:56:34.520 eles e Diga Oi há uma nova atualização disponível no Visual Studio, 00:56:34.570 --> 00:56:39.970 Vá baixá-lo. Ou mais importante dar-lhes uma classificação baixa latência 00:56:40.020 --> 00:56:43.890 de pipe onde se fizerem alterações em uma instância do VS, o outro 00:56:43.940 --> 00:56:45.430 Sincronizar instâncias do VS. 00:56:46.140 --> 00:56:48.340 Você pode sues tópicos e inscrições para isso. 00:56:49.760 --> 00:56:52.470 Então pense conceitualmente como um usuário do tópico por VS. 00:56:53.200 --> 00:56:58.800 Você tiver uma instância por VS de assinatura sempre conectado usando MQP. 00:56:58.850 --> 00:57:03.260 Portanto, MQP nos dá muito da conexão eficiência em que 00:57:03.310 --> 00:57:07.830 conosco milhões e milhões de seções simultânea com muito, 00:57:07.880 --> 00:57:12.350 sobrecarga muito baixa, só esperando para notificações ocasionais. 00:57:12.380 --> 00:57:14.840 Essa é a diferença sobre as notificações. Eles são muito ocasionais 00:57:14.890 --> 00:57:18.080 por natureza. Com que freqüência fazer pessoal alterar a cor do perfil? 00:57:19.770 --> 00:57:20.260 Um dia? 00:57:20.310 --> 00:57:22.960 Semana? Espera-se que não todos os dias. 00:57:23.790 --> 00:57:25.160 Depende do seu humor que acho. 00:57:26.260 --> 00:57:29.100 Mas não acontece com muita freqüência. Com que freqüência eles têm atualizações 00:57:29.150 --> 00:57:33.660 para distribuir? Não é muito freqüente. Mas Você ainda tem esse tipo BNS 00:57:33.710 --> 00:57:38.290 de infra-estrutura disponível para é onde você tem conexões 00:57:38.340 --> 00:57:41.780 Aguardando a notificação porque Quando essa notificação 00:57:41.830 --> 00:57:45.170 torna-se disponível, desejado no um instante. Deseja à direita 00:57:45.220 --> 00:57:46.040 em seguida, e ali. 00:57:51.000 --> 00:57:54.990 Assim, aqui você precisa realmente acha sobre e você precisa considerar 00:57:55.040 --> 00:57:59.320 sobre fluxos de mensagens. Porque hoje tópicos permitem até 2000 00:57:59.370 --> 00:58:03.170 Quando você está pensando e assinaturas de escala no número 00:58:03.220 --> 00:58:07.420 de receptores, 2000 pode ser o suficiente ou 2000 pode não ser suficiente. 00:58:07.980 --> 00:58:10.910 Se você pensar sobre o Visual Studio, uma única pessoa ter mais 00:58:10.960 --> 00:58:13.700 de 2000 instâncias de o IDE em execução 00:58:16.030 --> 00:58:20.210 praticamente impossível. Talvez não sei é possível, mas isso não acontece. 00:58:20.520 --> 00:58:24.520 Isso para eles, um usuário do tópico por VS está bem, mas você pode 00:58:24.570 --> 00:58:27.660 ser todos está escutando o mesmo feed. Você deseja 00:58:27.710 --> 00:58:30.790 ser capaz de enviar todos enviar... uma única mensagem e enviá-la 00:58:30.840 --> 00:58:34.790 projeção ampla para todos. Bem, em seguida você deseja encadear tópicos. 00:58:35.250 --> 00:58:38.680 E você que usando automática de encaminhamento. 00:58:39.850 --> 00:58:43.350 Não vou entrar no grupo Esses detalhes padrão em 00:58:43.400 --> 00:58:45.280 condições de como configurar filtros. 00:58:45.800 --> 00:58:48.520 Todos esses são exemplos no MSDN.com. 00:58:49.130 --> 00:58:55.380 Este exemplo em particular é chamado lista. Há um exemplo de chamada 00:58:55.430 --> 00:58:58.720 Publicar inscrever-se. O código completo Para isso estão disponível. 00:58:58.770 --> 00:59:02.570 Incentivar que vocês assuma realmente uma visão, mas com esses tópicos 00:59:02.620 --> 00:59:06.190 Você realmente pode liquidar a esses rich fluxos são onde todas as mensagens 00:59:06.240 --> 00:59:09.930 não é necessário que são roteados para todos o pessoal de 2 milhões e, em seguida, 00:59:09.980 --> 00:59:14.280 obter solta toda vez. Pode ser roteado para uma pessoa, para muitos 00:59:14.330 --> 00:59:18.680 pessoas, ou em um tipo interminável de caso onde você escreve apenas endereços. 00:59:18.730 --> 00:59:19.660 Como o email. 00:59:20.190 --> 00:59:23.130 Nesse caso é como dizer que a mensagem de que dizer em primeiro lugar, 00:59:23.180 --> 00:59:24.230 vírgula, segundo. 00:59:25.130 --> 00:59:27.850 E eu estou tratando dois dispositivos o dispositivo primeiro e o segundo 00:59:27.900 --> 00:59:30.770 dispositivo ou duas assinaturas, o primeiro e o segundo. 00:59:30.820 --> 00:59:35.390 Porque eles têm regras configuradas como pela primeira vez e como segundo lá. 00:59:36.390 --> 00:59:40.470 Estamos muito, examinar esses sub pub (indiscernible) 00:59:42.610 --> 00:59:47.050 encaminhamento automático. Muito fácil Para usar. Essencialmente, você cria 00:59:47.100 --> 00:59:52.150 o destino da fila primeiro e em seguida, na fila de origem, você 00:59:52.200 --> 00:59:55.970 Adicione uma única propriedade. A única propriedade é chamado de origem.ForwardTo, 00:59:57.220 --> 01:00:00.600 a fila de destino e isso ele. Todas as mensagens recebidas 01:00:00.650 --> 01:00:03.280 na fila de origem entrar no a fila de destino. 01:00:03.330 --> 01:00:10.030 As fontes podem ser inscrições e filas. As auditorias podem ser tópicos 01:00:10.080 --> 01:00:10.960 e filas. 01:00:13.190 --> 01:00:16.800 Completamente simétrico, configure quantas desculpas de fonte que você deseja 01:00:16.850 --> 01:00:18.810 como e ver que. 01:00:19.400 --> 01:00:22.540 Se você tiver transitórios casos onde Você tem inscrições que 01:00:22.590 --> 01:00:23.390 vai longe, 01:00:24.660 --> 01:00:28.430 Você pode usar a exclusão automática quando ociosos. Então Isso também é um recurso muito puro. 01:00:28.480 --> 01:00:32.570 Permite que você gerencie um número grande de conexões temporárias. Na verdade 01:00:32.620 --> 01:00:35.640 um dos principais cenários, isso é está sendo usado é o SignalR e 01:00:35.690 --> 01:00:38.590 Soquete de i/o. Eles são muito, muito transitórios por natureza. 01:00:38.640 --> 01:00:40.200 Conexões vem, conexões de ir. 01:00:41.380 --> 01:00:43.700 Cargas são adicionadas e removidas nós. 01:00:44.600 --> 01:00:48.680 Portanto, eles usam o barramento de serviço como um back reproduzir em essencialmente que estão 01:00:48.730 --> 01:00:52.540 gravar uma assinatura por nó sempre que vem de uma nova assinatura 01:00:52.590 --> 01:00:56.160 não uma nova conexão é exibida um novo nó aparece, quando eles 01:00:56.210 --> 01:00:57.260 Adicione servidores. 01:00:58.320 --> 01:01:03.210 E, em seguida, eles usam tópicos e assinatura como o pipe back para 01:01:03.260 --> 01:01:05.970 transferência de mensagens entre os nós e obtenha uma escala mais ampla. 01:01:07.010 --> 01:01:10.090 E, em seguida, quando um nó desaparece, a assinatura expira, os 01:01:10.140 --> 01:01:17.490 as mensagens são já existe. Ambos entre esses códigos são código aberto. 01:01:17.540 --> 01:01:20.240 Ambos estão disponíveis para scale-out, check-out do sinal ou de soquete 01:01:20.290 --> 01:01:24.720 E/s porque é necessário um mensagens duráveis pipe no final, serviço 01:01:24.770 --> 01:01:27.980 Barramento tem implementações para ambas. 01:01:29.920 --> 01:01:33.050 Eu quis falar um pouco criado sobre disponibilidade deixe-me 01:01:33.100 --> 01:01:36.780 rapidamente que cobrem. Eu sei Estamos quase ao longo do tempo 01:01:38.830 --> 01:01:42.440 o código precisa ser resiliente em relação à operação falhas, assim como conectado 01:01:42.490 --> 01:01:43.470 com os problemas. 01:01:43.990 --> 01:01:46.750 Filas de mensagens mortas, como já foi dito Você realmente pode ajudar você. Elas ajudam a 01:01:46.800 --> 01:01:50.790 nível no aplicativo onde decivilization de uma mensagem ou 01:01:50.840 --> 01:01:51.830 algo pode falhar. 01:01:52.980 --> 01:01:57.440 Todas as mensagens que lança o barramento de serviço tem uma propriedade transitória em 01:01:57.490 --> 01:01:58.020 sobre ele 01:01:59.480 --> 01:02:02.780 claramente e simplesmente torna mais fácil Para saber se você 01:02:02.830 --> 01:02:04.350 tenham que repeti-lo ou não. 01:02:05.090 --> 01:02:08.560 Por padrão, na verdade, estamos automaticamente nova tentativa. Então eu falei 01:02:08.610 --> 01:02:12.090 sobre tempos limite basicamente a operação tempos limite. Por padrão 01:02:12.140 --> 01:02:15.190 operação tempos limite são definidas como 60 segundos que significa que se você 01:02:15.240 --> 01:02:19.720 fazer o envio de chamada, ele poderá falhar uma vez, Tentaremos-la novamente após 01:02:19.770 --> 01:02:22.980 três segundos. Ele pode arquivar duas vezes. Ela será Tente novamente após dez segundos. 01:02:23.030 --> 01:02:27.840 Em que 60 segundos disponibilizam para nós, nós iremos Tente fazer a chamada tenha êxito. 01:02:27.890 --> 01:02:29.740 E se não, nós lhe enviaremos ele volta para você. 01:02:31.320 --> 01:02:33.650 Se você tiver algum outro lugar para mantê-lo, tudo bem. 01:02:33.700 --> 01:02:36.920 Caso contrário, verifique como transitório e em seguida, enviá-la novamente, acho que. 01:02:38.160 --> 01:02:42.430 E tópicos e filas de partição significativamente maior disponibilidade. 01:02:43.080 --> 01:02:48.230 Aperfeiçoamento de magnitude. Então altamente, altamente recomendável usar 01:02:48.280 --> 01:02:49.710 Esse recurso. 01:02:51.830 --> 01:02:55.280 Tente novamente diretiva por padrão. Não desativá-lo, por favor. 01:02:57.200 --> 01:02:59.970 Espaços para nome par. A última coisa falarei sobre hoje. 01:03:00.490 --> 01:03:03.540 Se você tem um barramento de serviço nomeado space, as mensagens estão fluindo bem 01:03:03.590 --> 01:03:08.210 por meio do e, em seguida, todos os dados Centro vai caput ou pelo menos 01:03:08.260 --> 01:03:13.570 o espaço para nome inteiro vai um caput. Espaço para nome incorreto criará 01:03:13.620 --> 01:03:15.790 espaço para nome de backup. Criar espaço para nome de backup. 01:03:15.840 --> 01:03:19.190 Apenas forneça conosco e nós será Iniciar o armazenamento de mensagens em 01:03:19.240 --> 01:03:23.440 espaço para nome de backup. Portanto, qualquer mensagem que falha indo em 01:03:24.140 --> 01:03:25.350 entrará na parte de trás para cima. 01:03:26.210 --> 01:03:29.450 Em algum momento mensagens serão iniciado a fluir pelo. O sistema 01:03:29.500 --> 01:03:30.340 virá novamente. 01:03:31.350 --> 01:03:35.150 E, nesse ponto, temos um sifão terão essas mensagens 01:03:35.200 --> 01:03:39.110 filas de transferência e reenqueue -los à fila original. 01:03:40.650 --> 01:03:43.590 De tudo isso, seu código do remetente não é alterado, o receptor 01:03:43.640 --> 01:03:46.370 código não é alterado. O remetente e o receptor, como se eles fossem 01:03:46.420 --> 01:03:48.470 sempre falando ao serviço Espaço para nome de barramento. 01:03:49.240 --> 01:03:54.700 Nos bastidores, estamos criando as filas de transferência, movendo 01:03:54.750 --> 01:03:57.870 as mensagens lá e depois puxando -los de volta para você. 01:03:58.720 --> 01:04:03.160 E essa é a única informação código que você precisa modificar. 01:04:03.740 --> 01:04:06.070 Esta não é a única solução que você tem Para isso. Falaremos sobre o 01:04:06.120 --> 01:04:08.520 considerações, mas isso é o somente parte do código que você precisa 01:04:08.570 --> 01:04:13.330 modificar o que é que, quando você criar uma fábrica, que é o 01:04:13.380 --> 01:04:17.690 executar tempo enviar e receber o código classe, Emparelhe-lo com um nome 01:04:17.740 --> 01:04:21.230 espaço, diz Ei que há um segundo fábrica, um segundo espaço para nome 01:04:21.280 --> 01:04:24.130 Gerenciador de com que você deseja para você ser acompanhado. 01:04:24.660 --> 01:04:28.600 E tudo é feito com o lado do cliente. Nenhuma alteração de remetente. 01:04:28.650 --> 01:04:31.470 Nenhuma alteração de destinatário. Código permanece o mesmo. 01:04:36.210 --> 01:04:41.520 Agora, há suporte disponível do remetente. Como você viu no diagrama, 01:04:41.570 --> 01:04:44.590 o destinatário não receberá a mensagem até o nome original 01:04:44.640 --> 01:04:45.760 espaço em volta. 01:04:46.330 --> 01:04:49.340 Essa é mais uma disponibilidade de envio. Agora, é por isso que 01:04:49.390 --> 01:04:54.000 nós o chamamos de opções de disponibilidade de envio. Pedidos podem ser perdidos porque 01:04:54.050 --> 01:04:57.910 mensagens que estão na transferência fila não será exibida. 01:04:58.630 --> 01:05:02.360 E final às extremidades receber latência claro que pode ser alto. 01:05:02.410 --> 01:05:06.420 Portanto, há algumas considerações mas pense nisso como realmente 01:05:06.470 --> 01:05:10.730 um cenário fundamental da tomada de tipo de recuperação de desastres 01:05:12.070 --> 01:05:14.770 cenários de cada vez. 01:05:15.810 --> 01:05:18.710 Portanto apenas para fechar, nós vimos Azure Barramento de serviço realmente pode ser dimensionado 01:05:18.760 --> 01:05:21.870 em todas as dimensões. Muitos remetentes. Grande quantidade de throughput. 01:05:21.920 --> 01:05:23.080 Vários receptores. 01:05:23.730 --> 01:05:27.420 E você pode melhorar a confiabilidade as duas usando os novos recursos-out 01:05:27.470 --> 01:05:31.950 da caixa como filas de partição e combinados espaços para nome ou por 01:05:32.000 --> 01:05:37.320 tornar o seu código usar padrões como Async e lote e coisas. 01:05:38.100 --> 01:05:41.750 Toneladas de links. Toneladas de recursos. Você tem acesso a tudo isso. 01:05:41.800 --> 01:05:44.130 Muito obrigado. Peço desculpas seja qual for.