Olá, Habr!
Neste artigo, começaremos a discutir como é a estrutura interna e quais tecnologias são usadas em seu desenvolvimento.
Por que acreditamos que isso é interessante? Em primeiro lugar, porque a plataforma '1C:Enterprise 8' é um grande (mais de 10 milhões de linhas de código) aplicativo em C++ (cliente, servidor etc.), JavaScript (cliente web), e, recentemente, também . Grandes projetos são interessantes simplesmente pela escala, pois questões que passam despercebidas em pequenas bases de código se tornam evidentes nesses projetos. Em segundo lugar, '1C:Enterprise' é um produto replicável, 'pronto para uso', e há muito poucos artigos sobre esses tipos de desenvolvimentos no Habrahabr. E também é sempre interessante saber como as coisas funcionam em outras equipes e empresas.
Então, vamos começar. Neste artigo, iremos revisar algumas tecnologias utilizadas na plataforma, delinear o panorama sem nos aprofundar na implementação. Afinal, para muitos mecanismos, um relato detalhado demandaria um artigo separado, e para alguns, até um livro inteiro!
Para começar, é importante definir algumas questões básicas — o que é a plataforma '1C:Enterprise' e de quais componentes ela é composta. A resposta a essa pergunta não é simples, pois o termo 'Plataforma' (para abreviar, vamos chamá-la assim) refere-se tanto a uma ferramenta de desenvolvimento de aplicativos de negócios quanto a um ambiente de execução e a ferramentas de administração. Podemos, de forma condicional, destacar os seguintes componentes:
- cluster de servidores
- um cliente 'fino' que pode se conectar ao servidor via http e seu próprio protocolo binário
- um cliente para operar em arquitetura de duas camadas com um banco de dados localizado em um disco rígido ou pasta de rede
- cliente web
- ferramentas de administração do servidor de aplicativos
- ambiente de desenvolvimento (conhecido como Configurador)
- ambiente de execução para iOS, Android e Windows Phone (plataforma móvel 1C)
Todas essas partes, exceto o cliente web, são escritas em C++. Além disso, existe um recém-anunciado , escrito em Java.
Aplicativos nativos
Para o desenvolvimento de aplicativos nativos, utiliza-se C++03. No Windows, o compilador usado é o Microsoft Visual C++ 12 (perfil compatível com Windows XP), enquanto para Linux e Android usa-se gcc 4.8, e para iOS — clang 5.0. A biblioteca padrão utilizada é única para todos os sistemas operacionais e compiladores — STLPort. Esta solução reduz a probabilidade de erros específicos da implementação do STL. Atualmente, estamos planejando a transição para a implementação do STL fornecida com o CLang, uma vez que o STLPort interrompeu seu desenvolvimento e não é compatível com o modo de suporte ao C++11 ativado no gcc.
A base de código do servidor é 99% comum, enquanto a do cliente é em torno de 95%. Além disso, até a plataforma móvel utiliza o mesmo código C++ que a ‘grande’, embora a percentagem de unificação seja um pouco menor.
Como a maioria dos usuários de C++, não pretendemos usar 100% das funcionalidades da linguagem e suas bibliotecas. Assim, quase não utilizamos Boost e, em termos de recursos da linguagem, fazemos pouco uso da conversão de tipos dinâmica. Contudo, aplicamos ativamente:
- STL (em particular, strings, contêineres e algoritmos)
- herança múltipla, incluindo herança múltipla de implementação
- templates
- exceções
- ponteiros inteligentes (implementação própria)
Graças ao uso da herança múltipla de interfaces (classes completamente abstratas), um modelo componente se torna viável, sobre o qual falaremos a seguir.
Componentes
Para garantir a modularidade, toda a funcionalidade é dividida em componentes, que são bibliotecas dinâmicas (*.dll para Windows, *.so — para Linux). Existem mais de uma centena de componentes, a seguir apresentamos descrições de alguns deles:
backend
Contém o ‘motor’ de metadados da plataforma
accnt
Objetos que desenvolvedores de aplicação usam para construir a contabilidade (planos de contas e registros contábeis)
bsl
Motor de execução da linguagem embutida
nuke
Implementação própria do alocador de memória
dbeng8
Motor de banco de dados baseado em arquivos. Uma simples máquina de banco de dados tipo servidor de arquivos, fundamentada no ISAM, incluindo um processador SQL simples
wbase
Contém classes e funções básicas para a implementação da interface do usuário do Windows — classes de janelas, acesso ao GDI, etc.
A divisão em múltiplos componentes é benéfica sob vários aspectos:
- A separação favorece um melhor design, especialmente uma melhor isolamento do código
- Com um conjunto de componentes, é possível montar diferentes variantes de entrega:
- Por exemplo, a instalação de um cliente leve incluirá wbase, mas não terá backend
- enquanto no servidor wbase, inversamente, não estará presente
- Ambas as variantes, claro, conterão nuke e bsl
Todos os componentes necessários para essa variante de execução são carregados quando o programa é iniciado. Isso é especialmente importante para o registro de classes SCOM, que será discutido a seguir.
SCOM
Para decomposição em um nível mais baixo, utiliza-se o sistema SCOM — semelhante em ideologia à biblioteca ATL. Para aqueles que não trabalharam com ATL, listarei brevemente suas principais funcionalidades e características.
Para a classe SCOM especialmente projetada:
- Fornece métodos de fábrica que permitem criar uma classe de outro componente conhecendo apenas seu nome (sem divulgar a implementação)
- Fornece infraestrutura de ponteiros inteligentes com contagem de referências. Não é necessário monitorar manualmente a vida útil da classe SCOM
- Permite verificar se um objeto implementa uma interface específica e automaticamente converter um ponteiro para o objeto em um ponteiro para a interface
- Criar um objeto-serviço, sempre disponível através do método get_service, etc.
Por exemplo, pode-se descrever na componente json.dll uma classe para leitura de JSON (por exemplo, JSONStreamReader).
Classes e instâncias podem ser criadas a partir de outros componentes que precisam ser registrados na máquina SCOM:
SCOM_CLASS_ENTRY(JSONStreamReader)
Esse macro descreverá uma classe registradora estática especial, cujo construtor será chamado ao carregar o componente na memória.
Depois disso, é possível criar sua instância em outro componente:
IJSONStreamReaderPtr jsonReader = create_instance(SCOM_CLSIDOF(JSONStreamReader));
Para suporte a serviços, o SCOM oferece uma infraestrutura adicional, bastante complexa. O conceito central é o processo SCOM, que serve como contêiner para os serviços em execução (ou seja, atua como um Localizador de Serviços), e também contém a vinculação a recursos localizáveis. O processo SCOM é vinculado ao fluxo do sistema operacional. Graças a isso, dentro do aplicativo, é possível obter serviços da seguinte maneira:
SCOM_Process* process = core::current_process();
if (process)
return get_service(process);
Além disso, ao alternar processos lógicos (SCOM) vinculados ao fluxo, é possível obter aplicativos praticamente independentes em termos de espaço informacional, funcionando dentro de um único fluxo. Assim é o nosso cliente leve, que opera com uma base de dados de arquivos — dentro de um processo do sistema operacional, existem dois processos SCOM, um ligado ao cliente e o outro ao servidor. Essa abordagem permite padronizar a escrita de código, que funcionará tanto em uma base de dados local quanto na versão 'real' cliente-servidor. O custo dessa uniformidade são os gastos operacionais, mas a prática mostra que eles valem a pena.
A lógica de negócios e a parte de interface do 1C:Enterprise são implementadas com base no modelo de componentes SCOM.
Interface do usuário
Falando em interfaces. Não utilizamos os controles padrão do Windows, nossos elementos de controle são implementados diretamente na API do Windows. Para a versão Linux, foi criada uma camada que funciona através da biblioteca wxWidgets.
A biblioteca de elementos de controle não depende de outras partes do '1C:Enterprise' e é utilizada também em várias pequenas utilidades internas.
Ao longo dos anos de desenvolvimento do 1C:Enterprise, a aparência dos controles mudou, mas a mudança significativa nos princípios ocorreu apenas uma vez, em 2009, com o lançamento da versão 8.2 e o surgimento das 'formas gerenciadas'. Além da mudança na aparência, o princípio de montagem de formulários foi fundamentalmente alterado — houve a substituição da posicionamento pixel a pixel dos elementos em favor da montagem em fluxo. Além disso, na nova modelo, os elementos de controle não trabalham diretamente com objetos de domínio, mas com DTOs especiais ().
Essas mudanças permitiram criar o cliente web do '1C:Enterprise', que replica a lógica dos controles em C++ em JavaScript. Esforçamo-nos para manter a equivalência funcional entre os clientes leve e web. Nos casos em que isso não é possível, por exemplo, devido a limitações do API disponível em JavaScript (como as possibilidades de manipulação de arquivos, que são muito limitadas), frequentemente implementamos a funcionalidade necessária por meio de extensões de navegador escritas em C++. No momento, suportamos o Internet Explorer e Microsoft Edge (Windows), Google Chrome (Windows), Firefox (Windows e Linux) e Safari (MacOS).
Além disso, a tecnologia de formulários gerenciados é usada para criar a interface de aplicativos móveis na plataforma 1C. Em dispositivos móveis, a renderização dos controles é implementada utilizando tecnologias 'nativas' do sistema operacional, mas para a lógica de layout do formulário e a resposta da interface, o mesmo código da 'grande' plataforma '1C:Enterprise' é utilizado.
Interface 1C no sistema operacional Linux
Interface 1C em dispositivo móvel
Interface 1C em outras plataformas 
Interface 1C no sistema operacional Windows
Interface 1C — cliente web
Código aberto
Embora não usemos bibliotecas padrão para desenvolvedores C++ no Windows (MFC, controles da WinAPI), não escrevemos todos os componentes nós mesmos. Já mencionamos a biblioteca , e também usamos:
- para trabalhar com HTTP e FTP.
- para trabalhar com criptografia e estabelecer conexões TLS
- para análise de XML
- para trabalhar com protocolos de e-mail (POP3, SMTP, IMAP)
- para análise de mensagens de e-mail
- para armazenar logs de atividades dos usuários
- para internacionalização
A lista pode ser continuada.
Além disso, usamos versões fortemente modificadas de e na criação de testes unitários.
As bibliotecas exigiram adaptações para compatibilidade com o modelo SCOM da organização de componentes.
A popularidade da 1C faz da plataforma uma excelente avaliação para as bibliotecas utilizadas nela. A diversidade de usuários e cenários rapidamente revela bugs mesmo nas partes de código mais raramente usadas. Nós os corrigimos internamente e tentamos devolver os patches aos autores das bibliotecas. A experiência de interação varia muito.
Desenvolvedores e responde rapidamente a pull-requests, mas o patch, por exemplo, em não conseguimos devolver.
Conclusão
Neste artigo, abordamos alguns aspectos principais do desenvolvimento da plataforma '1C:Enterprise'. Em um artigo de tamanho limitado, abordamos apenas alguns aspectos que consideramos interessantes.
Uma descrição geral dos vários mecanismos da plataforma pode ser vista .
Quais tópicos você gostaria de ver em artigos futuros?
Como a plataforma móvel 1C foi implementada?
Descrição da estrutura interna do cliente web?
Ou, talvez, você esteja interessado no processo de seleção de recursos para novas versões, desenvolvimento e testes?
Escreva nos comentários!
Fonte: habr.com
