¿Qué es Service Mesh?

1 ¿Qué es Service Mesh?

Primero hablemos del término Service Mesh, que de hecho es un término muy, muy nuevo. Al igual que la encuesta que acabamos de investigar, la mayoría de los estudiantes nunca han oído hablar de él.

Este término fue utilizado por primera vez por Buoyant, la empresa que desarrolló Linkerd, y se utilizó internamente. Este término se utilizó públicamente por primera vez el 29 de septiembre de 2016. Con la introducción de Linkerd en 2017, Service Mesh entró en el campo de visión de la comunidad tecnológica nacional. Primero se tradujo como "capa de malla de servicios", lo cual es un poco confuso. Después de unos meses de uso, se cambió a una red de servicio. Más adelante les presentaré por qué se llama Grid.

Veamos primero la definición de Service Mesh, que fue dada por William, CEO de Linkerd. Linkerd es el primer Service Mesh de la industria y crearon el término Service Mesh, por lo que esta definición es más oficial y autorizada.

Echemos un vistazo a la traducción al chino En primer lugar, la red de servicios es una capa de infraestructura cuya función es manejar la comunicación entre los servicios y la responsabilidad es lograr la entrega confiable de solicitudes. En la práctica, la malla de servicios se implementa generalmente como un proxy de red ligero, generalmente implementado con la aplicación, pero transparente para la aplicación.

Si observa esta definición directamente del texto, puede encontrarla relativamente vacía y no es fácil entender lo que es. Veamos algo específico.

El modelo de implementación de Service Mesh, primero mire una sola solicitud. Para una solicitud simple, la instancia de la aplicación cliente como el iniciador de la solicitud primero enviará la solicitud a la instancia local de Service Mesh de una manera simple. Estos son dos procesos independientes y se llaman de forma remota.

Service Mesh completará el proceso completo de invocación entre servicios, como el descubrimiento de servicios y el equilibrio de carga, y finalmente enviará la solicitud al servicio de destino. Esto se manifiesta como Sidecar.

La traducción china de la palabra "sidecar" significa "sidecar" o "coche". También existe una traducción rústica llamada "sidecar". Sidecar existe desde hace mucho tiempo y agrega un proxy entre el cliente original y el servidor.

En el caso de múltiples invocaciones de servicios, en esta figura podemos ver que la malla de servicios se encuentra debajo de todos los servicios, esta capa se denomina capa de infraestructura dedicada para la comunicación entre servicios. Service Mesh se hará cargo de toda la red y reenviará todas las solicitudes entre servicios. En este caso, veremos que el servicio anterior ya no es responsable de entregar la lógica específica de la solicitud, sino solo de completar el procesamiento comercial. El vínculo de comunicación entre servicios está separado de la aplicación, presentando una capa de abstracción.

Si hay una gran cantidad de servicios, aparecerá la cuadrícula. En la figura, el cuadrado verde de la izquierda es la aplicación, el cuadrado azul de la derecha es Service Mesh y las líneas azules representan la relación de llamada entre servicios. La conexión entre los sidecars formará una red, que es el origen del nombre de la malla del servicio. En este momento, lo que refleja el agente es diferente al sidecar anterior, formando una malla.

Repasemos las definiciones dadas anteriormente y repasemos estas cuatro palabras clave. En primer lugar, la red de servicios es abstracta, lo que en realidad abstrae una capa de infraestructura fuera de la aplicación. En segundo lugar, la función es lograr una entrega confiable de solicitudes. Implementado como un agente de red ligero. La última palabra clave es ser transparente para la aplicación.

Por favor, preste atención. En la figura anterior, la red puede no ser particularmente obvia en este caso. Pero si se quita la aplicación de la izquierda, y ahora solo se presentan las llamadas entre Service Mesh y ellos, la relación será particularmente clara en este momento, y es una red completa. Este es un punto clave muy importante en la definición de Service Mesh, que se diferencia de Sidecar: el agente ya no se considera un componente separado, sino que se enfatiza la red formada por la conexión de estos agentes. En Service Mesh, hay un fuerte énfasis en la red compuesta por conexiones proxy, en lugar de tratar a las personas como sidecars.

Ahora, básicamente, hemos introducido claramente la definición de Service Mesh, y todos deberían poder comprender aproximadamente qué es Service Mesh.

2 Evolución de la malla de servicios

La segunda parte describe la evolución de Service Mesh hasta usted. Cabe señalar que aunque el término Service Mesh no existió hasta septiembre de 2016, lo que describe apareció hace mucho tiempo.

Primero, observe la "Era Antigua", la primera generación de sistemas informáticos de red. Al principio, los desarrolladores necesitaban tratar los detalles de la comunicación de red en su propio código, como la secuencia de paquetes de datos, el control de flujo, etc., lo que resultaba en una mezcla de lógica de red y lógica empresarial. Juntos, esto no funcionará. Luego vino la tecnología TCP / IP, que resolvió el problema del control de flujo.Como puede ver en la imagen de la derecha, la función no ha cambiado: todas las funciones están ahí y el código aún debe escribirse. Sin embargo, lo más importante, el control de procesos, se ha extraído de la aplicación. Al comparar los diagramas izquierdo y derecho, se extraen como parte de la capa de red del sistema operativo, que es TCP / IP, por lo que la estructura de la aplicación es simple.

Ahora que debería estar escrito, no es necesario considerar cómo enviar la tarjeta de red. Después de TCP / IP, esto es completamente innecesario. Lo anterior es algo muy remoto, probablemente sucedió hace cincuenta años.

La era de los microservicios también se enfrenta a cosas similares. Por ejemplo, cuando estamos haciendo microservicios, tenemos que lidiar con una serie de cosas relativamente básicas, como el registro de servicios comunes, el descubrimiento de servicios y el equilibrio de carga después de obtener instancias de servidor. Proteja el servidor para fusionar / reintentar, etc. Todos los microservicios con estas funciones no pueden escapar, entonces, ¿qué debo hacer? Solo puede escribir código y escribir todas las funciones en formato. Descubrimos que los primeros microservicios eran los mismos que antes, con una gran cantidad de código no funcional agregado a la aplicación. Para simplificar el desarrollo, comenzamos a usar bibliotecas de clases, como la típica suite Netflix OSS. Después de hacer bien estas cosas, el problema de codificación del desarrollador está resuelto: solo es necesario escribir una pequeña cantidad de código, estas funciones se pueden realizar. Por esta razón, en los últimos años, todo el mundo ha visto muy rápido la popularidad de Spring Cloud en la comunidad Java, y casi se ha convertido en sinónimo de microservicios.

En este punto, ¿es perfecto? Por supuesto, si es perfecto, entonces no estaré aquí hoy :)

Veamos estas pocas cosas que se llaman puntos débiles: hay más contenido y el umbral es más alto. Investiga, si aprendes Spring Cloud, ¿cuánto tiempo te llevará dominarlo y aplicarlo en el producto para solucionar los problemas que surjan? ¿Es suficiente una semana? Una semana no es suficiente para la mayoría de las personas y la mayoría de las personas necesita de tres a seis meses. Debido a que encontrará varios problemas cuando aterrice, tomará mucho tiempo si puede resolverlo usted mismo. Estos son los subproyectos comunes de Spring Cloud. Solo se enumeran las partes más comunes. Hay muchos contenidos de la suite netflix OSS bajo Spring Cloud netflix. Para comer realmente Spring Cloud, debe comer todas estas cosas; de lo contrario, se sentirá muy incómodo cuando tenga problemas.

Con tantas cosas, todos aquí tienen una capacidad de aprendizaje relativamente sólida. Puede hacerse en un mes, pero el problema es cuánto tardará su equipo de desarrollo, especialmente el equipo de desarrollo empresarial. Esto es algo muy terrible: los equipos empresariales suelen Hay muchos colegas jóvenes.

Entonces las cosas no son tan sencillas, lo peor es que tenemos que afrontar mucha realidad.

Por ejemplo, ¿cuáles son las fortalezas de nuestro equipo de desarrollo comercial? ¿El más fuerte será la tecnología? No, en términos generales, la comprensión más sólida de nuestro equipo de desarrollo comercial del negocio es la familiaridad de todo el sistema comercial.

La segunda cosa, ¿cuál es el valor fundamental de las aplicaciones empresariales? Hemos trabajado tan duro para escribir tantos microservicios. ¿Es para realizar microservicios? Los microservicios son solo nuestro medio, lo que en última instancia necesitamos lograr son negocios, que es nuestro objetivo real.

La tercera cosa es que, en términos de microservicios, existen desafíos más difíciles que aprender el marco de microservicios. En el aterrizaje real de los microservicios, habrá una comprensión más profunda. Por ejemplo, la división de microservicios, como diseñar una buena API, mantener la estabilidad y una fácil expansión, y si implica la coherencia de los datos en varios servicios, la mayoría de los equipos tendrán un dolor de cabeza. Finalmente, está la ley de Conway, pero todos los estudiantes que prestan servicio eventualmente se encontrarán con este problema fundamental y, en la mayoría de los casos, quieren llorar sin lágrimas.

Pero aún no han terminado. Lo más doloroso que escribir un nuevo sistema de microservicios es que hay que transformar el antiguo sistema en microservicios.

Sumar todo esto no es suficiente. Se necesita una cosa más. Esta es aún más terrible: los equipos de desarrollo empresarial a menudo se encuentran bajo una gran presión empresarial y nunca hay suficiente tiempo y mano de obra. Decir que estar en línea el próximo mes significa estar en línea el próximo mes, diciendo que la promoción del doble once no empujará al doble doce. Al jefe no le importa si tiene tiempo para aprender Spring Cloud o si su equipo comercial puede manejar todos los aspectos de los microservicios. Las empresas siempre miran los resultados.

El segundo punto problemático son las funciones insuficientes. A continuación se incluye una lista de funciones comunes de la gobernanza del servicio. La función de gobernanza de Spring Cloud no es lo suficientemente potente. Si estas funciones se tratan una por una, las funciones proporcionadas directamente por Spring Cloud están lejos de ser suficientes. Muchas funciones deben ser resueltas por usted mismo sobre la base de Spring Cloud.

La pregunta es cuánto tiempo planea invertir en recursos humanos para hacer esto. Algunas personas dicen que soy un gran problema y que no hago algunas funciones, como la escala de grises, y simplemente me conecto, pero esto es bastante caro.

El tercer punto de dolor es el lenguaje cruzado. Cuando aparecieron los microservicios por primera vez, prometieron una característica muy importante: que se pueden escribir diferentes microservicios en el lenguaje de programación más adecuado en el que sean mejores, favoritos y más adecuados. Esta promesa solo se puede decir que la mitad está bien, pero La otra mitad no es buena, es falsa. Porque cuando lo implementas, por lo general se basa en una biblioteca de clases o marco. Una vez que comienzas a codificar en un lenguaje de programación específico, encontrarás que parece incorrecto. ¿por qué? A la izquierda están los lenguajes de programación convencionales que enumeré de la lista de clasificación de lenguajes de programación. Los primeros son más familiares para todos. Hay docenas de otros que no se enumeran detrás, y los lenguajes de programación emergentes están en el medio, que son un poco más de nicho.

La pregunta ahora es cuántos lenguajes necesitamos para proporcionar bibliotecas y marcos.

Este problema es muy agudo. Para resolver este problema, generalmente solo hay dos opciones:

Uno es un lenguaje de programación unificado, toda la empresa utiliza un lenguaje de programación

Otra opción es escribir tantas bibliotecas como lenguajes de programación

Creo que si tiene estudiantes que están haciendo infraestructura, debe haber encontrado este problema.

Pero el problema aún no ha terminado, el marco está escrito y es posible escribir una copia de cada idioma. Pero luego habrá un cuarto punto de dolor: la actualización de la versión.

Su marco no puede ser perfecto desde el principio, todas las funciones están completas, no hay ERRORES y no hay necesidad de cambiar después de la distribución Este estado ideal no existe. Debe ser que 1.0, 2.0 y 3.0 se actualizan gradualmente, las funciones se aumentan gradualmente y los ERRORES se reparan gradualmente. Pero después de distribuirse a los usuarios, ¿los usuarios actualizarán inmediatamente? Realmente imposible.

Qué hacer en este caso, habrá inconsistencias entre las versiones del cliente y del servidor, debe tener mucho cuidado para mantener la compatibilidad y luego tratar de instar a sus usuarios: Soy todo 3.0, no usa 1.0, debe actualizar rápidamente. Pero si no se actualiza, continúas soportando y luego intentas resolver la compatibilidad de tu versión.

¿Qué tan complicada es la compatibilidad de versiones? Hay cientos de servidores y miles de clientes, y cada versión puede ser diferente. Este es un producto cartesiano. Pero no lo olvides, hay otro problema con el lenguaje de programación mencionado anteriormente, ¡tienes que multiplicar N!

Imagínese lo que sucede cuando el cliente Java1.0 del marco accede al lado del servidor node.js 3.0, y qué sucede cuando el cliente c ++ 2.0 accede al lado del servidor golang 1.0. ¿Quieres hacer todas las pruebas de compatibilidad? En este caso, ¿cuántos casos necesita escribir para las pruebas de compatibilidad? Es casi imposible.

¿Qué hacer entonces? Cómo solucionar estos problemas es un problema real y siempre debemos afrontarlo.

Vamos a pensarlo:

La primera es dónde están las raíces de estos problemas: hemos hecho tantas cosas dolorosas, hemos enfrentado tantos problemas y estos desafíos difíciles, ¿tienen algo que ver con el servicio en sí? Por ejemplo, escribir un servicio de usuario y realizar operaciones CRUD en los usuarios ¿Tiene algo que ver con las cosas que acabo de mencionar? Encontré que algo anda mal. Estos no tienen nada que ver con el servicio en sí, sino con la comunicación entre los servicios. Este es el problema que tenemos que resolver.

Entonces mira cuál es nuestro objetivo. Todos nuestros esfuerzos anteriores son en realidad para garantizar que la solicitud comercial enviada por el cliente se envíe al lugar correcto. Cual es el lugar correcto? Por ejemplo, si hay diferencias en la versión, ¿debería ir a la versión 2.0 o la versión 1.0? ¿Qué tipo de equilibrio de carga se necesita y si debe usar escala de grises? Al final, estas consideraciones son para hacer que la solicitud vaya al lugar correcto que necesita.

El tercero es la naturaleza del asunto. Durante todo el proceso, esta solicitud nunca se ha modificado. Por ejemplo, en el servicio de usuario que mencionamos anteriormente, CRUD se realiza en los usuarios, no importa cómo vaya la solicitud, la semántica de negocios no cambiará. Ésta es la esencia de las cosas, algo que no cambia.

Este problema tiene un alto grado de universalidad: todos los lenguajes, todos los frameworks, todas las organizaciones, estos problemas son los mismos para cualquier microservicio.

Habiendo dicho eso, todos deberían tener un sentimiento: ¿Es esta pregunta similar a qué pregunta?

Los predecesores de hace cincuenta años, ¿cuáles son sus problemas? ¿Por qué aparece TCP y qué problemas resuelve TCP? ¿Cómo se soluciona?

El problema que resuelve TCP es muy parecido a este, es enviar la solicitud al lugar correcto. Todas las comunicaciones de red, siempre que se utilice el protocolo TCP, estos cuatro puntos son los mismos.

¿Qué sucede después de tener TCP? Después de tener TCP, desarrollamos nuestras aplicaciones basadas en TCP. ¿Qué deben hacer nuestras aplicaciones? ¿Nuestra aplicación debe preocuparse por la implementación de la capa de enlace debajo de la capa TCP? No hay necesidad. De manera similar, cuando desarrollamos aplicaciones basadas en HTTP, ¿las aplicaciones deben preocuparse por la capa TCP?

¿Por qué nos preocupamos por la capa de comunicación del servicio cuando desarrollamos aplicaciones de microservicio? Aprendemos y hacemos todo en la capa de comunicación de servicios ¿Por qué hacemos tanto?

En este caso, surge naturalmente otra idea: dado que podemos mover la pila de tecnología de acceso a la red a TCP, ¿podemos también mover la pila de tecnología de microservicios hacia abajo?

El estado más ideal es que agreguemos una capa de microservicio a la capa de protocolo de red para lograr esto. Sin embargo, debido a problemas estándar, no está implementado ahora. Por el momento, esto no debería ser realista. Por supuesto, puede haber una capa de red de microservicios en el futuro.

Hay algunos pioneros que intentaron utilizar soluciones de proxy, nginx común, haproxy, apache y otros proxies. Estos códigos tienen poco que ver con los microservicios, pero dan una idea: insertar algo entre el servidor y el cliente para completar la función, evitando la comunicación directa entre los dos. Por supuesto, la función del agente es muy sencilla, el desarrollador tiene una buena idea a primera vista, pero la función no es suficiente, ¿qué debo hacer?

En este caso apareció la primera generación de Sidecar. El rol que juega Sidecar es similar al de un agente, pero las funciones son mucho más completas. Básicamente, las funciones implementadas por el framework de microservicios original en el lado del cliente se implementarán en consecuencia.

La primera generación de sidecar son principalmente las empresas cotizadas, de las cuales la más famosa es netflix.

En este lugar, mencionémoslo, tenga en cuenta que la cuarta es que las tres primeras funciones son todas de empresas extranjeras, pero en realidad, el sidecar no solo lo juegan los extranjeros, también hay fabricantes nacionales y empresas que hacen cosas similares. Por ejemplo, Vipshop Cuando trabajaba en el departamento de infraestructura de Vipshop, en el primer semestre de 2015, nuestro marco orientado a servicios OSP hizo un ajuste estructural importante y agregó un Sidecar llamado proxy local. Tenga en cuenta que esta vez es el primer semestre de 2015, que es similar al extranjero. Creo que debe haber productos similares en China, pero el mundo exterior no los conoce.

Los Sidecars en este período tenían limitaciones. Todos estaban diseñados para una infraestructura específica. Por lo general, estaban directamente vinculados a la propia infraestructura y marco de la empresa que desarrolló Sidecar en ese momento, y se basaron en el sistema original. Habrá muchas restricciones Uno de los mayores problemas es que no se puede utilizar universalmente: no hay forma de desmontarlo para que otros lo utilicen. Por ejemplo, Airbnb debe usar zookeeper, netflix debe usar eureka y el proxy local de Vipshop está vinculado al marco osp y otra infraestructura.

La razón principal de estas fijaciones está relacionada con la motivación de estos sidecars. Por ejemplo, netflix permitirá que las aplicaciones de idiomas que no sean JVM se conecten a Netflix OSS, y soundcloud permitirá que las aplicaciones Ruby heredadas utilicen la configuración básica de la JVM. En ese momento, el marco OSP de Vipshop, el proxy local, debía resolver el problema del acceso a lenguajes distintos de Java, así como el problema mencionado anteriormente que los departamentos comerciales no están dispuestos a actualizar. Estos problemas son más molestos, pero hay que solucionarlos porque el sidecar se ve obligado a salir.

Debido a estos antecedentes y requisitos especiales, el Sidecar de primera generación no se puede utilizar universalmente porque se construyó originalmente sobre el sistema original. Aunque no se puede quitar solo, aún puede funcionar bien en el sistema original, por lo que no hay motivación para quitarlo. Como resultado, aunque muchas empresas tenían Sidecar antes, no se ha difundido ampliamente, porque incluso después de su lanzamiento, otras no podrán usarlo.

Una cosa para mencionar aquí es que a mediados de 2015, tuvimos una idea en ese momento para separar el proxy local del OSP y transformarlo en un Sidecar universal. Está previsto que sea compatible con HTTH1.1, simplemente opere el encabezado http y el cuerpo se puede considerar transparente para nosotros, por lo que es fácil lograr la universalidad. Desafortunadamente, no se realizó debido a la prioridad y otras razones, principalmente porque hubo muchas otras tareas, como varias transformaciones comerciales, que no fueron lo suficientemente necesarias.

Desafortunadamente, no nos dimos cuenta de esta idea en ese momento, esto fue en 2015, que fue muy temprano. Si se hubiera realizado en ese momento, es muy probable que hubiéramos descartado la primera malla de servicios de la industria. Es una pena pensar en ello ahora.

Sin embargo, no somos los únicos que tenemos esta idea. Hay algunas personas que tienen ideas similares a las nuestras, pero afortunadamente, tienen la oportunidad de hacer cosas. Esta es la primera generación de Service Mesh, un sidecar universal.

La aparición de un Service Mesh de uso general, el primer Linkerd de la izquierda es el primer Service Mesh de la industria, es decir, creó el término Service Mesh. Hora: El 15 de enero de 2016, se lanzó 0.0.7. Esta es la primera versión vista en github. De hecho, esta versión es muy cercana a la época en que teníamos ideas. Luego vino la versión 1.0, que se lanzó en abril de 2017, dentro de seis meses. Por lo tanto, Service Mesh es un término muy nuevo y es normal que nadie haya oído hablar de él.

El siguiente es Envoy, versión 1.0 lanzada en 2016.

Cabe destacar aquí que tanto Linkerd como Envoy se unieron a la CNCF, Linkerd fue en enero de este año y Envoy ingresó en septiembre, que está a solo un mes de distancia. Todos ustedes deberían comprender el estado de CNCF en el campo de Cloud Native, ¿verdad? Se puede decir que la posición de CNCF en Cloud Native es la misma que la de Naciones Unidas en el orden internacional después de la Segunda Guerra Mundial.

Después de eso, el tercer Service Mesh, nginmesh, vino del conocido nginx, y la primera versión se lanzó en septiembre de 2017. Debido a que es tan nuevo y recién está comenzando, no hay nada que presentar en particular.

Echemos un vistazo a la diferencia entre Service Mesh y Sidecar.Los dos primeros puntos ya se han mencionado:

Primero, Service Mesh ya no se considera un componente separado, sino que enfatiza la red formada por la conexión

El segundo Service Mesh es un componente universal

Luego quiero enfatizar el tercer punto: el sidecar es opcional y permite la conexión directa. Por lo general, en el marco de desarrollo, a los clientes de lengua nativa les gusta elegir la conexión directa, y otros lenguajes eligen usar sidecar. Por ejemplo, el marco escrito en java, el cliente java está conectado directamente y el cliente php usa el sidecar. Pero también puede optar por utilizar sidecars. Por ejemplo, el OSP de Vipshop utiliza un proxy local para todos los idiomas. También es opcional en el sidecar. Sin embargo, Service Mesh requerirá un control completo de todo el tráfico, es decir, todas las solicitudes deben pasar a través de la malla de servicios.

A continuación, presentaré Istio a todos. Creo que esto es un estilo rey. Viene de Google, IBM y Lyft. Es el maestro de Service Mesh.

Todo el mundo mira su icono, es un velero. Istio es griego, y el significado en inglés es "navegar", que se traduce como navegar. ¿Ves la asociación entre este nombre y el icono? Otro producto a nivel de fenómeno de google en la era de la nube, K8S, kubernete también se originó en griego, capitán, piloto o timonel, el ícono es un timón.

Se puede decir que el nombre y el icono de istio están en la misma línea que k8s. Esta cosa se lanzó en 0.1 en mayo de 2017, y 0.2 se lanzó el 4 de octubre hace solo dos semanas. Todos están familiarizados con el desarrollo de software y deben comprender en qué etapa 0.1 / 0.2 se encuentra la iteración del software. 0.1 equivale aproximadamente a que el bebé acaba de nacer y 0.2 no ha sido destetado. Sin embargo, incluso en una versión tan temprana, mi evaluación de él ya es una obra maestra, un estilo de rey, ¿por qué?

¿Por qué es Istio king style? Lo más importante es que aporta un control sin precedentes a Service Mesh. El Service Mesh implementado en el modo Sidecar controla todo el tráfico entre servicios. Siempre que Service Mesh pueda controlar todo el tráfico, también puede controlar todas las solicitudes en el sistema. Por esta razón, Istio trae un panel de control centralizado que le permite lograr el control.

A la izquierda hay una vista única, con un panel de control agregado al sidecar para controlar el sidecar. Esta imagen no es particularmente obvia. Mire la imagen de la derecha. Cuando hay una gran cantidad de servicios, el panel de servicios se siente más claro. En toda la red, todo el tráfico está bajo el control de Service Mesh y todo Service Mesh está bajo el control del panel de control. Todo el sistema se puede controlar a través del panel de control, que es la mayor innovación que trae Istio.

Istio fue desarrollado por tres empresas. Las dos primeras son aterradoras, Google e IBM, y ambas son plataformas en la nube, la plataforma en la nube de Google, la plataforma en la nube de IBM y todos conocen el nombre de GCP. El supuesto fondo famoso probablemente se refiere a este look, ¿verdad?

La fuerza de Istio es muy fuerte, y he elogiado mucho aquí: el concepto de diseño es muy novedoso y vanguardista, creativo, valiente, perseguido y estructurado. La fuerza del equipo de Istio también es asombrosa, si tienes tiempo, puedes ir a ver la lista de comités de istio para hacerte una idea. Istio es también el nuevo producto de peso pesado de Google y es probable que se convierta en el próximo producto fenomenal. ¿Cuál es el producto fenomenal actual de Google? K8s. Y es probable que Istio se convierta en el próximo producto de nivel K8S.

Hablando de nacer en el tiempo, ¿qué es el impulso? ¿En qué época estamos hoy? Es la era de la popularización masiva de la tecnología de Internet, la era de los contenedores de microservicios en pleno apogeo y la era de Cloud Native. También es una era en la que las empresas tradicionales están experimentando una transformación de Internet. Los usuarios empresariales de hoy quieren transformarse. Esta tendencia es muy obvia. Todos están cambiando o preparándose para cambiar, pero es inherentemente insuficiente. ¿Qué es la deficiencia congénita? Sin genes, sin capacidad, sin experiencia, sin talento, y enfrentamos todos los puntos débiles que mencionamos anteriormente. Todo lo que aparece Istio ahora, el momento es muy adecuado. No olvide que hay un fondo de CNCF detrás de istio, que está a punto de dominar el k8s.

Después de que se liberó a istio, la comunidad respondió positivamente y los supuestos respondedores se reunieron. Entre ellos, Envoy, una de las únicas mallas de servicio en el mercado, está dispuesta a ser la capa inferior para istio, mientras que las otras dos implementaciones de Linkerd / nginmesh también abandonan directamente la confrontación con istio, eligen cooperar e integrarse activamente con istio. Los grandes de la comunidad, como los que se enumeran aquí, respondieron la primera vez: deberían integrarse con istio o crear sus propios productos basados ​​en istio. ¿Por qué es la primera vez? Cuando istio lanzó la versión 0.1, expresaron directamente su actitud y comenzaron a hacer fila.

La arquitectura de Istio se divide principalmente en dos partes principales. El siguiente panel de datos es para la malla de servicio tradicional, actualmente Envoy, pero también mencionamos anteriormente que linkerd y nginmesh se están integrando con istio, que se refiere a reemplazar Envoy como un panel de datos.

Otra gran pieza es el panel de control de arriba, que es lo que realmente trae istio. Dividido principalmente en tres partes, en la figura enumero sus respectivas responsabilidades y funciones que se pueden lograr.

Debido a que el tiempo es limitado, no se lanzará hoy.

Aquí hay una dirección para todos, que es un intercambio en línea que hice antes. La introducción detallada de Istio tiene mucho contenido. Echemos un vistazo más de cerca.

Interpretación de 4D: nueva generación de Service Mesh Service Mesh

Luego, también organizamos una comunidad técnica de malla de servicios para traducir la documentación de istio.

Traducción al chino de documentos oficiales de Istio

http://istio.doczh.cn/

En resumen, la malla de servicios es un enfoque paso a paso: desde el agente original hasta el sidecar con muchas restricciones, pasando por la malla de servicios generales y luego hasta Istio con funciones de administración mejoradas, se convertirá en la próxima generación de microservicios en el futuro.

Tenga en cuenta que solo ha pasado un año desde que apareció el término malla de servicios.

3 ¿Por qué elegir Service Mesh?

Los primeros tres puntos débiles se han resuelto y estos problemas ya no son un problema con Service Mesh. ¿Cómo resolver los puntos débiles de la actualización? Service Mesh es un proceso independiente que se puede actualizar por separado sin cambiar la aplicación.

La malla de servicio permite a los clientes acceder a través de llamadas remotas. Siempre que se pueda realizar la solicitud, simplemente envíela a servicemesh. El cliente es extremadamente simplificado, para las solicitudes de descanso típicas, casi todos los idiomas tienen un soporte perfecto. El servidor solo necesita hacer una cosa, registrarse en el servicio. Esto hace que el soporte multilingüe sea muy cómodo. Ahora finalmente puede elegir libremente un lenguaje de programación.

Aquí hay un milagro, el pez y la pata de oso tienen ambos: al mismo tiempo, bajan el umbral y aumentan la función. Algunos estudiantes que creen en la conservación de la calidad se sentirán acientíficos, fíjense en la razón de que estas dos mejoras se pueden lograr al mismo tiempo, es para dar la malla de servicio a la malla de servicio. Service Mesh es universal y se puede reutilizar repetidamente.

La malla de servicios trae cambios al equipo de desarrollo comercial: reduce la barrera de entrada, proporciona una base estable y ayuda al equipo a lograr la transformación tecnológica. El objetivo final es liberar al equipo de desarrollo empresarial de los detalles técnicos específicos de la implementación del microservicio y volver al negocio.

El segundo cambio es fortalecer el equipo de gestión de operación y mantenimiento, si hay estudiantes que están haciendo operación y mantenimiento, puedes pensarlo bien: si tienes una malla de servicios, ¿cuánto vas a administrar y controlar el sistema? Tenga en cuenta que la implementación de muchas funciones ya no está relacionada con la aplicación y se está moviendo a la malla de servicio, y la malla de servicio generalmente está bajo el control de operación y mantenimiento.

La malla de servicios es un gran beneficio para los lenguajes de nicho emergentes. Para los nuevos lenguajes, ¿qué es lo más doloroso al competir con los lenguajes de programación tradicionales? Es ecología, como varias bibliotecas y marcos. En el campo de los microservicios, es muy difícil para los lenguajes de nicho emergentes competir con Java y otros: esto es usar sus propias debilidades para competir con las ventajas de otros. Con Service Mesh, los lenguajes de nicho tienen la oportunidad de evitar esta deficiencia, ya no tienen que competir con Java por la ecología, sino para dar rienda suelta a sus características lingüísticas y hacer lo que mejor saben hacer.