1. Principios de los Microservicios
- Al modelar en torno a conceptos empresariales, la experiencia ha demostrado que las interfaces definidas en torno a contextos delimitados empresariales son más estables que las interfaces definidas en torno a conceptos técnicos.
- Adoptando la cultura de la automatización, los microservicios contienen demasiada complejidad, como que tenemos que administrar una gran cantidad de servicios. Entonces, la mejor manera es dedicar una cierta cantidad de tiempo en la etapa inicial para crear herramientas que admitan microservicios; también hay pruebas automatizadas, scripts de implementación, etc., que pueden ayudarnos a hacer la mayoría de las cosas que consumen mucho tiempo.
- Oculte los detalles de implementación internos para hacer que un servicio sea independiente de otros servicios y maximizar la capacidad de evolucionar de forma independiente. El modelado de contexto acotado puede ayudar aquí. Los servicios también deberían ocultar sus bases de datos para evitar caer en el acoplamiento de datos. Elija API que admitan tecnologías comunes siempre que sea posible, lo que le brinda la libertad de elegir usar diferentes pilas de tecnología.
- Se puede implementar de forma independiente y los efectos secundarios causados por la implementación se pueden reducir adoptando el modo de host único de servicio único. Considere usar técnicas de implementación blue/green o Canary.
- Para aislar las fallas, debemos tener en cuenta las posibles fallas en los servicios posteriores, o el sistema sufrirá una falla catastrófica. Así que recuerde las "formas anti-frágiles", como configurar los tiempos de espera correctamente, saber cuándo y cómo usar mamparos e interruptores automáticos.
2. Cuándo no debes usar microservicios
- La primera sugerencia es que cuanto menos sepa sobre un dominio, más difícil será encontrar el contexto adecuado para su servicio. Como se mencionó anteriormente, la división incorrecta de los límites de los servicios puede generar cambios frecuentes en la colaboración entre los servicios, lo cual es muy costoso. Entonces, lo primero que debe hacer antes de particionar los servicios es dedicar un tiempo a comprender qué hace el sistema y luego tratar de identificar los límites claros del módulo. Si se trata de un campo comercial completamente nuevo, considere construir primero un solo sistema y dividirlo después de que sea estable.
3. Palabras finales
La arquitectura de microservicios nos brinda más opciones y nos obliga a tomar más decisiones. Por lo tanto, no podemos evitar cometer errores en algunas decisiones, así que intente influir en el alcance de la decisión tanto como sea posible. La idea aquí es adoptar la arquitectura evolutiva.
Los microservicios construidos por cada organización son únicos, no busques los llamados estándares, es mejor usarlos como referencia. Nuestro sistema necesita ser cambiado y evolucionado paulatinamente para adaptarse a nuestro negocio, en cualquier momento, nuestro negocio puede llevarse a cabo normalmente y con cierta eficiencia, lo que puede demostrar que nuestro sistema es estable y eficaz.
Nota de Blogger: si los lectores también usan el lenguaje Go para desarrollar proyectos y tienen la intención de adoptar la arquitectura de microservicios, lo invitamos a prestar atención al proyecto de ejemplo go-kit go-kit- examples , que contiene documentos detallados y códigos necesarios para comenzar con go-kit, y más Contiene puertas de enlace y proyectos de demostración de microservicios completamente comentados.
-------------------------------------------------- -------------- La línea divisoria de saosao ------------------------------- - ----------------------------------------
Grupo de la tribu de codificación de Blogger 588757596, ¡vengan a jugar juntos!