Para algunos, los microservicios son la capacidad de rehacer y refactorizar una aplicación a un estilo relativamente moderno. Esta solución arquitectónica no es adecuada para otros debido a las peculiaridades de la interacción de varias partes de la aplicación. En cualquier caso, al elegir una arquitectura, es útil estudiar la experiencia de otros desde la transición del monolito a un conjunto de servicios.
Pedimos compartir nuestro estudio de caso sobre el desarrollo y la entrega de microservicios Alexei Baitov, ingeniero principal de 2GIS. Hablemos de soluciones arquitectónicas, implementación y escalabilidad. Preguntemos sobre tendencias y herramientas convenientes para el trabajo.
- Alexey, cuéntanos un poco sobre ti y sobre tu equipo en 2GIS . ¿En qué estás trabajando ahora?
Llegué a TI en 2003 como administrador del sistema, me sumergí en el desarrollo en 2011. Durante este tiempo, trabajó en PHP, JavaScript, implementó una serie de servicios RESTful y un controlador Python para Git. He estado trabajando en 2GIS desde 2015.
Participó en el desarrollo de dos arquitecturas de microservicios. El primero consistió en un servicio. Era un proxy inverso asíncrono con un caché. De hecho, él se dedicaba a enviar mensajes. Fui el único involucrado en la elaboración de los requisitos, el desarrollo y la creación de DevOps, pero los expertos de nuestra compañía 2GIS me ayudaron.
El servicio fue escrito en Go. La compilación rápida me permitió no esperar y pude concentrarme en la implementación continua. Entonces estábamos empezando a usar
GitLab CI ,
Prometheus ,
Grafana y
Deis (análogo de código abierto de
Heroku ). Contamos con un equipo de Infraestructura y Operaciones, que en el momento de mi desarrollo llevó todas estas soluciones de infraestructura al nivel de producción. Decidí probar todo esto e implementé con éxito un microservicio independiente.
Hace dos años, me mudé a otro equipo en un nuevo proyecto, donde comencé a participar en la programación funcional en Scala. Nuestro equipo desde cero ha desarrollado una arquitectura de microservicios para el almacenamiento de materiales publicitarios de 2GIS en Scala, C # y JavaScript. Puse los cimientos de todos los servicios con las herramientas y la experiencia obtenida para desarrollar las prácticas de DevOps (implementación y mantenimiento continuos). La arquitectura ha pasado del prototipo a la operación industrial. Ella absorbió dos monolitos, ahora consta de 15 servicios y está en constante expansión.
- ¿Está de acuerdo en que los microservicios son esencialmente un conjunto de servicios implementados independientemente que tienen características comunes, es decir, un conjunto de ciertas características les da la apariencia de un microservicio? ¿Es necesario ampliar esta definición? O, de hecho, ¿las empresas tienen una comprensión diferente de la arquitectura de microservicios?Me gusta la siguiente
definición . La arquitectura de microservicios es un estilo arquitectónico que estructura una aplicación como una colección de servicios poco acoplados que implementan una lógica comercial específica. Los servicios en una arquitectura de microservicios pueden no tener características comunes, pero se combinan dentro de una lógica comercial común.
Por supuesto, cada compañía tendrá su propio microservicio. Este es un conjunto de prácticas: arquitectura distribuida, integración y entrega continua, etc. Si expande el concepto de práctica a las herramientas utilizadas, las opciones para implementar microservicios serán muy diversas.
- Existen diferentes opiniones sobre la composición del equipo, que deben participar en la escritura y el soporte de microservicios. ¿Qué opinas de esto? ¿Cuál es el tamaño óptimo del equipo y cómo debe construirse mediante la interacción dentro de él cuando se desarrolla una arquitectura de microservicio? ¿Hay un buen ejemplo de trabajo en equipo de tu práctica?Se considera correcto desarrollar un servicio de tal manera que su área temática completa pueda caber en la cabeza de un desarrollador. Al mismo tiempo, varias personas pueden participar en el desarrollo de este servicio. Esto ayudará a evitar el factor del autobús cuando el desarrollador se fue de vacaciones o se enfermó. El desglose correcto en los servicios permite que una nueva persona ingrese rápidamente al contexto.
La arquitectura de microservicios nos dice que a menudo incluye varios servicios. Por lo tanto, un desarrollador no puede hacer. La arquitectura de microservicios se basa en el modelo del producto (o lógica empresarial común). Los desarrolladores se seleccionan para que resulte implementar este modelo y al mismo tiempo centrarse en el cliente.
El enfoque en el cliente se organiza a través del contacto directo entre el desarrollador y el cliente. Los desarrolladores necesitan ver cómo se usa su producto. A partir de esto, los deseos de conocimiento en el campo tecnológico, la capacidad de entregar el producto al cliente y acompañarlo lo antes posible.
Es difícil decir sobre el tamaño del equipo. Probablemente todos ya conozcan la declaración de Jeff Bezos, el fundador de Amazon, de que el tamaño del equipo en el desarrollo orientado a servicios debería ser lo suficientemente pequeño como para que todos puedan recibir dos pizzas. En los comentarios sobre Habré, hubo una discusión sobre este tema, y escribieron que una persona puede no tener suficiente pizza y, por lo tanto, un equipo debe estar formado por una o dos personas. Martin Fowler, citando una declaración sobre dos pizzas, dijo que se trataba de grandes pizzas americanas, después de lo cual especificó que el equipo no debería tener 50, sino alrededor de 12 personas. Creo que todo depende del modelo del producto. Pero la aclaración de Fowler sobre "no más de 12 personas" ha ganado en mi práctica hasta ahora. Noté que dentro del equipo es deseable dividir de acuerdo con los intereses tecnológicos, para encontrar personas de ideas afines.
No es necesario que todos en el equipo conozcan bien todas las áreas tecnológicas utilizadas en el trabajo, pero el conocimiento total del equipo debe ser uniformemente profundo. Por ejemplo, dos personas participan en la construcción inicial de una implementación y, en el futuro, lo más probable es que también la mejoren significativamente. Pero al mismo tiempo, todo el equipo debe tener una buena comprensión del proceso de implementación. Esto le permitirá expresar sus deseos y hacer cambios. ¿Por qué dos personas? Porque a veces una persona puede caer en un estupor creativo. Y en la discusión, la verdad nace.
Naturalmente, construimos sobre este principio, unidos por intereses tecnológicos. Al mismo tiempo, el desarrollador también puede participar en el establecimiento de prácticas de DevOps, y el ingeniero de control de calidad puede desarrollar un servicio auxiliar que no sea de producción (por ejemplo, calentar el caché o el servicio de buscar anomalías en los datos en diferentes entornos).
- Casi todos los informes sobre microservicios comienzan con la historia de que "aquí tuvimos un iceberg y vimos, aserramos, aserramos ... Se hicieron nuevas partes de la aplicación en base a microservicios, y luego comenzamos a separar las" piezas "del motor principal ... "
Dime, ¿eres un defensor del desarrollo desde cero o puede haber situaciones en las que valga la pena hacer una conclusión gradual de un monolito? ¿Cómo determinar la estrategia de salida?Soy un defensor del desarrollo desde cero. Pero esto solo funciona si el conjunto de funciones no es demasiado complicado. Por lo general, se hace un pequeño monolito MVP. Y a veces es necesario cambiar radicalmente su implementación interna varias veces. Esto puede ser causado tanto por un cambio en la tarea técnica, como por el hecho de que se comprende la implementación: aparecen abstracciones de alto nivel en el nivel del modelo de negocio. Después de eso, puede pasar a la arquitectura de microservicio.
Pero si trabaja a través de estas abstracciones desde el principio y las dibuja en diferentes anotaciones (UML, BPMN, IDEF), de modo que todos los participantes en el proceso entiendan con qué están trabajando, entonces es muy posible implementar una arquitectura de microservicio de inmediato.
Nuestro camino hacia la arquitectura de microservicios no fue directo. Al principio había un monolito. Procesó materiales publicitarios textuales. Hace tres años y medio, necesitábamos trabajar con materiales publicitarios gráficos (imágenes, logotipos). Hubo un deseo de introducir en la lógica de negocios lo que faltaba al trabajar con materiales publicitarios de texto.
Para probar un nuevo modelo de negocio, implementamos el trabajo con materiales publicitarios gráficos como el segundo monolito en otra pila de tecnología. Después de un año y medio de operación, nos dimos cuenta de que este enfoque era correcto.
Durante este tiempo, obtuvimos mucha lista de deseos, revelamos la aspereza de la lógica empresarial.
La implementación del segundo monolito fue difícil de expandir al primero. Por lo tanto, decidimos no realizar el desarrollo en dos monolitos a la vez, sino combinarlos en el marco de la tercera arquitectura de acuerdo con el modelo de negocio muy nuevo. Se creó un equipo de siete desarrolladores, un ingeniero de control de calidad y dos analistas. Dos desarrolladores de este equipo crearon y respaldaron previamente el primer monolito, y uno más: el segundo monolito. Es decir, nuestro equipo que ya estaba en la entrada conocía bien las trampas de los monolitos anteriores.
El primer monolito fue escrito en C #. El segundo está en PHP. No queríamos perder los voluminosos trozos de código depurados del primer monolito, y al mismo tiempo se requerían múltiples hilos, código seguro y mecanografía fuerte. El código PHP parcialmente no cayó bajo estos requisitos. Por lo tanto, C # se mantuvo como la base e implementó lo que hizo bien en el marco del primer monolito, trabajar con el contenido de materiales publicitarios, pero sobre la base de otro almacenamiento: almacenamiento compatible con S3 y Kafka.
Para trabajar con el nuevo modelo de negocio, Scala y la base de datos PostgreSQL fueron seleccionadas esta vez. Scala cumplió con nuestros requisitos técnicos. Además, los desarrolladores de Scala se ubicaron en el mismo piso que los desarrolladores de C #. Esto redujo el tiempo para la comunicación del equipo. La ley de Conway funcionó: la estructura de la empresa dictaba la estructura de la aplicación. El desarrollador de PHP se ha desarrollado en un desarrollador de Scala. Acabo de terminar de trabajar en un microservicio independiente en Golang con un ciclo completo de CI / CD, después de lo cual me uní al equipo y también me convertí en desarrollador de Scala.
Es interesante lo que propuse exactamente para trabajar con la lógica de negocios de Scala, y no con C #. El hecho es que no teníamos suficientes desarrolladores de C #. PHP-shnik y yo queríamos volver a entrenarnos para Scala. Además, tuvimos la oportunidad de atraer a un desarrollador experimentado de Scala. Otro punto: si implementamos todo en C #, podríamos obtener una arquitectura de microservicio u otro monolito en la salida. La división en Scala y C #, las diferentes necesidades de almacenamiento y la disponibilidad de desarrolladores experimentados en cada una de las áreas requeridas, todo esto apunta directamente a la arquitectura del microservicio. Y solo nos beneficiamos de esto. Hace un año, la arquitectura de microservicios para trabajar con materiales gráficos y textuales entró en operación comercial y ha estado funcionando con éxito hasta el día de hoy.
A la pregunta de si es posible crear una arquitectura de microservicio desde cero. Hace un año y medio, en el proceso de trabajar en la arquitectura de microservicios, surgió una demanda para respaldar una nueva dirección en nuestros productos: materiales publicitarios de video. Era necesario probar rápidamente un nuevo modelo de ventas. Nuestra arquitectura estaba en su infancia. El trabajo con materiales de video cubrió una nueva área de tecnología. Decidimos no cambiar el vector de desarrollo e implementamos MVP para materiales de video como una arquitectura de microservicio independiente en C # y alojamiento de video confiable. Esta es una experiencia exitosa, y tenemos un
informe sobre este tema. Por lo tanto, tenemos dos arquitecturas de microservicios paralelas existentes. MVP no se desarrolló mucho, la lista de deseos también se acumuló en ella, y pronto combinaremos todo en el marco de una arquitectura de microservicio único: obtendremos un único repositorio de textos publicitarios, materiales gráficos y de video.
- Inmediatamente, hay dos factores importantes que hablan a favor de los microservicios. El primero es la capacidad de generar partes individuales en la nube y, como resultado, una escalabilidad colosal. El segundo es la capacidad de crear un servicio separado en otro idioma. ¿Qué otras ventajas de cambiar a microservicios ves? Bueno, de los inconvenientes, por supuesto, también quiero escuchar.Si hablamos del componente tecnológico, las ventajas, además de lo anterior, incluyen la posibilidad de utilizar otra pila de tecnologías. Y si no nos conviene, elegiremos otro. Las nuevas tecnologías evitan los problemas de las soluciones antiguas. La arquitectura de microservicios también brinda estabilidad e independencia: la degradación de un servicio no debe conducir a la degradación completa de todo el sistema. La componibilidad del servicio permite la reutilización de la funcionalidad del servicio en otras arquitecturas de microservicios. Desde el punto de vista del componente organizacional, dividir en servicios le permite dividir el desarrollo dentro de equipos distribuidos o un equipo grande.
Las principales desventajas de la arquitectura de microservicios: es mucho más complicada y su implementación es más costosa.
También debe estar preparado para admitir contratos de servicio, seleccionar el protocolo de acceso remoto correcto, resolver problemas de interacción segura entre servicios, posibles fallas, así como deduplicar y administrar transacciones distribuidas.
En general, en el dominio público puede encontrar mucha información y materiales sobre cómo trabajar con él. Pero, de hecho, todo depende de la tarea. En mi práctica, las ventajas siempre han sido más significativas que las desventajas.
Todavía vale la pena recordar las palabras de Sam Newman: cuanto menos es el servicio, más se manifiestan todas las ventajas y desventajas de la arquitectura de microservicios.
- Tienes algunos informes interesantes sobre microservicios. Implementación de microservicios y el enfoque de implementación continua en la arquitectura de microservicios . En una de las diapositivas de la primera hay plantillas de implementación, y en el informe dice que para usted el enfoque de tendencia es la distribución a través de contenedores. Durante este tiempo, nada ha cambiado? ¿Un montón de Docker + Kubernetes no ha perdido su relevancia?Estamos transfiriendo más y más servicios a este paquete. Creo que hemos elegido la dirección correcta y por el momento planeamos adherirnos a ella. Si algo cambia, se lo contaré en un nuevo informe o entrevista.
- ¿Qué tan fácil es el despliegue continuo y la transferencia de microservicios a prod?Todo depende de cómo construir el proceso. Al principio parece que todo es simple. Los servicios son independientes, se implementan por separado. La débil coherencia está garantizada por diferentes enfoques para trabajar con la evolución del contrato. Y aquí tienes que elegir. Por ejemplo, puede implementar el control de versiones de un contrato o agregar un servicio para desconectar un contrato (desacoplamiento del contrato).
Si en una arquitectura de microservicio en desarrollo activo hay 10 o más servicios a la vez y cada uno tiene su propia versión, entonces hay un problema de consistencia de la versión. Debemos tratar de no confundirnos en la compatibilidad de servicios de diferentes versiones.
La implementación continua significa que podemos entregar la aplicación en cualquier momento a cualquier entorno.
Una aplicación en arquitectura de microservicios es una colección de servicios. Entonces, en cualquier momento, necesitamos conocer una combinación estable de versiones de servicio. Y en otro lugar debemos tener un conjunto de direcciones de dominio y otros parámetros específicos para diferentes entornos para configurar servicios y vincularlos entre sí.
Todo esto debe almacenarse en algún lugar, para corregir los cambios en varios lugares (los microservicios son independientes después de todo) y no confundirse.
La implementación continua significa la capacidad de retroceder a cualquier versión en cualquier momento. En consecuencia, puede ser que necesite revertir varios servicios a la vez y deberá observar el orden correcto de implementación inversa del servicio.
En uno de mis informes, hablo sobre nuestro enfoque de la evolución de los contratos, cómo resolvieron el problema de la coherencia de las versiones y cómo construyeron el proceso de implementación en la arquitectura de microservicio de más de diez servicios. Una implementación continua puede no estar libre de problemas, pero todo es solucionable.
- ¿Cuál podría ser el conjunto inicial de herramientas para una implementación continua de microservicios? ¿Qué opciones recomendaría usar para trabajar con microservicios?La implementación continua es una secuencia de canalizaciones, que incluye integración continua, pruebas de integración y entrega de servicios al entorno de orquestación. Las herramientas de secuenciación por pasos más populares son
Jenkins 2 Pipelines ,
TeamCity Build Chains ,
Bitbucket Pipelines y
GitLab CI Pipelines . Primero necesita automatizar la integración continua (CI). Necesitamos un servidor de CI remoto para construir y ejecutar pruebas en este ensamblado.
Las herramientas enumeradas ofrecen sus soluciones. Usamos GitLab CI, y GitLab Runners actúan como tales servidores. El artefacto de construcción es la imagen de
Docker . Como parte de las pruebas de integración, puede realizar pruebas de carga y capacitivas utilizando
Gatling , en particular, para determinar los recursos que necesita (procesador y memoria) para funcionar en un entorno de orquestación (por ejemplo,
Kubernetes ).
Helm se usa ampliamente para la implementación, le permite describir la arquitectura de microservicios para diferentes entornos. En nuestra empresa no utilizamos Helm. Tenemos nuestra propia herramienta de implementación, que se creó cuando Helm estaba en la versión clásica y no era compatible con diferentes entornos. Ambas herramientas tienen cualidades útiles similares, pero la implementación y distribución son diferentes. Y nuestra propia herramienta nos permite realizar mejoras y adaptar todo a nuestra infraestructura.
- ¿Qué tecnologías son óptimas para las pequeñas y medianas empresas que desean implementar microservicios? ¿Es esto un placer demasiado caro para ellos?Cada vez más, me encuentro con confirmaciones de que las pequeñas y medianas empresas no son apropiadas para crear su propio entorno de orquestación (por ejemplo,
Kubernetes ,
Docker Swarm o
Apache Mesos ). . (
Google Cloud Platform ,
Amazon Web Services ,
Microsoft Azure Oracle Cloud ) .
GitLab GitLab CI. . GitLab Helm . Helm . Helm , , , .
, , , open source, .
Spinnaker Heroku — , , .
— , , , . . ?, . , , .
( ) . .
. . , (package). .
( ) Docker-, Git. , . ,
. , .
, . : API. . : . , API. , API , — . , API, .
. , ; API, ; , , .
, , . , ?— - .
, API, , . . .
, , . , , . , , .
— , . 2. , ? ?. .
Mesosphere ,
OpenShift PaaS IaaS . Deis
,
Deis . open source
Heroku , Heroku Buildpack', Dockerfile' Docker-. . make Deis. .
Deis2 . Deis, Kubernetes.
Infrastructure & Operations , , Kubernetes Deis2. , , Deis2, , — Kubernetes. . Deis2 : , pod pod' namespace. Infrastructure & Operations. Kubernetes . Deis2 Kubernetes. Deis2 Kubernetes.
— , , , ? ?Helm. , . Helm .
Helm , — : , .
Helm chart' chart, , .
2 , 10 . ( backing : Postgres, Kafka, Zookeeper, Ceph). - , yaml- , IDE, . , . Python, Python . , . , . , . , , . . , , , ( ) . , , Helm, Kubernetes - , yaml.
API
API Gateway . , — .
, : . , , .
DevOps , . DevOpsConf Russia .
DevOpsConf Russia 1 2 RootConf, , , , . DevOps , .
DevOps , , – . 15 .