1. Migración de Manejo de Datos Antipatron.
El antipatrón de migración basado en datos se produce
principalmente cuando se migra de una aplicación
monolítica a una arquitectura de microservicios. La razón
por la que esto es un antipatrón es que al principio parece
una buena idea migrar la funcionalidad del servicio y los
datos correspondientes al crear microservicios, pero
como aprenderá en este capítulo, esto lo llevará por un
mal camino que puede resultar en alto riesgo, exceso de
costo y esfuerzo de migración adicional.
Comprender los riesgos relacionados con la migración de
datos y la importancia de "datos sobre funcionalidad" es
el primer paso para evitar este antipatrón.
La técnica para evitar este antipraton consiste en realizar primero una migración de la funcionalidad, es decir, primero refactorizar el código fuente, pasando por primero modularizar el contexto o dominio y continuar con la definición y construcción de servicios, a medida que se conoce el código que se está modificando se va ajustando la granuralidad de cada uno, finalmente se realiza la migración de los datos al nuevo esquema o base de datos objetivo.
El tiempo entre el momento en que se crea el servicio y
los datos finalmente se migran crea un acoplamiento de
datos entre los servicios. Esto significa que cuando se
cambia el esquema de la base de datos, todos los
servicios que usan ese esquema deben coordinarse desde
un punto de vista de control de cambios y liberación, algo
que desea evitar con la arquitectura de microservicios.
Migre la funcionalidad del servicio primero, luego la porción
de datos más tarde
2. Time Out Antipraton
Los microservicios son una arquitectura distribuida, es decir, que los servicios se implementan como aplicaciones separadas y se accede por medio de un protocolo de acceso de manera remoto. Por lo tanto uno de los desafíos es la disponibilidad y la capacidad de respuesta.
La
disponibilidad es la capacidad del consumidor de conectarse con el servicio y poder enviarle una
solicitud.
La capacidad es el tiempo que le toma
al servicio responder a una solicitud.
¿qué sucede si el consumidor logra conectarse pero el servicio no
responde? En este caso, se puede
elegir esperar indefinidamente o aprovechar algún tipo
de valor de tiempo de espera.
Está técnica parece ser una buena idea, pero puede
llevarlo por un mal camino conocido como el antipatrón
de (Time Out) tiempo de espera.
Comúnmente se usan 2 técnicas. La primera es usar el tiempo de espera de la base de datos y tomarlo como referencia. La segunda es duplicar el tiempo de espera máximo bajo carga. Profundizando el segundo escenario si un servicio toma 2 segundos en promedio en responder y 5 segundos bajo carga, el tiempo de espera seria de 10 segundos. Esto se considera antipratón ya que a pesar de ser una solución lógica ocasiona que se deba esperar 10 segundos para determinar que un servicio fallo y comunmente un usuario al pasar 3 segundos vuelve a intentar una operación o cierra su aplicación.
Patrón Circuit Breaker.
Este patrón funciona como un interruptor automático en su
casa. Cuando está cerrado, la electricidad fluye a través
de él, pero una vez que está abierto, no puede pasar
electricidad hasta que se cierra el interruptor. Del mismo
modo, si un circuit breaker en tu software detecta que un
servicio no responde, se abrirá y rechazará las
solicitudes a ese servicio. Una vez que el servicio se
vuelve receptivo, el interruptor se cerrará, permitiendo
que las solicitudes pasen.
Dependiendo de la implementación, el consumidor del
servicio siempre consultará primero con el circuit breaker para ver si está abierto o cerrado o también se puede
hacer a través de un patrón de interceptor para que el
consumidor del servicio no necesite saber que el
circuit breaker está en el proceso de solicitud.
La ventaja significativa de este patrón sobre los valores de tiempo de espera es que
el consumidor del servicio sabe de inmediato que el
servicio no responde en lugar de tener que esperar el
valor de tiempo de espera.
Para profundizar en este patrón recomiendo:
Ejemplos de implementación:
1. https://www.dropbox.com/s/alx848n1dsgj6un/CircuitBreaker2.zip?dl=1
Comunicación basada en Eventos
Patron Service Discovery
3. Antipatron "I Was Taught to Share” Me enseñaron a compartir.
Este nivel de uso compartido no solo desglosa el contexto
limitado de cada servicio, sino que también presenta
varios problemas, incluida la confiabilidad general, el
control de cambios, la capacidad de prueba y la
implementación.
Demasiadas dependencias
Si considera cómo se desarrollan la mayoría de las
aplicaciones de software orientadas a objetos , no es
difícil ver los problemas con el uso compartido,
particularmente cuando se migra de una arquitectura
monolítica en capas a una de microservicios. Una de las
cosas por las que debe esforzarse en la mayoría de las
aplicaciones monolíticas es la reutilización y el uso
compartido de códigos. La Figura 3-2 ilustra los dos
artefactos principales (clases abstractas y utilidades
compartidas) que terminan siendo compartidos en la
mayoría de las arquitecturas monolíticas en capas.
Uno de los objetivos principales del estilo de arquitectura
de microservicios es compartir lo menos posible. Esto
ayuda a preservar el contexto limitado de cada servicio,
que es lo que le brinda la capacidad de realizar pruebas e
implementaciones rápidas. Con microservicios todo se
reduce a cambiar el control y las dependencias. Cuantas
más dependencias tenga entre los servicios, más difícil
será aislar los cambios del servicio, lo que dificultará
probar e implementar servicios individuales por
separado. Compartir demasiado crea demasiadas
dependencias entre los servicios, lo que da como
resultado sistemas frágiles que son muy difíciles de
probar e implementar.
Técnicas para compartir código
Un consejo para las bibliotecas compartidas : evite
combinar todo su código compartido en una única
biblioteca compartida como common.jar . El uso de una
biblioteca común hace que sea difícil saber si necesita
incorporar el código compartido y cuándo. Una mejor
técnica es separar las bibliotecas compartidas en otras
que tengan contexto. Por ejemplo, cree bibliotecas
basadas en contexto como security.jar , persis‐ tence.jar ,
dateutils.jar , etc. Esto separa el código que no cambia a
menudo del código que cambia con frecuencia, lo que
hace que sea más fácil
4. Alcance de Informes - Reportes
Con el estilo arquitectural de microservicios los servicios y los datos se encuentra en un contexto aislado por lo tanto es único y es fundamental mantenerlo, eso quiere decir que los datos se migran a Esquemas, Instancia o hasta base de datos separadas, por lo tanto la reportabilidad se complica.
Existen 4 técnicas para manejarlo, de las cuales 3 son antipatrones.
- the database pull model.
- HTTP pull model,
- batch pull model
- the event-based push model
- the database pull model.(Modelo de informes de extracción de base de datos)
La forma más rápida y fácil de obtener
datos oportunos es acceder a ellos directamente. Pero esto genera interdependencias significativas entre los
servicios y el servicio de informes. Esta es una
implementación típica del estilo de integración de bases
de datos compartidas, que combina aplicaciones a través
de una base de datos compartida.
- HTTP pull model,(Modelo de informes de extracción HTTP)
Si bien este modelo conserva la autononia de cada
servicio, es demasiado lenta.
Además, dependiendo del
volumen de datos puede ser una carga demasiado
grande para una simple llamada HTTP.
- batch pull model(Modelo de informes de extracción por lotes)
Este modelo utiliza una base de
datos de informes o un almacén de datos que contiene
los datos de informes agregados y reducidos. La base de
datos de informes generalmente se completa a través de
un trabajo por lotes que se ejecuta en un horario especifico para
extraer todos los datos e insertarlos en la base de
datos de informes. El principal problema es si el esquema de la base de datos de
servicio cambia, también lo debe hacer el proceso de
carga de datos por lotes.
- the event-based push model (Basado en eventos)
Este modelo conserva el
contexto limitado de cada servicio y al mismo tiempo
garantiza una tiempo razonable de disponibilidad de los datos. Este modelo
también tiene una base de datos de informes separada
propiedad del servicio de informes. Cada
microservicio envía asincrónicamente sus actualizaciones de los datos que necesita el
servicio de informes. Para este modelo se requiere un contrato
entre cada microservicio y el servicio de captura de datos, ese contrato es independiente del esquema de base
de datos propiedad del servicio. Sin embargo, los
servicios están algo acoplados en el sentido de que cada
servicio debe saber cuándo enviar qué información para
informar.
5. Grains of Sand Pitfall ("Granos de la trampa de Arena")
Elegir el nivel
correcto de granularidad para sus servicios es
fundamental para el éxito de cualquier esfuerzo de
microservicios. La granularidad del servicio puede
afectar el rendimiento, la robustez, la fiabilidad, el
control de cambios, la capacidad de prueba e incluso la
implementación.
Este antipatron se produce cuando se crean servicios demasiado
finos.
En ocasiones sucede esto porque se confunde un servicio con una clase. La implementación de un
componente de servicio utilizando una relación
uno a uno entre un módulo y un componente de servicio
no solo se presta a componentes que son demasiado
finos, sino que también conduce a prácticas de
programación deficientes. Los servicios implementados a
través de una sola clase tienden a tener clases que son
demasiado grandes y conllevan demasiada
responsabilidad, lo que dificulta su mantenimiento y
prueba.
- Analisis del alcance
La primera forma de determinar si sus servicios tienen el
nivel correcto de granularidad es analizar el alcance y la
función del servicio. ¿Qué hace el servicio? ¿Cuáles son
sus operaciones? Documentar o expresar verbalmente el
alcance y la función del servicio es una excelente manera
de determinar si el servicio está haciendo demasiado. El
uso de palabras como "y" y "además" suele ser un buen
indicador de que el servicio probablemente está
haciendo demasiado.
La cohesión también juega un papel con respecto al
alcance y la función del servicio. La cohesión se define
como el grado y la forma en que las operaciones del servicio están interrelacionadas.
Si descubre que tiene que comunicarse con demasiados
servicios para completar solicitudes de negocios
individuales, entonces probablemente haya hecho que
sus servicios sean demasiado específicos. Al analizar el
nivel de coreografía de servicio, generalmente pasará de
los servicios de grano fino a los de grano más grueso.
6. Desarrollador sin causa Caída
Entender el porque de las decisiones de la arquitectura
7. Analizar las ventajas y desventajas de los microservicios para determinar si es la arquitectura correcta.
8. la trampa del contrato estatico.
Todos los microservicios tienen contratos entre los
consumidores del servicio y el microservicio. Un contrato
generalmente contiene un esquema que especifica los datos de
entrada y salida esperados y, a veces, el nombre de la
operación (dependiendo de cómo esté implementando su
servicio). Los contratos generalmente son propiedad del
servicio y pueden representarse a través de formatos como
XML, JSON o incluso un objeto Java o C #. Y, por supuesto, esos
contratos nunca cambian, ¿verdad? Incorrecto.
El escollo de los contratos estáticos ocurre cuando no
puede versionar sus contratos de servicio desde el
principio, o incluso no lo hace. La versión de contrato es
absolutamente crítica no solo para evitar cambios
importantes (cambiar un contrato y todos los
consumidores que usan ese contrato), sino también para
mantener la agilidad al apoyar la compatibilidad con
versiones anteriores.
VERSIONAMIENTO DE SERVICIOS: API MANAGMENT, VERSIONAMIENTO Y PRINCIPIO DE MANTENER LA FUNCIONALIDAD ANTERIOR.
9. ¿Ya estamos allí? : Medición de latencia.
10. Dale un descanso de
trampa.
Comuni
Comentarios
Publicar un comentario