Estilo de arquitectura de microserviciosMicroservices architecture style

Una arquitectura de microservicios consta de una colección de servicios autónomos y pequeños.A microservices architecture consists of a collection of small, autonomous services. Los servicios son independientes entre sí y cada uno debe implementar una funcionalidad de negocio individual.Each service is self-contained and should implement a single business capability.

Diagrama lógico del estilo de arquitectura de microservicios

¿Qué son los microservicios?What are microservices?

  • Los microservicios son pequeños e independientes, y están acoplados de forma imprecisa.Microservices are small, independent, and loosely coupled. Un único equipo reducido de programadores puede escribir y mantener un servicio.A single small team of developers can write and maintain a service.

  • Cada servicio es un código base independiente, que puede administrarse por un equipo de desarrollo pequeño.Each service is a separate codebase, which can be managed by a small development team.

  • Los servicios pueden implementarse de manera independiente.Services can be deployed independently. Un equipo puede actualizar un servicio existente sin tener que volver a generar e implementar toda la aplicación.A team can update an existing service without rebuilding and redeploying the entire application.

  • Los servicios son los responsables de conservar sus propios datos o estado externo.Services are responsible for persisting their own data or external state. Esto difiere del modelo tradicional, donde una capa de datos independiente controla la persistencia de los datos.This differs from the traditional model, where a separate data layer handles data persistence.

  • Los servicios se comunican entre sí mediante API bien definidas.Services communicate with each other by using well-defined APIs. Los detalles de la implementación interna de cada servicio se ocultan frente a otros servicios.Internal implementation details of each service are hidden from other services.

  • No es necesario que los servicios compartan la misma pila de tecnología, las bibliotecas o los marcos de trabajo.Services don't need to share the same technology stack, libraries, or frameworks.

Además de los propios servicios, hay otros componentes que aparecen en una arquitectura típica de microservicios:Besides for the services themselves, some other components appear in a typical microservices architecture:

Administración e implementación.Management/orchestration. Este componente es el responsable de la colocación de servicios en los nodos, la identificación de errores, el reequilibrio de servicios entre nodos, etc.This component is responsible for placing services on nodes, identifying failures, rebalancing services across nodes, and so forth. Normalmente, este componente es una tecnología estándar, como Kubernetes, en lugar de algo creado de forma personalizada.Typically this component is an off-the-shelf technology such as Kubernetes, rather than something custom built.

Puerta de enlace de APIAPI Gateway. La puerta de enlace de API es el punto de entrada para los clientes.The API gateway is the entry point for clients. En lugar de llamar a los servicios directamente, los clientes llaman a la puerta de enlace de API, que reenvía la llamada a los servicios apropiados en el back-end.Instead of calling services directly, clients call the API gateway, which forwards the call to the appropriate services on the back end.

Entre las ventajas de usar una puerta de enlace de API se encuentran las siguientes:Advantages of using an API gateway include:

  • Desacoplan los clientes de los servicios.It decouples clients from services. Los servicios pueden cambiar de versión o refactorizarse sin necesidad de actualizar todos los clientes.Services can be versioned or refactored without needing to update all of the clients.

  • Los servicios pueden utilizar los protocolos de mensajería que no son fáciles de usar para un servicio web, como AMQP.Services can use messaging protocols that are not web friendly, such as AMQP.

  • La puerta de enlace de API puede realizar otras funciones transversales como la autenticación, el registro, la terminación SSL y el equilibrio de carga.The API Gateway can perform other cross-cutting functions such as authentication, logging, SSL termination, and load balancing.

VentajasBenefits

  • Agilidad.Agility. Dado que microservicios se implementan de forma independiente, resulta más fácil de administrar las correcciones de errores y las versiones de características.Because microservices are deployed independently, it's easier to manage bug fixes and feature releases. Puede actualizar un servicio sin volver a implementar toda la aplicación y revertir una actualización si algo va mal.You can update a service without redeploying the entire application, and roll back an update if something goes wrong. En muchas aplicaciones tradicionales, un error en una parte de la aplicación puede bloquear todo el proceso de lanzamiento.In many traditional applications, if a bug is found in one part of the application, it can block the entire release process. Es posible que se requieran nuevas características a la espera de que se integre, pruebe y publique una corrección de errores.New features may be held up waiting for a bug fix to be integrated, tested, and published.

  • Equipos pequeños y centrados.Small, focused teams. Un microservicio debe ser lo suficientemente pequeño como para que un solo equipo de características lo pueda compilar, probar e implementar.A microservice should be small enough that a single feature team can build, test, and deploy it. Los equipos pequeños favorecen la agilidad.Small team sizes promote greater agility. Los equipos grandes suelen ser menos productivos, porque la comunicación es más lenta, aumenta la sobrecarga de administración y la agilidad disminuye.Large teams tend be less productive, because communication is slower, management overhead goes up, and agility diminishes.

  • Base de código pequeña.Small code base. En las aplicaciones monolíticas, con el paso del tiempo se da la tendencia de que las dependencias del código se acaben enredarse, por lo que para agregar una nueva característica, es preciso tocar el código en muchos lugares.In a monolithic application, there is a tendency over time for code dependencies to become tangled Adding a new feature requires touching code in a lot of places. Al no compartir el código ni los almacenes de datos, la arquitectura de microservicios minimiza las dependencias y resulta más fácil agregar nuevas características.By not sharing code or data stores, a microservices architecture minimizes dependencies, and that makes it easier to add new features.

  • Mezcla de tecnologías.Mix of technologies. Los equipos pueden elegir la tecnología que mejor se adapte al servicio de una combinación de pilas de tecnología, según corresponda.Teams can pick the technology that best fits their service, using a mix of technology stacks as appropriate.

  • Aislamiento de errores.Fault isolation. Si un microservicio individual no está disponible, no interrumpe toda la aplicación, siempre que los microservicios de nivel superior estén diseñados para controlar los errores correctamente (por ejemplo, mediante la implementación de disyuntores).If an individual microservice becomes unavailable, it won't disrupt the entire application, as long as any upstream microservices are designed to handle faults correctly (for example, by implementing circuit breaking).

  • Escalabilidad.Scalability. Los servicios se pueden escalar de forma independiente, lo que permite escalar horizontalmente los subsistemas que requieren más recursos, sin tener que escalar horizontalmente toda la aplicación.Services can be scaled independently, letting you scale out subsystems that require more resources, without scaling out the entire application. Mediante un orquestador como Kubernetes o Service Fabric se puede empaquetar una mayor densidad de servicios en un solo host, lo que aumenta la eficacia en el uso de los recursos.Using an orchestrator such as Kubernetes or Service Fabric, you can pack a higher density of services onto a single host, which allows for more efficient utilization of resources.

  • Aislamiento de los datos.Data isolation. Al verse afectado solo un microservicio, es mucho más fácil realizar actualizaciones del esquema.It is much easier to perform schema updates, because only a single microservice is affected. En una aplicación monolítica, las actualizaciones del esquema pueden ser muy complicadas, ya que las distintas partes de la aplicación pueden tocar los mismos datos, por lo que realizar modificaciones en el esquema resulta peligroso.In a monolithic application, schema updates can become very challenging, because different parts of the application may all touch the same data, making any alterations to the schema risky.

DesafíosChallenges

Las ventajas de los microservicios tienen un "precio".The benefits of microservices don't come for free. Estos son algunos de los aspectos que deben tenerse en cuenta antes de embarcarse en una arquitectura de microservicios.Here are some of the challenges to consider before embarking on a microservices architecture.

  • Complejidad.Complexity. Una aplicación de microservicios tiene más partes en movimiento que la aplicación monolítica equivalente.A microservices application has more moving parts than the equivalent monolithic application. Cada servicio es más sencillo, pero el sistema como un todo es más complejo.Each service is simpler, but the entire system as a whole is more complex.

  • Desarrollo y pruebas.Development and testing. La escritura de un servicio pequeño que utilice otros servicios dependientes requiere un enfoque que no sea escribir una aplicación tradicional monolítica o en capas.Writing a small service that relies on other dependent services requires a different approach than a writing a traditional monolithic or layered application. Las herramientas existentes no siempre están diseñadas para trabajar con dependencias de servicios.Existing tools are not always designed to work with service dependencies. La refactorización en los límites del servicio puede resultar difícil.Refactoring across service boundaries can be difficult. También supone un desafío probar las dependencias de los servicios, especialmente cuando la aplicación está evolucionando rápidamente.It is also challenging to test service dependencies, especially when the application is evolving quickly.

  • Falta de gobernanza.Lack of governance. El enfoque descentralizado para la generación de microservicios tiene ventajas, pero también puede causar problemas.The decentralized approach to building microservices has advantages, but it can also lead to problems. Puede acabar con tantos lenguajes y marcos de trabajo diferentes que la aplicación puede ser difícil de mantener.You may end up with so many different languages and frameworks that the application becomes hard to maintain. Puede resultar útil establecer algunos estándares para todo el proyecto sin restringir excesivamente la flexibilidad de los equipos.It may be useful to put some project-wide standards in place, without overly restricting teams' flexibility. Esto se aplica especialmente a las funcionalidades transversales, como el registro.This especially applies to cross-cutting functionality such as logging.

  • Congestión y latencia de red.Network congestion and latency. El uso de muchos servicios pequeños y detallados puede dar lugar a más comunicación interservicios.The use of many small, granular services can result in more interservice communication. Además, si la cadena de dependencias del servicio se hace demasiado larga (el servicio A llama a B, que llama a C...), la latencia adicional puede constituir un problema.Also, if the chain of service dependencies gets too long (service A calls B, which calls C...), the additional latency can become a problem. Tendrá que diseñar las API con atención.You will need to design APIs carefully. Evite que las API se comuniquen demasiado, piense en formatos de serialización y busque lugares para utilizar patrones de comunicación asincrónica.Avoid overly chatty APIs, think about serialization formats, and look for places to use asynchronous communication patterns.

  • Integridad de datos.Data integrity. Cada microservicio es responsable de la conservación de sus propios datos.With each microservice responsible for its own data persistence. Como consecuencia, la coherencia de los datos puede suponer un problema.As a result, data consistency can be a challenge. Adopte una coherencia final cuando sea posible.Embrace eventual consistency where possible.

  • Administración.Management. Para tener éxito con los microservicios se necesita una cultura de DevOps consolidada.To be successful with microservices requires a mature DevOps culture. El registro correlacionado entre servicios puede resultar un desafío.Correlated logging across services can be challenging. Normalmente, el registro debe correlacionar varias llamadas de servicio para una sola operación de usuario.Typically, logging must correlate multiple service calls for a single user operation.

  • Control de versiones.Versioning. Las actualizaciones de un servicio no deben interrumpir servicios que dependen de él.Updates to a service must not break services that depend on it. Es posible que varios servicios se actualicen en cualquier momento; por lo tanto, sin un cuidadoso diseño, podrían surgir problemas con la compatibilidad con versiones anteriores o posteriores.Multiple services could be updated at any given time, so without careful design, you might have problems with backward or forward compatibility.

  • Conjunto de habilidades.Skillset. Los microservicios son sistemas muy distribuidos.Microservices are highly distributed systems. Evalúe cuidadosamente si el equipo tiene los conocimientos y la experiencia para desenvolverse correctamente.Carefully evaluate whether the team has the skills and experience to be successful.

Procedimientos recomendadosBest practices

  • Adapte los servicios al dominio empresarial.Model services around the business domain.

  • Descentralice todo.Decentralize everything. Los equipos individuales son responsables de diseñar y compilar servicios.Individual teams are responsible for designing and building services. Evite el uso compartido de código o esquemas de datos.Avoid sharing code or data schemas.

  • El almacenamiento de datos debería ser privado para el servicio que posee los datos.Data storage should be private to the service that owns the data. Use el almacenamiento recomendado para cada tipo de servicio y de datos.Use the best storage for each service and data type.

  • Los servicios se comunican a través de API bien diseñadas.Services communicate through well-designed APIs. Evite la pérdida de detalles de la implementación.Avoid leaking implementation details. Las API deben modelar el dominio, no la implementación interna del servicio.APIs should model the domain, not the internal implementation of the service.

  • Evite el acoplamiento entre servicios.Avoid coupling between services. Entre las causas de acoplamiento se encuentran los protocolos de comunicación rígidos y los esquemas de bases de datos compartidos.Causes of coupling include shared database schemas and rigid communication protocols.

  • Descargue a la puerta de enlace de cuestiones transversales, como la autenticación y la terminación SSL.Offload cross-cutting concerns, such as authentication and SSL termination, to the gateway.

  • Conserve el conocimiento del dominio fuera de la puerta de enlace.Keep domain knowledge out of the gateway. La puerta de enlace debe controlar y enrutar las solicitudes de cliente sin ningún conocimiento de las reglas de negocios o la lógica de dominio.The gateway should handle and route client requests without any knowledge of the business rules or domain logic. En caso contrario, la puerta de enlace se convierte en una dependencia y puede provocar el acoplamiento entre servicios.Otherwise, the gateway becomes a dependency and can cause coupling between services.

  • Los servicios deben tener un acoplamiento flexible y una alta cohesión funcional.Services should have loose coupling and high functional cohesion. Las funciones que es probable que cambien juntas se deben empaquetar e implementar en conjunto.Functions that are likely to change together should be packaged and deployed together. Si residen en distintos servicios, estos terminan estrechamente acoplados, porque un cambio en un servicio requerirá la actualización del otro servicio.If they reside in separate services, those services end up being tightly coupled, because a change in one service will require updating the other service. La comunicación demasiado intensa entre dos servicios puede ser un síntoma de un acoplamiento estrecho y una cohesión baja.Overly chatty communication between two services may be a symptom of tight coupling and low cohesion.

  • Aísle los errores.Isolate failures. Utilice estrategias de resistencia para impedir que los errores dentro de un servicio se reproduzcan en cascada.Use resiliency strategies to prevent failures within a service from cascading. Consulte Patrones de resistencia y Diseño de aplicaciones confiables.See Resiliency patterns and Designing reliable applications.

Pasos siguientesNext steps

Para obtener instrucciones detalladas sobre cómo crear una arquitectura de microservicios en Azure, consulte Designing, building, and operating microservices on Azure (Diseño, creación y funcionamiento de microservicios en Azure).For detailed guidance about building a microservices architecture on Azure, see Designing, building, and operating microservices on Azure.