Sobre el Autor
顾宇Consultor senior de ThoughtWorks
Antes del inicio oficial, haz una encuesta. Cuando escuchas acerca de los microservicios, ¿estás contento, cuestionando o dolorido?
Lo que comparto hoy es el reflejo y el aterrizaje eficiente de microservicios. Te lo diré con anticipación. Esto es para el equipo. Si ves videos de microservicios y tutoriales en Internet, puedes implementar la tecnología de microservicios tú mismo en la nube. Cuando te encuentres con un equipo que quiera implementar microservicios, tendrá algunos problemas, estos contenidos son principalmente para esta parte.
1. Reflexiones provocadas por tres casos de microservicios
1.1 Desacoplamiento de sistemas heredados de Java
Este proyecto de servicio fue el primer año que me uní a ThoughtWorks. En septiembre de 2013, no sabía que era un proyecto de microservicio. El concepto de microservicio apareció recién en 2014. En ese momento, era el desacoplamiento de Java, que era un cliente externo, y era un motor de búsqueda vertical.
La empresa eligió un muy buen momento y punto de entrada, y pronto se convirtió en el número uno de esta industria en Australia. La vieja tecnología que usaban no podía vencer a sus competidores. Tenían nuevos competidores compitiendo con ella con tecnologías más nuevas, más rápidas y más baratas casi todos los meses, por lo que querían disociarse.
¿Cómo dividir la aplicación razonablemente en esta situación? Comenzamos con el antiguo Spring 2.5, usando Java ESB como bus y colgando muchos servicios en él, el antiguo modelo SOL. Más tarde, usamos la API de Restful para desacoplar el modelo y lo desmantelamos de toda la subcontratación de Java en un servicio independiente. Podemos permitir que las aplicaciones desensambladas se implementen de forma independiente. Este fue el problema que encontramos en ese momento. Nuestra comprensión en ese momento era muy simple: hacer microservicios es hacer una implementación continua de la API Restful.
Me tomó siete meses completar el proyecto, luego comenzamos a copiar esta experiencia.
1.2 Un operador de telecomunicaciones
Este proyecto es un operador australiano, el problema con el proyecto en ese momento era así, en ese momento adquirió una empresa para convertirse en operador móvil y adquirió un operador de banda ancha. Su base de usuarios se está expandiendo rápidamente, por lo que necesita cambiar su aplicación en línea. Los problemas que enfrentamos en ese momento eran cómo implementar aplicaciones de manera rápida y estable, cómo mejorar la productividad del equipo, especialmente el nivel de automatización, y cómo eliminar los cuellos de botella en los procesos y la colaboración entre departamentos.
En ese momento, nuestro equipo de Operaciones tenía solo 4 personas y queríamos mejorar la productividad del equipo. Las mejoras que no sean el cuello de botella son falsas. Hemos realizado consultas y mejoras de DevOps, y hemos aumentado la eficiencia de desarrollo en un 300%, pero en realidad es menos del 300%. Para el nivel superior, el efecto de la mejora es el mismo, o la versión se implementa una vez al mes.
El equipo que se conecta conmigo implementa la versión una vez cada tres meses. Si algo sale mal, solo puedo esperar al mes siguiente. Lo que pensé fue que incluso si hacías DevOps, todavía no acelerabas. Nuestra solución en ese momento era separar una parte relacionada con nuestros socios y convertirla en un servicio separado, nuestra parte usa nuestro método para que todos se vuelvan asincrónicos. DevOps logra lo último y obtiene microservicios.
Cuando tiene una sola aplicación que mejora continuamente la velocidad y la calidad de la canalización de entrega continua, solo puede eliminarla para mejorarla. Puede expandir la aplicación a pedido y puede obtener un punto de riesgo más pequeño, porque cada implementación es un punto y el impacto de la producción es muy pequeño. Por lo tanto, creo que lo último en DevOps es obtener microservicios.
1.3 Productos de computación en la nube de un gran grupo de TI
Este es un cliente nacional, con sede en Shenzhen, y también es un producto de computación en la nube. Después de terminar mi último proyecto de microservicios, descubrí la rutina de los microservicios, tienes que encontrar el cuello de botella que realmente resuelva el problema. En ese momento, el cuello de botella del proyecto era cómo acortar el tiempo de lanzamiento, cómo lanzarlo de forma independiente y los microservicios se retrasaron.
Se necesitan ocho semanas para que este proyecto se publique. Creemos que es muy difícil para un sistema de plataforma de computación en la nube tan grande enviar un paquete completo, por lo que dividimos una parte. Pero hay un problema: este plan de división de microservicios se ha retrasado.
La semana antes de la Navidad de 2015, dije que hiciera esto. Me uní al proyecto una semana antes del 1 de abril de 2016. Cuando me enteré de esto, descubrí que ya habían pasado unos tres meses, excepto por un montón de informes y reuniones. minutas., y los planes de evaluación de los consultores de todas las partes, ninguno de ellos está en su lugar. Estaba pensando que los microservicios es un asunto muy simple a través de mi experiencia anterior, ¿por qué es tan difícil aterrizar?
Su cuello de botella a menudo proviene de la organización y es efectivo crear microservicios a partir del ajuste de la estructura organizativa. Queremos hacer microservicios, dibujar la arquitectura del sistema, dividiremos y diseñaremos, y los resultados serán lentos y no buenos.Cuando surjan nuevos problemas más adelante, necesitaremos modificar el plan original.
1.4 Puntos comunes de los tres casos
-
Todos los equipos y aplicaciones de desarrollo necesitan mantener una implementación de alta eficiencia del equipo cuando la escala crece;
-
Practicar la entrega continua y DevOps en el equipo;
- Deje que la aplicación se publique sin conflictos en el espacio y el tiempo;
Si tiene una sola aplicación, definitivamente creará un par de sucursales y tendrá que lidiar con los conflictos al fusionar, y es posible que no sea factible conectarse en línea después de la prueba. Entonces, para hacer esto, necesitamos hacer grandes ajustes.
1.5 Cómo afrontar el crecimiento
Este es el modelo de crecimiento que encontramos cuando crece la demanda y la escala. Cuando se encuentra con SCALE UP, es necesario gestionar el crecimiento de los recursos, lo que conlleva costes adicionales.
Existe una ley llamada ley de rendimientos marginales decrecientes, por lo que haremos otro tipo de expansión, es decir, ESCALA FUERA, que es una expansión lineal, pero necesitamos un sistema fuerte. Podemos aprovechar el éxito de un equipo y el el éxito de una aplicación junto con la escala El crecimiento de la empresa continúa expandiéndose, esta es la idea básica de hacer microservicios. El problema al que se enfrenta es resolver el conflicto de desarrollo y despliegue en el tiempo y el espacio en el caso de un crecimiento rápido o de gran escala.
Después de que encontramos el problema de la escala, hubo un punto de inflexión en los costos.
El eje X es el costo, el eje Y es la escala, la línea negra es la aplicación única y la línea verde es la aplicación de microservicio. Las aplicaciones de microservicio comienzan como un sistema distribuido y el costo inicial será un poco más alto que el de una sola aplicación. Después de un tiempo, llegarán al punto X. En este punto, no hay diferencia entre una aplicación monolítica y una aplicación de microservicio. Sin embargo, cuando la aplicación crece, si es una sola aplicación, cumplirá con el límite de costo. Cuando se alcanza el límite de costo, no se puede soportar la expansión de escala, por lo que hay un límite de crecimiento, que se llama X '. Cuando la complejidad de la aplicación crece en escala y costo hasta cierto punto, se transforma en una aplicación de microservicio.
El hecho es muy cruel, la mayoría de las empresas no golpean a Nantou y no miran atrás, esto es ideal. El concepto de separación de funciones existe desde hace mucho tiempo. Los microservicios utilizan nuevas tecnologías y nuevas botellas de vino viejo. Los microservicios no han aportado nuevos avances metodológicos.
Por lo tanto, considere la transformación de microservicios como una inversión, una inversión en el límite de crecimiento de la empresa, luego de obtener una mayor capacidad de expansión, obtendrá un límite mayor, porque podrá copiar sus ventajas.
1.6 Problemas resueltos por microservicios
¿Qué problemas están resolviendo esencialmente los microservicios?
-
El equipo y la aplicación están en alto crecimiento;
-
Mejorar la eficiencia general de la entrega a través de la implementación independiente y la liberación independiente;
- Resolver el acceso conflictivo a una única base de código en el tiempo y el espacio;
Si está haciendo microservicios, primero verifique si tiene ese problema.
2. Dificultades para conseguir microservicios
Echemos un vistazo a las dificultades del aterrizaje de microservicios. Estos son problemas comunes en los proyectos de microservicios en los que he participado en el pasado. La dificultad es que estos problemas requieren más tiempo para pensar y discutir, y proporcionan una base para las decisiones de arquitectura de microservicios.
-
No sé cómo dividir;
-
Dificultad en la implementación de la estructura;
-
La gestión es cada vez más compleja;
-
La pila de tecnología no sabe elegir;
-
El equipo no sabe organizarse;
- Cómo administrar microservicios;
2.1 Problemas técnicos y no técnicos
¿Los microservicios son técnicos o no técnicos? De hecho, son ambos. Recomiendo encarecidamente el libro "Humanware". Hay dos frases en su prefacio: "El problema importante de los sistemas de software no radica en la tecnología, sino en los factores sociales". "Si los problemas que enfrentamos son inherentemente sociológicos, entonces la buena tecnología no proporcionar mucha ayuda ".
Los microservicios son un problema de administración que está oculto bajo problemas técnicos. Si su pila de tecnología carece de administración, si usa una buena solución de refactorización para optimizar continuamente el código al principio, es bueno para usted hacer microservicios y hacer una sola responsabilidad más adelante. , Puede migrar en un solo paso. Nuestra base de código está realmente aislada. Cuando fusionamos el código, tenemos pruebas automatizadas, por lo que hacemos un cambio con un clic para copiar la base del código y cambiarla a llamadas a API, lo que puede garantizar que los microservicios no sean demasiado grandes después de que conéctate. El problema.
No se dio cuenta de que los microservicios son un problema de transformación organizacional.
Esta imagen es de Netflix. Netflix tiene su propia experiencia de hacer microservicios en Internet. Esta imagen también proviene de allí. Dice que los microservicios son un cambio organizacional y los cambios organizacionales son difíciles.
Los microservicios no son todo viento en popa, pero la gestión es algo que no se puede ver. Tenemos que dejar que muchos equipos vean los problemas de gestión. Ver es el comienzo del cambio. Solo cuando podemos ver los problemas, sabemos cómo cambiar.
Hay un modelo de cambio de Satya en Humanware. Cuando tienes una arquitectura existente, la introducción de microservicios causará confusión. Después de la intervención y el coaching, practica e integra, retroalimenta y fortalece para formar una arquitectura de microservicio. Si está satisfecho con los microservicios, significa que ha alcanzado la etapa de la arquitectura de microservicios. La dificultad es la parte caótica en el medio, y el caos es un proceso insuperable.Cuando te encuentras con cosas nuevas, tienes que estimular tus nuevos hábitos y debes experimentar cosas desacostumbradas.
2.2 ¿Qué es eficiente?
Hablando de los pasos para la implementación eficiente de microservicios, ¿cómo pueden considerarse eficientes?
-
A partir del resultado, busque la distancia más corta. A través del modelo de desarrollo original, después de analizar y luego aterrizar, estás cada vez más lejos de los microservicios, no te hace más rápido ni más simple;
-
Las cosas más difíciles se resuelven primero. Los cambios tecnológicos suelen ser la parte más fácil y la parte más difícil es la parte de implementación técnica;
- Bajo costo, bajo riesgo, absolutamente sin desperdicio;
Tres. Cinco pasos para implementar microservicios de manera eficiente
3.1 Empiece por el final y forme un equipo
No piense primero en la tecnología, primero configure un equipo de microservicios. Si hace microservicios de la forma tradicional, solo repetirá los mismos errores. Un equipo autónomo con todas las funciones es un equipo que puede publicar microservicios de forma independiente. Requiere 1 administrador de microservicios para resolver las dependencias e interferencias del proceso; 2-4 desarrollo / pruebas, centrándose en el desarrollo y las pruebas de microservicios; 1-2 operación y mantenimiento, utilizado para proporcionan la versión y el despliegue más rápidos. Si su organización es un equipo de DevOps separado, se recomienda tener 1-2 operaciones y mantenimiento.
Un equipo pequeño independiente es para evitar la dependencia. Está acostumbrado a un método de desarrollo en el proceso y entorno de desarrollo original. Después de cambiar a otro método, siempre piensa en el método de desarrollo anterior.
Sin embargo, queremos enfatizar que todo en un equipo lo hace el equipo. Por un lado, se trata de mejorar la capacidad del personal. Por otro lado, es hacer que todos sientan que pueden tener más control, y el estado de ánimo es mejor que antes. Pulse el correcto. Manera de tomar la decisión correcta. También hay asuntos especiales, si sigue el camino original, la eficiencia no mejorará. Para dar la máxima prioridad a los microservicios, debe haber un sentido de ritual.
Este es un consejo técnico: un microservicio, una base de código y una canalización.
Hay dos tipos de organizaciones: una es una organización suelta y plana, que tiene un protocolo de gestión fuerte, si se aplica un sistema de software, se adaptará rápidamente a la arquitectura del sistema de software. Si es de otro tipo, la arquitectura del software se cambiará a una estructura organizacional, esta es la llamada ley de Conway, es decir, su estructura organizacional y la arquitectura del sistema son básicamente equivalentes.
En diferentes organizaciones, es posible que la estructura del sistema cambie la estructura de la organización, y es posible que la estructura de la organización cambie la estructura de su sistema. Si el tamaño del equipo supera las 200 personas, cambiar la forma de administrar la organización a través de medios técnicos generalmente no lo hará. tener éxito, a menos que sea muy poderoso.
3.2 Construyendo un discurso de elevador de microservicios
El discurso del ascensor proviene de McKinsey, que es para mantener simple el concepto de microservicios. Debe ser simple al principio y los bordes se pueden cortar fácilmente. Lo más importante es no a 15 segundos, finalizar el microservicio en 15 segundos.
Este es el título de nuestra empresa: sin teléfonos móviles ni computadoras, el efecto de comunicación de la reunión es bueno, por lo que debe colgarse en la pared para formar un sentido de ritual y seguir formando pistas. El discurso elevador del equipo de microservicios debe llegar a un consenso y luego darse cuenta rápidamente.
3.3 Obtén una victoria rápida
Lanza el primer microservicio con un costo mínimo, lo que traerá mucha moral al equipo. El objetivo no debe ser demasiado alto. La vitrina impulsa el desarrollo. Puede desarrollar lo que quiera demostrar y habrá resultados efectivos todos los días. Establezca una meta el primer día, muestre esto mañana y asegúrese de mostrarlo mañana.
¿Cuál es el lanzamiento del primer microservicio con el menor costo? El costo más bajo es el tamaño del equipo de 2 a 8 personas, el tiempo es de 2 a 4 semanas y se debe seleccionar la pila de tecnología menos costosa.
Hay un cambio de función cuando realiza la segmentación en línea de microservicios. Debe usarlo en lugar de las ramas. Además, es importante enfatizar el desarrollo de un solo tronco. Si usas ramas, significa que hay ramas y tu código está acoplado. El acoplamiento demuestra que puedes desmantelarlo. Lo peor es darte una interfaz que no sirve. entrega continua. Debe conectarse rápidamente, implementar rápidamente en el entorno de producción, en lugar de hacerlo en el entorno de prueba.
3.4 El código se mueve ligeramente, ¡DevOps primero!
Es fácil para los ingenieros ver el código y liderar los detalles del código, lo cual es difícil e imposible de hacer. Cuando escuchas una excusa, no hay dirección hacia el destino. Si su organización es una organización separada entre Dev y Ops, consulte primero al ingeniero de Ops. Es mejor tener un ingeniero de operaciones en el equipo de microservicios. Si no tiene las condiciones para implementar DevOps, la arquitectura de microservicio debe comenzar desde el lado de la operación y el mantenimiento, no desde el lado del desarrollo.
Hacer DevOps es hacer CLAMS. Debe haber medición, no hay mejora sin medición. Automatización significa automatizar todo, excepto el envío y la publicación de código. Este es un requisito para el equipo. Si el control de calidad se hace bien, la publicación también se puede automatizar. No es necesario que nadie realice ninguna verificación en el medio, ni la verificación se puede resolver mediante automatización.
Se enumeran las automatizaciones clave: la primera son las pruebas automatizadas, con pruebas automatizadas funcionales y no funcionales.
El segundo es la gestión automatizada de la infraestructura, principalmente la infraestructura y el código. Si la infraestructura debe construirse manualmente, la velocidad de los microservicios no cumplirá con el estándar.
El tercero es el despliegue automatizado, no el release, el despliegue de microservicios al entorno de producción aún requiere pasos de verificación manual, porque no está muy acostumbrado, y es necesario hacerlo al principio.
La implementación es una acción técnica. Usted implementa la aplicación en el entorno de producción, mientras que la liberación es una acción comercial, que consiste en determinar qué parte del usuario puede ver su microservicio.
El cuarto es el monitoreo y la alarma automatizados. El monitoreo y las alarmas automatizadas de los microservicios es diferente del monitoreo y las alarmas anteriores. Es necesario averiguar cómo enterrar el problema de antemano.
Use Lean para encontrar problemas a través de la visualización y encuentre varios problemas existentes a través de Kanban. No diré mucho sobre esto, puede encontrar materiales de referencia relevantes. Para encontrar problemas a través de la visualización, este problema no es un problema arquitectónico, sino un problema de gestión. En el equipo, cuando hay un problema, es de todos. Construya el concepto de compartir y compartir, y no culpe a los demás.
Para crear una cultura DevOps completa, DevOps tiene sentido decir que es una cultura. Hay cuatro culturas: flexibilidad, comunicación, aprendizaje y atmósfera.
DevOps tiene varias prácticas centrales, la primera es la entrega continua,
El segundo es la infraestructura como código, que se utiliza para la asignación de recursos y la orquestación de recursos.
El tercero es que la infraestructura es transparente para los microservicios.
Me he encontrado con algunas situaciones en las que los microservicios y el código de infraestructura se colocan en una base de código. Cada microservicio tiene diferentes requisitos de infraestructura. Si se realizan cambios, se involucran demasiadas acciones. No coloque toda la infraestructura en una base de código.
3.5 Mejora continua, copia de la experiencia exitosa
¿Qué es la maldición del conocimiento? Después de aprender un poco de conocimiento, ya no puede imaginarse su estado como principiante. Una vez que termines los microservicios, vas a enseñar a los principiantes, el efecto no será muy bueno. Por tanto, al inicio de los microservicios, es necesario hacer un registro de los diversos problemas de los microservicios y dar parte de la experiencia exitosa a los recién llegados, mucho mejor que encontrar una persona con experiencia en microservicios para enseñar a los recién llegados. Porque si una persona muy experimentada enseña a una nueva persona, será maldecido con conocimiento y olvidará cómo comenzó como principiante.
El resultado clave que debe resumirse para replicar la experiencia exitosa, para lograr la especificación del proceso de extremo a extremo desde el desarrollo del microservicio hasta el lanzamiento, es mejor estar automatizado, y la automatización en sí misma es un sistema de gestión. La especificación de la calidad técnica del desarrollo de microservicios, la adherencia a las mejores prácticas de cooperación en el equipo y el resumen de algunos problemas deben mejorarse continuamente a través de reuniones retrospectivas.
Finalmente, necesitamos rotar el equipo de forma cruzada. Después de que haya un equipo de microservicio, algunas personas serán eliminadas del medio para agregar recién llegados, y debemos adaptarnos a la cultura de microservicios. El microservicio en sí requiere un equipo relativamente pequeño para simplificar toda la implementación.
Quiero reunirme y comunicarme con más colegas, y quiero escuchar interpretaciones más técnicas de expertos.
La Cumbre Internacional DevOps es un evento de lluvia de ideas
Deje que DevOps regrese a un lugar más esencial y comprenda mejor el espíritu de DevOps