En términos de arquitectura y diseño de software, ¿cómo se "apilan" los microservicios (juego de palabras) contra el middleware? Vengo de Java, y parece que cuando te alejas de REST directo como API y abstraes diferentes capas y parámetros de conexión, al menos en Java, casi has cerrado el círculo de vuelta a algunas ideas de la vieja escuela. . Hemos vuelto a la virtualización ... donde la JVM ya es virtual.
De una manera agnóstica, usted puede, y yo diría, las ventajas de abstraer una API RESTful a CORBA. O, de una manera más centrada en Java, JMS o MDB.
Hubo un tiempo en que EJB era un gran problema en Java, luego se reconoció un poco como un clúster, pero, ahora, ¿volvemos al principio?
¿O los microservicios ofrecen algo que CORBA, o incluso mejor, MDB, carece? Cuando leo (TLDR) Martin Fowler explicando microservicios, me parece una buena solución a un mal problema, por así decirlo. O más bien, un enfoque de mente cerrada que introduce un nivel de complejidad que solo empuja el problema. Si los servicios son verdaderamente micro y numerosos, cada uno tiene un costo en dólares para ejecutarlo y mantenerlo.
Además, si un micro servicio entre muchos cambia su API, entonces todo lo que depende de ese servicio se rompe. No parece estar débilmente acoplado, parece lo contrario de ágil. ¿O estoy haciendo mal uso de esas palabras?
Por supuesto, hay una cantidad indeterminada de opciones entre estos extremos.
Tiburón contra Gorila ... ¡vete! (Para los pedantes, eso debe ser irónico, y no es mi intención en absoluto. La pregunta debe tomarse al pie de la letra. Si la pregunta puede mejorarse, hágalo o comente y lo solucionaré. )
Imagine una multitud de microservicios que se ejecutan en la ventana acoplable, todos en una máquina, hablando entre ellos ... locura. Difícil de mantener o administrar, y casi imposible cambiar algo porque cualquier cambio se producirá en cascada y causará errores imprevisibles. ¿Cómo es de alguna manera mejor que estos servicios estén dispersos en diferentes máquinas? Y, si se distribuyen, entonces seguramente algunas técnicas muy, muy antiguas de la escuela han resuelto, al menos hasta cierto punto, la informática distribuida.
¿Por qué la escala horizontal es tan frecuente, o al menos deseable?
giant blob, ya que tiene que tener interfaces, por lo que cada parte que comienza desde el núcleo es una especie de MS, y lo primero es antes cualquier equipo comenzó a escribir código para acordar las especificaciones v0.0.1.Respuestas:
TL; DR. He tenido el placer de beber una gran cantidad de Kool-Aid con sabor a Microserver, por lo que puedo hablar un poco sobre las razones detrás de ellos.
Pros:
Contras:
Creo que fundamentalmente no entiendes cómo se supone que funciona una arquitectura de microservicio. La forma en que se supone que se ejecuta es que cada microservicio (denominado en adelante MS) tiene una API rígida en la que todos sus clientes están de acuerdo. El MS puede realizar los cambios que desee siempre que se conserve la API. La MS se puede descartar y reescribir desde cero, siempre que se conserve la API.
Para ayudar en el acoplamiento suelto, cada MS depende de la versión n-1 de sus dependencias. Esto permite que la versión actual del servicio sea menos estable y un poco más arriesgada. También permite que las versiones salgan en oleadas. Primero se actualiza 1 servidor, luego la mitad y finalmente el resto. Si la versión actual alguna vez desarrolla problemas serios, la MS puede revertirse a una versión anterior sin pérdida de funcionalidad en otras capas.
Si la API necesita ser cambiada, debe cambiarse de una manera que sea compatible con versiones anteriores.
fuente
Todas las técnicas de desarrollo de software que hemos inventado han sido sobre la gestión de la complejidad de alguna manera. Una gran parte de ellos ha sido y sigue siendo sobre abstracción, encapsulación y acoplamiento flexible. Los microservicios son otra forma de hacer esas cosas, por lo que probablemente se parece a muchas técnicas antiguas de alto nivel teórico, pero eso no lo hace menos útil o relevante.
Con respecto al acoplamiento flojo, creo que has entendido mal el objetivo un poco. Si la tarea A necesita llamar a la tarea B, nunca habrá forma de hacer que A y B estén 100% desacopladas. Nunca va a pasar. Lo que puede hacer es asegurarse de que, si la tarea B llama a la tarea C, la tarea C nunca debería tener que preocuparse por los cambios a A. Si estas tres tareas están unidas en una gran burbuja, pasando estructuras entre sí, entonces hay un posibilidad significativa de que todos tengan que cambiar si alguno de ellos lo hace. Pero si los tres son microservicios, entonces básicamente está garantizado que un cambio en A solo obligará a B a actualizarse (a menos que sea un cambio tan grande en la funcionalidad central de A que probablemente debería haberlo convertido en un servicio completamente nuevo). Esto es especialmente cierto si todas las actualizaciones de microservicios se realizan de forma compatible con versiones anteriores, como deberían ser.
Con respecto al comentario ágil, puedo decirle por experiencia personal que nuestro código de microservicio funciona mucho mejor con el código ágil que nuestro código "vinculado a un gran blob". En el último, cada vez que alguien corrige un error en una función de bajo nivel, literalmente tiene que enviar un correo electrónico a todo el departamento de I + D diciendo "por favor vuelva a vincular sus tareas o todos se estrellarán el viernes". Recibimos un par de estos cada semana . Si su código estuviera en un microservicio, todos nos beneficiaríamos automáticamente de la solución tan pronto como implementara una nueva versión.
No entiendo completamente el comentario sobre COBRA y MDB, ya que no parecen ser arquitecturas de software sino componentes de una; Según tengo entendido, son formas potenciales de definir los protocolos de mensajería de sus microservicios y / o implementar dichos microservicios, no en sí mismas alternativas a los microservicios.
fuente
Por la nube.
¿Ya te has reído? Sin embargo, en serio: para muchas empresas, el mayor costo del software ya no es el software. Es el ancho de banda, el hardware, los costos de CDN, etc. Ahora que todos tienen un dispositivo móvil, hay mucho más tráfico. Y eso solo empeorará a medida que su tostadora tenga su propia conectividad a Internet.
Por lo tanto, las empresas buscan administrar esos costos. Específicamente, están tratando de manejar el problema comercial de "si esto explota, ¿cómo puedo servir a millones de personas que obtienen / usan mi software, sin pagar por adelantado por los servidores que sirven a millones de personas que obtienen / usan mi software? ? ".
Porque responde a este problema comercial (enorme y creciente).
Cuando tiene una docena de usuarios, puede lanzar todos los servicios en una caja. Esto es bueno, ya que solo quieres pagar por una caja. Y tampoco desea pagar por los cambios en la aplicación para dividir los diversos servicios cuando su empresa escala. En estos días, no tiene tiempo para hacerlo antes de que la multitud de clientes encienda sus servidores de todos modos.
También es bueno porque le permite hacer malabares con las asignaciones de servidores para que pueda:
Tener implementaciones muy granulares hace que esas dos cosas sean más fáciles / mejores (además de ayudar a forzar una mejor separación de las preocupaciones).
fuente