AMBROSIA
1.0.0
Windows Build (netCore3.1):
Windows Build (NetFramework 461):
Linux Build (netcore3.1):
Nó JS (netCore3.1):
Nó JS (NetFramework 461):
Ambrosia é uma abordagem independente da linguagem de programação para criar e implantar aplicativos distribuídos altamente robustos. Ambrosia reduz drasticamente os custos de desenvolvimento e implantação e tempo para o mercado, fornecendo automaticamente recuperação e alta disponibilidade.
Os aplicativos orientados para o datacenter de hoje, que incluem os serviços mais populares em execução na nuvem hoje, são compostos por pilhas de software distribuídas e altamente complexas. Por exemplo, eles normalmente incorporam o Hub de Eventos ou Kafka para diário robustamente diário de entrada e interações para recuperação, registrar informações importantes em lojas como Blobs do Azure para depuração e usam mecanismos extremamente caros, como transações distribuídas e funções sem estado com back-end persistente distribuído, em Back-Ends, em Back-Ends Distribuído, em para garantir exatamente uma vez a execução do código de serviço.
Por outro lado, a Ambrosia oferece automaticamente a recuperação de programadores, alta disponibilidade, depuração, atualizabilidade e exatamente uma vez a execução, sem exigir que os desenvolvedores tenham juntos sistemas complexos ou use mecanismos excessivamente caros.
Para saber mais sobre a implementação e o desempenho da Ambrosia, você pode ler nosso artigo VLDB.
Convidamos os desenvolvedores que desejam desenvolver ou contribuir com a Ambrosia para se juntar à nossa comunidade Gitter.
Conceitos de Ambrosia
Como funciona
Características
Início rápido para desenvolvedores de aplicativos
Início rápido para colaboradores de Ambrosia
Referência
Dependências
Suporte ao idioma
Uso
Comunicação segura entre serviços
Comparação com
A resiliência virtual é um mecanismo em um ambiente de programação e execução (possivelmente distribuído), normalmente empregando um log, que explora a natureza replicável e a serializabilidade de um aplicativo para mascarar automaticamente a falha.
Utilizamos o termo resiliência virtual para descrever o mecanismo na Ambrosia que permite que os programadores escrevam seus aplicativos de maneira alheia, removendo a necessidade de os escritores de aplicação escreverem lógica para recuperação ou proteção do estado. Os sistemas de processamento de dados, que normalmente expressam suas consultas nas variantes do SQL, forneceram a sua resiliência virtual a seus escritores de consulta há décadas. Os sistemas Reduce Map, que não usam necessariamente o SQL, também fornecem essa capacidade. Observe que, em todos esses casos, esse recurso alavanca a capacidade de reproduzir deterministicamente, como Ambrosia.
Para alcançar a resiliência virtual por meio da Ambrosia, os aplicativos devem manter o seguinte contrato: de algum estado inicial, qualquer execução dos mesmos solicitações na mesma ordem resulta no mesmo estado final , bem como nas mesmas solicitações de saída na mesma ordem .
Os blocos básicos de construção de ambrosia são imortais , objetos distribuídos confiáveis que se comunicam através dos RPCs. Um imortal define um conjunto de estado persistente e um conjunto de manipuladores de RPC que operam nesse estado. Uma instância de um imortal é uma entidade nomeada que mantém o estado e executa os manipuladores de RPC de acordo com a definição do imortal. Uma aplicação de Ambrosia geralmente possui várias instâncias do mesmo imortal; Por exemplo, um aplicativo pode definir um único "trabalho" imortal para executar um trabalho de processamento de dados e executar várias instâncias desse trabalho operando em diferentes conjuntos de dados.
A figura abaixo descreve a arquitetura básica de um aplicativo de Ambrosia, mostrando dois serviços de Ambrosia comunicando, chamados imortais. As caixas internas da figura representam o código que pode ser executado em 2 processos separados, ou no caso de C#, podem ser executados em um processo integrado. Cada instância de um imortal existe como um objeto de software e um thread de controle em execução dentro do processo de aplicação. Uma instância imortal se comunica com outras instâncias imortais através do coordenador imortal , que registra duramente os RPCs da instância e encapsula a rede de baixo nível necessária para enviar RPCs. A posição das solicitações no log determina a ordem em que eles são enviados ao processo de solicitação de execução e, em seguida, reexecionarão após a recuperação.
Além disso, a ligação específica de ambrosia específica do idioma fornece um serializador de estado. Para evitar a reprodução desde o início do serviço durante a recuperação, o coordenador imortal ocasionalmente os pontos de verificação do estado do imortal, que inclui o estado de aplicação. A maneira como essa serialização é fornecida pode variar de idioma para idioma, ou mesmo entre as ligações para o mesmo idioma.
Aqui está uma lista de recursos que a Ambrosia fornece aos desenvolvedores de aplicativos e implementadores:
Defina um novo serviço para executar em Ambrosia
Implantar serviços em Ambrosia
Instância de serviço de depuração
Ativo ativo
Atualizações ao vivo, atualizações de teste
RPC
RPC assíncrono (alfa)
Comece com uma de nossas amostras para colocar um serviço em funcionamento na Ambrosia.
Construa o coordenador imortal da Ambrosia e o gerador de código do cliente C# com este script Bash:
./build_dotnetcore_bindist.sh
Dado um .NET Core SDK, isso funcionará no Windows, Mac OS ou Linux. Depois disso, você tem uma distribuição binária de Ambrosia construída dentro do diretório ./bin em sua cópia de trabalho.
Confira também nosso guia contribuinte.
Atualmente, a Ambrosia exige uma assinatura do Azure para escrever seus logs no armazenamento replicado. No futuro, prevemos abstrair esse componente para poder usar outras opções de armazenamento para logs.
Atualmente, a Ambrosia suporta C# na estrutura .NET Core e .Net. A partir da versão 2.0.0.0, a Ambrosia também suporta Node.js usando o TypeScript. Esperamos adicionar apoio a outros idiomas no futuro.
Usage: dotnet Ambrosia.dll RegisterInstance [OPTIONS] Options: -i, --instanceName=VALUE The instance name [REQUIRED]. -rp, --receivePort=VALUE The service receive from port [REQUIRED]. -sp, --sendPort=VALUE The service send to port. [REQUIRED] -l, --log=VALUE The service log path. -cs, --createService=VALUE [A - AutoRecovery | N - NoRecovery | Y - AlwaysRecover]. -ps, --pauseAtStart Is pause at start enabled. -npl, --noPersistLogs Is persistent logging disabled. -lts, --logTriggerSize=VALUE Log trigger size (in MBs). -aa, --activeActive Is active-active enabled. -cv, --currentVersion=VALUE The current version #. -uv, --upgradeVersion=VALUE The upgrade version #. -h, --help show this message and exit Usage: dotnet Ambrosia.dll AddReplica [OPTIONS] Options: -r, --replicaNum=VALUE The replica # [REQUIRED]. -i, --instanceName=VALUE The instance name [REQUIRED]. -rp, --receivePort=VALUE The service receive from port [REQUIRED]. -sp, --sendPort=VALUE The service send to port. [REQUIRED] -l, --log=VALUE The service log path. -cs, --createService=VALUE [A - AutoRecovery | N - NoRecovery | Y - AlwaysRecover]. -ps, --pauseAtStart Is pause at start enabled. -npl, --noPersistLogs Is persistent logging disabled. -lts, --logTriggerSize=VALUE Log trigger size (in MBs). -aa, --activeActive Is active-active enabled. -cv, --currentVersion=VALUE The current version #. -uv, --upgradeVersion=VALUE The upgrade version #. -h, --help show this message and exit Usage: dotnet Ambrosia.dll DebugInstance [OPTIONS] Options: -i, --instanceName=VALUE The instance name [REQUIRED]. -rp, --receivePort=VALUE The service receive from port [REQUIRED]. -sp, --sendPort=VALUE The service send to port. [REQUIRED] -l, --log=VALUE The service log path. -c, --checkpoint=VALUE The checkpoint # to load. -cv, --currentVersion=VALUE The version # to debug. -tu, --testingUpgrade Is testing upgrade. -h, --help show this message and exit
Leia sobre como garantir comunicações entre componentes distribuídos implantados em Ambrosia aqui.
