Por que sua arquitetura de software GIS não é nativa da nuvem? Você moveu seu servidor GIS para a nuvem, então sua arquitetura GIS é nativa da nuvem?
Resposta: Se você apenas mover seu servidor GIS para AWS ou Azure, então seu SDI não é nativo da nuvem. Isso é chamado de re-hospedagem ou Infraestrutura como serviço (IaaS). Você pode obter alguns benefícios de um banco de dados gerenciado em nuvem, como AWS RDS, e sua única instância de servidor GIS pode ser dimensionada conforme necessário. No entanto, você não tem uma infraestrutura verdadeiramente elástica e escalonável que uma arquitetura nativa da nuvem pode fornecer.
E o que isto significa?
- Expansão de escala
Para alcançar a escalabilidade real, você precisa escalar vários servidores por trás do balanceador de carga. Veja a solução da Esri abaixo.
Implantação de várias máquinas de cluster de servidor GIS
Infelizmente, esta solução é estática (não apenas porque você precisa comprar uma licença principal da Esri com antecedência). Não há mecanismo automático para adicionar instâncias ao cluster. Entre no grupo de escalonamento automático AWS. A AWS fornece balanceamento de carga dinâmico e o grupo de escalonamento automático adiciona e exclui instâncias EC2 do cluster conforme necessário.
Para que tudo isso funcione, o servidor deve ser sem estado. No exemplo da Esri, você deve ter notado que o "diretório do servidor e armazenamento de configuração" estão localizados em um diretório de rede compartilhado. Isso serve a dois propósitos. Você precisa armazenar blocos em cache e metadados de configuração sobre serviços e camadas. Vamos ver como melhorar isso.
- Metadados de serviço e caches de bloco
Primeiro, vamos armazenar os metadados de serviços e camadas no banco de dados. Uma vantagem desse método é que não precisamos fazer um plano de backup separado para a configuração do servidor e banco de dados, e podemos facilmente consultar a configuração, se necessário. Não se preocupe, podemos armazenar várias conexões nos metadados para que nosso banco de dados operacional possa ser separado seletivamente do banco de dados de metadados.
Então, vamos armazenar em cache todos os metadados no Elasticache Redis para acesso super rápido à memória. Agora, fizemos o nosso melhor em metadados de serviço e de camada: velocidade e durabilidade.
Em seguida, vamos verificar nosso cache de blocos. Pode ser uma fatia raster ou MVT. Vamos colocar todas as fatias em um intervalo S3 e, em seguida, colocar o Cloudfront CDN nele. Não se esqueça de excluir todos esses blocos raster em branco para otimizar o armazenamento. Você pode sentir que seu mapa se tornou mais suave e mais sensível?
- Big Data
Se seu banco de dados não pode escalar com você durante a inevitável análise de dados geográficos de IoT / drone / visão computacional, qual é a vantagem de ser capaz de atender a milhões de solicitações da web por segundo? O mesmo conceito de escala horizontal também se aplica, para que você possa executar o processamento de consulta paralela em grande escala. Você pode usar o Hadoop, mas aqueles que sabem escrever funções de redução de mapa em geoespacial são muito caros e até um pouco esnobes. JK Corporation.
Se houver um repositório de big data com recursos de consulta espacial, ele tem uma interface de consulta tradicional para que você possa conectá-lo às suas ferramentas de análise e relatório (como o Tableau), isso seria ótimo. boas notícias! Existem dois tipos de bancos de dados de big data: MemSQL com interface MySQL e dados Citus com interface PostGIS.
- GeoEvents (assuntos geográficos)
Vamos apresentar os recursos de processamento do geoevento. O mapeamento em tempo real pode ser obtido por meio de websockets, webhooks e / ou Pubnub. Para geofencing, você deve considerar o Azure Stream Analytics, que inclui os principais recursos geoespaciais.
- Composable (composable)
Os modelos do AWS CloudFormation permitem combinar e ajustar a pilha de infraestrutura conforme necessário por meio de um modelo declarativo. Pense nisso como um instalador de nuvem flexível que pode automatizar seus devops e processos de infraestrutura. Se você não está familiarizado com este conceito, leia o código de infraestrutura.
- Acessível (disponível)
A loja de aplicativos em nuvem está aberta! É chamado de mercado AWS. Como um comprador de aplicativo corporativo, se você lida apenas com o mercado da AWS, isso não simplificará seu teste, fornecimento ambiental e aquisição? Se você puder construir uma pilha complexa de infraestrutura de dados espaciais do mercado em menos de uma hora com apenas alguns cliques, será mais fácil para você? Não estou dizendo que haja apenas uma instância de AMI disponível.
- Azure / Docker / Kubernetes
Todas essas coisas nativas da nuvem podem ser feitas no Azure e em várias plataformas de orquestração Docker (que podem ser no Azure, AWS ou no local). Para simplificar, optei por usar alguns exemplos de grupo de AWS e de escalonamento automático para ilustrar uma forma popular de infraestrutura nativa da nuvem. Use os exemplos a seguir de técnicas semelhantes para comparar as opções com awsazure e Docker. (Excluindo Google Cloud Platform)
- Compatibilidade
- Anúncio Shameless Plug
Se você quiser saber como tudo isso funciona na vida real para uma das maiores marcas do mundo, entre em contato - [email protected]. Confira também alguns vídeos de produtos para ver como tornamos a publicação de serviços de dados de localização compatíveis com o Esri e OGC super simples. No momento, estamos aceitando um número limitado de clientes piloto, onde aproveitamos a automação para migrar seus dados e serviços / configuração de camada do ArcGIS Server para a nuvem gratuitamente, enquanto mantemos a compatibilidade com seus aplicativos e ferramentas Esri existentes.
https://www.linkedin.com/pulse/cloud-native-gis-architecture-mike-mcdougall/
O artigo acima é um artigo no LinkedIn sobre GIS nativo da nuvem. Na verdade, acho que o artigo a seguir é melhor
https://blog.csdn.net/supermapsupport/article/details/85988021