No entiendo nada sobre la arquitectura de microservicios, así que decidí leer y resumir el libro de Sam Newman, Creación de microservicios. En mi opinión, resultó ser una buena introducción para las personas que están comenzando a sumergirse en este tema.
Microservicios
La idea de la arquitectura de microservicios se basa en varios conceptos: diseño orientado a temas, entrega continua, virtualización bajo demanda, automatización de infraestructura, pequeños equipos independientes y sistemas escalables. El microservicio es un servicio autónomo pequeño (puede reescribirse por completo en dos semanas) que realiza una sola tarea. Al mismo tiempo, los límites de los microservicios se forman sobre la base de los límites comerciales.
Ventajas del enfoque:
- la heterogeneidad tecnológica es posible;
- la degradación elegante se logra fácilmente;
- partes individuales del sistema escalan independientemente;
- despliegue independiente de servicios;
- simple intercambio de responsabilidades entre equipos.
Parece que es posible reemplazar la arquitectura del microservicio simplemente poniendo código en las bibliotecas. Pero esto resuelve solo una parte de los problemas: la heterogeneidad técnica, el escalado simple y la implementación independiente son imposibles. Además, el problema de la conectividad incontrolada continúa.
En algunos idiomas (por ejemplo, Erlang), partes individuales del programa (módulos) se pueden escalar e implementar de forma independiente. Pero esto es más bien una excepción a la regla.
Los microservicios no son una bala de plata. Están sujetos a todos los problemas de los sistemas distribuidos. Es importante aprender cómo implementar, probar y monitorear dicho sistema de manera de calidad. La arquitectura de microservicios no es adecuada para todas las empresas.
Arquitecto de desarrollo
Cuando se desarrolla un sistema que consta de muchos servicios, aumenta el papel del arquitecto.
. . , , . — . , , , .
— , , .
:
( ) .
— , . , , .
. , . .
( DDD) — .
, , . . , , — .
« », -.
. : , , - . , -.
:
-, , — . , . — . , — .
, «» , , . , - . . , .
, . . «-», .
— . . , ( ). ( ).
, — RPC REST. RPC — , , . REST — , ( REST-).
. - ( ATOM) . , , .
. : , — . -, .
.
— ( 1.5.3 2.0.0) . URI (, /v1/createUser/, /v2/createUser/), , HTTP, .
( 1.5.3 2.0.0), — , . , .
, . .
— . , , .
— API-, . , ( ).
— backend-for-frontend (BFF). (, ) API- .
, API-.
(, CMS CRM). . — , API.
. , , .
. — . , , . : ; .
, . — . . , (, , ).
. . :
. , (, ) . (-).
( , , ). . . .
, . , Chef, Puppet Ansible. — , . — , deb-. . , . — .
LXC- — . . Docker — , , Kubernetes.
- , , . , , -. E2e , .
- - — (), (). . — Mountebank.
(e2e) . CI, , . CDC ( ).
- . ( ).
. .
-, .
- : — . . -.
( - ) — . (, , - -). , . , . , .
.
-, , . , .
-, . , (, logstash) (, Kibana) .
( , ) -. , - .
: - .
. , .
. — , , . — , . . , .
, :
- . , - - . , — , .
- HTTP(S) Basic Auth. -, HTTPS, SSL-. -, ( Basic Auth).
- . , — , , .
- . , .
- - (HMAC). , , . ( JWT) . — , .
- API-. , , API-. , , .
. , .
. , IP- . .
. , .
«, , , »
, , , .
— , , - . , .
: , , . . , , .
— (graceful degradation).
— . , - .
— . , , , . , , - .
— , . , , ( ), . . «», , .
, .
— . . .
— . . .
— . . - , .
— , (), . . .
. , .
, -, :
, , .
HTTP . cache-control expires ETag . HTTP, , .
. , . , , - . , .
— . ( , , ) . , .
CAP
: , . .
La forma más fácil es usar DNS. Si sus capacidades no son suficientes, puede usar cosas como Zookeeper, Consul o Eureka.
Documentación
Los servicios API deben documentarse. Es altamente deseable que el código y la documentación estén conectados y que sea imposible cambiar una cosa. Por ejemplo, puede tomar Swagger o HAL.
Resumen
La arquitectura de microservicios se basa en varios principios:
- modelado en torno a conceptos comerciales;
- cultura de la automatización;
- detalles ocultos de implementación interna;
- descentralización integral;
- despliegue independiente;
- fallas aisladas;
- observación integral