Una API grande para varios microservicios versus muchas API pequeñas cada una con su propia API

7

Tengo una aplicación que se está dividiendo en varios servicios. De una pregunta anterior aquí, creo que inicialmente JSON / REST es el camino a seguir para la comunicación.

Algunos de mis microservicios deben estar disponibles públicamente para que los usen terceros.

Ahora me pregunto cuál es la mejor manera de estructurar esto. Puedo ver 2 estructuras diferentes, cada una con ventajas y desventajas.

  1. Cada servicio tiene su propio dominio y capa de servicio web, por lo que podría tener api.customers.mycompany.com , api.documents.mycompany.com , api.users.mycompany.com etc.
  2. Todos los servicios se encuentran detrás de una capa de servicios web común, por lo que tengo; api.mycompany.com/customers , api.mycompany.com/documents etc ...

La opción 1 ofrece una mejor reducción de las dependencias y la capacidad de mantenimiento, pero al costo de la necesidad de administrar muchos más dominios, y si un tercero necesita acceder a varios servicios diferentes, entonces necesitan almacenar y administrar varias direcciones URL diferentes. / p>

La Opción 2 obviamente hace que el mantenimiento y el desarrollo sean más difíciles, ya que toda la capa web debe actualizarse si se agrega un nuevo método a cualquier api, y la capa web adquiere el conocimiento de cómo organizar llamadas a cada servicio específico. Pero la opción 2 también centraliza el registro, la gestión de errores del servicio de seguridad, etc. También significa que nosotros (y nuestros terceros) solo tenemos un único dominio del que preocuparnos.

Así que mi pregunta es; para aquellos de ustedes que han recorrido este camino, ¿qué opción eligieron y se arrepintieron?

    
pregunta Matt 08.06.2016 - 15:57

1 respuesta

6

Realmente se trata de exponer sus microservicios individualmente en lugar de detrás de una envoltura. Yo diría que si sus servicios ya están listos para ser utilizados por terceros ", entonces simplemente sería sensato exponerlos.

Sin embargo, la seguridad y la cordialidad con el cliente dicen que desea un único punto de acceso que reenvíe o traduzca su API externa a las API de servicio internas.

No creo que nos haya dado suficiente información para decidir cuál es la "mejor", pero tenga en cuenta que si tiene una única API externa, puede modificar sus microservicios sin afectar la API que ve el cliente. es decir, si cambia un servicio para usar una API diferente, puede mantener la API externa sin cambios y solo modificar las llamadas que realiza.

Por lo tanto, probablemente optaría por la opción 2 y lo tendría en vivo como un proyecto separado, en su mayoría independiente de los microservicios. Internamente, omite esta capa por completo, solo para acceso externo.

    
respondido por el gbjbaanb 08.06.2016 - 16:45

Lea otras preguntas en las etiquetas