WEBVTT 00:00:01.460 --> 00:00:02.340 Buenas tardes. 00:00:04.930 --> 00:00:05.880 ¿Cómo están amigos? 00:00:08.810 --> 00:00:14.600 ¿Buena? Lo ha hecho casi al final de la conferencia. 00:00:15.630 --> 00:00:17.150 ¿Cómo es la experiencia ¿sido hasta ahora? 00:00:17.160 --> 00:00:19.360 [Aplausos] 00:00:19.520 --> 00:00:20.120 >> Bien. 00:00:20.170 --> 00:00:24.940 Maravilla. Como dicen ellos Guarde siempre el mejor para el final. 00:00:26.240 --> 00:00:32.190 Así que espero en no le decepcionará ¿chicos. Realmente aprecio 00:00:32.240 --> 00:00:34.450 el lo que esta tarde. 00:00:35.200 --> 00:00:40.360 Soy Abhishek Lal. Administrador de programas con el equipo de la plataforma Windows Azure. 00:00:41.090 --> 00:00:45.840 Este es el equipo en el que se basa el PaaS servicios como servicios para dispositivos móviles, 00:00:45.890 --> 00:00:48.550 Bus de servicio, caché de Azure. 00:00:49.240 --> 00:00:51.080 Y servicios de medios. 00:00:51.720 --> 00:00:54.320 Estos servicios están lo el equipo posee. 00:00:54.830 --> 00:00:58.940 Y específicamente he estado trabajando para los tres últimos más años 00:00:58.990 --> 00:01:05.100 en la construcción de la mensajería con piezas. Por lo que se trata de colas, 00:01:05.150 --> 00:01:08.720 temas, son sub pub, las piezas de eso. 00:01:09.470 --> 00:01:15.150 Hoy hablaremos acerca de mensajería a escala. 00:01:17.010 --> 00:01:22.030 Las colas y temas. Ahora están familiarizado con Bus de servicio. 00:01:22.840 --> 00:01:26.920 Abarcan la retransmisión. Lo hace abarcan concentrador de notificación, 00:01:27.780 --> 00:01:29.010 las colas y temas. 00:01:29.560 --> 00:01:34.840 Por lo que es una especie de una amplitud completa servicios relacionados con la mensajería. 00:01:35.710 --> 00:01:39.560 Esta sesión en especial va centrarse principalmente en las colas 00:01:39.610 --> 00:01:46.260 y los temas, por lo es el principal área. Pero si tiene preguntas 00:01:46.310 --> 00:01:50.120 o cualquier cosa que le gustaría saber específicamente acerca de retransmisión o 00:01:50.170 --> 00:01:55.150 concentradores de notificación, me complace responder o seleccione al menos 00:01:55.200 --> 00:01:57.410 que en la dirección correcta. 00:01:58.820 --> 00:02:00.930 Hay un montón de cosas Me gustaría tratar hoy. 00:02:01.710 --> 00:02:04.730 Hable acerca de los diferentes aspectos de escala. Quiero hablar 00:02:04.780 --> 00:02:08.490 acerca de remitentes y receptores y rendimiento, todos los diferentes 00:02:08.540 --> 00:02:11.630 patrones, así como la características del código. 00:02:12.390 --> 00:02:14.870 De cómo se puede lograr la escala. 00:02:15.810 --> 00:02:19.040 Así que voy a tratar mantener un buen ritmo. 00:02:19.640 --> 00:02:24.190 Preguntas son excelentes. Si ves que me iniciar el corte preguntas cortas 00:02:24.240 --> 00:02:27.780 sólo un poco más adelante, así puede cubrir todas las cosas que quiero 00:02:27.830 --> 00:02:31.490 para cubrir. Estará disponible después de la sesión y siempre puede 00:02:31.540 --> 00:02:36.200 llegar a me, pero mantenerlo interactivo. Todo lo que tiene, 00:02:36.250 --> 00:02:41.270 aquí están los micrófonos. Simplemente y a destacar. 00:02:43.930 --> 00:02:48.720 Comenzaremos hablando acerca de lo que de nuevo. Como una actualización 00:02:48.770 --> 00:02:51.210 en lo que nos hemos anunciado como SDK 2.3. 00:02:52.250 --> 00:02:56.290 Se tendrá que cambiar a hablar las dimensiones de escala. 00:02:56.340 --> 00:03:00.420 Hablaremos acerca de remitentes, receptores, rendimiento, cómo lograrlo. 00:03:01.800 --> 00:03:05.770 Y, a continuación, dedicaremos algún tiempo en Consideraciones acerca de la disponibilidad. 00:03:05.820 --> 00:03:07.850 Disponibilidad sólo lo que significa que en general 00:03:09.190 --> 00:03:14.340 resistencia, mejor SLA y cómo para diseñar la aplicación para 00:03:14.390 --> 00:03:19.520 estar siempre, siempre, ejecutar allí, por lo que dedicaremos algunos 00:03:19.570 --> 00:03:20.510 hora en. 00:03:22.060 --> 00:03:25.780 Así SDK 2.3. 00:03:26.330 --> 00:03:28.310 ¿Qué sólo publicamos? 00:03:29.070 --> 00:03:32.540 En la sesión de mensajes. De miembro etc. El jurado son una inserción 00:03:32.590 --> 00:03:36.970 estilo de API. Esencialmente toma distancia todo el trabajo del usuario 00:03:37.020 --> 00:03:42.960 de la escritura de los bucles de C o nada de esa complejidad y 00:03:43.010 --> 00:03:46.420 le ofrece un muy evento-diferentes modelo para consumir mensajes. 00:03:46.470 --> 00:03:50.110 Se trata de la API del lado receptor. Por lo tanto tenemos para las sesiones. 00:03:50.160 --> 00:03:52.680 Sin duda trataremos con más detalle en la actualidad. 00:03:53.890 --> 00:03:58.440 Detección automática de modo de conectividad. Como sabe, uno de los bienes 00:03:58.490 --> 00:04:02.520 valor de la clave ha sido el Bus de servicios de Azure que cuando se conecta 00:04:02.950 --> 00:04:07.700 para las colas y los temas de la nube detrás de los servidores de seguridad 00:04:07.750 --> 00:04:11.450 sus propios centros de datos o desde el centros de datos de los clientes que 00:04:11.500 --> 00:04:16.230 se encuentran detrás muy bien protegida de los servidores de seguridad, servicio 00:04:16.280 --> 00:04:19.660 Bus tiene la capacidad de realizar conexiones salientes no sólo en el puerto TCP 00:04:19.710 --> 00:04:22.110 pero el puerto 83 y 443 00:04:23.670 --> 00:04:25.860 mientras se bloquean los puertos TCP. 00:04:26.700 --> 00:04:30.790 Esta función estará disponible todavía ahora Si se establecen directamente 00:04:30.840 --> 00:04:34.230 el directorio con el modo de TCP, por lo que no tenía la opción. 00:04:34.910 --> 00:04:38.730 Ahora en el código se puede establecer simplemente automáticamente detecta y se lo 00:04:38.780 --> 00:04:42.910 Ver automáticamente si es el puerto TCP disponible, haremos todo lo. 00:04:42.960 --> 00:04:48.410 Si el servidor de seguridad bloquea, lo haremos colóquelo a HTTP. Así SDK 00:04:48.460 --> 00:04:51.560 2.3, que está disponible para mensajería también. 00:04:54.390 --> 00:04:57.980 Compatible con CORS. ¿Cuántas personas ¿saber qué es CORS? 00:05:00.360 --> 00:05:04.200 Mayoría de la gente sabe. Es esencialmente permite enviar y recibir fácil 00:05:04.250 --> 00:05:09.370 de los exploradores. La idea es que siempre puede haber hecho, tienes 00:05:09.420 --> 00:05:14.320 STPI con SCTP. Puede hacer enviar mensajes, recibir mensajes, 00:05:14.370 --> 00:05:18.920 pero con Corazones ahora facilita mucho los exploradores y los sitios Web con mayor facilidad 00:05:18.970 --> 00:05:23.650 para integrar atrás y se profundizará en eso en detalle hoy en día. 00:05:25.010 --> 00:05:29.530 De forma similar, una especie de ayuda rendimiento, así como a escala 00:05:29.580 --> 00:05:34.760 para los remitentes HTTP, tenemos procesamiento por lotes ahora disponible. 00:05:35.200 --> 00:05:43.980 Y, a continuación, par de rendimiento del lado de cliente contadores que si está 00:05:44.030 --> 00:05:46.900 realmente a una aplicación que es complicado o que estás 00:05:46.950 --> 00:05:50.450 va a ejecutar en entornos diferentes, Puede que necesite 00:05:50.500 --> 00:05:53.340 depurar y puede que necesite el perfil así que hemos agregado cliente 00:05:53.390 --> 00:05:57.890 contadores de rendimiento del lado de los mensajes enviados por segunda, letras por segundo 00:05:57.940 --> 00:06:01.460 cosas como lo que realmente, puede ayudarle a perfil 00:06:01.510 --> 00:06:05.250 mensajería capa es haciendo en general está opuesto 00:06:05.300 --> 00:06:09.020 está haciendo la ocasión. Para aquellos manifiestan para esos perf 00:06:09.070 --> 00:06:14.230 contadores como parte del paquete de NuGet de esta forma permite realmente 00:06:14.280 --> 00:06:17.550 Hacer buena de depuración. 00:06:20.550 --> 00:06:23.340 Y por último, será para las colas con problemas de entrega. 00:06:23.880 --> 00:06:27.380 Deadlettering es una muy, muy eficaz característica que protege 00:06:27.430 --> 00:06:30.820 Eres back-ends si hay daños mensajes. Estos suelen 00:06:30.870 --> 00:06:34.620 llama a las colas de daños donde probar para recibir un mensaje y el 00:06:34.670 --> 00:06:38.600 no se ha formado el mensaje o no hay un error en alguna parte del código 00:06:38.650 --> 00:06:42.080 en el civilizador de algún lugar donde no es capaz de abrir 00:06:42.130 --> 00:06:44.560 el mensaje y bloquea su back-end. 00:06:45.780 --> 00:06:50.390 Bus de servicio le ofrece la posibilidad de de la configuración de una entrega máx. 00:06:50.440 --> 00:06:54.420 número cuyo valor predeterminado es 10 y lo que significa es que si vemos 00:06:54.470 --> 00:06:57.660 hemos proporcionado el mensaje te 10 veces y tiene 00:06:57.710 --> 00:07:01.310 no se completó correctamente la mensaje, tendremos que desplazar desde 00:07:01.360 --> 00:07:03.240 la cola principal en el cola con problemas de entrega. 00:07:03.870 --> 00:07:07.930 Así que esto literalmente ayuda a las aplicaciones ser resistente de forma predeterminada 00:07:08.190 --> 00:07:12.840 sin tener que escribir una única línea de código y proteger 00:07:12.890 --> 00:07:18.660 los servidores back-end. Así que interese es la capacidad de canal 00:07:18.710 --> 00:07:23.810 los mensajes automáticamente crear enriquecidos flujos de mensajes y ahora 00:07:23.860 --> 00:07:30.000 puede tener una aplicación que pueda tener 6, 8, 10 colas y ansiosa 00:07:30.050 --> 00:07:34.450 para toda la cola con problemas de entrega en una única cola, lo que significa 00:07:34.500 --> 00:07:38.530 Ahora tendrá un lugar ahora recibir todos los mensajes dudosos 00:07:38.980 --> 00:07:42.340 independientemente de cuántos colas o temas o suscripciones 00:07:42.390 --> 00:07:46.280 así que utiliza es un ¿necesita agregar característica demasiado. 00:07:47.180 --> 00:07:49.910 Cubriremos en un poco más en detalle. 00:07:51.740 --> 00:07:57.570 Quiero recapitular rápidamente en qué hemos hecho desde el pasado abril 00:07:57.620 --> 00:08:01.400 porque cuando hablamos de hoy en día en términos de escala y performance 00:08:01.450 --> 00:08:05.780 y el rendimiento que se verá muchas Estas características en la que se hace referencia 00:08:06.180 --> 00:08:08.570 sólo quería destacarlos en términos de si son 00:08:08.620 --> 00:08:12.370 ya disponibles hoy día y ha estado durante algún tiempo, pero 00:08:12.420 --> 00:08:16.250 están aún allí. 00:08:18.520 --> 00:08:22.290 Lo que ve aquí es que actúa debajo de la línea, la primera 00:08:22.340 --> 00:08:26.310 bus de servicio en los compromisos del pasado año que hicimos con el Bus de servicio 00:08:26.360 --> 00:08:28.900 1.1 para Windows server release. 00:08:29.580 --> 00:08:33.210 Esto es completamente simétrico para cola y temas, lo que significa 00:08:33.260 --> 00:08:37.450 Si selecciona SDK 2.1, por ejemplo, lo que era el último SDK, 00:08:38.470 --> 00:08:42.010 ¿podrá cualquiera visitas el servicio o en premisa todos 00:08:42.060 --> 00:08:45.070 las características que están disponibles. 00:08:46.760 --> 00:08:51.600 Cadencia de este tipo de versión de la nube cada tres meses se 00:08:51.650 --> 00:08:55.290 puede ver cada tres o cuatro meses y de manera local suelte en 00:08:55.340 --> 00:08:59.520 por lo menos una vez al año es lo que tratamos de mantener y, a continuación, poner ambos 00:08:59.570 --> 00:09:02.680 la función se establece en la paridad. 00:09:05.540 --> 00:09:08.740 Por lo que está disponible para usted por referencia posteriormente en términos de 00:09:08.790 --> 00:09:10.010 las características. 00:09:12.110 --> 00:09:13.310 ¿Alguna pregunta hasta ahora? 00:09:15.820 --> 00:09:16.720 Sí, por favor. 00:09:16.730 --> 00:09:19.730 [Indiscernible] 00:09:19.950 --> 00:09:23.560 >>, Así que la pregunta era: cuando la siguiente actualización y donde 00:09:23.610 --> 00:09:28.920 convertiremos en realidad el 2.3, la última no existe la funcionalidad. 00:09:28.970 --> 00:09:33.240 Ahora mismo no tengo ninguna fecha para compartir para el siguiente servicio 00:09:33.290 --> 00:09:36.320 Versión de bus pero habrá ser un 2.2 o un 1.2. 00:09:37.800 --> 00:09:42.620 Pero por lo general se puede considerar esto versión concreta esa fecha 00:09:43.340 --> 00:09:46.900 coincide con la versión de Windows Server para la mayoría de las veces intentan 00:09:46.950 --> 00:09:51.580 Para alinear con las versiones de servidor, por lo que se obtiene la máxima de plataforma 00:09:51.630 --> 00:09:55.010 beneficio así nos aseguramos de que tenemos servidor mayor con el último 00:09:55.060 --> 00:09:59.310 organización en clústeres con la administración más reciente y estropea todo. 00:09:59.360 --> 00:10:03.610 Normalmente sólo la guía supone que el mismo tipo de cadencia 00:10:03.660 --> 00:10:05.820 se seguirá. Es una buena pregunta. 00:10:08.920 --> 00:10:13.130 La escala en el remitente. Comencemos con Esto en términos de la primera 00:10:13.180 --> 00:10:14.210 aspecto de la escala. 00:10:15.570 --> 00:10:18.650 Por lo que los remitentes no es nada, pero un lugar en el que esté 00:10:18.660 --> 00:10:20.040 [Indiscernible] 00:10:20.000 --> 00:10:22.830 Puede pensar en muchos escenarios aquí. Puede pensar en dispositivo 00:10:22.880 --> 00:10:24.970 telemetría, las acciones del usuario. 00:10:26.630 --> 00:10:31.030 Y los sistemas de generación de eventos y B a B tipo de escenario. 00:10:31.080 --> 00:10:32.910 Los eventos generados. 00:10:33.640 --> 00:10:37.660 ¿Cómo cuidar de escenarios donde tiene muchos de estos 00:10:37.710 --> 00:10:41.620 o tal vez algunos de ellos con un lote de eventos o un lote de remitentes 00:10:41.670 --> 00:10:45.250 ¿con muchos eventos? Todos los son los escenarios posibles. 00:10:46.830 --> 00:10:50.480 Así que le proponemos concreto. Vamos a iniciar con un escenario real 00:10:50.530 --> 00:10:54.510 los clientes que son de uso para hoy que es donde se debe 00:10:54.560 --> 00:10:58.850 recopilar eventos de análisis de un gran número de dispositivos. 00:11:00.370 --> 00:11:05.900 Estos dispositivos pueden resultarle familiares pero eso es una coincidencia que 00:11:05.950 --> 00:11:11.000 No se confirman ni negar. Por lo que puede ser cualquier dispositivo. 00:11:11.050 --> 00:11:12.350 Puede ser cualquier dispositivo. 00:11:13.160 --> 00:11:18.850 Ahora, todo esto comienza con la ser capaz de poner en cola en el dispositivo 00:11:18.900 --> 00:11:24.250 mensajes, poder tomar algunos temas o un tema y empuje 00:11:24.300 --> 00:11:28.090 una gran cantidad de información en ese canal. 00:11:29.520 --> 00:11:33.640 una vez que tiene un mensaje en un tema se puede considerar que puede 00:11:34.710 --> 00:11:39.370 tiene varios escenarios en los que desea utilizarlo. 00:11:39.420 --> 00:11:43.330 Análisis en tiempo real o lo que con su propio código es 00:11:43.380 --> 00:11:48.570 realmente se hacen mucho más importantes y popular. Abran 00:11:48.620 --> 00:11:53.840 para la sesión de Orleans que ¿se ha hecho de ayer? Bueno, si 00:11:53.890 --> 00:11:57.080 lo hizo, Maravilla, impresionante pieza tecnología de porque intenta 00:11:57.130 --> 00:12:02.580 Para resolver este problema de ejecutar su código a escala en distribuido 00:12:02.630 --> 00:12:06.190 Si usted está tratando con la manera eventos que se generan 00:12:06.240 --> 00:12:10.830 un gran número de remitentes y correlación en todos los sentidos. 00:12:12.020 --> 00:12:15.930 Entonces, ¿cómo es posible garantizar que estos ¿se separan los sistemas back-end? 00:12:15.980 --> 00:12:18.590 ¿Cómo es posible garantizar que estos son capaces de sistemas back-end 00:12:18.640 --> 00:12:24.640 consumir mensajes a esa velocidad y actuar ¿en formas que son flexibles? 00:12:25.950 --> 00:12:29.560 Y para eso coloca temas en el medio. No sólo los temas tan 00:12:29.610 --> 00:12:33.440 proporciona el almacenamiento en búfer, como sería una cola, lo que significa 00:12:33.490 --> 00:12:35.950 el fondo puede hacerse un par de horas y no 00:12:36.000 --> 00:12:39.060 perder cualquiera de los eventos. Los eventos sigue ahí pero 00:12:39.110 --> 00:12:40.490 También proporcionan sub pub. 00:12:41.470 --> 00:12:45.530 Lo que significa que si tiene otros sistemas que están haciendo 00:12:45.580 --> 00:12:51.310 estado de seguimiento, digamos que poner los valores en los cables azules, o 00:12:51.360 --> 00:12:56.520 hacen que el análisis de proceso por lotes con vincular la estructura de archivos en 00:12:56.570 --> 00:13:00.330 HDFS y, a continuación, ejecutar Hadoop trabajos en él. 00:13:01.400 --> 00:13:05.850 O poner alto estás datos en un almacén de datos SQL 00:13:05.900 --> 00:13:09.170 y ejecutar consultas de BI Además de eso. 00:13:09.790 --> 00:13:13.980 Todos estos sistemas pueden visitar en la misma secuencia de eventos. 00:13:15.280 --> 00:13:18.350 Y no sólo la misma secuencia de eventos, Puede examinarlo evento 00:13:18.400 --> 00:13:21.780 secuencia demasiado. Tal vez el BI trabajar almacén, no desea consumir 00:13:21.830 --> 00:13:25.870 todos los eventos. Cualquiera de la acción relacionada los eventos no pertenecen ahí. 00:13:25.920 --> 00:13:29.420 Son sólo para el material de código. Puede dividir las secuencias 00:13:29.470 --> 00:13:30.210 de esa manera. 00:13:32.750 --> 00:13:36.990 Y, a continuación, desde el back-end, ya sea está leyendo el Azure 00:13:37.040 --> 00:13:41.730 tablas o el almacén de datos SQL puede generar la fiesta 00:13:41.780 --> 00:13:43.200 las placas y análisis. 00:13:44.750 --> 00:13:45.750 Por lo tanto, uno de los principales 00:13:46.970 --> 00:13:49.340 puntos de diseño en este paquete. 00:13:50.180 --> 00:13:52.920 Primero utiliza temas para el ventilador. 00:13:53.960 --> 00:13:57.730 Ventilador de esencial significa que tienen menos temas que tienen dispositivos. 00:13:57.780 --> 00:13:59.900 ¿Verdad? ¿Cuáles son las puede ser la cardinalidad. 00:14:01.080 --> 00:14:03.820 Probablemente no va a ser uno. No va a ser una 00:14:03.870 --> 00:14:07.660 tema para todo. Es probable que no va a ser N. permite a 00:14:07.710 --> 00:14:12.220 Ir a un lugar en el medio y como hablamos acerca de cómo elaborar 00:14:12.270 --> 00:14:13.860 con el número correcto. 00:14:14.410 --> 00:14:18.960 Va a equilibrar a través de la carga centros de datos por varias razones. 00:14:19.320 --> 00:14:22.490 Si lo piensa, estos dispositivos son en realidad geográficamente 00:14:23.190 --> 00:14:26.300 repartir, por lo que desee hacer de que el dispositivo utiliza el 00:14:26.350 --> 00:14:30.740 menor cantidad de energía, el más bajo conexión de latencia para poder 00:14:30.790 --> 00:14:33.770 para llegar y sus datos de la cola. 00:14:35.480 --> 00:14:39.640 Por lo que es la carga equilibrada en los datos centros. Por lo que este bus está disponible 00:14:39.690 --> 00:14:45.690 en todas las regiones de Azure, centros de todos los datos. Para tener la posibilidad de 00:14:45.740 --> 00:14:50.730 difundir temas alrededor. En ahora que no significa que el back-end 00:14:50.780 --> 00:14:53.890 los sistemas han de ser renunciado en todos esos lugares, demasiado. 00:14:54.880 --> 00:14:58.000 En if hecho, si piensa en Hadoop los clústeres, por lo general es 00:14:58.050 --> 00:15:01.860 no se replica en cada región en cada centro de datos. 00:15:01.910 --> 00:15:05.890 Pero esto da una baja latencia extremo. Desde allí puede 00:15:05.940 --> 00:15:10.490 recopilar datos de donde se está genera. Y, a continuación, tire de él 00:15:10.540 --> 00:15:14.310 en el back-end. A través de para todas las regiones y 00:15:14.360 --> 00:15:18.450 suscripciones en diferentes regiones y correlación de datos. 00:15:20.910 --> 00:15:23.690 Filtro True para todo menos una suscripción, en vertical 00:15:23.740 --> 00:15:27.550 caso del cliente, en realidad por qué consumir todos sus datos y 00:15:27.600 --> 00:15:31.700 código de seguimiento de estado y por lotes análisis pero no en BI. 00:15:31.750 --> 00:15:35.900 Así que todos esos tres eran realmente los filtros pero una suscripción 00:15:35.950 --> 00:15:39.960 tenía un filtro de reducción. Tenía una filtro que dice si es un juego 00:15:40.010 --> 00:15:45.060 evento, entonces no importa y por supuesto puede hacer 00:15:45.110 --> 00:15:47.360 análisis en tiempo real y por lotes. 00:15:49.410 --> 00:15:53.110 En este escenario, pensé que podrá saltar a una rápida demostración. 00:15:54.270 --> 00:15:59.080 Y mostrar el CORS compatible con aspecto de ella. 00:16:00.290 --> 00:16:05.680 Ya que permite a un lote de cliente desde la perspectiva 00:16:05.730 --> 00:16:11.600 de ser capaz de cola mensajes sólo con puro 00:16:13.270 --> 00:16:15.140 HTTP y esas cosas. 00:16:15.730 --> 00:16:21.550 Tengo un sitio Web configurada. UDS. puede golpear demasiado si tiene 00:16:21.600 --> 00:16:25.950 un dispositivo o algo así. La llamada Nota el usuario de archivo es el azul 00:16:26.000 --> 00:16:28.260 sitios Web. NET. 00:16:29.750 --> 00:16:40.510 Aquí es muy sencillo JavaScript que lo haré 00:16:40.560 --> 00:16:41.160 mostrar. 00:16:41.880 --> 00:16:43.280 Y lo que hace 00:16:48.770 --> 00:16:53.470 se toma los valores de clave, el basic valores de cuál es su nombre 00:16:53.520 --> 00:16:58.790 ¿Cuál es el nombre de la cola, el nombre de espacio Dame la regla SaaS, el 00:16:58.840 --> 00:17:02.140 autorización de la firma de acceso compartido, eso es lo que está utilizando 00:17:02.190 --> 00:17:03.800 así como la clave de SaaS. 00:17:04.950 --> 00:17:07.970 Y se basa en los que puede enviar un mensaje. 00:17:14.280 --> 00:17:18.140 Mensaje que se envió correctamente. Eso es . Para ver si se 00:17:18.190 --> 00:17:21.380 tiene muchos y muchos clientes de explorador o cualquier otro cliente o 00:17:21.430 --> 00:17:25.940 dispositivo que se puede hacer sólo HTTP puro, No hay ningún SOAP aquí. No hay ningún... 00:17:26.900 --> 00:17:31.300 codificación. Puede colocar el mensaje propiedades en JSON y, a continuación, 00:17:31.350 --> 00:17:35.930 una manera es muy sencilla obtener mensajes en la cola. Permítanme mostrarles 00:17:35.980 --> 00:17:38.170 que el código de este sitio Web. 00:17:47.070 --> 00:17:52.110 Aquí puede ver si se está realizar cualquiera de las propiedades completa 00:17:52.730 --> 00:17:55.220 o incluso propiedades sólo muy, muy básicas, 00:17:58.440 --> 00:18:05.280 puede enviar fácilmente ese código. Y de hecho, la biblioteca de JavaScript 00:18:05.330 --> 00:18:09.370 que se utiliza aquí, le permiten Me demuestran que a usted también. 00:18:16.200 --> 00:18:22.410 Por lo que ésta es la página web que demostró y se puede ver cómo 00:18:35.560 --> 00:18:40.400 simple realmente el envío y la recepción de este mensaje. 00:18:40.450 --> 00:18:44.840 El HTTP, la eliminación es realmente para el escenario de recepción. 00:18:45.430 --> 00:18:47.500 Que veremos más adelante. 00:18:48.120 --> 00:18:56.600 Y puesto que es, en caso de envío, lo sentimos, en cuanto a escenario de envío. 00:18:58.510 --> 00:19:02.420 Así que 00:19:03.620 --> 00:19:05.210 me envíe más mensajes. 00:19:05.810 --> 00:19:09.220 Y para mostrar los mensajes aparecen, tengo Server 00:19:09.270 --> 00:19:12.280 Cargado con el explorador... 00:19:21.330 --> 00:19:25.310 conectado a mi espacio de nombres. Y he tiene una cola simple en el que 00:19:25.360 --> 00:19:28.770 puede ver ahora hay dos en los mensajes de la cola. Si hago un 00:19:28.820 --> 00:19:35.430 actualización, veo 14 mensajes. Por lo tanto Cuando los mensajes llegan en ellos 00:19:35.480 --> 00:19:37.840 se mostrará en esta cola. 00:19:48.480 --> 00:19:53.620 Hablaremos sobre el escenario de recepción más tarde, en términos de la 00:19:53.670 --> 00:19:56.920 Cliente HTTP. Eso es para un cliente HTTP. 00:19:57.510 --> 00:20:02.200 Pero quería hablar específicamente acerca de los protocolos. 00:20:02.820 --> 00:20:06.840 ¿Cuáles son las consideraciones que puede hacerse al decidir 00:20:06.890 --> 00:20:11.460 Si desea utilizar HTTP o utilizar el AMQP. Como ya sabe el servicio 00:20:11.510 --> 00:20:13.930 Bus es compatible con varios protocolos. 00:20:15.060 --> 00:20:21.750 HTTP es sólo nuestra RKDPI es AMQP protocolo estándar que hago 00:20:21.800 --> 00:20:27.620 hablando sobre y SBMP es nuestro otro protocolo propietario sobre. NET. 00:20:29.320 --> 00:20:35.000 Ahora, cada uno de ellos puede tener consideraciones de rendimiento y consideraciones. 00:20:35.710 --> 00:20:39.950 Por tanto, si tiene un dispositivo en el que es muy bajo con tecnología, que es posible 00:20:40.000 --> 00:20:44.810 le preocupan qué protocolo implementación se puede colocar 00:20:44.860 --> 00:20:49.590 ahí. Si tiene escenarios donde desea ser proveedor independiente, 00:20:50.070 --> 00:20:54.160 es posible que tenga alcance consideraciones diciendo no comprarán en 00:20:54.210 --> 00:20:57.830 cualquier protocolo determinado o API con un proveedor. Voy a 00:20:57.880 --> 00:21:00.060 Utilice un estándar abierto como AMQP. 00:21:01.900 --> 00:21:04.390 A veces las características varían según el protocolo. 00:21:05.130 --> 00:21:08.000 Y la parte desea destacar que se pierde en un lote de 00:21:08.050 --> 00:21:11.300 gente que es en su mayor parte recibir características. 00:21:11.950 --> 00:21:13.290 Hay algún lado de envío 00:21:14.560 --> 00:21:19.100 implicaciones, también, la mayoría de los tiempo que está en la recepción donde 00:21:19.150 --> 00:21:23.270 protocolos realmente aplazados un lote y verá por qué 00:21:23.320 --> 00:21:24.240 el caso. 00:21:25.950 --> 00:21:28.810 Y, a continuación, en general hay algunos diferencias de cuota en términos 00:21:28.860 --> 00:21:32.360 de cuántas conexiones puede crear con AMQP y SBMP. 00:21:32.410 --> 00:21:35.550 Son también consideraciones importantes Cuando piense: Hola, 00:21:35.600 --> 00:21:38.980 protocolo que voy a utilizar para mi a gran escala, gran número 00:21:39.030 --> 00:21:50.090 ¿de remitentes? Protocolos tan binarios frente a HTTP, por qué es importante 00:21:50.140 --> 00:21:53.280 ¿para mensajería? ¿Cuáles son la clave ¿Consideraciones para la mensajería? 00:21:53.810 --> 00:21:56.350 Sólo quería destacar la clave escenarios en los que sería un 00:21:56.400 --> 00:21:59.380 así que la diferencia puede elegir y decidir si es importante 00:21:59.430 --> 00:22:02.780 o no para su caso particular. 00:22:04.210 --> 00:22:08.070 Caso HTTP, cada vez que realiza destacar, vas a ser 00:22:08.120 --> 00:22:11.480 se puede llegar a una entidad. Para que de uno de los extremos ya sea 00:22:11.530 --> 00:22:13.850 un extremo de envío o un extremo de recepción. 00:22:14.850 --> 00:22:16.820 Puede realizar una operación pendiente. 00:22:17.560 --> 00:22:21.540 Enviar sólo un único o una llamada de recepción única. 00:22:22.370 --> 00:22:26.300 Y la mayoría de los casos, la operación duración no puede ser más de 00:22:26.350 --> 00:22:30.940 60 segundos o lo que sea su carga. equilibrador permite por lo que 00:22:31.480 --> 00:22:33.060 se está ejecutando en el proveedor. 00:22:34.490 --> 00:22:41.480 Así que incorporar una especie de un caso escenarios donde desee 00:22:41.530 --> 00:22:43.390 para hablar con varios puntos finales. 00:22:44.040 --> 00:22:47.590 Muchas veces en comprar direccional escenarios de comunicación está 00:22:47.640 --> 00:22:51.230 va a enviar a una cola y recepción de una suscripción. 00:22:52.080 --> 00:22:55.730 O también enviar una notificación a concentrador. Todos los tipos de 00:22:55.780 --> 00:22:57.060 escenarios pueden estar ahí. 00:22:57.640 --> 00:23:01.320 Con un protocolo binario, en realidad puede crear una única conexión, 00:23:01.370 --> 00:23:08.270 un bocado, un socket único, y todos los vínculos de la 00:23:08.320 --> 00:23:13.320 Contexto AMQP es un multiflexed enlaces más que una conexión HTTP. 00:23:14.500 --> 00:23:18.740 Así obtendrá muchas ventajas por no tener que hacer el protocolo de enlace 00:23:18.790 --> 00:23:22.680 y no tener que establecer ese socket y eso por cada una 00:23:22.730 --> 00:23:26.880 entidad frente haciendo pagar coste una vez y, a continuación, volver a utilizar 00:23:26.930 --> 00:23:29.460 que cuando se habla a varias entidades. 00:23:30.290 --> 00:23:33.900 Dicho escenario se tenga en cuenta. A veces al escribir las entradas de campo 00:23:33.950 --> 00:23:37.240 o puertas de enlace personalizadas en el que esté frente a una gran cantidad de dispositivos, esto 00:23:37.290 --> 00:23:40.690 será una consideración muy importante. 00:23:43.280 --> 00:23:48.250 La otra parte es larga de extracción. ¿Hay algo constante 00:23:48.300 --> 00:23:51.400 acerca de la extracción en las colas, derecha, ¿de Hola, tengo un mensaje? 00:23:51.450 --> 00:23:55.160 ¿tengo un mensaje? Es necesario ¿un mensaje? Aquí porque es 00:23:55.210 --> 00:24:01.040 una conexión en el protocolo AMQP nos mantener activa la conexión. 00:24:01.090 --> 00:24:04.370 No tienes que hacer ninguna operación que tienen una pendiente 00:24:04.420 --> 00:24:09.120 recibir que se puede establecer para un tiempo de espera infinito. Podría 00:24:09.170 --> 00:24:12.110 liquidar un día, una semana. Por lo general no se liquida 00:24:12.160 --> 00:24:16.090 infinito. Se establece por lo que las características de apagado 00:24:16.140 --> 00:24:19.560 aspecto, tal vez 20 minutos o algo así. Pero 00:24:19.610 --> 00:24:24.920 puede tener un largo de extracción pendientes de recepción y no tendrá que preocuparse acerca de 00:24:24.970 --> 00:24:27.640 Batido ciclos de CPU y material de 00:24:29.370 --> 00:24:33.080 obtención de información. Le mantendremos la conexión en viva a través de 00:24:33.130 --> 00:24:37.040 pings o lo que sea el equilibrador de carga es necesario y se les proporcionará 00:24:37.090 --> 00:24:41.640 es la respuesta de baja latencia cada vez que un mensaje se muestra. 00:24:42.360 --> 00:24:45.820 Por lo que se convierte en otra muy importante consideración en términos 00:24:45.870 --> 00:24:50.380 de costo, así como el impacto sobre el el dispositivo. Protocolos tan binarios 00:24:50.430 --> 00:24:53.310 marcar la diferencia en términos de de los escenarios. 00:24:56.240 --> 00:24:59.820 La contraprestación que protocolos trae están en SDK. 00:24:59.870 --> 00:25:03.520 Desea mejorar la productividad. Que desee Para utilizar la base sólida. Que desee 00:25:03.570 --> 00:25:08.220 Para utilizar las bibliotecas de sólido. Por lo que es realmente desea poder elegir 00:25:08.270 --> 00:25:11.010 el protocolo adecuado con el SDK de la derecho. 00:25:12.880 --> 00:25:13.950 Así que para el Bus de servicio, 00:25:15.670 --> 00:25:19.750 Si utiliza .NET y, a continuación, la predeterminada Protocolo SBMP es el valor predeterminado. 00:25:19.800 --> 00:25:24.130 Eso es lo que se utiliza. Puede cambiar para AMQP en cualquier momento y 00:25:24.180 --> 00:25:25.170 También está bien. 00:25:25.850 --> 00:25:28.980 Hay algunas defensas recomendadas en este momento, pero nos vamos a cerrar 00:25:29.030 --> 00:25:33.730 Esta brecha muy pronto. Pero si eres con. NET, es de SBMP, a continuación 00:25:33.780 --> 00:25:36.010 una especie de su defecto escenario hoy. 00:25:37.560 --> 00:25:42.400 Si está utilizando HTTP, si eso de caso, tenemos los contenedores HTTP en un lote 00:25:42.450 --> 00:25:46.160 de sistemas operativos disponibles y muchas bibliotecas disponibles. 00:25:47.010 --> 00:25:50.510 Y, a continuación, con AMQP inicia Para ver un lote de comunidad 00:25:50.560 --> 00:25:51.700 las bibliotecas se ven. 00:25:52.940 --> 00:25:59.670 Estaba siendo un estándar abierto de AMQP diseñado y desarrollado todos con 00:26:00.690 --> 00:26:05.690 teniendo en cuenta, eficaz y confiable, tipo portátil de datos 00:26:05.740 --> 00:26:10.310 representación y flexibilidad en mente. Flexibilidad en términos de 00:26:10.360 --> 00:26:13.470 Si es cliente a cliente bibliotecas o cliente de broker 00:26:13.520 --> 00:26:15.120 o roto a afectaba a las bibliotecas. 00:26:16.680 --> 00:26:20.260 Así que comienza con el AMQP avanzar de estandarización. 00:26:20.310 --> 00:26:26.370 Por cierto, AMQP última fue OASIS estándar Octubre. Sólo borra ISO/IEC. 00:26:27.560 --> 00:26:32.950 Ahora es una empresa internacional reconocida estándar, también. Para que de 00:26:33.210 --> 00:26:35.180 recién salido de la imprenta. 00:26:36.990 --> 00:26:41.560 Pero ¿qué significa para usted es que se verá un montón de bibliotecas 00:26:42.230 --> 00:26:47.750 desarrollado por la biblioteca Apache Qpid conjunto o en la biblioteca de protón 00:26:47.800 --> 00:26:51.010 clientes en varios idiomas. 00:26:51.890 --> 00:26:55.240 C, Java, hay una implementación de JMS. 00:26:56.110 --> 00:27:00.670 De PHP. Todos ellos estarán disponibles que con la Comunidad 00:27:00.720 --> 00:27:05.970 origen compatibilidad con abierta de biblioteca y desarrollando y contribuir 00:27:06.020 --> 00:27:06.740 a y 00:27:07.970 --> 00:27:12.310 con el servicio más o con cualquier otro proveedor que admite la 00:27:12.360 --> 00:27:14.070 Portal AMQP allí. 00:27:14.820 --> 00:27:18.400 Por tanto, si se intenta obtener acceso de Bus de servicio, puede ver los distintos protocolos. 00:27:18.450 --> 00:27:22.940 Tiene muchas opciones de lo que SDK utiliza y qué bibliotecas 00:27:22.990 --> 00:27:34.850 utiliza y no tienes que ser limitada de ninguna manera especial. 00:27:34.900 --> 00:27:36.150 Sincronización, async, frente a lote. 00:27:37.150 --> 00:27:40.650 Ya que somos conscientes de lo que es los matices de protocolo, creo que 00:27:40.700 --> 00:27:45.840 Hablemos acerca de cuándo debe escribimos el código de sincronización, async 00:27:45.890 --> 00:27:49.170 código, código de lote y cuáles son las diferencias reales en términos 00:27:49.220 --> 00:27:54.100 de rendimiento que se puede ver en estos escenarios. 00:27:55.890 --> 00:27:58.710 Procesamiento por lotes claramente aumenta el rendimiento. 00:27:59.460 --> 00:28:04.620 Siempre es una práctica muy, muy buena en cuanto a si tiene 00:28:04.670 --> 00:28:09.260 en el lado de recepción o incluso en el lado de envío, utilizar el procesamiento por lotes. 00:28:09.310 --> 00:28:13.190 La preocupación sólo negativa para padres a veces, con el es latencia 00:28:13.240 --> 00:28:17.490 y vamos a ver lo que puede ser afectados pero no demasiado. 00:28:17.540 --> 00:28:18.880 Hablaremos de eso. 00:28:21.250 --> 00:28:24.830 Async en general es siempre el práctica recomendada. Desea siempre 00:28:24.880 --> 00:28:28.620 Para utilizar siempre que sea posible. Excepto ¿desea enlazar 00:28:28.670 --> 00:28:31.760 el número de llamadas enfrentadas. ¿ no quiero tener una estrecha 00:28:31.810 --> 00:28:34.720 bucle que realiza un número infinito de las llamadas y veremos cómo 00:28:34.770 --> 00:28:37.660 Bus de servicios de ayuda a esa situación. 00:28:40.160 --> 00:28:44.110 Y por último ver el binario protocolos significativamente mayores 00:28:44.160 --> 00:28:47.980 ser capaz de lograr el rendimiento sólo porque estos protocolos, 00:28:48.030 --> 00:28:54.290 se desarrolló el protocolo AMQP con eficacia en cuenta con 00:28:55.260 --> 00:28:58.750 el control de flujo y todo eso integrado en la capa de protocolo 00:28:58.800 --> 00:29:03.950 se verá muchas ventajas se muestran. Así que en realidad 00:29:04.000 --> 00:29:08.550 muestra algunos números. Algunos ejecutando Para poder comparar los números 00:29:08.600 --> 00:29:10.090 Esto por sí mismo. 00:29:20.030 --> 00:29:24.820 Aquí tengo un código que es va a intentar enviar los mensajes. 00:29:26.190 --> 00:29:28.970 Y se puede ver que he dividido hasta en tres partes. 00:29:29.850 --> 00:29:32.930 La primera de ellas hace un envío de sincronización. 00:29:33.690 --> 00:29:38.660 Aquí están las líneas claves. Para cada uno los mensajes, no un qClient y enviar 00:29:38.710 --> 00:29:44.060 desactivar el mensaje. Se trata de una sincronización muy llamada. Pesos de uno para completar. 00:29:44.110 --> 00:29:48.030 Se espera la confirmación proceder desde el servidor, llegar a 00:29:48.080 --> 00:29:51.200 Devuelve desde el cliente, un completo bucle y, a continuación, se mueve en. 00:29:52.910 --> 00:29:56.650 En el segundo se hace de forma asincrónica. 00:29:57.900 --> 00:30:02.780 En esencia es crear Tareas asincrónicas en todas estas 00:30:03.350 --> 00:30:04.470 operaciones de envío. 00:30:05.700 --> 00:30:09.150 Y, a continuación, espera a todos para completar las tareas. 00:30:11.410 --> 00:30:15.170 Y, a continuación, por último, hay una por lotes envío y llamo a pedido 00:30:15.220 --> 00:30:19.430 envío de lote porque con Async, generalmente la gente 00:30:19.480 --> 00:30:22.840 un escenario donde oye, con Async, se pierde el orden. No sé 00:30:22.890 --> 00:30:25.800 sabe que sucederá en primer lugar, Qué ocurrirá a continuación. 00:30:26.300 --> 00:30:29.430 Y por eso hay enviar lotes que es una especie de superior 00:30:29.480 --> 00:30:32.300 en ambos casos porque conserva todos los... o todo el 00:30:32.350 --> 00:30:35.920 procede a través de o todo el lote vuelve y usted 00:30:35.970 --> 00:30:38.910 Vea cuánto rendimiento después Esto puede tener el impacto. 00:30:40.310 --> 00:30:45.300 Así que tiene todo esto apunta a un sencillo en la cola de mensajes muestra. 00:30:45.350 --> 00:30:47.900 Puede ver ahora la el número de cola es cero. 00:30:48.910 --> 00:30:52.560 Y me propongo mi número de mensajes a un número reducido de 100. 00:30:53.660 --> 00:30:54.780 Por lo que vamos a hacer esto. 00:30:57.310 --> 00:30:59.530 Y veremos cuánto. 00:31:00.250 --> 00:31:04.670 Primero está haciendo uso de envío sincronización. Haciendo por tanto de forma sincrónica 00:31:04.720 --> 00:31:09.020 100 llamadas desde mi equipo portátil todos los hacia el servicio y la espalda. 00:31:09.550 --> 00:31:13.970 Tardó unos diez segundos en términos de eso. Y para demostrar que, 00:31:14.020 --> 00:31:18.360 siempre podemos volver, comprobar el número de mensajes y debería 00:31:18.410 --> 00:31:21.860 Ahora, estar en 100. Todos los cien mensajes han hecho aquí. 00:31:23.160 --> 00:31:26.940 Ahora veamos lo que sucede cuando Hacer lo mismo con Async. 00:31:29.190 --> 00:31:30.590 Lo mismo con Async. 00:31:31.940 --> 00:31:36.120 Y no hay diferencia en términos de de los mensajes porque 00:31:37.540 --> 00:31:40.460 los mensajes se han hecho aquí. Ahora es 200 mensajes. 00:31:41.250 --> 00:31:46.450 Tardó.3 segundos. Para todos los mensajes para ENTRAR. 00:31:50.260 --> 00:31:52.620 Lote, es aún más rápido. 00:31:53.370 --> 00:31:54.990 Es en realidad aún más rápido. 00:31:56.080 --> 00:31:58.880 Y el nuevo, porque debajo de la cubierta, Bus de servicio 00:31:58.930 --> 00:32:04.440 está utilizando un protocolo binario cuando se nos mensajes de forma asincrónica, 00:32:04.490 --> 00:32:09.600 mesa fragmentarlos juntos y enviarlas a través de con implícita de procesamiento por lotes. 00:32:10.260 --> 00:32:13.630 Puedes establecer ese valor. El intervalo de vaciado de lote, lo que 00:32:13.680 --> 00:32:17.710 establecer en una fábrica de mensajería, permite ¿Para establecer esa ventana. 00:32:18.310 --> 00:32:21.010 Se puede establecer en una ventana más amplia. Verá más latencia 00:32:21.060 --> 00:32:23.690 pero se verá mucho mejor rendimiento to-end. Puede 00:32:23.740 --> 00:32:27.310 establézcalo en una cantidad de ventana más pequeña y se verá mejor latencia 00:32:27.360 --> 00:32:32.110 y quizá un poco de menor rendimiento. Aunque puede ver el 00:32:32.160 --> 00:32:36.660 magnitud de la diferencia aquí es convierte en términos de sincronización 00:32:36.710 --> 00:32:38.410 frente a Async frente a lote. 00:32:45.080 --> 00:32:49.310 Hagamos ver rápidamente, ya que tenemos nuestros 300 mensajes, 00:32:49.360 --> 00:32:51.110 ¿Qué podemos hacer en el lado de recepción? 00:33:02.730 --> 00:33:06.700 En la recepción, Nota aquí que no soy con el mensaje de las API. 00:33:08.710 --> 00:33:12.460 Esto es sólo para mostrar un manzanas comparación de manzanas de lo que 00:33:12.510 --> 00:33:15.560 la sincronización de las API de aspecto y, a continuación, le mostraré cómo el 00:33:15.610 --> 00:33:18.370 en mensaje API hace todo Esto para usted. 00:33:20.100 --> 00:33:23.620 Se trata de una sincronización recibir. 00:33:24.300 --> 00:33:28.740 Para tener claramente dos llama a ser realizados en el servidor por lo que este 00:33:28.790 --> 00:33:33.600 es en términos del procesamiento de mensajes. Nunca perderá 00:33:33.650 --> 00:33:38.280 un mensaje en el cable o en tránsito debido a que no 00:33:38.330 --> 00:33:41.950 completar, le enviaremos el mismo mensaje de vuelta. 00:33:43.810 --> 00:33:48.260 La siguiente es una Async y aquí se puede ver el lo que estoy haciendo 00:33:49.430 --> 00:33:56.230 es una tarea con un continúe con a continuación, llame el completo allí. 00:34:01.730 --> 00:34:05.290 Y otra vez va a esperar para todos los las tareas se completen de talla 00:34:05.340 --> 00:34:07.770 antes de llamar a mi cronómetro hecho. 00:34:09.300 --> 00:34:10.660 Y por último lote. 00:34:11.330 --> 00:34:12.950 Lote es un poco más interesante. 00:34:13.890 --> 00:34:19.030 En este caso, es más fácil porque me recibir por lotes, tenga en cuenta una pasada 00:34:19.080 --> 00:34:21.370 un número de mensaje es que es 100. 00:34:22.040 --> 00:34:24.860 Ahora que se llama a recibir por lotes con cien no significa 00:34:24.910 --> 00:34:28.830 Obtendrá cientos de mensajes parte posterior. Lo que haremos lo que sea 00:34:28.880 --> 00:34:32.660 es el más óptimo para el cable de base competir por ser consumidor, 00:34:32.710 --> 00:34:35.970 basándose en el número de otro nodos tiene que extraer el mensaje para ver 00:34:36.020 --> 00:34:38.800 generar un lote óptimo y enviar que. 00:34:39.610 --> 00:34:43.320 Y por eso tengo un bucle externo que llama 00:34:43.370 --> 00:34:47.620 recibir el lote hasta que no llegue a Mis cientos mensajes. Quiero 00:34:47.670 --> 00:34:51.430 para realizar este cálculo por lotes hasta Llego a cientos de mensajes. 00:34:53.920 --> 00:34:59.030 Y en este caso, voy a sólo conservar su token bloqueado. 00:34:59.080 --> 00:35:01.160 Eso es todo lo que hago en el mensaje. No tengo que mantener 00:35:01.210 --> 00:35:04.440 todo el mensaje. Una vez que consuma procesar el mensaje, he 00:35:04.490 --> 00:35:07.710 siendo sólo tengo que seguir el símbolo (token) de bloqueo y después llamar 00:35:07.760 --> 00:35:12.940 el lote completo Async con todos los tokens bloqueados allí. 00:35:14.060 --> 00:35:16.940 Y voy a hacerlo en forma de lotes, de nuevo, no voy a esperar 00:35:16.990 --> 00:35:19.490 todo lo que pueda hasta el final ¿completar todos los mensajes? 00:35:19.500 --> 00:35:21.500 [Indiscernible] 00:35:21.660 --> 00:35:22.750 ¿.. .subset allí? 00:35:23.510 --> 00:35:24.840 >> Lo siento, ¿cuál era la pregunta? 00:35:24.890 --> 00:35:28.400 >> Si puede procesar algunos de los mensajes, pudo completar 00:35:28.450 --> 00:35:30.520 ¿que las pruebas, llevar a cabo un subconjunto? 00:35:30.860 --> 00:35:34.510 >> Completamente. Absolutamente. Lote tan completo Async. 00:35:35.250 --> 00:35:39.040 Se puede llamar con un único tokens bloqueado dos bloqueados tokens, lo que 00:35:39.090 --> 00:35:42.720 el conjunto es. Es sólo que será enviar todos esos símbolos bloqueados 00:35:42.770 --> 00:35:46.250 en un lote y volver el resultados de un lote. Por lo que tiene 00:35:46.300 --> 00:35:50.010 ahorro que la latencia y ida y vuelta para hacer todo eso 00:35:50.060 --> 00:35:52.540 y, por lo que es muy eficaz. 00:35:54.300 --> 00:35:56.070 Vamos a verlo que se suma a. 00:35:58.400 --> 00:36:03.230 Aquí tengo el mismo caso. Soy en primer lugar se va a sincronizar y 00:36:03.280 --> 00:36:07.440 trata de recibir todos los cien... los primeros cien mensajes 00:36:07.490 --> 00:36:11.190 allí. Ahora se trata de lo que es peor de nota rendimiento de enviar porque 00:36:11.240 --> 00:36:14.080 se hace dos veces el número de operaciones por lo que deseo recibir 00:36:14.130 --> 00:36:16.460 todos los mensajes, completar todos los mensajes. Recibir todos los mensajes, 00:36:16.510 --> 00:36:20.110 Complete todos los mensajes. Y a continuación, vaya. Así 18 segundos. 00:36:20.160 --> 00:36:24.220 En lugar del diez envía habíamos visto para enviar, tarda 18 segundos 00:36:24.270 --> 00:36:28.760 a esos mensajes y completa ellos. Así que definitivamente no es bueno. 00:36:30.090 --> 00:36:35.330 Con Async porque están haciendo un montón de ellos en paralelo, ahora puedes hacia abajo 00:36:35.380 --> 00:36:38.880 acerca de 2,8 segundos. Ahora, estos números son... 00:36:39.410 --> 00:36:43.230 llévela con un grano de sal, pueden ejecutarse en una red aquí, 00:36:43.940 --> 00:36:47.470 pero se puede ver la magnitud de la diferencia. Puede ver 00:36:47.520 --> 00:36:49.620 Cuánto una mejora que lo hace. 00:36:50.830 --> 00:36:52.580 Y ahora vamos a ver lo que pasa por lotes. 00:36:55.730 --> 00:37:00.720 Estamos. Podemos hacer lo mismo casi características como 00:37:00.770 --> 00:37:04.590 0,1 segundos para todos los cien operaciones que habían tomado... 00:37:05.410 --> 00:37:07.930 sólo porque estamos utilizando lote de allí. 00:37:11.380 --> 00:37:16.640 Ahora, no sólo podrá verlos todos ventajas aquí, pero el servicio 00:37:16.690 --> 00:37:21.680 Bus realmente es muy fácil se escribe este código en particular. 00:37:21.730 --> 00:37:26.700 El código que he mostrado no es muy complejo, pero ¿realmente se tomó 00:37:26.750 --> 00:37:29.280 es un paso más allá y ¿hace aún más fácil. 00:37:30.200 --> 00:37:33.470 Para el... por cierto, sólo quiero mostrar aquí en el 00:37:33.520 --> 00:37:37.280 mensajes que vea esos 300 mensajes allí, si actualiza, se 00:37:37.330 --> 00:37:41.920 debe volver a cero indica No miento. Todos esos 300 00:37:41.970 --> 00:37:43.380 se procesan los mensajes. 00:37:47.270 --> 00:37:54.910 Está bien. Por lo tanto, veremos el mensaje en API, pero en el interés 00:37:54.960 --> 00:37:57.880 de momento, voy a velocidad hasta aquí un poco. 00:38:00.480 --> 00:38:04.820 Por lo que se ha visto la diferencia entre Async, sincronización y lote, y 00:38:04.870 --> 00:38:10.330 Espero que [Indiscernible] siempre usar el procesamiento por lotes. Lo siguiente sobre el rendimiento. 00:38:10.380 --> 00:38:14.100 Colas con particiones y temas. Por lo que lanzamos 2.2 del SDK. 00:38:15.680 --> 00:38:19.590 Básicamente una partición de colas y temas una cola y partición 00:38:19.640 --> 00:38:21.830 es a través de varios nodos de procesamiento. 00:38:23.240 --> 00:38:26.950 Esto no sólo ofrece mucho más potencia el rendimiento en términos de 00:38:27.000 --> 00:38:31.900 Para poder procesar más mensajes, pero ofrece más capacidad de almacenamiento de información. 00:38:32.410 --> 00:38:35.820 Ofrece la posibilidad de tener colas mucho mayores. Da 00:38:35.870 --> 00:38:38.170 es la capacidad de ser más resistente. 00:38:39.270 --> 00:38:42.290 Si está disponible, una partición puede continuar con otra partición 00:38:42.340 --> 00:38:43.580 para procesar los mensajes. 00:38:44.640 --> 00:38:49.270 Por lo que la partición colas y ahora para la mayoría de los escenarios se ofrecerá 00:38:49.320 --> 00:38:52.990 es un rendimiento mucho mejor disponibilidad y resistencia 00:38:53.040 --> 00:38:58.570 vea la característica. Fuera de la caja. Es tan fácil de crear y 00:38:58.620 --> 00:39:02.700 Utilizar colas de partición que es sólo la recomendación en cuanto a 00:39:02.750 --> 00:39:06.470 Utilice siempre estos. Utilizar siempre estos. De hecho, en el siguiente 00:39:06.520 --> 00:39:11.000 Versión de SDK, vamos a hacer es el valor predeterminado que de forma predeterminada, 00:39:11.050 --> 00:39:13.380 Cuando se crea una cola, usted Obtenga una cola con particiones. 00:39:15.690 --> 00:39:20.650 Ahora, es necesario estar al corriente de lo que sucede cuando se realiza 00:39:20.700 --> 00:39:22.590 una cola y en particiones a través de. 00:39:24.060 --> 00:39:26.530 Si no utiliza sesiones, vamos a hablar mucho acerca de las sesiones 00:39:26.580 --> 00:39:30.340 en detalle, pero si no está utilizando las sesiones, a continuación, en esencia, 00:39:31.060 --> 00:39:33.050 tienes que ser... 00:39:34.220 --> 00:39:38.380 debe tener en cuenta que los mensajes es posible que aparezcan en el orden correcto 00:39:38.430 --> 00:39:41.830 ahora porque esencialmente pueden Ir a las distintas particiones 00:39:41.880 --> 00:39:46.770 y si está disponible, una partición se mostrará el mensaje 00:39:46.820 --> 00:39:47.720 en el orden correcto. 00:39:48.460 --> 00:39:51.270 Así que eso es algo a tener en cuenta pero si utiliza sesiones, 00:39:51.320 --> 00:39:54.720 que analizaremos ahora, entonces semántica pedida 00:39:54.770 --> 00:39:56.100 se conservan completamente. 00:39:57.120 --> 00:40:02.330 Y veremos cómo. Sólo para mostrar el código aquí, en cualquier momento 00:40:02.380 --> 00:40:05.590 crear una cola no existe un único propiedad EnablePartitioning. 00:40:05.640 --> 00:40:08.720 Hoy en día se establece en false de forma predeterminada. Como he dicho en el siguiente 00:40:08.770 --> 00:40:10.040 SDK será true. 00:40:10.780 --> 00:40:13.750 Tan sólo debería establecer. Por la forma no sé cómo se 00:40:13.800 --> 00:40:18.770 por lo general lo hacen pero mi filosofía en general, nunca es copia 00:40:18.820 --> 00:40:20.730 código que aparece en una presentación de PowerPoint. 00:40:21.330 --> 00:40:24.470 No sé si eso funciona para ¿chicos. Nunca copiar 00:40:24.520 --> 00:40:28.150 código que ver en PowerPoint porque será más simple 00:40:28.590 --> 00:40:32.710 y basic tipo de código que cualquiera puede colocar allí. En este 00:40:32.760 --> 00:40:35.500 caso está bien. Sólo configura una propiedad, son, por lo está bien. 00:40:35.550 --> 00:40:38.540 Pero si alguna vez mostraba que el código en PowerPoint, no copie. 00:40:40.650 --> 00:40:46.660 Rendimiento de la conexión así. Hemos hablado acerca de remitentes. Hemos visto 00:40:46.710 --> 00:40:50.290 cómo las conexiones binarias son realmente, muy importante. Hay 00:40:50.340 --> 00:40:55.090 algunos casos en que podría enviar mediante un tubo de grasa muy. 00:40:55.660 --> 00:40:58.340 Piense en ello como su fondo por lo que estamos intentando en los mensajes de la cola. 00:40:58.390 --> 00:41:03.370 Tienes un montón de los registros que desee Para empujar arriba y cosas así. 00:41:04.400 --> 00:41:08.450 En algún momento, creando más conexiones TCP físicas puede 00:41:08.500 --> 00:41:12.630 ser una buena idea y puede hacerlo fácilmente. Cada mensaje 00:41:12.680 --> 00:41:16.220 en la instancia de fábrica para una clase instancia de fábrica de mensajería 00:41:16.270 --> 00:41:18.390 corresponde a una conexión de PCP. 00:41:19.390 --> 00:41:22.550 Por lo que el mayor número de clientes de cola y lo que va a crear 00:41:22.600 --> 00:41:25.680 de la misma fábrica como mostré se están multiplexado todos 00:41:25.730 --> 00:41:31.430 las conexiones en el mismo socket TCP. Por lo tanto, crear más fábricas de mensajes. 00:41:31.480 --> 00:41:33.700 Y si se crea más de mensajería fábricas, sólo obtendrá más 00:41:33.750 --> 00:41:38.720 se pueden insertar los tubos y más datos a través de para una consideración clave 00:41:38.770 --> 00:41:42.540 Para eso. Resistencia de nivel de conexión se basa. Una vez que 00:41:42.590 --> 00:41:46.140 crear una fábrica de mensajería, nunca debe descartarlo. 00:41:46.190 --> 00:41:49.320 Si la conexión se interrumpe, vamos a Vuelva a crearla. Si el vínculo se rompe 00:41:49.370 --> 00:41:52.740 a una cola, se le vuelva a crearla. Lo que se volverá a generar es 00:41:52.790 --> 00:41:54.860 en términos de lo que nunca debe hacer esto... 00:41:55.370 --> 00:41:58.030 tiene que deshacerse de este objeto y volver a crear este objeto. 00:41:58.310 --> 00:42:02.780 Cree varios de ellos y volver a utilizar Por tanto como es necesario. 00:42:05.910 --> 00:42:07.540 Por lo nos lleva a las sesiones. 00:42:08.520 --> 00:42:11.670 Ya te digo a tomar todos estos remitentes gran número 00:42:11.720 --> 00:42:14.910 de remitentes y multiplexar a todos en muy pocos 00:42:14.960 --> 00:42:17.850 de colas, ¿cómo va ¿en el servidor en realidad? 00:42:17.900 --> 00:42:21.110 Hemos visto tipo Orleans de marco y eso, que son todos 00:42:21.160 --> 00:42:23.460 intentando desmultiplexar la secuencia, 00:42:24.720 --> 00:42:26.530 desmultiplexar la secuencia. 00:42:28.490 --> 00:42:33.070 Son una maravilla construida en sesiones función de servicio de Bus que 00:42:33.120 --> 00:42:37.130 crea esencialmente las subcolas. Cada sesión se puede considerar 00:42:37.180 --> 00:42:40.290 de como una subcola cuando una cola llena. 00:42:41.480 --> 00:42:44.860 Y la naturaleza original sólo establecer el identificador de sesión. 00:42:44.910 --> 00:42:46.840 Es la única uno propiedad debe establecer. 00:42:48.090 --> 00:42:51.240 El receptor es donde el paradigma cambia. 00:42:52.050 --> 00:42:56.090 El receptor ya no va y dice Dame el mensaje siguiente. 00:42:56.140 --> 00:42:59.670 El receptor dice me da el siguiente sesión. Dame la siguiente 00:42:59.720 --> 00:43:02.690 subcola que tiene algunos mensajes y entraré en proceso 00:43:02.740 --> 00:43:06.760 orden con que irá de procesarlos un estado, que se podría almacenar 00:43:06.810 --> 00:43:10.600 para que el receptor. Por tanto, si piensa acerca de millones de dispositivos, 00:43:10.650 --> 00:43:13.290 Ahora se puede considerar en una sola cola, puede hacer que todas estas 00:43:13.340 --> 00:43:18.620 millones de las subcolas y almacén estado por subcola. Por lo tanto muy, 00:43:18.670 --> 00:43:20.410 muy eficaz en este sentido. 00:43:21.050 --> 00:43:24.400 Puede hacer trabajo establece trabajo establecer el anclaje. Lo que significa que puede decir. 00:43:24.450 --> 00:43:29.230 receptor de uno, desea localizar dispositivos de 1 a 100. Por lo tanto, 00:43:29.280 --> 00:43:32.810 Le voy a pedir las sesiones 1 a través de 100 y se fija 00:43:32.860 --> 00:43:33.440 a eso. 00:43:35.000 --> 00:43:39.680 Y por supuesto podrá almacenar estado. Así que voy a mostrar la 00:43:39.730 --> 00:43:43.490 código para esto. Esencialmente, se hace true cuando la sesión de PA 00:43:43.540 --> 00:43:45.270 se crea la cola. 00:43:45.790 --> 00:43:49.670 En el lado de envío, sólo tienes que establecer una propiedad, el identificador de sesión. 00:43:50.530 --> 00:43:55.720 Y, a continuación, recibir por lado, todos los aplicar el mismo tipo de parámetros 00:43:55.770 --> 00:43:59.840 como he mostrado, el mensaje de aceptación sesión, puede aceptar 00:43:59.890 --> 00:44:03.730 la sesión con el ID del mensaje o ahora ¿qué hemos sólo publicado 00:44:03.780 --> 00:44:08.760 es una manera muy sencilla de ser capaz de hacer 00:44:11.810 --> 00:44:13.010 receptores de la sesión. 00:44:14.920 --> 00:44:18.080 Así abrirá un remitente de la sesión. 00:44:18.970 --> 00:44:21.810 Ya nos dimos cuenta de que el procesamiento por lotes es la mejor forma de enviar 00:44:21.860 --> 00:44:25.740 por lo que está haciendo todo el remitente para cada sesión ID se va 00:44:25.790 --> 00:44:30.240 enviar tantos mensajes como el ID. de sesión más uno. Por tanto, si tiene 00:44:30.290 --> 00:44:33.480 Identificador de la sesión, voy a enviar dos mensajes. Si se trata de sesión 00:44:33.530 --> 00:44:36.070 ID de dos, voy a enviar tres mensajes y así sucesivamente. 00:44:37.350 --> 00:44:38.920 Así que comenzaré sólo al remitente. 00:44:39.880 --> 00:44:43.910 Y aquí, si mira esta cola, en el ejemplo de message queue, 00:44:44.580 --> 00:44:49.140 Cuando se creó la cola, el extra sólo una propiedad, establecer 00:44:49.190 --> 00:44:55.090 era, la propiedad de sesión requerida. Fue la única diferencia. 00:44:55.670 --> 00:44:59.940 Ahora cuando vaya a este particular cola y ver que tiene 00:44:59.990 --> 00:45:02.440 propiedades, este 00:45:08.230 --> 00:45:09.410 ver... 00:45:11.710 --> 00:45:16.480 requiere es propiedad de sesión False. Eso no es bueno. 00:45:16.530 --> 00:45:20.780 Está bien. Voy a eliminar esta cola después. 00:45:24.670 --> 00:45:34.390 Crear en el ejemplo de sesión del mensaje. 00:45:37.280 --> 00:45:38.780 Requieren la sesión. 00:45:45.040 --> 00:45:47.020 Se va a leer en el remitente. 00:45:51.490 --> 00:45:53.840 Así se iniciará el envío de mensajes. 00:46:09.430 --> 00:46:18.880 Supongo que no encuentra que nombre de la cola ahora. 00:46:18.890 --> 00:46:20.800 [Indiscernible] 00:46:20.870 --> 00:46:27.580 >> AH, ¿? En las sesiones de mensaje... AH, ahí. 00:46:29.640 --> 00:46:36.750 Perfecto. Permíteme cambiar ejemplo de sesión mensaje en a. 00:46:39.450 --> 00:46:40.630 Muchas gracias. 00:46:42.100 --> 00:46:43.360 Ahora ejecutemos este tipo. 00:46:46.770 --> 00:46:49.710 Ahí. Dicho todos los envío de mensajes. Ahora voy a mostrar 00:46:49.760 --> 00:46:54.350 es lo que el código de recepción parece que para esto. 00:46:55.510 --> 00:46:59.710 Ésta es la nueva API que sólo hemos publicado, el de 00:46:59.760 --> 00:47:02.010 API de procesamiento de mensajes. 00:47:03.430 --> 00:47:07.500 En su función de trabajador de Azure, Voy a cambiar esto también. 00:47:10.890 --> 00:47:14.690 En su función de trabajador de Azure, en el en el método de inicio que haría 00:47:14.740 --> 00:47:19.540 la misma, basta con comprobar si existe la cola y crear el qClient. 00:47:20.250 --> 00:47:24.120 En la regla de ejecución, observará que el el código obtiene aún más sencillo. 00:47:25.610 --> 00:47:29.270 Todo lo que haces es esto un registro llamada. 00:47:29.900 --> 00:47:32.770 Decir registrar un controlador de sesión. 00:47:33.670 --> 00:47:36.500 Y eso es todo. No engañar bucles para escribir. 00:47:37.120 --> 00:47:38.950 Ninguna duración para administrar. 00:47:39.580 --> 00:47:43.920 Todo eso se encargará de la biblioteca de cliente para TI. 00:47:43.970 --> 00:47:48.540 Sólo tienes que encapsulan todos la lógica de cómo va 00:47:48.590 --> 00:47:53.790 para procesar esa única transmisión en uno clase denominada la mi controlador de sesión. 00:47:54.700 --> 00:47:57.450 Vamos a examinar esta clase y vea lo que estoy haciendo aquí. 00:47:58.700 --> 00:48:02.660 Lo primero es ¿qué debo hacer cuando ¿Aparece el mensaje en realidad? 00:48:05.430 --> 00:48:09.430 En el mensaje, Estoy imprimiendo sólo Me llegó el mensaje y 00:48:09.480 --> 00:48:10.870 Aumentando el recuento. 00:48:11.610 --> 00:48:15.320 Eso es todo lo que hago en esta clase. Count es un miembro privado 00:48:15.370 --> 00:48:19.860 aquí y sólo estamos ahorrando ese valor. 00:48:21.090 --> 00:48:22.960 Por lo que establecemos recuento 00:48:24.710 --> 00:48:28.550 es igual a cero y mantener un recuento es así que todos los procesos. 00:48:29.270 --> 00:48:34.550 En una sesión cerrada, cerrar sesión se llama cuando hay ningún 00:48:34.600 --> 00:48:38.750 más mensajes disponibles para sesión o se ha alcanzado 00:48:38.800 --> 00:48:42.360 el número máximo de moneda. Hablamos acerca de cuántos simultáneamente 00:48:42.410 --> 00:48:43.630 Desea poseer. 00:48:44.260 --> 00:48:48.230 Si ha llegado a su máximo recuento de simultaneidad de cuántos 00:48:48.280 --> 00:48:53.040 las sesiones de proceso, lo llamaremos Cierre de sesión y abrir 00:48:53.090 --> 00:48:57.610 una nueva sesión, dependiendo de qué mensajes están disponibles. Por lo que cerrar 00:48:57.660 --> 00:49:00.700 su oportunidad de decir que tengo llegado un conjunto de mensajes, ha 00:49:00.750 --> 00:49:03.900 los procesa para este en particular sesión y ahora debe 00:49:03.950 --> 00:49:05.580 Guardar estado de. 00:49:07.140 --> 00:49:10.730 Y aquí se puede ver todo lo que estoy haciendo llama a definir estado y get 00:49:10.780 --> 00:49:15.250 estado que se encuentra en la objeción de la sesión. Estas son básicamente las secuencias. 00:49:16.050 --> 00:49:20.770 Y guardar el valor de recuento cada vez que se cierra la sesión. 00:49:21.780 --> 00:49:26.130 Y, a continuación, el final es el error caso de cuando se pierde una sesión. 00:49:27.420 --> 00:49:31.050 Recuerde, la razón por la que puedas para correlacionar todos estos mensajes 00:49:31.100 --> 00:49:34.310 es debido a bloquear una sesión para usted. Nos aseguramos de que está 00:49:34.360 --> 00:49:38.790 el receptor único que mensajes de ese subcola, 00:49:38.840 --> 00:49:40.510 ese subsesión. 00:49:41.190 --> 00:49:43.780 Y siempre puede perder un bloqueo. Un bloqueo se perdía porque 00:49:43.830 --> 00:49:47.660 de un error en el servidor. Podría se pierden debido a la conexión 00:49:47.710 --> 00:49:51.410 problemas o tal vez su procesador colgado y perdió el bloqueo 00:49:51.460 --> 00:49:55.290 debido a que, a continuación, hacer una operación allí, por lo que siempre puede obtener 00:49:55.340 --> 00:49:58.940 llama a este error. En este caso, todo lo que hará es abandonar el 00:49:58.990 --> 00:50:03.500 conjunto local de cambios y mover en. En cuanto a. 00:50:04.870 --> 00:50:07.150 Vamos a ver lo que parece. 00:50:07.670 --> 00:50:08.790 Un funcionamiento real. 00:50:10.210 --> 00:50:10.800 ¿Hubo alguna pregunta? 00:50:10.850 --> 00:50:11.930 ¿>> Funciona igual? 00:50:13.740 --> 00:50:17.500 ¿>>, Así que la pregunta era: Esto funcionará el mismo para las suscripciones? Cien por ciento. 00:50:17.550 --> 00:50:21.170 Es completamente simétrico. Si recibe de una cola 00:50:21.220 --> 00:50:24.130 o que está recibiendo desde una suscripción. 00:50:25.440 --> 00:50:28.920 Ésta es la función de trabajador ahora. Permiten Me comprobar lo que realmente rápidamente 00:50:28.970 --> 00:50:30.850 buscado el número de cola Después de la 00:50:32.060 --> 00:50:36.390 se realizó la función de envío. Aspecto tiene mensajes de 3.700 derecho 00:50:36.440 --> 00:50:40.610 Ahora, 33, parece procesamiento se inició. 00:50:41.650 --> 00:50:56.690 Permítame ir allí... Vamos. Ahora. 00:50:56.740 --> 00:51:03.350 Buena. Así que ahora mi equipo trabajar con y 00:51:03.400 --> 00:51:06.090 puede ver miles de procesamiento y miles de mensajes. 00:51:06.890 --> 00:51:10.740 Y el código que escribí pensar muy simplista 00:51:10.790 --> 00:51:15.170 acerca de sólo una sesión simple, un solo sesión y no tenía 00:51:15.220 --> 00:51:18.800 escribir un bucle de recepción única. Sólo tenía que registrar el controlador de canalización. 00:51:19.200 --> 00:51:23.370 El controlador que he mostrado es el caso simple donde se 00:51:23.420 --> 00:51:28.420 puede tener instancias de esta creada y no estás haciendo cualquier inicialización. 00:51:28.450 --> 00:51:32.020 Tenemos una fábrica de copia de seguridad que También está disponible. Puede hacer 00:51:32.070 --> 00:51:36.960 un generador de controladores de registro y forma de que controlar la creación 00:51:37.010 --> 00:51:38.700 semántica de eso también. 00:51:40.370 --> 00:51:43.560 Pero aquí, puede ver persisten sesión cerrada y estada. 00:51:44.420 --> 00:51:48.340 Voy a acercar aquí por lo que la gente puede ver claramente lo que pasó. 00:51:49.070 --> 00:51:54.740 Si ve cada sesión, sesión estado era 22 de sesión 21. 00:51:54.790 --> 00:51:57.810 Estado de la sesión era 46 para la sesión de 45. 00:51:58.620 --> 00:52:03.770 Porque esa clase tiene sólo los mensajes que pertenecían a esa sesión. 00:52:04.200 --> 00:52:08.320 Todo lo que era el archivo y multiplexado fácil y todo lo que se ha controlado. 00:52:08.370 --> 00:52:12.410 bus de servicio para usted. Así que cuando piensa acerca de multiplexación 00:52:12.460 --> 00:52:15.990 un gran número de remitentes en conocer un número reducido de colas, 00:52:16.040 --> 00:52:19.260 que no se ha perdido la simplicidad de ser capaz de procesar 00:52:19.310 --> 00:52:23.800 en el back-end mediante Estas secuencias individuales 00:52:30.570 --> 00:52:34.260 allí. 00:52:37.740 --> 00:52:41.000 Hablamos sobre el estado de sesión. Correlación con las sesiones. 00:52:41.350 --> 00:52:46.020 Así que, para resumir, en realidad antes de que resumimos, tener acceso. 00:52:46.590 --> 00:52:49.230 Por lo que es otro punto clave Cuando tienes estas muy, muy 00:52:49.280 --> 00:52:52.530 gran número de remitentes, ¿cuál es el ¿el modelo de autenticación? ¿Qué es la seguridad. 00:52:52.580 --> 00:52:55.750 ¿modelo que se va a utilizar? Así que diría acceso compartido 00:52:55.800 --> 00:52:58.420 firma es definitivamente el recomienda el modelo de autenticación. 00:52:59.010 --> 00:53:02.150 Hay mucho más detalle. De hecho el deck cuenta con más detalle 00:53:02.200 --> 00:53:08.190 Cómo configurar las firmas de acceso compartido. Puede ir al portal 00:53:08.540 --> 00:53:10.040 y la gestión de colas. 00:53:10.910 --> 00:53:15.270 Aquí tengo el MONTÓN de cola que se utilizan tipos desde el sitio Web. 00:53:16.050 --> 00:53:18.850 Y puedo ir aquí y configurar. 00:53:19.420 --> 00:53:23.650 Tenga en cuenta que tenía Oh... 00:53:23.660 --> 00:53:23.720 [Indiscernible] 00:53:23.700 --> 00:53:25.290 >> Lo siento. Lo siento. 00:53:28.330 --> 00:53:33.790 Por lo que pasó el portal de Azure y Mi cola de lote seleccionado. 00:53:34.890 --> 00:53:38.340 Y, en este caso, cuando voy a configurar ficha, vea Mi compartida 00:53:38.390 --> 00:53:42.420 tener acceso a nombres de directiva aquí. Así que en ese ejemplo de sitio Web que 00:53:42.470 --> 00:53:45.240 anterior, si llama a una operación de recepción, deberá esto sería realmente 00:53:45.290 --> 00:53:49.650 un error porque ahora mismo, la única Esta autorización es enviar. 00:53:50.890 --> 00:53:54.310 Pero puedo ir fácilmente y agregar la escucha autorización para esa regla. 00:53:55.730 --> 00:53:56.440 Tiene que guardar. 00:53:57.340 --> 00:53:58.640 Diciendo que la cola de la actualización. 00:53:59.190 --> 00:54:00.050 Y ahora cualquiera 00:54:01.700 --> 00:54:06.780 token que se generó para este regla tendrán la capacidad 00:54:06.830 --> 00:54:11.480 para enviar y recibir. Así que ahora Puedo ir aquí y haga clic en recibir, 00:54:12.880 --> 00:54:15.660 Bueno, aquí tienes. Parece que la gente ha estado enviando mensajes. 00:54:15.710 --> 00:54:18.320 Ahora vaya a la sesión de charla va, pueden quedarse en contacto 00:54:18.370 --> 00:54:20.210 entre ellos en línea. 00:54:21.490 --> 00:54:24.220 Firma de acceso compartido por lo tanto, son muy, muy ligero, muy 00:54:24.270 --> 00:54:28.290 modelo de fácil de usar. Si necesita saltar a una clase de SDS de modelo, 00:54:28.340 --> 00:54:35.540 son que ACS es totalmente compatible. ACS es siendo la mejor opción allí. 00:54:35.590 --> 00:54:37.660 Acaba de ver con las colas. 00:54:39.580 --> 00:54:43.390 Para resumir, hemos visto los protocolos. ¿Por qué son relevantes. 00:54:43.650 --> 00:54:47.970 Fuimos a través de la correlación de la secuencia, ¿Por qué no es necesario que 00:54:48.020 --> 00:54:50.860 Cree una cola de cada dispositivo. No desea administrar 00:54:50.910 --> 00:54:53.980 colas de un millón. Pero no lo hace desea escribir código que 00:54:54.030 --> 00:54:57.760 tiene que ser muy complejo demasiado. Por lo tanto las dos son muy, muy 00:54:57.810 --> 00:55:00.840 con el servicio de soporte Bus de mensajería. 00:55:01.900 --> 00:55:05.320 Colas, temas, suscripciones. Simétrico en todas ellas. 00:55:05.370 --> 00:55:08.990 Todo lo que he mostrado en términos de lo que funciona con colas para 00:55:09.040 --> 00:55:12.280 sesiones funciona de la misma manera con los temas y las suscripciones 00:55:12.330 --> 00:55:16.290 y los filtros. Al crear una suscripción, Acabas de decir requiere 00:55:16.340 --> 00:55:18.360 sesión en él es igual a true o no. 00:55:21.680 --> 00:55:22.910 La escala en los receptores. 00:55:27.210 --> 00:55:30.850 Visual Studio tiene este desafío donde puede iniciar una tonelada de 00:55:30.900 --> 00:55:34.520 las instancias de la IDE y luego puede volver y cambiar tu 00:55:34.570 --> 00:55:37.840 en uno de ellos y el perfil desea que todos ellos para sincronizar. 00:55:38.640 --> 00:55:41.980 ¿Cómo va a comunicarse ¿en todos estos casos? 00:55:42.490 --> 00:55:45.600 Y estos son instancias dinámicas También porque el número de VS 00:55:45.650 --> 00:55:49.910 las instancias que han lanzado varía Dependiendo del día de la semana. 00:55:49.960 --> 00:55:53.530 En realidad, tenemos las estadísticas para mostrar que, por cierto. 00:55:53.580 --> 00:55:57.170 Las personas abren instancias más el miércoles que abren el viernes. 00:55:57.220 --> 00:56:04.740 Por lo que la productividad es tanque antes del viernes. De todos modos, el problema puede volver a 00:56:04.790 --> 00:56:07.440 resolver con temas donde se tener millones y millones de 00:56:07.490 --> 00:56:11.110 puntos finales. Y desea que todos escuchar sus propios uno de ellos 00:56:11.160 --> 00:56:14.070 suscripción única para los mensajes. 00:56:15.150 --> 00:56:19.140 De si se generan dichos mensajes. en el back-end basado 00:56:19.190 --> 00:56:22.840 en un cambio en el sistema o algo como lo que desea enviar 00:56:22.890 --> 00:56:26.270 una notificación a un usuario, que desee. para notificar a los de Windows 00:56:26.320 --> 00:56:30.510 cuadro 7 no se encuentra ninguna notificación servicio. Desea notificar 00:56:30.560 --> 00:56:34.520 ellos y digo hola hay una nueva actualización disponible en Visual Studio, 00:56:34.570 --> 00:56:39.970 Vaya a descargarlo. O lo que es más importante darles a una especie de baja latencia 00:56:40.020 --> 00:56:43.890 del tubo donde si se realizan cambios en una instancia de VS, otro 00:56:43.940 --> 00:56:45.430 Sincronización las instancias de VS. 00:56:46.140 --> 00:56:48.340 Puede demanda temas y suscripciones para eso. 00:56:49.760 --> 00:56:52.470 Por lo que piense es conceptualmente como un usuario de tema por VS. 00:56:53.200 --> 00:56:58.800 Tiene una instancia de suscripción por VS siempre conectado mediante Carreora. 00:56:58.850 --> 00:57:03.260 Carreora nos da mucha conexión en el que tiene la eficiencia 00:57:03.310 --> 00:57:07.830 nos millones y millones de simultánea, las secciones con 00:57:07.880 --> 00:57:12.350 muy baja sobrecarga, esperando para notificaciones ocasionales. 00:57:12.380 --> 00:57:14.840 Es la diferencia acerca de las notificaciones. Son muy ocasionales 00:57:14.890 --> 00:57:18.080 en la naturaleza. ¿Cuántas personas ¿cambiar el color de su perfil? 00:57:19.770 --> 00:57:20.260 ¿Un día? 00:57:20.310 --> 00:57:22.960 ¿Semana? Espero que no todos los días. 00:57:23.790 --> 00:57:25.160 Depende de su estado de ánimo que supongo. 00:57:26.260 --> 00:57:29.100 Pero no sucede muy a menudo. ¿Con qué frecuencia tienen las actualizaciones 00:57:29.150 --> 00:57:33.660 ¿expulsar? No muy a menudo. Pero Tienes este tipo BNS 00:57:33.710 --> 00:57:38.290 de la infraestructura disponible para ¿dónde tiene conexiones 00:57:38.340 --> 00:57:41.780 Esperando esa notificación. Cuando dicha notificación 00:57:41.830 --> 00:57:45.170 se convierte en disponible, lo quieres en una instantánea. Desea derecho 00:57:45.220 --> 00:57:46.040 en ese momento. 00:57:51.000 --> 00:57:54.990 Aquí tienes que cree acerca de y se debe pensar 00:57:55.040 --> 00:57:59.320 acerca de los flujos de mensajes. Dado que en la actualidad temas le permiten hasta 2000 00:57:59.370 --> 00:58:03.170 las suscripciones y cuando está pensando en de escala en el número 00:58:03.220 --> 00:58:07.420 de receptores, 2000 puede ser suficiente o 2000 puede no ser suficiente. 00:58:07.980 --> 00:58:10.910 Si piensa en Visual Studio, una sola persona tener más 00:58:10.960 --> 00:58:13.700 de 2000 instancias de el IDE ejecuta es 00:58:16.030 --> 00:58:20.210 casi imposible. Tal vez es posible, pero no sucede. 00:58:20.520 --> 00:58:24.520 Para ellos, un usuario de tema por VS está bien, pero para los que es posible que 00:58:24.570 --> 00:58:27.660 Puede que todo el mundo está escuchando a la misma fuente. Desea 00:58:27.710 --> 00:58:30.790 ser capaz de enviar todo el mundo... un solo mensaje y enviarlo 00:58:30.840 --> 00:58:34.790 amplia difusión a todos los usuarios: Bueno, entonces desea encadenar temas. 00:58:35.250 --> 00:58:38.680 Y hacer que ese uso auto reenvío. 00:58:39.850 --> 00:58:43.350 No voy a saltar en grupo Estos detalles del patrón en 00:58:43.400 --> 00:58:45.280 condiciones de cómo configurar los filtros. 00:58:45.800 --> 00:58:48.520 Todos estos son ejemplos de MSDN.com. 00:58:49.130 --> 00:58:55.380 En este ejemplo concreto se llama lista. Hay un ejemplo de llamada 00:58:55.430 --> 00:58:58.720 publicar suscribirse. El código completo para estos está disponibles. 00:58:58.770 --> 00:59:02.570 Animo a que los chicos a tomar un aspecto, pero con estos temas. 00:59:02.620 --> 00:59:06.190 realmente puede arreglar estos ricos flujos son donde todos los mensajes 00:59:06.240 --> 00:59:09.930 no es necesario que se enrutan a todos la gente de 2 millones y, a continuación, 00:59:09.980 --> 00:59:14.280 quitar cada vez. Puede obtener. enrutar a una persona, a muchas 00:59:14.330 --> 00:59:18.680 las personas, o en un tipo sin fin de caso donde simplemente escribir la dirección. 00:59:18.730 --> 00:59:19.660 Como el correo electrónico. 00:59:20.190 --> 00:59:23.130 En este caso es como decir el mensaje en primer lugar, puedo decir 00:59:23.180 --> 00:59:24.230 coma, segundo. 00:59:25.130 --> 00:59:27.850 Y me dirijo a dos dispositivos el primer dispositivo y el segundo 00:59:27.900 --> 00:59:30.770 dispositivo o dos suscripciones la primera y la segunda. 00:59:30.820 --> 00:59:35.390 Porque tienen reglas configuradas como primer y segundo allí. 00:59:36.390 --> 00:59:40.470 Así que, fíjese sub de pub (invisible) 00:59:42.610 --> 00:59:47.050 reenvío automático. Muy, muy fácil Para utilizar. Básicamente se crea 00:59:47.100 --> 00:59:52.150 el destino de la cola en primer lugar y en la cola de origen, 00:59:52.200 --> 00:59:55.970 Agregar una propiedad única. La propiedad única se denomina origen.Pasar, 00:59:57.220 --> 01:00:00.600 a la cola de destino y . Todos los mensajes procedentes 01:00:00.650 --> 01:00:03.280 en la cola de origen, vaya a la cola de destino. 01:00:03.330 --> 01:00:10.030 Las fuentes pueden ser las suscripciones y colas. Las auditorías pueden ser temas 01:00:10.080 --> 01:00:10.960 y las colas. 01:00:13.190 --> 01:00:16.800 Establecer tantos, completamente simétrico disculpas de fuente como se haría 01:00:16.850 --> 01:00:18.810 como y verlo. 01:00:19.400 --> 01:00:22.540 Si tiene casos transitorios donde Tienes suscripciones que 01:00:22.590 --> 01:00:23.390 vas, 01:00:24.660 --> 01:00:28.430 Puede utilizar la eliminación automática en inactivo. Por lo tanto También es muy función. 01:00:28.480 --> 01:00:32.570 ¡ Administrar gran número de conexiones transitorias. De hecho 01:00:32.620 --> 01:00:35.640 uno de los escenarios clave, se trata de que se utiliza es por SignalR y 01:00:35.690 --> 01:00:38.590 E/S de socket. Son muy, muy transitorio en la naturaleza. 01:00:38.640 --> 01:00:40.200 Conexiones, conexiones. 01:00:41.380 --> 01:00:43.700 Las cargas se agregan y se quitan los nodos. 01:00:44.600 --> 01:00:48.680 Para que utilicen el Bus de servicio como copia de seguridad reproducir en esencia son 01:00:48.730 --> 01:00:52.540 escribir una suscripción por nodo siempre que incluye una nueva suscripción 01:00:52.590 --> 01:00:56.160 no una nueva conexión se enciende un nodo nuevo aparece, cuando se 01:00:56.210 --> 01:00:57.260 Agregar servidores. 01:00:58.320 --> 01:01:03.210 Y, a continuación, utilizar temas y suscripción como la canalización espera a 01:01:03.260 --> 01:01:05.970 transferencia de mensajes entre los nodos a escala más amplia. 01:01:07.010 --> 01:01:10.090 Y, a continuación, cuando un nodo se va, la suscripción caduca, los 01:01:10.140 --> 01:01:17.490 los mensajes se han ido allí. Ambos de esos código son código abierto. 01:01:17.540 --> 01:01:20.240 Ambos están disponibles si desea escala horizontal, salida de señal o Socket 01:01:20.290 --> 01:01:24.720 ENTRADA-salida porque necesita una mensajería duradera canalización al final, servicio 01:01:24.770 --> 01:01:27.980 Bus tiene implementaciones para las dos. 01:01:29.920 --> 01:01:33.050 Quiero hablar un poco construido acerca de la disponibilidad déjame 01:01:33.100 --> 01:01:36.780 cubrir rápidamente. Sé Casi estamos en el tiempo 01:01:38.830 --> 01:01:42.440 código debe ser resistente a la operación errores así como conectado 01:01:42.490 --> 01:01:43.470 con los problemas. 01:01:43.990 --> 01:01:46.750 Colas con problemas de entrega, como dije Realmente ayudará a. Ayudan a 01:01:46.800 --> 01:01:50.790 en la aplicación de nivel donde decivilization de un mensaje o 01:01:50.840 --> 01:01:51.830 algo puede fallar. 01:01:52.980 --> 01:01:57.440 Todos los mensajes que se inicia el servicio de autobús tiene una propiedad transitoria en 01:01:57.490 --> 01:01:58.020 en él 01:01:59.480 --> 01:02:02.780 claramente y simplemente facilita Para saber si usted 01:02:02.830 --> 01:02:04.350 tiene que vuelva a intentarlo o no. 01:02:05.090 --> 01:02:08.560 De manera predeterminada, somos automáticamente vuelve a intentar. He hablado 01:02:08.610 --> 01:02:12.090 acerca de los tiempos de espera de operación básicamente tiempos de espera. De forma predeterminada 01:02:12.140 --> 01:02:15.190 tiempos de espera de la operación se establecen en 60 segundos que significa que si se 01:02:15.240 --> 01:02:19.720 realizar un envío de llamada, es posible que una vez, no lo intentaremos de nuevo, después de 01:02:19.770 --> 01:02:22.980 tres segundos. Puede presentar dos veces. Vamos a inténtelo otra vez después de diez segundos. 01:02:23.030 --> 01:02:27.840 En que 60 segundos nos da, vamos a Pruebe a hacer esa llamada se realice correctamente. 01:02:27.890 --> 01:02:29.740 Y si no, le enviaremos se devuelven. 01:02:31.320 --> 01:02:33.650 Si tiene algún otro lugar para conservarlo, está bien. 01:02:33.700 --> 01:02:36.920 En caso contrario, compruebe como transitorio y Enviar atrás, entonces. 01:02:38.160 --> 01:02:42.430 Temas y colas de partición disponibilidad mejorada considerablemente. 01:02:43.080 --> 01:02:48.230 Mejora de orden de magnitud. Por lo tanto muy aconsejable usar 01:02:48.280 --> 01:02:49.710 Esta característica. 01:02:51.830 --> 01:02:55.280 Vuelva a intentar la política predeterminada. No desactivarlo, por favor. 01:02:57.200 --> 01:02:59.970 Espacios de nombres emparejados. El último lo que hablaré hoy. 01:03:00.490 --> 01:03:03.540 Si utiliza un Bus de servicio con el nombre de espacio, los mensajes se transmiten bien 01:03:03.590 --> 01:03:08.210 a través de y, a continuación, todos los datos Centro va cabeza o al menos 01:03:08.260 --> 01:03:13.570 el espacio de nombres completo es una cabeza. Se creará el espacio de nombre incorrecto 01:03:13.620 --> 01:03:15.790 la copia de seguridad espacio de nombres. Crear la copia de seguridad espacio de nombres. 01:03:15.840 --> 01:03:19.190 Proporcione sólo a nosotros y a inicio de almacenar mensajes en 01:03:19.240 --> 01:03:23.440 la copia de seguridad espacio de nombres. Por lo que cualquiera mensaje que no puede entrar en el 01:03:24.140 --> 01:03:25.350 suban a la parte posterior. 01:03:26.210 --> 01:03:29.450 En algún momento se iniciará los mensajes que fluye a través de. El sistema 01:03:29.500 --> 01:03:30.340 vuelva. 01:03:31.350 --> 01:03:35.150 Y en este momento tenemos un sifón tendrá los mensajes de estos 01:03:35.200 --> 01:03:39.110 las colas de transferencia y reenqueue ellos a la cola original. 01:03:40.650 --> 01:03:43.590 Para todo ello, el código de remitente no cambia el receptor 01:03:43.640 --> 01:03:46.370 no cambia el código. El remitente y el receptor, como si fueran 01:03:46.420 --> 01:03:48.470 siempre hablando al servicio Espacio de nombres del bus. 01:03:49.240 --> 01:03:54.700 En realidad, estamos creando las colas de transferencia mover 01:03:54.750 --> 01:03:57.870 los mensajes y extracción ellos atrás para usted. 01:03:58.720 --> 01:04:03.160 Y ésta es la única parte de código que se debe modificar. 01:04:03.740 --> 01:04:06.070 Esto no es el único trabajo que tiene Para ello. Hablaremos sobre la 01:04:06.120 --> 01:04:08.520 consideraciones, pero esto es la sólo una parte de código que debe 01:04:08.570 --> 01:04:13.330 modificar que es que cuando se crea una fábrica, que es el 01:04:13.380 --> 01:04:17.690 Ejecute tiempo envía y recibe código clase, usted emparejar con un nombre 01:04:17.740 --> 01:04:21.230 espacio, dices Hola que hay un segundo fábrica, un segundo espacio de nombres 01:04:21.280 --> 01:04:24.130 Administrador con los que desee al combinarse con. 01:04:24.660 --> 01:04:28.600 Y todo lo demás se realiza mediante la en el cliente. Ningún cambio de remitente. 01:04:28.650 --> 01:04:31.470 Ningún cambio de receptor. Código sigue siendo el mismo. 01:04:36.210 --> 01:04:41.520 Ahora, se admite el remitente. Como se vio en el diagrama, 01:04:41.570 --> 01:04:44.590 el receptor no recibirá el mensaje hasta el nombre original 01:04:44.640 --> 01:04:45.760 espacio vuelve. 01:04:46.330 --> 01:04:49.340 Esto es más de una disponibilidad de envío. Ahora por eso 01:04:49.390 --> 01:04:54.000 lo llamamos enviar opciones de disponibilidad. Orden puede perderse porque 01:04:54.050 --> 01:04:57.910 mensajes que se encuentran en la transferencia cola no se mostrará. 01:04:58.630 --> 01:05:02.360 Y, a continuación, extremo a extremos recibir latencia por supuesto puede ser alto. 01:05:02.410 --> 01:05:06.420 Por lo tanto, hay algunas consideraciones pero creo que esto como 01:05:06.470 --> 01:05:10.730 un escenario clave de fabricación tipo de recuperación ante desastres 01:05:12.070 --> 01:05:14.770 nunca escenarios. 01:05:15.810 --> 01:05:18.710 Sólo para cerrar, nos vimos Azure Realmente puede escalar el Bus de servicio 01:05:18.760 --> 01:05:21.870 en todas las dimensiones. Muchos remitentes. Montón de rendimiento. 01:05:21.920 --> 01:05:23.080 Muchos de los receptores. 01:05:23.730 --> 01:05:27.420 Y mejorar la confiabilidad ambas con las nuevas características de salida 01:05:27.470 --> 01:05:31.950 del cuadro como colas de partición y los espacios de nombres o 01:05:32.000 --> 01:05:37.320 hacer que el código se utilizan modelos como Async, por lotes y esas cosas. 01:05:38.100 --> 01:05:41.750 Toneladas de vínculos. Toneladas de recursos. Tener acceso a todo eso. 01:05:41.800 --> 01:05:44.130 Muchas gracias. Pido disculpas por lo que sea.