O objetivo é criar uma nova inicialização altamente carregada em condições modernas. Consideraremos a criação da arquitetura usando o exemplo do
Billingolang , um projeto de cobrança universal para fins gerais, escrito em golang. O projeto inclui acesso via API, site, integração em sistemas contábeis, relatórios e gráficos.
Os sistemas de rosca única foram inicialmente descartados. Eu tive que escolher entre Erlang, Golang e Rust. Golang foi escolhido como a principal linguagem de programação, porque é difícil encontrar programadores Erlang, embora a estabilidade e a troca a quente do código tenham sido uma vantagem para Erlang. A ferrugem, apesar da falta formal de condições de corrida, ainda é mais adequada não para aplicativos de gravação, mas para drivers e sistemas operacionais.
As mensagens entre os componentes do sistema não ocorrem no
RabbitMQ clássico, mas no
NATS - este último mostrou benchmarks no servidor que está sendo usado no momento, 1 milhão de mensagens (+ 360 K para cluster) por segundo, contra 40 K para uma lebre. Sim, e é mais rápido e fácil do que o RabbitMQ.
Banco de Dados:
MySQL InnoDB Cluster 7.6 (servidor MySQL 8.0). Lindo layout e ferramenta de depuração da comunidade
MySQL Workbench .
API - escrita em
Swagger (OpenAPI 2.0). Isso evita erros de diferentes programadores, gera código limpo e bem documentado e documentação da API. Infelizmente, o Swagger usa
gorila / mux para fazer o root
por padrão , mas depois de gerar toda a API, a raiz será refeita para
kataras / muxie - é mais rápido.
Frontend: a partir dos frameworks disponíveis: Iris, Beego e Revel - Revel é selecionado. Mais lento que Iris, mas está tudo pronto, incluindo a integração com gráficos. A carga principal ainda será suportada pela API.
Escalonamento: todos os componentes do sistema são montados em contêineres LXC, enquanto na frente deles está o balanceador
HAProxy . A idéia de escalar se resume a alternar consistentemente para servidores mais poderosos com a preservação da estrutura de contêineres à medida que os clientes crescem e, posteriormente, distribuir os contêineres para servidores separados, substituindo o HAProxy pelo NATS. Além do dimensionamento clássico por hardware, há sempre a possibilidade de aumentar o número de goroutinas dentro dos manipuladores de contêineres para solicitar API e site Embora esse processo, como a prática tenha mostrado, tenha limitações lógicas.
Em geral, a idéia principal do artigo e minha profunda convicção é que a arquitetura inicial de projetos de alta carga, em condições modernas, não faz sentido em sistemas de thread único, apesar dos anos de infraestrutura desenvolvida e da presença de um grande número de programadores disponíveis. E todo o esquema do projeto deve ser criado inicialmente, facilitando a transferência para equipamentos mais poderosos e distribuídos. Isso permitirá, no futuro, encontrar facilmente um equilíbrio entre a escala de hardware e código, sem multiplicar os custos.
Um erro comum e mais comum cometido por novas startups é um desenvolvimento inicial ruim da arquitetura. De acordo com o princípio - "comece a escrever rapidamente e depois descobriremos". Como regra, como resultado - isso leva ao colapso do projeto.
Como se costuma dizer - "90% do sucesso é preparação". Não tenha medo de gastar inicialmente na criação de uma arquitetura competente e atenciosa - ela será bem paga.
Boa sorte