Infelizmente, este termo não tem um bom análogo no idioma russo. A Wikipédia dá "multilocação, locação múltipla." Isso às vezes é chamado de “propriedade múltipla”. Esses termos podem ser um tanto confusos, uma vez que o assunto não está inerentemente associado ao aluguel ou à propriedade. Esta é uma questão de arquitetura de software e organização de seu funcionamento. E este último não é menos importante.
Começamos a formular nossa compreensão de multilocação ao mesmo tempo em que começamos a projetar uma abordagem para o modelo de nuvem (serviço) de trabalho 1C:Enterprise. Isto foi há vários anos. E desde então nossa compreensão tem se expandido continuamente. Estamos constantemente descobrindo cada vez mais novos aspectos deste assunto (prós, contras, dificuldades, características, etc.).
Às vezes, os desenvolvedores entendem a multilocação como um assunto muito simples: “para que os dados de várias organizações sejam armazenados em um banco de dados, você precisa adicionar uma coluna com o identificador da organização a todas as tabelas e definir um filtro para ela”. É claro que também iniciamos nosso estudo do assunto a partir deste momento. Mas eles rapidamente perceberam que esta era apenas uma clareira (também, aliás, nada fácil). Em geral, este é um “país inteiro”.
A ideia básica de multilocação pode ser descrita mais ou menos assim. Uma aplicação típica é uma casa de campo concebida para acolher uma família, que utiliza as suas infra-estruturas (paredes, telhado, abastecimento de água, aquecimento, etc.). Um aplicativo de multilocação é um prédio de apartamentos. Nele, cada família utiliza a mesma infraestrutura, mas a própria infraestrutura é implementada para toda a casa.
A abordagem de multilocação é boa ou ruim? Você pode encontrar opiniões muito diferentes sobre isso. Parece não haver “bom ou mau” de forma alguma. Você precisa comparar os prós e os contras no contexto das tarefas específicas que estão sendo resolvidas. Mas este é um assunto à parte...
No seu sentido mais simples, o objetivo da multilocação é reduzir o custo de manutenção de uma aplicação através da “socialização” dos custos de infraestrutura. Este é o mesmo movimento que reduzir o custo de uma aplicação usando uma solução de produção (possivelmente com customização e modificação), em vez de escrevê-la “sob encomenda”. Apenas num caso o desenvolvimento é socializado e, no outro, a exploração.
Além disso, repetimos, não existe qualquer ligação direta com o método de venda. A arquitetura multitenancy também pode ser usada em uma infraestrutura de TI corporativa ou departamental para automatizar um grande número de filiais e empresas holding semelhantes.
Podemos dizer que a multilocação não é apenas uma questão de organizar o armazenamento de dados. Este é um modelo de como a aplicação funciona como um todo (incluindo uma parte significativa da sua arquitetura, do seu modelo de implantação e da sua organização de manutenção).
O mais difícil e interessante do modelo de multilocação, parece-nos, é que a essência da aplicação “se bifurca”. Parte da funcionalidade funciona com dados específicos de áreas (apartamentos) e “não está interessada” no facto de existirem residentes noutros apartamentos. E alguns percebem a casa como um todo e trabalham para todos os moradores ao mesmo tempo. Ao mesmo tempo, estes últimos não podem ignorar o facto de se tratarem, afinal, de apartamentos separados, sendo necessário garantir o nível necessário de granularidade e segurança.
Em 1C:Enterprise, o modelo multitenancy é implementado no nível de diversas tecnologias. Estes são os mecanismos da plataforma 1C:Enterprise, os mecanismos de"E"", mecanismos (bibliotecas de subsistemas padrão).
Cada um desses itens contribui para a construção da infraestrutura geral de um prédio de apartamentos. Por que isso é implementado em diversas tecnologias, e não em uma, por exemplo, em uma plataforma? Em primeiro lugar, porque alguns dos mecanismos, em nossa opinião, são bastante apropriados para serem modificados para uma opção de implantação específica. Mas, em geral, esta é uma questão difícil e somos constantemente confrontados com uma escolha - em que nível é melhor implementar este ou aquele aspecto da multilocação.
Obviamente, a parte básica dos mecanismos precisava ser implementada na plataforma. Bem, por exemplo, a própria separação de dados. É aqui que as pessoas geralmente começam a falar sobre multilocação. Mas no final, o modelo multitenancy “viajou” através de uma parte significativa dos mecanismos da plataforma e exigiu o seu refinamento e, em alguns casos, repensar.
No nível da plataforma, implementamos exatamente os mecanismos básicos. Eles permitem que você crie aplicativos que são executados em um modelo de multilocação. Mas para que os aplicativos “vivam e funcionem” nesse modelo, é necessário ter um sistema para gerenciar suas “atividades de vida”. As tecnologias 1cFresh e uma camada de lógica de negócios unificada no nível BSP são responsáveis por isso. Assim como em um prédio de apartamentos a infraestrutura fornece aos moradores tudo o que precisam, as tecnologias 1cFresh fornecem tudo o que precisam para aplicações executadas em um modelo multitenancy. E para que as aplicações possam interagir com esta infraestrutura (sem modificações significativas), nelas são colocados os “conectores” correspondentes na forma de subsistemas BSP.
Do ponto de vista dos mecanismos da plataforma, é fácil perceber que à medida que ganhamos experiência e desenvolvemos o caso de uso da nuvem “1C:Enterprise”, estamos ampliando a composição dos mecanismos que estão envolvidos nesta arquitetura. Vamos dar um exemplo. No modelo de multilocação, as funções dos participantes do serviço de aplicação mudam significativamente. O papel (nível de responsabilidade) dos responsáveis pela operação das aplicações aumenta significativamente. Tornou-se necessário que eles tivessem ferramentas de controle de aplicativos mais poderosas. Porque os utilizadores da aplicação (residentes) confiam antes de mais nada no fornecedor com quem trabalham. Para isso, implementamos um novo . Esse mecanismo permite que os administradores do provedor limitem a liberdade dos desenvolvedores de aplicativos ao nível de segurança exigido - em essência, isolem a operação do aplicativo para cada locatário dentro de uma determinada sandbox.
Não menos interessante é a arquitetura de gerenciamento de aplicações operando em modo multitenancy (o que é implementado nas tecnologias 1cFresh e BSP). Aqui, em comparação com o modelo de implantação convencional, os requisitos para automação dos processos de gestão aumentam significativamente. São dezenas desses processos: criação de novas áreas de dados (“apartamentos”), atualização de aplicativos, atualização de informações regulatórias, backups, etc. Por exemplo, para garantir uma interação confiável entre aplicações e componentes do sistema de controle, implementamos tecnologia de sistema de chamada assíncrona com entrega garantida.
Um ponto muito sutil é a forma de socialização de dados e processos. Parece simples (se é que parece para alguém) apenas à primeira vista. O maior desafio é o equilíbrio entre a centralização de dados e processos e a descentralização. Por um lado, a centralização permite reduzir custos (espaço em disco, recursos do processador, esforços do administrador...). Por outro lado, limita a liberdade dos “inquilinos”. Esse é exatamente um dos momentos de “bifurcação” da aplicação, quando o desenvolvedor precisa pensar simultaneamente na aplicação no sentido estrito (servindo um “apartamento”) e no sentido amplo (servindo todos os “inquilinos” ao mesmo tempo) .
Como exemplo desse “dilema”, pode-se citar informações regulatórias e de referência. Claro que existe uma grande tentação de torná-lo comum a todos os “inquilinos” da casa. Isso permite armazená-lo em uma cópia e atualizá-lo para todos de uma vez. Mas acontece que alguns moradores precisam de mudanças específicas. Curiosamente, na prática isso ocorre, mesmo para informações especificadas pelos reguladores (órgãos governamentais). Esta acaba por ser uma questão difícil: socializar ou não socializar? É tentador, claro, tornar a informação geral para todos e privada para quem a deseja. E isso já leva a uma implementação muito difícil. Mas estamos trabalhando nisso...
Outro exemplo é o desenho da implementação de processos regulares (executados dentro de um cronograma, iniciados pelo sistema de controle, etc.). Por um lado, podem ser implementados para cada área de dados separadamente. É mais fácil e conveniente. Mas, por outro lado, essa granularidade fina cria uma grande carga no sistema. Para reduzir a carga, é necessário implementar processos socializados. Mas eles exigem um estudo mais cuidadoso.
Claro, isso levanta uma questão muito significativa. Como os desenvolvedores de aplicativos podem garantir a multilocação? O que eles precisam fazer para isso? É claro que nos esforçamos para garantir que o fardo das questões tecnológicas e de infraestrutura recaia, tanto quanto possível, sobre os ombros da tecnologia fornecida, e o desenvolvedor do aplicativo pensa apenas em termos de tarefas de lógica de negócios. Mas, como acontece com outras questões arquiteturais importantes, os desenvolvedores de aplicativos precisam ter algum conhecimento de como trabalhar no modelo de multilocação e algum esforço será necessário ao desenvolver aplicativos. Por que? Porque há pontos que a tecnologia não consegue fornecer automaticamente sem levar em conta a semântica dos dados. Por exemplo, a mesma definição dos limites da socialização da informação. Mas tentamos manter essas dificuldades pequenas. Já existem exemplos de implementação de tais aplicações.
Um ponto importante no contexto da implementação de multitenancy em 1C:Enterprise é que estamos criando um modelo híbrido no qual um aplicativo pode operar tanto no modo multitenancy quanto no modo normal. Esta é uma tarefa muito difícil e objeto de uma discussão separada.
Fonte: habr.com