Node.js + Couchbase 3.0 + SDK 2.0 + Bootstrap
Requisitos
Quando chegou a hora de criar uma demonstração do produto para a Conferência Couchbase Connect, foram estabelecidos os seguintes requisitos:
[1] Deve ser uma demonstração ao vivo, com a participação do público - nada de filmes prontos ou apresentações apenas em PowerPoint. O nível foi elevado, com riscos significativos.
[2] Ele deve demonstrar o poder do Couchbase 3.0 e mostrar a consistência em tempo real dos dados entre clusters em diferentes centros de dados (XDCR).
[3] Ele deve ser ágil, aproveitando o poder dos novos SDKs do Couchbase 2.0.
[4] O aplicativo precisa ter o código concluído em 4 dias para reforçar como o desenvolvimento com o Couchbase é ideal para a empresa ágil.
[5] Diga ao mundo como foi feito e prove-o publicando o código-fonte.
Decidiu-se que um aplicativo de leilão, distribuído em dois servidores da Web em dois centros de dados diferentes que conversam com dois clusters diferentes, atingiria o objetivo. Um cluster de Salt Lake City e um cluster de Londres manterão a consistência com replicação bidirecional entre eles usando o XDCR. O novo protocolo DCP no Couchbase 3.0 significa que a consistência seria limitada apenas pela velocidade dos fios. Um servidor de aplicativos em cada data center executando o node.js lida com o tráfego em cada região. O código pode ser baixado de repositório do couchbaselabs no github. **
Design de aplicativos
Além de usando node.js Com o Express e o Couchbase 2.0 SDK, o bootstrap foi usado para o desenvolvimento de front-end. Os SDKs 2.0 são uma conquista notável e incluem novos avanços significativos que simplificam o desenvolvimento. Informações sobre os SDKs 2.0 e por que o Couchbase continua a ampliar a liderança de desenvolvimento no mercado podem ser encontradas em nosso portal do desenvolvedor.
Gerenciamento de sessões
Embora nenhuma autenticação seja necessária para um leilão apenas por diversão, ainda é necessário um meio de identificar usuários e sessões simultâneas. Um formulário de login simples armazena um cookie com um ID de usuário para cada sessão. A função de login verifica se o usuário existe e se há alguma violação de palavras filtradas antes de criar um cookie de sessão.
filterScan(novoUsuário, função (filtcb) {
se (filtcb) {
db.ler(novoUsuário, função (erro, usuário) {
se (erro && err.código === couchbase.erros.keyNotFound) {
res.biscoito('usuário', novoUsuário);
db.upsert(novoUsuário, 0, função (erro, res) {
se (erro) {
console.registro("LOGIN:ERROR CREATING:" + erro);
feito("LOGIN:ERROR CREATING:" + erro, nulo);
retorno;
}
console.registro("LOGIN:" + novoUsuário + ":SUCCESS");
feito(nulo, "LOGIN:" + novoUsuário + ":SUCCESS");
retorno;
});
} mais {
se (usuário) {
console.registro("LOGIN:ERROR:" + novoUsuário + " EXISTE");
feito("LOGIN:ERROR:" + novoUsuário + " existe - escolha um nome de usuário diferente", nulo);
retorno;
}
console.registro("LOGIN:ERROR:END:" + erro);
feito("LOGIN:ERROR" + erro, nulo);
retorno;
}
});
} mais {
console.registro("LOGIN:ERRO:VIOLAÇÃO DE PALAVRA");
feito("LOGIN:ERROR, TERMO PROIBIDO NO NOME DE USUÁRIO", nulo);
retorno;
}
});
}
Em seguida, uma função de "middleware" muito pequena verifica se um usuário configurou uma sessão antes de rotear as solicitações de entrada.
se (req.cookies.usuário) {
retorno próxima();
}
res.redirecionar(‘/’);
}
Uma outra função de "middleware" verifica se uma contagem regressiva está definida ou se esse leilão está fechado.
db.ler("estado,função(erro,feito){
se(feito.valor.ativo) {
retorno próxima();
}mais{
se(feito.valor.contagem regressiva != "nenhum")
{
res.renderizar('countdown.jade');
}mais {
db.ler("bicicleta, função (erro, cb) {
res.renderizar("vencedor, {usuário: req.cookies.usuário, quantidade: cb.valor.oferta, alta: cb.valor.alta});
retorno;
});
}
}
});
}
Interação com o usuário
O arquivo app.js controla o funcionamento do aplicativo. Todas as rotas são definidas no objeto routes.js em um arquivo específico. O objeto do aplicativo é passado para o objeto routes. Essa é uma preferência estilística que facilita a funcionalidade do middleware (conforme usado nos exemplos acima). A API REST é direta: Os seguintes métodos são expostos:
POST api/auction/login [definir uma sessão, cookie, para cada usuário único]
GET api/auction/login [método de segurança, em caso de atualização da página]
GET api/auction/load [carregar a página do leilão]
POST api/auction/bid [definir um lance, com validação]
GET api/auction/bid [método de segurança, em caso de atualização da página]
GET api/auction/get [obter o maior lance atual]
POST api/auction/open/:password [redefine o leilão, libera o balde e define o leilão como aberto]
POST api/auction/close/:password [definir leilão como fechado]
POST api/auction/view/build [definir uma visualização a ser usada para examinar o histórico de lances]
GET api/auction/view/get [obter visualização do histórico de lances]
GET api/auction/countdown/get [obter o tempo em segundos entre o leilão "ir ao ar" e agora]
POST api/auction/countdown/set/:yyyy/:mm/:dd/:hh [definir data de entrada em vigor do leilão]
POST api/auction/countdown/del/:password [definir a contagem regressiva do leilão como nenhum e o leilão como ativo]
Atualizações dinâmicas
Na demonstração principal, vários usuários dão lances simultaneamente em dois clusters diferentes, e todas as atualizações precisam ser imediatamente propagadas para qualquer outro usuário que esteja visualizando a página do leilão. Há várias maneiras de fazer isso, cada uma com vantagens e desvantagens. Esse aplicativo específico carrega a página de leilão por meio de um modelo jade. O modelo jade instancia um loop de sondagem jquery ajax. Esse loop pesquisa o endpoint /api/auction/get REST duas vezes a cada segundo para determinar o maior lance.
setInterval(função () {
pollBid()
}, 500);
função pollBid() {
$.obter('/api/auction/get', função (cb) {
se (cb) {
$("#bid").html(“$” + cb.oferta);
$("#high").html(cb.alta);
}
mais {
}
});
}
Administração
Os métodos a seguir são chamados usando comandos curl durante a demonstração para definir os estados do leilão. A sequência para a demonstração é redefinir o leilão, definir uma data de entrada em operação, definir o leilão em operação quando a palestra começar e fechar o leilão.
curl -X POST http://localhost:3001/api/auction/open/un5ecure_pa55word
curl -X POST http://localhost:3001/api/countdown/set/2014/10/06/13
curl -X POST http://localhost:3001/api/countdown/del/un5ecure_pa55word
curl -X POST http://localhost:3001/api/auction/close/un5ecure_pa55word
Fonte e considerações
Grande parte da funcionalidade deste aplicativo é codificada e específica para este caso de uso de demonstração de palestra. O modelo de dados é específico para esse caso de uso e só é aplicável como prova de conceito. O caso de uso não tem acesso seguro ou autenticação. Ao implantar em diferentes clusters vinculados pelo XDCR, é necessária uma administração adicional para "redefinir" o leilão. Não é possível "liberar" os compartimentos que estão participando atualmente do XDCR.
** Isenção de responsabilidade: o Couchbase Labs fornece código experimental apenas para fins de pesquisa e desenvolvimento. O código e os aplicativos do Couchbase Labs não são suportados por nenhum contrato de suporte do Couchbase e são fornecidos no estado em que se encontram, sem garantia de qualquer tipo.
Todd, obrigado pela postagem e pela demonstração. Você poderia compartilhar as configurações de cluster que usou na versão do AWS para atingir o desempenho de 3M/s? Ou seja, que tipo de potência de servidor foi necessária?
TIA,
Dave
Dave, essas instâncias eram c3.4xlarge. O Couchbase Server 3.0 foi instalado com as configurações padrão.