¿Cuál es el papel del arquitecto en la arquitectura de microservicios?

A continuación se detallan los puntos que un arquitecto de micro servicios debería considerar antes de comenzar el viaje. Tenga en cuenta que un buen modelado de dominio y reactivo es esencial para crear un diseño robusto de micro servicio.

  1. Es una mala idea diseñar y desarrollar microservicios desde cero si su organización y usted no tienen antecedentes de trabajar en una sola, en comparación con lo que ha arraigado la cultura de microservicios.
  2. La mejor práctica es comenzar a refactorizar un microservicio cuyo modelo de dominio se entiende bien en base al supuesto de que está en evolución durante bastante tiempo.
  3. El arquitecto debe considerar varios otros patrones, diseño arquitectónico, aspecto de implementación al diseñar su modelo de dominio, por ejemplo, reglas comerciales, persistencia, almacenamiento en caché, gestión de transacciones, seguridad, generación de código, TDD, principios de refactorización.
  4. Un modelo de dominio defectuoso puede dar lugar a la creación de una “Capa de servicio pesado” o lo que comúnmente se conoce como “Modelo de dominio anémico”, donde las clases de fachada (beans de sesión sin estado en la mayoría de los casos) comienzan a acumular más y más lógica empresarial y el objeto de dominio se convierte en meros datos transportistas con toneladas de captadores y colocadores.
  5. El arquitecto debe concebir el modelo de dominio de tal manera que el modelo se centre en un dominio operativo comercial específico, debe estar en la alineación adecuada con el modelo comercial, las estrategias y el proceso comercial, que evoluciona a lo largo de un período de tiempo.
  6. El arquitecto debe enfocarse en el aspecto de implementación de los microservicios donde cada servicio trabaja en completo aislamiento uno del otro utilizando el paradigma de alta cohesión y acoplamiento flexible.
  7. Identifique las siguientes prácticas recomendadas de microservicios al salir con diseño, contexto acotado, CQRS, abastecimiento de eventos, persistencia Polyglot, interrupción de circuitos (Hystrix), gestión de datos controlada por eventos, etc.
  8. Identifique si se debe usar un modelo OSS basado en Netflix para la implementación de servicios o un modelo diferente de implementación
  9. Identifique herramientas robustas para diversas metodologías y técnicas, tales como tienda de eventos, registro de servicios, descubrimiento de servicios (Consul, etc.), CD / CI, bases de datos para persistencia políglota, contenedores, para diversos servicios y su implementación
  10. Identifique las técnicas de integración, como las puertas de enlace API, para el registro de servicios, la limitación, la gestión, la orquestación, la coreografía, etc.
  11. Identidad y autenticación, utilizando herramientas como Oauth2 o JSON Web Tokens
  12. Identifique la responsabilidad de DevOps en términos inequívocos e identifique herramientas para la misma que incluyen Docker y contenedorización y decida si usar VM vs. Contenedores
  13. identificar un PAS, una buena idea, sin embargo, para una fácil implementación en la nube de servicios, PCF, Kubernetes, Fabric 8 es una buena herramienta. Proponga enérgicamente un PaaS para el despliegue, ya que la mayor parte del dolor / trampa del despliegue puede ser atendida por un PaaS robusto.
  14. Identificar herramientas de monitoreo, como Kibana, logstach, grafana
  15. Construir una hoja de ruta adecuada junto con negocios en torno a la arquitectura de servicios para varios componentes de negocios de forma aislada o en grupo para ser competitivos y rápidos en el mercado
  16. La mejor práctica no solo para el equipo individual que desarrolla sus servicios independientes (funcionalidades comerciales) en sus respectivos dominios tecnológicos
  17. Gestione la interacción entre varios equipos en el desarrollo de micro servicios y mantenga las dependencias al mínimo
  18. interactuar con Ops para desarrollar un plan de lanzamiento incremental y pruebas automatizadas de servicio
  19. Hay un montón de otros detalles esenciales que un arquitecto tiene que identificar y que forman la base del desarrollo de micro servicios. eso incluye, entre otros, identificar diversas tecnologías para los servicios que se desarrollarán y expondrán.
  20. Esta pregunta requiere un libro completo para explicar la responsabilidad de un arquitecto 🙂

Creo que debería ser sobre lo siguiente:

  1. Diseño / selección de facilitación de EM. El famoso “hacer o comprar / obtener” de toda la infraestructura de MS o partes de ella, que, etc.
  2. Protocolos entre MS: tcp, udp, http, message-queue, etc. Uno o unos pocos?
  3. Desglosando el proyecto en componentes conceptuales. Decidir qué sería una MS y qué sería una biblioteca estática, que debería ser un grupo de MS-s, etc.
  4. Asegurar que el flujo de ejecución, las dependencias, etc. sean razonables.
  5. Pensando en una cabeza de escala: cómo afectaría a los planes de futuro cercano y haría planes preventivos inteligentes (dentro de límites razonables, por supuesto, no debe planear en exceso de antemano).
  6. Sea un “código nazi” de vez en cuando y asegúrese de refactorizar en cada proceso.
  7. Inspira, por supuesto
  8. Que sea divertido para el equipo …
  9. Mantenlo hermoso …

Los arquitectos, en la arquitectura de Microservicios, desempeñan el papel de urbanistas. Deciden a grandes rasgos sobre el diseño del sistema de software en general.

Ayudan a decidir la zonificación de los componentes. Se aseguran de que los componentes sean cohesivos entre sí pero no estén estrechamente acoplados. No necesitan preocuparse por lo que hay dentro de cada zona.

Dado que tienen que mantenerse al día con los nuevos desarrollos y problemas, tienen que codificar con los desarrolladores para aprender los desafíos que enfrentan en la vida cotidiana.

Pueden hacer recomendaciones para ciertas herramientas y tecnologías, pero el equipo que desarrolla un micro servicio está finalmente facultado para crear y diseñar el servicio. Recuerde, la implementación de un micro servicio puede cambiar con el tiempo.

Deben proporcionar un gobierno técnico para que los equipos en su desarrollo técnico sigan los principios de Microservice.

A veces trabajan como custodios de la arquitectura general de Microservicios.