SaaS / Multilocação abordagens para (GWT, mola, hibernação) aplicações de web com base em Java

votos
27

Atualmente, estou olhando para converter um web-app baseado em único inquilino Java que usa Spring, GWT, Hibernate, Jackrabbit, Hibernate Search / Lucene (entre outros) em um aplicativo estilo SaaS pleno direito.

Me deparei com um artigo que destaca as seguintes 7 coisas como mudanças importantes para fazer a um único aplicativo inquilino para torná-lo um aplicativo SaaS:

  1. A aplicação tem de suportar multi-tenancy.
  2. A aplicação deve ter algum nível de auto-serviço de inscrição.
  3. Deve haver um mecanismo de subscrição / faturamento no lugar.
  4. A aplicação deve ser capaz de escalar de forma eficiente.
  5. Deve haver funções no local para monitorar, configurar e gerenciar o aplicativo e inquilinos.
  6. Deve haver um mecanismo para apoiar a identificação de usuário única e autenticação.
  7. Deve haver um mecanismo para apoiar algum nível de personalização para cada inquilino.

A minha pergunta é se alguém implementado qualquer um dos acima de 7 coisas em um app / multi-tenant SaaS usando tecnologias similares aos que eu listei? Estou muito interessado em obter o máximo de entrada sobre as melhores maneiras de fazer isso antes de eu ir para o caminho que eu estou considerando atualmente.

Como um começo Tenho a certeza que eu tenho um bom controle sobre como lidar com vários inquilinos em um nível modelo. Estou pensando em adicionar um ID inquilino para todas as nossas mesas e, em seguida, usando um filtro de Hibernate (e um filtro de texto completo para Hibernate Search) para filtrar com base no conectado no ID do arrendatário do usuário para todas as consultas.

Mas eu tenho algumas preocupações em torno do desempenho, bem especialmente quando o nosso número de inquilinos cresce bastante elevado.

Todas as sugestões sobre como implementar tal solução será muito apreciado (e peço desculpa se esta pergunta é um pouco demasiado open-ended).

Publicado 28/03/2011 em 16:39
fonte usuário
Em outras línguas...                            


5 respostas

votos
13

Eu recomendaria que você arquitetar seu aplicativo para suportar todos os 4 tipos de isolamento inquilino banco de dados ou seja separado para cada inquilino, esquema separado para cada inquilino, tabela separada para cada inquilino e mesa partilhada por todos os inquilinos com um ID do arrendatário. Isto lhe dará a flexibilidade para dividir horizontalmente seu banco de dados como você crescer, ter vários bancos de dados de cada um tendo um grupo de inquilinos menores e também a capacidade de ter um banco de dados separado para algumas grandes inquilinos. Alguns de seus grandes inquilinos também poderia insistir que seus dados (banco de dados) deve residir em sua premissa, enquanto o aplicativo pode ser executado fora da nuvem.

Aqui está uma lista de verificação exaustive de características não-funcionais e nível de infra-estrutura que você pode querer considerar ao arquitetar seu aplicativo (alguns deles você pode não precisar de imediato, mas pensar em uma situação de negócios de como você vai lidar com essa necessidade se o seu competição começa oferecê-lo)

  1. personalização nível inquilino de um) temas de interface do usuário e logotipos b) as formas e grades, c) extensões do modelo de dados e campos personalizados, d) modelos de notificação, e) pegar listas e dados mestre
  2. criação nível inquilino e administração de funções e privilégios, permissões de acesso nível de campo, políticas de escopo de dados
  3. configurações de controle de acesso de nível de inquilino para módulos e funcionalidades, de modo que os módulos e recursos específicos pode ser ativado / desativado, dependendo do pacote de assinatura.
  4. Medição e monitoramento de tarefas / eventos / transações e restrição de controle de acesso, quando a quota comprada é excedido. A capacidade de meter qualquer nova entidade no futuro, se e quando as alterações do modelo de negócios.
  5. Externalizar as regras de negócio e fluxos de trabalho fora de sua base de código e representando-os como meta dados, de modo que você pode personalizá-los para cada grupo de inquilino / inquilino.
  6. construtor de consulta para a criação de relatórios personalizados que está ciente do inquilino, bem como campos personalizados adicionados por inquilinos específicos.
  7. Tenant encapsulamento e conexão nível estrutura de gerenciamento de cadeia de tal forma que seus desenvolvedores não têm que se preocupar com IDs inquilino ao escrever consultas.

Todos estes são baseados em nossa experiência na construção de uma estrutura multi-tenant de propósito geral que pode ser usado para qualquer domínio ou aplicação. Infelizmente, você não pode usar o nosso quadro, uma vez que é baseado em .NET

Mas as necessidades de engenharia de qualquer produto SaaS multi-tenant (novos ou migraram) são os mesmos, independentemente da tecnologia de pilha que você usa.

Respondeu 19/04/2011 em 11:26
fonte usuário

votos
4

Todas as tecnologias que você listou são bastante comuns e razoável para ambas as aplicações single e multi-tenant. Eu diria que suportam os 7 "coisas" para SaaS é muito mais de uma função de como você usa as tecnologias do que o que. Parece que você já tem um aplicativo de inquilino única que funciona. Então, provavelmente não há muita razão para desviar as seleções de tecnologia lá, a menos que algo não está funcionando muito bem já. Sua pergunta é outra forma bastante aberto, porém, por isso é difícil de ser muito mais específico lá.

Eu tenho algum feedback sobre a divisão do banco de dados (e talvez outras coisas) por ID inquilino embora. Se você sabe que você pode, eventualmente, ter um monte de inquilinos (dizem muitos milhares ou mais, particularmente se eles são pequenos), então o que você sugere é talvez melhor. Se, contudo, você terá um menor número de inquilinos (particularmente se eles são grandes) que você pode querer considerar um banco de dados por inquilino, de modo que cada um tem o seu próprio espaço de tabela. Por isso quero dizer uma instalação de banco de dados único com várias instâncias do mesmo esquema dentro dela, um por inquilino.

Existem algumas razões para isso pode ser uma vantagem. Um deles é o desempenho como você mencionou. Adicionando um ID inquilino para cada mesa única é sobrecarga no acesso ao disco, tempo de consulta e aumenta a complexidade do código. Cada índice no banco de dados será necessário incluir o ID do arrendatário também. Você corre um risco adicional de mistura de dados entre os inquilinos, se você não for cuidadoso (embora um filtro Hibernate iria ajudar a mitigar isso). Com um banco de dados por inquilino você pode restringir o acesso apenas a correta. Portando sua aplicação atual provavelmente será muito mais fácil também, você basicamente só precisa interceptar o seu pedido em algum lugar cedo para decidir o inquilino com base na URL e aponte para o banco de dados certo. Backups também são fáceis de fazer por inquilino, particularmente útil se você nunca pretende que lhes permite o download de uma cópia de segurança.

Por outro lado, há razões para não fazer isso. Você vai ter um monte de esquemas de banco de dados para lidar com e eles terão que ser atualizados de forma independente (que pode realmente ser uma vantagem se você quiser evitar tomar todos os inquilinos para baixo por uma alteração de esquema, você pode rolá-los fora de forma incremental). Ele permite que você tem casos especiais que poderiam desviar-se tratar a plataforma como um verdadeiro implantação SaaS multi-tenant que é atualizado todos de uma vez, resultando em gerenciamento de múltiplas versões em produção. Finalmente eu ouvi há um ponto de ruptura com apenas sobre cada fornecedor de banco de dados lá fora, o número de instâncias de esquema que vai apoiar em uma instalação (supostamente alguns podem ir a centenas de milhares embora).

Ela realmente depende de seu caso de uso é claro. Você mencionou um único inquilino que me leva a acreditar que você não tem muitos inquilinos agora, no entanto você mencionar crescente para muitos inquilinos. Eu não tenho certeza se você significar centenas ou milhões, mas de qualquer forma eu espero que isso ajude alguns com suas considerações. Melhor da sorte!

Respondeu 30/03/2011 em 04:57
fonte usuário

votos
0

O que você descreve é ​​um serviço plena aplicação estilo Saas servindo vários inquilinos. Existem algumas coisas que você tem que decidir como quão crítico é o isolamento de dados? Se você está construindo para um domínio médica ou financeira, o isolamento de dados é um fator crítico.

Bem, eu não posso ajudar a responder a todos os seus pontos, mas gostaria de sugerir a olhar para abordagem de banco de dados-per-tenant para a sua aplicação, pois proporciona o mais alto nível de isolamento de dados.

Desde que você está usando o Java, Spring, Hibernate pilha, eu posso ajudá-lo com um pequeno exemplo de aplicação que eu escrevi. É um exemplo de trabalho que você pode executar rapidamente em seu laptop local. Eu compartilhei isso aqui . Não dar uma olhada e deixe-me saber se ele responde a algumas das suas perguntas.

Respondeu 12/04/2018 em 18:51
fonte usuário

votos
0

Para (1): Hibernate apoiar configurações multi-tenant fora da caixa a partir da versão 4. No momento da escrita suportados são DB-per-tenant e esquema-per-tenant e mantendo todos os inquilinos em uma mesma DB usando discriminador ainda não é suportado. Temos usado essa funcionalidade com sucesso em nossa aplicação (abordagem DB-per-cliente).

Para (3): Depois de algumas investigações feito decidimos ir com Braintree para implementar faturamento. Outra soluções muitas pessoas recomendam: Authorize.net, Stripe, PayPal.

Para (4): configuração em cluster Temos usado com Hibernate / Primavera e JBoss Cache para 2 cache nível. Ao nos dias de hoje isso se tornou "comum" e que usam serviços de PaaS como Jelastic você ainda pode obtê-lo pré-configurados para fora da caixa.

Respondeu 16/04/2012 em 18:26
fonte usuário

votos
0

Não há uma resposta simples. Eu posso descrever a minha própria solução. Pode servir como uma inspiração para os outros.

  • inquilino por banco de dados (postgres)
  • um banco de dados compartilhado entre o inquilinos
  • Spring + MyBatis
  • autenticação Spring Security

Detalhes aqui: http://blog.trixi.cz/2012/01/multitenancy-using-spring-and-postgresql/

Respondeu 29/01/2012 em 18:55
fonte usuário

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more