Pergunta

Meu projeto de desenvolvimento atual tem dois aspectos.Primeiro, existe um site público onde usuários externos podem enviar e atualizar informações para diversos fins.Essas informações são então salvas em um SQL Server local nas instalações do colo.

O segundo aspecto é um aplicativo interno que os funcionários usam para gerenciar esses mesmos registros (conceitualmente) e fornecer atualizações de status, aprovações, etc.Este aplicativo está hospedado no firewall corporativo com seu próprio banco de dados SQL Server local.

As duas redes estão conectadas por uma solução VPN de hardware, o que é decente, mas obviamente não é a coisa mais rápida do mundo.

Os dois bancos de dados são semelhantes e compartilham muitas das mesmas tabelas, mas não são 100% iguais.Muitas das tabelas em ambos os lados são muito específicas para aplicações internas ou externas.

Então a questão é:quando um usuário atualiza suas informações ou envia um registro no site público, como você transfere esses dados para o banco de dados da aplicação interna para que possam ser gerenciados pela equipe interna?E vice versa...como você envia as atualizações feitas pela equipe de volta ao site?

Vale ressaltar que quanto mais “em tempo real” essas atualizações ocorrerem, melhor.Não que precise ser instantâneo, apenas razoavelmente rápido.

Até agora, pensei em usar os seguintes tipos de abordagens:

  1. Replicação bidirecional
  2. Interfaces de serviço da Web em ambos os lados com código para sincronizar as alterações à medida que são feitas (em tempo real).
  3. Interfaces de serviço da Web em ambos os lados com código para sincronizar as alterações de forma assíncrona (usando um mecanismo de enfileiramento).

Algum conselho?Alguém já passou por esse problema antes?Você encontrou uma solução que funcionou bem para você?

Foi útil?

Solução

Este é um cenário de integração bastante comum, acredito.Pessoalmente, acho que uma solução de mensagens assíncronas usando uma fila é ideal.

Você deve conseguir uma sincronização quase em tempo real sem a sobrecarga ou a complexidade de algo como replicação.

Os serviços web síncronos não são ideais porque seu código terá que ser muito sofisticado para lidar com cenários de falha.O que acontece quando um sistema é reiniciado enquanto o outro continua a publicar alterações?O sistema de envio atinge o tempo limite?O que isso faz com isso?A menos que você esteja preparado para perder dados, você desejará algum tipo de fila transacional (como MSMQ) para receber os avisos de alteração e garantir que eles cheguem ao outro sistema.Se algum dos sistemas estiver inativo, as alterações (passadas como mensagens) serão apenas acumuladas e, assim que uma conexão puder ser estabelecida, o servidor reiniciado processará todas as mensagens na fila e as atualizará, tornando a integridade do sistema muito, muito mais fácil de alcançar.

Existem algumas ferramentas de código aberto que podem realmente facilitar isso se você estiver usando .NET (especialmente se quiser usar o MSMQ).

  1. nServiceBus por Udi Dahan
  2. Trânsito de massa por Dru Sellers e Chris Patterson

Existem também produtos comerciais, e se você estiver considerando uma opção comercial, consulte aqui para obter uma lista de opções no .NET.É claro que o WCF pode fazer mensagens assíncronas usando ligações MSMQ, mas uma ferramenta como nServiceBus ou MassTransit fornecerá uma API de envio/recebimento ou Pub/Sub muito simples que tornará sua exigência um trabalho muito simples.

Se você estiver usando Java, há inúmeras implementações de barramento de serviço de código aberto que tornarão esse tipo de mensagem assíncrona e bidirecional muito fácil, como o Mule ou talvez apenas o ActiveMQ.

Você também pode querer considerar a leitura Udi Dahan's blog, ouvindo alguns de seus podcasts.Aqui estão mais alguns bons recursos para você começar.

Outras dicas

Estou no meio de um projeto semelhante, exceto que tenho vários sites que precisam ser sincronizados em conexões lentas (discada em alguns casos).

Primeiramente você precisa rastrear as alterações, se você puder usar o SQL 2008 (mesmo a versão Express é suficiente se o limite de 2 Gb não for um problema) isso vai aliviar bastante a dor, basta ativar o Change Tracking no banco de dados e em cada tabela.Estamos usando o SQL Server 2008 na sede com o esquema estendido e o SQL Express 2008 em cada site com um subconjunto de dados e esquema limitado.

Em segundo lugar, você precisa acompanhar suas alterações, Serviços de sincronização funciona muito bem e oferece suporte ao uso de um gateway WCF no banco de dados principal.Neste exemplo você precisará usar o Sincronizar usando SQL Express Client exemplo como ponto de partida, observe que ele é baseado no SQL 2005, portanto, você precisará atualizá-lo para aproveitar as vantagens dos recursos de controle de alterações em 2008.Por padrão, o Sync Services usa SQL CE nos clientes, o que tenho certeza que não é suficiente no seu caso.Você precisará de um serviço executado em seu servidor Web que periodicamente (pode ser a cada 10 segundos, se desejar) execute o método Synchronize().Isso informará ao seu banco de dados principal sobre as alterações feitas localmente e, em seguida, solicitará ao servidor todas as alterações feitas lá.Você pode configurar o código SQL get e apply para chamar procedimentos armazenados e pode adicionar manipuladores de eventos para lidar com conflitos (por exemplo,Atualização do cliente versus Atualização do servidor) e resolvê-los adequadamente em cada extremidade.

Temos uma loja como cliente, com três lojas conectadas à mesma VPN
Duas das lojas possuem um computador funcionando como "servidor" daquela loja e a terceira possui o "banco de dados mestre"
Para sincronizar tudo com o master não temos a melhor solução, mas funciona:existe um PC dedicado rodando um aplicativo que verifica o carimbo de data / hora de cada registro em cada tabela das duas lojas e se for diferente da última vez que você sincronizou, ele copia os resultados
Observe que isso funciona nos dois sentidos.Ou sejase você atualizar um produto no banco de dados master, essa alteração será propagada para as outras duas lojas.Se você tiver um novo pedido em uma das lojas, ele será transmitido ao “mestre”.
Com algumas otimizações você pode sincronizar todas as lojas em cerca de 20 minutos

Recentemente, tive muito sucesso com o SQL Server Service Broker, que oferece mensagens assíncronas confiáveis ​​e persistentes prontas para uso, com muito pouca dificuldade de implementação.

  • É rápido de configurar e, à medida que você aprende mais, pode usar alguns dos recursos mais avançados.
  • Desconhecido para a maioria, também faz parte das edições para desktop, portanto pode ser usado como um sistema de mensagens de estação de trabalho
  • Se você já possui habilidades em T-SQL, elas podem ser aproveitadas, pois todo o código para ler e escrever mensagens é feito em SQL
  • É incrivelmente rápido

É uma parte muito pouco divulgada do SQL Server e vale a pena dar uma olhada.

Eu diria que basta ter um trabalho que copie os dados da tabela de entrada do banco de dados pub para uma tabela pendente do banco de dados privado.Então, depois de atualizar os dados no lado privado, eles serão replicados para o lado público.Se você não tiver nenhum dos dados replicados no lado público atualizado, deverá ser uma solução de replicação transacional bastante fácil.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top