tenant - Enfoques de SaaS/Multi-Tenancy para aplicaciones web basadas en Java(GWT, Spring, Hibernate)

multi tenant java (5)

Actualmente estoy buscando convertir una aplicación web basada en Java de un solo inquilino que use Spring, GWT, Hibernate, Jackrabbit, Hibernate Search / Lucene (entre otros) en una aplicación de estilo SaaS completamente desarrollada.

Me topé con un artículo que destaca las siguientes 7 "cosas" como cambios importantes que se deben realizar en una sola aplicación de inquilino para convertirla en una aplicación de SaaS:

La aplicación debe soportar multi-tenancy.
La aplicación debe tener algún nivel de inscripción de autoservicio.
Debe haber un mecanismo de suscripción / facturación establecido.
La aplicación debe ser capaz de escalar de manera eficiente.
Debe haber funciones implementadas para monitorear, configurar y administrar la aplicación y los inquilinos.
Debe existir un mecanismo para admitir la identificación y autenticación únicas de los usuarios.
Debe haber un mecanismo establecido para admitir cierto nivel de personalización para cada inquilino.

Mi pregunta es: ¿alguien ha implementado alguna de las 7 cosas anteriores en una aplicación SaaS / multiusuario usando tecnologías similares a las que he enumerado? Estoy dispuesto a obtener la mayor cantidad de información sobre las mejores maneras de hacerlo antes de seguir el camino que actualmente estoy considerando.

Para empezar, estoy bastante seguro de tener un buen control sobre cómo manejar varios inquilinos a nivel de modelo. Estoy pensando en agregar una identificación de inquilino a todas nuestras tablas y luego usar un filtro de hibernación (y un filtro de texto completo para la búsqueda de hibernación) para filtrar en base a la identificación de inquilino del usuario registrado para todas las consultas.

Sin embargo, también tengo algunas preocupaciones sobre el rendimiento, especialmente cuando nuestro número de inquilinos crece bastante.

Cualquier sugerencia sobre cómo implementar tal solución será muy apreciada (y pido disculpas si esta pregunta es un poco demasiado abierta).

Le recomendaría que diseñe su aplicación para admitir los 4 tipos de aislamiento de inquilino, es decir, una base de datos independiente para cada inquilino, un esquema separado para cada inquilino, una tabla separada para cada inquilino y una tabla compartida para todos los inquilinos con un ID de inquilino. Esto le dará la flexibilidad de particionar horizontalmente su base de datos a medida que crece, ya que tendrá múltiples bases de datos, cada una con un grupo de arrendatarios más pequeños, y también la capacidad de tener una base de datos separada para algunos arrendatarios grandes. Algunos de sus grandes inquilinos también podrían insistir en que sus datos (base de datos) deben residir en sus instalaciones, mientras que la aplicación puede ejecutarse desde la nube.

Aquí hay una lista de verificación exhaustiva de las características no funcionales y de nivel de infraestructura que puede considerar al diseñar su aplicación (algunas de ellas no las necesita de inmediato, pero piense en una situación empresarial de cómo manejará esa necesidad si su la competencia empieza a ofrecerlo)

personalización a nivel de arrendatario de a) temas y logotipos de la interfaz de usuario b) formularios y cuadrículas, c) extensiones de modelo de datos y campos personalizados, d) plantillas de notificación, e) listas de captura y datos maestros
creación y administración de roles y privilegios a nivel de inquilino, permisos de acceso a nivel de campo, políticas de alcance de datos
configuración de control de acceso de nivel de inquilino para módulos y funciones, de modo que módulos y funciones específicos podrían habilitarse / deshabilitarse según el paquete de suscripción.
Medición y supervisión de tareas / eventos / transacciones y restricción del control de acceso una vez que se excede la cuota adquirida. La capacidad de medir cualquier entidad nueva en el futuro si y cuando cambie su modelo de negocio.
Externalización de las reglas de negocios y flujos de trabajo fuera de su base de código y representándolos como metadatos, para que pueda personalizarlos para cada grupo de inquilinos / inquilino.
El generador de consultas para crear informes personalizados que conozcan al arrendatario y los campos personalizados agregados por arrendatarios específicos.
La encapsulación de inquilinos y la gestión de cadenas de conexión a nivel de marco de modo que sus desarrolladores no tengan que preocuparse por las ID de inquilinos al escribir consultas.

Todo esto se basa en nuestra experiencia en la construcción de un marco multiusuario de propósito general que se puede utilizar para cualquier dominio o aplicación. Desafortunadamente, no puede utilizar nuestro marco ya que está basado en .NET

Pero las necesidades de ingeniería de cualquier producto SaaS multiusuario (nuevo o migrado) son las mismas independientemente de la pila de tecnología que utilice.

Lo que describe es una aplicación de estilo Saas de servicio completo que atiende a múltiples inquilinos. Hay algunas cosas que debe decidir, ¿qué tan crítico es el aislamiento de los datos? Si está construyendo para un dominio médico o financiero, el aislamiento de datos es un factor crítico.

Bueno, no puedo dejar de responder a todos sus puntos, pero sugeriría considerar el enfoque de base de datos por inquilino para su aplicación, ya que proporciona el nivel más alto de aislamiento de datos.

Ya que estás usando la pila de Java, Spring, Hibernate, puedo ayudarte con una pequeña aplicación de ejemplo que escribí. Es un ejemplo práctico que puede ejecutar rápidamente en su computadora portátil local. Lo he compartido here . Eche un vistazo y déjeme saber si responde algunas de sus preguntas.

No hay una respuesta simple. Puedo describir mi propia solución. Puede servir de inspiración para los demás.

inquilino por base de datos (postgres)
Una base de datos adicional compartida entre los inquilinos.
Primavera + MyBatis
Autenticación de seguridad de primavera

Detalles aquí: http://blog.trixi.cz/2012/01/multitenancy-using-spring-and-postgresql/

Para (1): Hibernate es compatible con configuraciones de múltiples inquilinos desde el inicio de la versión 4. En el momento de la publicación, se admiten DB-per-tenant y schema-per-tenant, y mantener a todos los inquilinos en una misma DB utilizando discriminator aún no está soportado. Hemos utilizado esta funcionalidad con éxito en nuestra aplicación (enfoque DB por cliente).

Para (3): Después de realizar una investigación, decidimos ir con Braintree para implementar la facturación. Otras soluciones que muchas personas recomiendan: Authorize.net, Stripe, PayPal.

Para (4): hemos utilizado la configuración en clúster con Hibernate / Spring y JBoss Cache para el almacenamiento en caché de segundo nivel. En estos días esto se convirtió en "común" y al utilizar servicios de PaaS como Jelastic, incluso puede configurarlo de manera predeterminada.

Todas las tecnologías que se enumeran son bastante comunes y razonables para aplicaciones de un solo inquilino y de varios inquilinos. Yo diría que apoyar las 7 "cosas" para SaaS es mucho más una función de cómo se usan las tecnologías que cuáles. Parece que ya tienes una aplicación de un solo inquilino que funciona. Así que probablemente no haya muchas razones para desviarse de las selecciones de tecnología allí a menos que algo no esté funcionando bien. Sin embargo, su pregunta es bastante abierta, por lo que es difícil ser mucho más específico allí.

Sin embargo, tengo algunos comentarios sobre cómo dividir la base de datos (y quizás otras cosas) por la identificación del inquilino. Si sabe que con el tiempo puede tener muchos inquilinos (digamos muchos miles o más, especialmente si son pequeños), entonces lo que sugiere es quizás lo mejor. Sin embargo, si tiene un número menor de inquilinos (especialmente si son grandes) es posible que desee considerar una base de datos por inquilino, de modo que cada uno tenga su propio espacio de tabla. Me refiero a una instalación de base de datos única con varias instancias del mismo esquema dentro de ella, una por inquilino.

Hay algunas razones por las que esto puede ser una ventaja. Uno es el rendimiento como mencionaste. Agregar una ID de inquilino a cada tabla es una sobrecarga en el acceso al disco, el tiempo de consulta y aumenta la complejidad del código. Cada índice en la base de datos deberá incluir también la identificación del inquilino. Corre un riesgo adicional de mezclar datos entre inquilinos si no tiene cuidado (aunque un filtro de Hibernación ayudaría a mitigar eso). Con una base de datos por inquilino, podría restringir el acceso solo a la correcta. Portar su aplicación actual probablemente también será mucho más fácil, básicamente, solo necesita interceptar su solicitud en algún momento temprano para decidir el inquilino según la URL y apuntar a la base de datos correcta. Las copias de seguridad también son fáciles de hacer por inquilino, particularmente útil si alguna vez tiene la intención de permitirles descargar una copia de seguridad.

Por otro lado hay razones para no hacer esto. Tendrá que lidiar con una gran cantidad de esquemas de base de datos y tendrán que actualizarse de forma independiente (lo que en realidad puede ser una ventaja si desea evitar que todos los inquilinos se apaguen para un cambio de esquema, puede extenderlos de manera incremental). Le permite tener casos especiales que podrían desviarse de considerar la plataforma como una verdadera implementación de SaaS multiusuario que se actualiza de una sola vez, lo que da como resultado la administración de varias versiones en producción. Finalmente, he escuchado que hay un punto de ruptura con casi todos los proveedores de bases de datos en el número de instancias de esquema que admitirán en una instalación (aunque supuestamente algunos pueden llegar a cientos de miles).

Realmente depende de su caso de uso, por supuesto. Mencionó a un único inquilino, lo que me lleva a creer que no tiene demasiados inquilinos en este momento, sin embargo, mencionó el crecimiento de muchos inquilinos. No estoy seguro de si te refieres a cientos o millones, pero de cualquier manera espero que esto ayude a algunos con tus consideraciones. ¡La mejor de las suertes!