tutorial rails ejemplos descargar curso caracteristicas ruby-on-rails ruby soa

ruby-on-rails - ejemplos - ruby on rails tutorial



Recursos y ejemplos de diseño de SOA de Ruby on Rails (2)

¿Es SOA incluso el diseño correcto?

Depende. ¿No odias este tipo de respuestas? La división de su aplicación en servicios acoplados de manera flexible mediante mensajes o llamadas a la API sería, por definición, implementando SOA.

La belleza de esto es que puede intercambiar la implementación del servicio sin cambiar sus interfaces y permitir implementaciones independientes sin tener que desactivar toda la aplicación. Además, implementaría la SOA a través de controladores API especializados que están versionados y exponen el estado personalizado en lugar de su estado completo que reservaría para usuarios autenticados o sesiones basadas en roles.

El dilema, desde mi experiencia, es si implementar llamadas síncronas o asíncronas. Las llamadas síncronas son obviamente más fáciles de programar, pero pueden dejar a su usuario colgado mientras se ejecutan, y tendría que manejar los tiempos de espera para consultas de larga duración. Cuidado con las bases de datos y los tiempos de espera del servidor web.

Si implementa llamadas asíncronas, digamos que a través de ActiveMessaging o similar, tendrá que manejar las devoluciones de llamada o algún tipo de notificaciones para que su usuario tenga una burbuja. También implica la configuración de intermediarios de mensajes primarios y secundarios, y quizás algunos JavaScript o sondeos para verificar el estado. ¡Aunque todo es divertido!

¿Dónde empiezo?

Primero vería si "vale la pena": después de todo, SOA es genial, pero introduce múltiples puntos de falla que no tiene actualmente. Si cree que su aplicación dividida resultará en servicios discretos que son de alta disponibilidad y servirá para otros proyectos, comenzaría con "el libro de druby" y "orientado a servicios" como mencionó.

¿Cuáles son algunos errores comunes que puedo evitar?

Creo que la mayor preocupación serían las transacciones a través de múltiples servicios y la capacidad de revertir toda la operación si falla un servicio distante. El problema comienza si estás en alguna operación en la que llamas a A y llama a B y B, C y C fallan. ¿Quién sabe que C falló? ¿Cómo le dirás a B y A que retrocedan? ¿Pueden ellos? ¿Guardan el estado? Preguntas difíciles para el diseño frontal.

Otro problema es que la vida se complica cuando lanza un flujo de trabajo sobre su SOA: ¿quién es el encargado del proceso de negocios? ¿Centralizado o distribuido? Todo es absolutamente genial de nuevo, pero la pesadez se arrastra, ¿no? Pero eso es vida si debes mudarte a SOA.

¿En qué debería estar pensando ahora y qué puedo hacer después? (es decir, el rendimiento)

Tomaría en cuenta los servicios genéricos obvios que se pueden usar en otras aplicaciones en este momento. No excedería SOA su entorno para evitar agregar puntos de falla y mantener los que SOA presenta al mínimo.

Estoy buscando algunos recursos para tomar una aplicación monolítica Rails 3.0 existente (35K LOC) y dividirla en un diseño SOA. Cualquier libro, blog, screencasts o aplicaciones de ejemplo sería increíble.

Las principales preguntas que busco responder son:

  • ¿Es SOA incluso el diseño correcto?
  • ¿Dónde empiezo?
  • ¿Cuáles son algunos errores comunes que puedo evitar?
  • ¿En qué debería estar pensando ahora y qué puedo hacer después? (es decir, el rendimiento)

Algunos recursos que he visto, pero no estoy totalmente seguro de si son los lugares correctos para comenzar:

Este es un excelente recurso de mi amigo que es el CTO en Crowdtap. Hicieron lo mismo y realmente les ayudó a mejorar enormemente la velocidad de desarrollo del producto y les dio una mejor cobertura de prueba. Espero que ayude a https://www.youtube.com/watch?v=KsiQXAXsQDQ