web-services service scalability soa high-availability

web services - Práctica SOA para un novato



web-services scalability (7)

Vale la pena ver: http://www.manning.com/davis/ ?

Soy un novato total en el mundo de SOA. Como tal, estoy buscando algunos "frameworks / tecnologías SOA" y tratando de entender cómo utilizarlos para construir un sitio web altamente escalable (clase de Facebook).

Hay varios "dolores" que trato de resolver aquí:

  1. Composabilidad (+ administración de dependencias, Pub / Sub)
  2. Idioma-independencia de los servicios
  3. Escalabilidad y rendimiento
  4. Alta disponibilidad

Estudié algunas tecnologías que responden a un subconjunto de los criterios anteriores:

  1. Thrift : la plataforma RPC multiplataforma de Facebook
  2. WCF : admite SOAP, JSON y REST, por lo que se puede considerar interoperable por idioma. Genera archivos WSDL que se pueden usar para generar proxies Java.
  3. Microsoft DSS : simplemente lo incluí en mi encuesta, pero no parece relevante, ya que está muy orientado al estado y específico de .NET.
  4. Servicios web

Ahora, entiendo cómo puedo sacar algunos de los aspectos de compibilidad e independencia del lenguaje de lo anterior. Pero, no he encontrado mucha información concreta (no zumbido) sobre cómo usar las herramientas anteriores / otras para escalabilidad y alta disponibilidad. Así que finalmente llegué a mi pregunta:

¿Cómo se pueden aprovechar las tecnologías SOA para resolver los problemas que he definido anteriormente? ¿Dónde puedo encontrar guías técnicas para eso? Estoy buscando algo más que diagramas de sistemas, sino bibliotecas reales, ejemplos de códigos, APIS ...

Creo que la pregunta tiene más que ver con los conceptos involucrados que con las herramientas. Respuestas a los artículos:

  1. Comprender e internalizar el contexto delimitado . Mantener separadas las piezas no relacionadas es importante para obtener una reutilización real en diferentes servicios. Las tecnologías relacionadas no lo ayudarán en esto, es usted quien separa la aplicación en contextos apropiados, que puede reutilizar adecuadamente para diferentes servicios.
  2. Un punto final claro para la comunicación basada en protocolos conocidos permite implementar diferentes piezas con diferentes tecnologías
  3. Hacer que las operaciones fluyan como acciones independientes basadas en diferentes protocolos, le brinda muchos lugares donde puede agregar niveles. Es un subproceso particular del proceso general que usa muchos recursos y el servidor no puede soportarlo más, simplemente muévase a un servidor por separado. La carga siguió creciendo, y ese servidor no lo está tomando más, agrega un servidor adicional y un balance de carga. También tiene más oportunidad de usar el almacenamiento en caché y la agrupación de conexiones.
  4. Tenga un subproceso crítico que necesite estar disponible todo el tiempo, agregue un servidor para que pueda fallar. Tenga un proceso general que debe estar "disponible" todo el tiempo, use las colas para las piezas que puedan procesarse más adelante.

¿Realmente necesitas soportar ese tipo de carga? Establezca objetivos de rendimiento / carga / interoperabilidad apropiados que se relacionen con el escenario específico. Si realmente necesita soportar ese tipo de carga, le recomiendo que contrate a alguien que la haya solucionado.

Si es algo para una carga que eventualmente podría ser, identifique los contextos delimitados y diseñe la interacción entre aquellos con una mentalidad SOA. Mantener el código limpio es todo lo que tiene que hacer para el resto, use TDD, acoplamiento flexible, pruebas de integración enfocadas, etc. en su base de códigos. Con un buen código, si luego necesita separar piezas del sistema, será mucho más fácil.

Puedo recomendar el libro: Enterprise Service Oriented Architectures, publicado por Springer Verlag.

Vea el proyecto Mule que agrupa la pila de servicios CXF y también el paquete Mule REST que proporciona alternativas RESTful. Creo que verá que soluciona todos sus problemas y hay muchos ejemplos en la documentación, así como en la distribución.

Todos los consejos aquí son buenos y buenos, pero no te preocupes hasta que realmente lo necesites.

Enfóquese en crear una aplicación útil y funcional que le guste a la gente. Cuando comiences a tener problemas, comienza a manejar los cuellos de botella.

Nunca podrás prever de qué manera fallará una aplicación, así que ¿cómo puedes saber si [[insertar técnico aquí]] es tu respuesta?