Tecnologia da área da baía de Wells Fargo SF
Escala .NET Core Aplicativos e microsserviços para desempenho extremo
Para .NET, Java e Node.js
Por Iqbal Khan
Presidente e Evangelista de Tecnologia
Os aplicativos de servidor de hoje precisam processar muitas transações muito rapidamente. Muitos deles são aplicativos da Web que atendem milhões de usuários todos os dias. Outros são microsserviços que atendem a milhões de aplicativos móveis ou dispositivos inteligentes da Internet das Coisas (IoT).
A maioria desses aplicativos está sendo implantada em contêineres como o Kubernetes para simplificar e automatizar a implantação, o dimensionamento e o gerenciamento. E os ambientes de implantação escolhidos mudaram do local para as nuvens líderes, como AWS, Azure, Google Cloud e muito mais.
Aprenda a desenvolver tais aplicativos que atendam aos requisitos de desempenho extremos de hoje, removendo gargalos de desempenho relacionados ao armazenamento de dados e bancos de dados e também à comunicação entre diferentes partes dos aplicativos de microsserviços.
Visão geral
Muito obrigado Mike e obrigado Jason por me dar a oportunidade de falar com um grupo tão importante no Wells Fargo, o San Francisco Bay Area Technology Group. Como Mike mencionou, eu trabalho na Alachisoft e a palavra Alachi, eu estava explicando a Mike e Jason é uma espécie de derivado da palavra hindi Ellachi que é ou Elaichi, que é um cardamomo de nome de tempero. Então, estávamos apenas nomeando a empresa há muitos anos e queríamos criar algo único, então criamos Alachisoft.
Nosso produto é realmente NCache. Então, eu não vou falar sobre NCache. A palestra de hoje é sobre 'Como você pode escalar seus aplicativos da Web e microsserviços para desempenho extremo?' Se você estiver desenvolvendo esses aplicativos em Java, .NET, .NET Core ou Node.js, então você veio à conversa certa.
O que é escalabilidade?
Então, vamos entender algumas definições, antes de entrar na conversa real. A primeira é: O que é escalabilidade? A escalabilidade é, na verdade, o alto desempenho do aplicativo, mas sob cargas de pico. Portanto, se seu aplicativo está executando super-rápido com apenas 5 usuários, ele não é realmente escalável, a menos que você tenha o mesmo super desempenho em uma velocidade com 5000, 50,000 ou 500,000 usuários. Se o seu aplicativo pode fazer isso, então ele é escalável e, obviamente, queremos que muitos de nossos aplicativos sejam escaláveis, e falarei sobre isso.
O que é escalabilidade linear?
A próxima definição é 'O que é escalabilidade linear?' Isso é mais uma arquitetura de aplicativo e terminologia de implantação. Se o seu aplicativo for arquitetado corretamente, ele será linearmente escalável, o que significa que, se você precisar aumentar a capacidade de transação por segundo, o que significa quantos usuários você pode lidar? Quantas solicitações de aplicativos você pode manipular? Se você quiser aumentar isso, basta adicionar mais servidores e cada servidor adicionado aumenta a capacidade de transação por segundo de maneira linear.
Então, não há bloqueio, não há gargalo. Obviamente, as curvas de leitura versus gravação são diferentes, mas ambas são lineares. Se você puder fazer isso, seu aplicativo será linearmente escalável e é algo que definitivamente queremos.
O que é escalabilidade não linear?
Isso é algo que não queremos e é se você arquitetou seu aplicativo de uma forma em que existem alguns gargalos, então, à medida que você aumenta sua carga no aplicativo e adiciona mais caixas, algo começa a ceder e seu aplicativo é iniciado para desacelerar, de fato, às vezes até trava.
Portanto, definitivamente não queremos que nossos aplicativos sejam arquitetados para serem não linearmente escaláveis.
Quem precisa de escalabilidade?
Ok, então, agora que entendemos o que significa escalabilidade, a próxima coisa a entender é, quem precisa dela? Quais aplicativos precisam de escalabilidade?
- Aplicações da Web
As aplicações mais comuns são aplicações web. Estes são para um banco como o Wells Fargo ou outros bancos com os quais trabalhamos como o grupo Citi e o Bank of America e o Barclays e o banco de Tóquio. Esses são aplicativos voltados para o cliente, você tem wellsfargo.com, que é para bancos de consumo e pequenas empresas e esses aplicativos da Web precisam ser capazes de lidar com muitos usuários sem diminuir a velocidade. Portanto, é muito importante que esses aplicativos funcionem super-rápido sob carga extrema.
- Serviços da Web / API da Web
O número dois são os serviços da web, aplicativos de API da web. Eles geralmente estão lá para atender a muitos aplicativos móveis ou qualquer outro aplicativo que os chame para executar determinadas tarefas. Então, se você tem, digamos, o Wells Fargo tem um aplicativo móvel para banco do consumidor, esse aplicativo móvel precisa conversar com algum back-end, e esse back-end hoje é provavelmente serviços da web. Obviamente, não sei disso, mas suponho que seja, porque muitos dos outros bancos com os quais trabalhamos têm essa situação em que os serviços da Web são os que estão lidando com essa solicitação de aplicativo móvel. E, eles têm exatamente a mesma sensibilidade. Eles precisam ser capazes de lidar com muita carga sem diminuir a velocidade.
- Microservices
Microsserviços é algo que está na moda hoje em dia e, vou falar um pouco mais sobre isso daqui a pouco, mas é essencialmente, você está rearquitetando os serviços da Web de uma nova maneira melhor, deixe-me apenas diga dessa maneira neste momento.
- Aplicativos de servidor
O quarto tipo de aplicativo é qualquer outro aplicativo de servidor que você possa ter. Podem ser, aplicativos de servidor estão fazendo processamento em lote. Eles também podem estar lidando com transações ao vivo, mas se enquadram em alguma outra categoria. Mas eles também têm o mesmo tipo de requisito de taxa de transferência de transação por segundo.
Portanto, se você estiver desenvolvendo qualquer um desses quatro tipos de aplicativos. Há também alguns outros, digamos, você pode estar fazendo aprendizado de máquina ao vivo e IA, mas não vou entrar nisso nesta palestra, não temos tempo suficiente. Mas, digamos, se você tiver esses quatro aplicativos, você definitivamente precisa que eles sejam escaláveis. E, esta é a conversa que vai passar por cima deles. No que diz respeito à tecnologia, as aplicações web em geral, são desenvolvidas em Java ou ASP.NET, ASP.NET Core, sendo a nova versão do ASP.NET e do Node.js e, todos os outros três tipos são Java ou .NET/.NET Core, Microsserviços sendo em Java ou .NET Core porque é a nova tecnologia.
Introdução aos microsserviços
Para aqueles que não sabem como são os Microsserviços, eu só queria dar uma breve visão arquitetônica dele. E, para aqueles que fazem isso, apenas tenham paciência comigo. Então, um microsserviços, a razão pela qual eles estão se tornando tão populares porque eles permitem que você divida seus aplicativos monolíticos em microsserviços de tamanho de byte e, cada microsserviço é desacoplado de outros microsserviços. E, essa dissociação significa que eles não chamam um ao outro. Eles têm seus próprios bancos de dados geralmente lógicos. Eles não precisam ter bancos de dados físicos separados, mas, pelo menos logicamente, geralmente têm seus próprios. Alguns dos Microsserviços podem usar um NoSQL database, MongoDB ou qualquer outra coisa. Alguns deles usarão bancos de dados relacionais, SQL Server, Oracle, DB2. Alguns deles podem estar indo para os dados legados do mainframe.
Então, o desacoplamento exige que eles conversem entre si através de algum tipo de barramento de eventos, que é o que é o tubo do lado direito. E eles são chamados por aplicativos móveis, aplicativos Web de página única ou aplicativo Web MVC padrão em Java, .NET ou Node.js, por meio do gateway de API. Então, esta é apenas uma boa visão do que são microsserviços. E vou falar sobre como eles têm os mesmos problemas de escalabilidade que outros aplicativos que tradicionalmente têm.
Ambientes de implantação de aplicativos
Outra coisa que eu queria abordar rapidamente porque queria colocar o contexto em torno do que vou falar são os diferentes tipos de ambientes de implantação que tivemos que enfrentar ao longo dos anos. Faço isso há mais de 15 anos e há muito tempo era tudo no local, datacenters com controle total. Mesmo agora, muitos dos bancos com os quais trabalhamos ainda têm seus próprios datacenters. Mas quase todo mundo está migrando ou pelo menos planejando migrar para a nuvem. Algumas pequenas e médias empresas migram para a nuvem pública. Muitas empresas maiores, especialmente, os serviços financeiros e os bancos geralmente preferem uma implantação de nuvem privada. Na verdade, alguns dos bancos com os quais trabalhamos preferem uma nuvem privada em uma estrutura do tipo Pivotal Cloud Foundry ou Red Hat Open Stack, o que lhes dá controle total sobre o ambiente de nuvem privada, não importa onde o nuvem privada existe. Se existe dentro de uma nuvem pública como um espaço alugado ou está no topo de seu datacenter que eles têm agora, ou é outra coisa, isso lhes dá liberdade. Mas, de qualquer forma, eles estão indo para a nuvem.
E, Kubernetes é algo que também vou abordar mais tarde, mas está se tornando realmente outra palavra da moda, assim como Microsserviços. Porque é uma tecnologia muito poderosa que simplifica o seu Dev Ops. Também oferece portabilidade de ambiente. Então, tudo o que você faz uma vez, funciona em todos os ambientes. Esteja você no local, em qualquer uma das nuvens, você tem o mesmo ambiente de implantação que funciona. E, também no Kubernetes, muitos dos bancos com os quais trabalhamos estão preferindo uma oferta mais neutra em plataforma de nuvem, como Tanzu Kubernetes ou Red Hat OpenShift. Então, vou passar por esses conceitos mais tarde como parte do tópico de escalabilidade sobre o qual estamos falando.
Problema de Escalabilidade
Ok, então, vamos voltar ao problema real sobre o qual falamos, ou seja, existe um problema de escalabilidade que precisamos resolver? Sim existe. Mas, não está na camada do aplicativo. Não está na arquitetura do aplicativo. É no armazenamento de dados, que se torna o gargalo. E, quando digo a palavra armazenamento de dados, quero dizer bancos de dados relacionais ou banco de dados ou dados legados de mainframe. NoSQL databases, eles não têm o mesmo tipo de gargalo e estão sendo cada vez mais usados. Mas, infelizmente, eles não podem ser a resposta para todo esse problema de escalabilidade.
Os gargalos de escalabilidade
Se você vir esta imagem, verá que o motivo pelo qual os bancos de dados relacionais e o mainframe legado são um gargalo é porque, diferentemente da camada de aplicativo, você pode adicionar mais servidores. Digamos que você tenha os aplicativos da Web aqui sendo implantados em um ambiente com balanceamento de carga de vários servidores, serviços da Web e microsserviços também da mesma maneira.
Novamente, não estou falando sobre seus ambientes neste momento, apenas dando a você um detalhamento lógico de vários servidores. Portanto, ter a capacidade de adicionar mais servidores significa que a camada do aplicativo nunca se torna um gargalo. Mas, à medida que você aumenta esse nível, o armazenamento de dados se torna cada vez mais um gargalo. E, embora NoSQL não se torna um gargalo, a razão pela qual isso não é uma resposta para todos os seus problemas é porque, NoSQL requer que você mova seus dados para longe do relacional e do mainframe. O que, em um mundo ideal, não deveria ser grande coisa, mas é um grande negócio. A maioria das empresas não pode se afastar completamente do relacional. Eles não podem se afastar completamente do mainframe. Eles podem usar NoSQL como uma combinação de alguns dados pode ser colocada em NoSQL database mas muitos dos dados precisam continuar em bancos de dados relacionais e no mainframe. E, desde que isso seja verdade, então o que isso significa é que qualquer solução de escalabilidade que tenhamos que encontrar não pode ser uma NoSQL database. Tem que ser outra coisa além de um NoSQL database. Ele precisa trabalhar com bancos de dados relacionais e com o banco de dados de mainframe legado.
Gargalos de microsserviços
Microsserviços, como mostrei a arquitetura, mesmo eles não estão dando a você uma escalabilidade incorporada a eles. Mesmo eles têm os mesmos gargalos de desempenho que os serviços da Web ou aplicativos da Web têm. A menos que estejam usando um NoSQL database, que é claro que eles não terão, mas mesmo eles precisam conversar com o mainframe para obter dados legados e muitos deles continuarão a conversar com bancos de dados relacionais. E eles têm um gargalo potencial adicional que é o barramento de eventos que existe para se comunicar entre si.
Se você tiver um ambiente de transações muito alto, esse barramento de eventos também pode ser um gargalo. Se você não tiver a solução certa posta em prática para o ônibus do evento.
Solução de escalabilidade
Portanto, felizmente existe uma solução para isso e é um cache distribuído na memória. E, eu vou entrar nas razões pelas quais é? Mas, deixe-me, apenas fazer algumas afirmações. A razão pela qual é uma solução é porque é extremamente rápido. Ele fornece escalabilidade linear e oferece alta disponibilidade. Então, essas são as três razões pelas quais é uma solução para o problema de escalabilidade. E há um benefício adicional que você obtém ao usar um cache distribuído na memória que, em uma grande empresa como a Wells Fargo, você pode realmente usá-lo como uma plataforma de compartilhamento de dados em vários aplicativos. Vou falar um pouco mais sobre isso, mas isso é uma espécie de benefício adicional ou como um benefício colateral de usar isso. A principal razão é a escalabilidade.
Cache distribuído na memória
Então, como um cache distribuído na memória fornece essa resposta? Como é essa solução para esse problema? A razão pela qual é uma solução é porque um cache distribuído na memória, antes de tudo, está na memória, então é super-rápido. In-memory é mais rápido do que até NoSQL databases. E, segundo, é distribuído. Um cache de distribuição na memória, na verdade, é uma coleção de vários servidores de cache de baixo custo. E cada servidor de cache não é um tipo de banco de dados de um servidor. Estes são mais como servidores web, 4 a 8 núcleos, às vezes mais. 16 a 32 GB de RAM. Obtenha quantos deles você quiser para cada aplicativo e crie isso como uma infraestrutura super rápida e altamente escalável para o aplicativo. Depois de ter a camada de aplicativos que você vê aqui com os aplicativos da web, os serviços da web e os microsserviços e os bancos de dados, sejam eles relacionais, herdados ou NoSQL. Mesmo NoSQL, como eu disse, não é tão rápido quanto um cache distribuído na memória.
Então, o que o cache de distribuição na memória faz? Ele cria um cluster desses servidores de cache e esse cluster agrupa a memória, a CPU e até a capacidade da placa de rede de todos esses servidores de cache juntos. Assim como a camada de aplicativo e, assim como a NoSQL database, embora ainda mais facilmente do que o NoSQL database, você continua adicionando mais servidores de cache à medida que sua capacidade de transação aumenta. Então, de repente você tem um redundante e, além disso, porque está na memória, ele tem que fornecer replicação de dados de uma maneira inteligente e eu vou revisar isso daqui a pouco para ter certeza de que, se algum servidor de cache cai, você não perde nenhum dado. Porque, caso contrário, qualquer armazenamento na memória não é valioso. Porque, se você perder gigabytes e gigabytes de dados apenas porque um servidor caiu, não é realmente uma solução muito atraente. Portanto, um cache distribuído na memória não apenas distribui os dados, mas também os replica de maneira inteligente sem comprometer o desempenho e escalabilidade.
Assim, tendo um cache distribuído na memória como parte de sua infraestrutura, de repente agora você tem a capacidade de remover esse gargalo, 80% de suas leituras de dados vão para o cache distribuído. Os 20% vão para os bancos de dados reais porque os bancos de dados ainda são a fonte de dados mestre. Portanto, quaisquer atualizações que você fizer nesses dados devem ser feitas no banco de dados relacional do mainframe legado ou no NoSQL. Mas, às vezes, até mais de 80%, 90% do seu tráfego de leitura ou gravação pode ser limitado apenas ao cache distribuído. E, de repente, seus aplicativos não sentem mais nenhum gargalo.
Então, isso é como um padrão de arquitetura de aplicativo essencial agora, onde você precisa ter um cache distribuído na memória, se quiser que seus aplicativos possam ser dimensionados.
Escalabilidade de Cache Distribuído
Estes são alguns números de referência de escalabilidade de NCache, onde você pode ver que com apenas 4 a 5 nós, você pode fazer 2 milhões de operações por segundo. E, como é uma escala linear, então, se você quiser ir para 4 milhões, basta adicionar mais 5 nós. E, como você sabe, 2 milhões de operações por segundo é uma carga de transação bastante alta, que a maioria de seus aplicativos, se eles puderem permanecer nessa carga, 90% de seus aplicativos ficarão satisfeitos com esse tipo de carga. Talvez alguns não e eles precisam de mais. E, quando precisarem de mais, basta adicionar mais servidores.
Usos comuns do cache distribuído
Então, espero que agora eu tenha convencido você de que um cache distribuído na memória é uma ótima ideia no que diz respeito a uma arquitetura de aplicativo. Então, a próxima ou a primeira pergunta que vem à mente depois disso é, ok, como eu aproveito isso, como desenvolvedor de aplicativos? Porque, estes são todos sobre aplicativos. Como uso um cache distribuído para aproveitar?
- Cache de dados do aplicativo
Portanto, há três maneiras comuns de usar um cache distribuído. O número um é Cache de dados do aplicativo. Esta é a maneira mais comum, que é o que eu estava falando. Que é que, quaisquer que sejam os dados que você está lendo do banco de dados, você os mantém no cache, então da próxima vez, você apenas os lê do cache, muito simples. E, o que quer que você atualize, você atualiza o cache e o banco de dados.
Agora, uma coisa que você precisa entender imediatamente, que para o cache de dados de aplicativos existe um problema único, que é que agora os dados existem em dois lugares, um é o banco de dados mestre, que pode ser seu relacional, NoSQL ou mainframe legado e um é o cache. Então, a primeira coisa que pode dar errado é que o cache pode ficar obsoleto. Então, você atualizou os dados, você tem um aplicativo que não está falando com o cache, ele vai e atualiza os dados no banco de dados e, de repente, o cache ficou com dados obsoletos e os dados obsoletos estão muito ruins. Tenho certeza, vocês sabem disso, mais do que ninguém, um banco saberia que dados obsoletos são muito ruins. Alguns dados obsoletos são bons, mas muitos dados obsoletos são muito ruins. Então, esta é a razão pela qual a maioria das pessoas quando pensam em cache, a reação do joelho é que tudo bem, vou armazenar em cache apenas dados somente leitura, que nunca mudam ou, pelo menos, durante a vida útil do meu aplicativo ou o que for , em muito tempo não vai mudar. Bem, se isso for apenas cerca de 10%, 15% de seus dados totais. Se você vai armazenar em cache apenas 10%, 15%, então você não está realmente aproveitando um cache distribuído. Você deve ser capaz de armazenar em cache os dados que mudam talvez a cada 5 segundos. Ou, ainda mais cedo do que isso. Porque, mesmo por 5-10 segundos, você pode lê-lo 10 vezes. E, quando você multiplica isso por milhões de transações que seu aplicativo está processando todos os dias, você economiza muitas viagens ao banco de dados e como ganhará escalabilidade.
Portanto, qualquer cache distribuído que não resolva isso, ignore esse desafio, que o cache não deve ficar obsoleto, deve estar sempre atualizado, vai forçá-lo a não usá-lo totalmente. Então, essa é a primeira coisa a ter em mente.
- Cache específico de aplicativo da Web
O caso de uso número dois é o aplicativo da web. E, o uso mais comum para aplicação web é sessões. Se você tem Java, ASP.NET, ASP.NET Core ou Node.js, todos desejam salvar suas sessões em um armazenamento rápido e escalável. E um cache distribuído é uma loja muito melhor do que qualquer outra coisa que esteja por aí. Seja Java ou .NET ou não Node.js. E, há outras coisas como, há a página cache de saída. Há também aplicativos da web ao vivo. No caso do .NET isso é chamado Sinal R, que você pode usar um cache distribuído como uma plataforma para compartilhar os eventos.
Mas, um aplicativo da Web, quando não é o cache de dados do aplicativo, quando o aplicativo da Web está armazenando seus dados no cache distribuído, ele tem um tipo diferente de problema a ser resolvido. Ou seja, agora, não há banco de dados que tenha uma cópia desses dados. Cache é a loja principal. E um cache sendo um armazenamento mestre significa que, se o servidor de cache ficar inativo, você perderá esses dados. O que não é aceitável, você não quer perder uma sessão de usuário só porque um servidor de cache ou um servidor web caiu. Se você deseja ter alta disponibilidade, precisa que o cache tenha os recursos da capacidade de replicar esses dados de maneira inteligente para vários servidores. Portanto, se algum servidor de cache cair, você não perderá esses dados. Então, essa é a parte importante. O cache de dados de aplicativos tem um desafio diferente. O cache específico do aplicativo da Web tem um desafio diferente.
- Pub/Sub mensagens, CQ e eventos
E, o terceiro caso de uso é que você pode usar e, isso é algo que muita gente não sabe, que é que você pode usar um cache distribuído como um Mensagens do Pub/Sub plataforma e eventos. Conversamos e vou mostrar que mesmo Microservices, eles precisam fazer Pub/Sub. Portanto, se eles usarem o cache distribuído como uma plataforma Pub/Sub Messaging além de usá-lo para armazenamento em cache de dados de aplicativos, o Pub/Sub Messaging não será um gargalo para eles.
Existem muitos outros produtos de mensagens que possuem muitos recursos de mensagens. E, um cache distribuído não corresponde a todos esses recursos, mas o que o cache distribuído faz é criar uma plataforma de mensagens na memória muito rápida para aquelas mensagens que precisam apenas ser compartilhadas dentro desse ambiente de microsserviços ou aplicativo da web. Portanto, é um ambiente muito mais simples, você não precisa manter essas mensagens por horas. Eles só precisam ser compartilhados nos próximos milissegundos, talvez. Mas há tanta atividade de transação que, sem uma arquitetura distribuída verdadeiramente na memória, a própria plataforma de mensagens se torna um gargalo. Então, agora, além do armazenamento de dados ser um gargalo, sua plataforma de mensagens também é um gargalo. Então, tenha isso em mente. E, novamente, a plataforma de mensagens tem o mesmo problema que um cache específico de uma aplicação web que é que, geralmente, o que quer que esteja sendo mantido como mensagem, não tem uma cópia de backup no banco de dados. Bem, pode ser uma versão transformada de alguns dados que já existem no banco de dados e você pode recriá-lo, mas não deseja. Então, você não quer perder esses dados, você não quer perder essas mensagens. Portanto, é por isso que um bom cache distribuído não apenas precisa ser rápido e escalável, mas também fornecer essa replicação inteligente não apenas para o cache específico da Web, mas também para o Pub/Sub Messaging.
Kubernetes e cache distribuído
Veja como temos um ambiente Kubernetes executando aplicativos da Web e microsserviços e usando um cache distribuído. Então, essa área verde é um cluster Kubernetes. E o Kubernetes tem esse conceito de cluster. Dentro de cada cluster você tem várias implementações. Portanto, cada um desses três retângulos de caixa é uma implantação. Portanto, há uma implantação de aplicativo da Web, há duas implantações de microsserviços e há uma implantação de cache distribuído e há um gateway de API para os microsserviços.
Não vou entrar em detalhes de como o Kubernetes funciona, mas basicamente, em um ambiente como esse, os microsserviços estão usando o cache distribuído tanto para o cache de dados do aplicativo quanto para o Pub/Sub Messaging. Visto que o aplicativo da Web está usando o cache distribuído para armazenamento em cache de dados do aplicativo e sessões da Web.
A maioria dos aplicativos da web não tem um Mensagens do Pub/Sub porque o Pub/Sub Messaging geralmente requer algum tipo de processo de servidor estável para se comunicar. Mas de qualquer forma, alguns deles podem, mas a maioria deles não. Mas, a mesma infraestrutura de cache que você tem para o cache de dados do aplicativo pode ser usada para sessões da Web e também pode ser usada para Pub/Sub Messaging e, neste caso, como você pode ver, são instâncias do Docker como Pods . Podem ser caixas Windows ou Linux, você sabe, isso depende de sua preferência de qual caminho você deseja seguir. A maioria dos bancos atualmente está migrando tudo para o Linux e até .NET Core porque, ele suporta Linux. Agora você pode ter aplicativos .NET e Java e, claro, Node.js no Linux.
Portanto, é assim que um ambiente Kubernetes se parece tanto para serviços quanto para aplicativos da Web e também para hospedar um cache distribuído. Uma coisa que eu queria destacar aqui é que, um cache distribuído para viver no Kubernetes tem que ser compatível com o Kubernetes. Ele deve ter implementado o que eles chamam de Operador Kubernetes. NCache tem. E assim, qualquer que seja o cache distribuído, verifique se ele é compatível com o Kubernetes.
Visão geral do cache de dados do aplicativo (API)
Então, este é meu único slide de codificação. Eu não vou entrar mais em codificação do que isso. A ideia disso é que, tudo bem, o Application Data Caching é o principal caso de uso para o cache distribuído, que todo aplicativo que você está desenvolvendo deve usar. Seja um aplicativo da Web, serviços da Web ou microsserviços. E você pode ver que esta é uma API muito simples que um cache distribuído possui.
- Conexão de cache
ICache cache = CacheManager.GetCache(“myDistributedCache”); cache.Dispose(); - Buscando dados
Employee employee = cache.Get<Employee>("Employee:1000"); bool isPresent = cache.Contains("Employee:1000"); - Gravando dados
cache.Add("Employee:1000", employee); cache.AddAsync("Employee:1000", employee); cache.Insert("Employee:1000", employee); cache.InsertAsync("Employee:1000", employee); Employee employee = (Employee) cache.Remove("Employee:1000"); cache.RemoveAsync("Employee:1000");
Você tem um identificador de cache, você faz cache.Get, cache.Contains. Há uma chave que geralmente é uma string e, você recebe de volta um valor e um valor pode ser um objeto, pode ser um objeto .NET, pode ser um objeto Java, pode ser um documento JSON. O Node.js obviamente funciona em JSON. Mas você pode até ter aplicativos .NET e Java armazenando seus objetos ou dados como JSON. E, na verdade, isso permite que você use isso como uma plataforma de compartilhamento de dados, porque você tem um aplicativo Java que armazena, digamos, um objeto cliente que era um objeto cliente Java. Quando é armazenado no cache distribuído, digamos, como NCache ele é transformado em um documento JSON e, em seguida, quando um aplicativo Node.js ou .NET ou .NET Core aplicativo quer buscá-lo eles obtê-lo ... Digamos, .NET Core o aplicativo o obterá como um objeto de cliente .NET ou um documento JSON e o Node.js provavelmente obterá um documento JSON de qualquer maneira. Então, a simplicidade está lá, Obter, Adicionar, Inserir, Remover o mais simples possível. Portanto, a curva de aprendizado é muito rápida no uso de um cache distribuído.
Recursos do cache de dados de aplicativos
Vou passar rapidamente por algumas das principais áreas do App Data Caching porque, se você for usar o cache distribuído, o maior caso de uso é o App Data Caching. E, o que é que você precisa estar ciente? O número um, como eu mencionei, existem duas cópias dos dados, uma no banco de dados e outra no cache, então como você mantém o cache atualizado?
- Expirações (absolutas e deslizantes)
O número um é um recurso chamado Expiration que quase todo cache distribuído tem como recurso e, geralmente, é o Expiração Absoluta. Alguns chamam de TTL ou expirações de tempo de vida. A outra expiração é chamada Expiração deslizante que não é para o App Data Caching, é mais para o tipo de sessão de uma situação em que você deseja expirar o objeto se ninguém o usar por um determinado período de tempo. Mas, a Expiração Absoluta, você está dizendo ao cache que eu sei que esses dados que estou armazenando em cache não serão alterados nos próximos cinco minutos ou nas próximas cinco horas ou 24 horas. Qualquer que seja a natureza dos dados, você pode especificar isso. E, ao final desse tempo, o cache expirará automaticamente. Assim, o aplicativo pode apenas adicioná-lo e seguir em frente. O aplicativo não precisa se preocupar em acompanhar todos esses dados. Então, esse é o mínimo que todo cache deve ter e a maioria deles tem. Mas o problema ou a limitação das expirações é que você está apenas fazendo um palpite. Em alguns casos, tudo bem porque os dados não estão mudando com tanta frequência, mas, como mencionei anteriormente, o benefício real está no armazenamento em cache de dados transacionais. Portanto, em dados transacionais, você deseja ser mais preciso.
- Sincronizar Cache com Banco de Dados
Outro recurso que um cache distribuído deve ter é que ele deve estar ciente de seu banco de dados até certo ponto, para que ele possa se sincronizar com os dados armazenados em cache, se esses dados, os dados correspondentes no banco de dados forem alterados, então o cache deve remover automaticamente esse item do cache, para que da próxima vez que seu aplicativo o desejar, ele não o encontre no cache e seja forçado a obtê-lo do banco de dados ou o cache deve recarregar uma cópia do isto. E, recarregar só é possível através de outro recurso que vou falar, chama-se leitura e escrita. Mas, se você puder sincronizar o cache com o banco de dados.
Portanto, existem duas maneiras de sincronizar. Um é baseado em eventos. Portanto, a maioria dos bancos de dados hoje em dia agora possui os eventos de alteração de dados. SQL Server tem, Oracle tem, MongoDB, Cosmos DB todos eles têm. Cosmos DB chama isso de feed de mudança, MongoDB chama de fluxo de mudança e SQL Server chama de dependência de SQL e Oracle, acho que chama de notificações de banco de dados ou algo assim.
Portanto, se seu cache distribuído está aproveitando esses recursos no banco de dados, ele pode criar algum tipo de relacionamento entre seus itens em cache e os conjuntos de registros do banco de dados. Portanto, quando esses dados forem alterados, o banco de dados notificará o cache distribuído que ok esses dados foram alterados, por favor, cuide de sua própria cópia deles. Portanto, seu cache pode removê-lo ou recarregar do banco de dados e, se o banco de dados não tiver eventos como um recurso, você poderá usar o polling como outro mecanismo.
- Lidar com Dados Relacionais
A terceira coisa que você deseja fazer é que, se estiver armazenando dados relacionais em cache, há alguns problemas de integridade de dados relacionados a relacionamentos, um para muitos, um para um. Então, se você pode dizer ao cache que este item, eu tenho esse objeto cliente e eu tenho esse objeto pedido, eles estão relacionados. Portanto, se o aplicativo remover o objeto cliente, o cache removerá automaticamente todos os pedidos. Então, dessa forma, não há, você sabe, o que você chama de referências pendentes no cache. São coisas assim, se você puder fazer isso, seu cache novamente estará sempre fresco.
- Consultas SQL
Portanto, com esses recursos, se seu cache tiver pelo menos os dois primeiros recursos, você terá confiança para colocar todos os tipos de dados no cache. E, uma vez que você tenha essa confiança, você começará a colocar muitos dados no cache. E, uma vez que você coloca muitos dados no cache, outro problema surge, que agora apenas encontrar dados com base em chaves não é suficiente. Portanto, você deseja encontrar dados da mesma forma que pode encontrá-los no banco de dados, que são as consultas SQL. Para .NET, .NET Core há também um LINQ. Então, se você pode pesquisar dados com base em atributos de objetos. Você pode dizer algo como me dê todos os objetos do cliente, onde a cidade é São Francisco. Então está agindo mais como um banco de dados. Há também dados de referência que você pode pesquisar. Há muitos dados de pesquisa que você pode pesquisar. Então, se você pode pesquisar os dados, agora o cache fica mais amigável. Você se sente mais confiante em armazenar em cache cada vez mais dados porque pode encontrá-los. Porque, se você não puder fazer consultas SQL, seu aplicativo de repente se tornará muito complicado. Você tem que manter o controle de cada chave que você armazenou.
- Grupos, Tags, Tags Nomeadas
O outro aspecto está novamente na mesma relação: você deseja agrupar dados relacionados para poder buscá-los de uma só vez. Portanto, diferentes caches distribuídos fornecem esse conceito de grupos e tags e tags de nome que você pode obter tudo o que corresponde a essa tag. Ou exclua tudo do cache ou busque-o no cache. Portanto, pela capacidade de encontrar dados rapidamente, além das chaves, torna-se muito importante quando você começa a armazenar em cache mais e mais dados.
- Leitura e escrita
Este é o recurso sobre o qual eu estava falando, o recurso de leitura e gravação. A importância desse recurso é que, digamos... Deixe-me primeiro explicar o que é isso. Então, quando você tem um cache distribuído, se você não tem esse recurso, então seu aplicativo vai e lê todos os dados, coloca no cache e também atualiza o banco de dados com ele. Mas, à medida que você torna o cache cada vez mais relevante para vários aplicativos, agora o cache deve... se o cache pode se tornar mais autossuficiente, ele pode cuidar de si mesmo, então isso simplifica os aplicativos. Então você tem vários aplicativos que eles estão apenas tratando esse cache como uma representação na memória de quaisquer fontes de dados mestres. Você sabe, como eles poderiam, como eu disse mainframe, relacional ou NoSQL. Então, eles vão para esse cache distribuído na memória como um armazenamento de valor de chave, que é muito direto, muito simples, está tudo na memória, então é super rápido e o cache distribuído é capaz de ler os dados, se não estiver disponível para leitura -through é algo que é o seu código que é registrado no cache distribuído. Assim, o cache distribuído chama seu código, vai para o banco de dados e lê o item correspondente. Então, digamos que você faça um cache. Ao pegar uma determinada chave e esse item não estava no cache, o cache chamará o read-through para ir buscá-lo no banco de dados.
- write-behind
Da mesma forma, você também pode usar o cache para atualizar os dados não apenas no cache, mas também ter o cache atualizado no banco de dados. E o write-behind é uma versão mais avançada dele, onde a atualização do cache acontece de forma síncrona, mas a atualização do banco de dados acontece de forma assíncrona.
- Carregador/Atualizador de Cache
O carregador e atualizador de cache é novamente outra maneira de aquecer o cache. Quando você inicia o cache, você o preenche com todos os dados que você sabe que sempre terá. Dessa forma, você não precisa chamar a leitura toda vez. Então, uma vez que você carregou esse cache com, digamos, milhões de objetos, então o cache refresher é outro recurso que pode atualizar periodicamente certos subconjuntos desses dados, com base em quaisquer regras de negócios que você especificar. Esses podem ser baseados em eventos, podem ser baseados em tempo, o que quer que sua lógica de negócios diga. Você pode dizer, ok, vá buscar uma cópia mais recente dos dados da fonte de dados mestre.
Agora, em muitas dessas situações, você terá esse cenário em que, se os dados não forem muito sensíveis aos negócios, não há problema em ter uma cópia obsoleta deles, se não for muito tarde ou muito atrasada. Mas tendo esses três recursos, leitura, gravação e carregador/atualizador de cache, de repente agora você tem um cache que é muito inteligente. Ele pode entrar e se carregar de várias fontes de dados e se tornar disponível não apenas no aplicativo, como já mencionei, mas em vários aplicativos.
Plataforma de compartilhamento de dados
Portanto, há vários aplicativos, como mencionei anteriormente, é o benefício colateral. O benefício marginal de usar um cache distribuído na memória. Então, o que isso significa? O que isso significa é que agora o cache distribuído se torna uma infraestrutura comum em vários aplicativos. Então, quando as aplicações precisam compartilhar dados entre si, ao invés de ter uma chamada para a outra ou ir para seus bancos de dados, basta colocá-la em um key value store bem simples de entender, que fica na memória, super rápido, altamente escalável. E, porque todos os recursos que mencionei, o read-through, write-through, cache loader, refresher, todas as outras pesquisas SQL, todos esses fazem isso como um banco de dados, mas não é uma fonte de dados mestre.
Portanto, na plataforma de compartilhamento de dados, o cache não é o mestre. É apenas uma cópia de outros masters, mas destina-se apenas para fins de compartilhamento. E sei que muitas empresas hoje em dia estão se concentrando muito na consolidação de vários aplicativos para ter uma visão comum, uma funcionalidade comum.
Eu sei que muitos dos bancos com os quais conversamos querem que a jornada do cliente seja compreendida em vários aplicativos. Então, como esses aplicativos se comunicam? Qual é o ponto central onde eles podem compartilhar dados entre si? Tem que ser algo na memória. Se não estiver na memória, será mais um gargalo. E a beleza do in-memory é que você sempre pode reiniciá-lo e não há perda de dados. Porque ele apenas recarrega os dados das fontes de dados mestres. Mas, ele se tornará disponível. E, por ser redundante, replica em vários servidores. Você sabe, a probabilidade de perder totalmente um cache distribuído é muito, muito baixa. Além disso, falarei sobre alguns dos outros recursos em que você pode ter o mesmo cache ativo em várias regiões, vários datacenters, um em São Francisco, um em Nova York e assim por diante. E, dessa forma, se você tiver alguma situação de recuperação de desastres, eu sei que vi no noticiário que alguns anos atrás vocês enfrentaram um desligamento bem grande. Bem, situações como essa exigem que você tenha uma verdadeira recuperação de desastres. Portanto, tudo precisa ser replicado em várias regiões. E, quando você usa um cache distribuído para fins de compartilhamento de dados, esse cache distribuído também deve ser replicado por vários motivos. Mas, este é um benefício muito importante para grandes corporações, especialmente como Wells Fargo, para reunir vários aplicativos. E, novamente, você pode ter vários desses porque, você é uma empresa tão grande, pode não ter um mestre para toda a empresa ou pode. Ou você pode ter vários deles em certas partes da sua empresa para compartilhar dados.
Arquitetura de cache distribuído
Agora que falei sobre todas as maneiras de usar um cache distribuído, o que você deve esperar de um bom cache distribuído em termos de arquitetura?
High Availability
O número um é a alta disponibilidade. Como um cache distribuído está sendo usado em ambientes de produção ao vivo, se ele não está oferecendo a você realmente alta disponibilidade, você precisa ser muito cético em relação a ele e alta disponibilidade significa que o cluster que o cache distribuído está criando precisa ter um peer- arquitetura peer-to-peer. Se não tiver uma arquitetura peer-to-peer, se tiver uma coisa de mestre-escravo, então, uma vez que o mestre morre, você sabe, os escravos se tornam somente leitura ou inoperáveis. Portanto, a capacidade de adicionar ou remover servidor, qualquer servidor em tempo de execução, é muito crítica.
Escalabilidade Linear
O número dois é a escalabilidade linear e isso vem com o particionamento dos dados. Vou apenas para o próximo slide e falar sobre isso. Portanto, o particionamento ocorre de duas maneiras, uma apenas particionando sem replicação e a segunda particionando com replicação. Então, um cache distribuído, como mencionei, fornece redundância e uma replicação inteligente.
O que é essa replicação inteligente? A replicação inteligente significa que todos os dados são... os dados são particionados e cada partição é copiada em um servidor diferente e tudo isso é dinâmico. Então, é autocura. Assim, quando você adiciona um novo servidor, uma nova partição é criada e novas réplicas são criadas e os dados são balanceados automaticamente.
Então, aqui está um exemplo. Digamos que você começou com um cluster de cache de dois servidores e deseja adicionar um terceiro porque sua carga de transações está crescendo. Assim que você adiciona um terceiro servidor, ele cria automaticamente uma terceira partição. Agora você tem três partições. Portanto, as réplicas também precisam reajustá-lo. Tudo isso acontece de forma dinâmica ou automática.
E, da mesma forma, digamos, você quer ou um servidor caiu por algum motivo. Digamos que o servidor 3 caiu, a partição 3 está fora do ar. Assim que a partição 3 estiver inativa, a réplica 3 se tornará ativa. E agora você tem uma anomalia onde você tem dois servidores e três partições. Então, agora ele precisa se mesclar automaticamente de volta em duas partições e duas réplicas. Tudo isso deve ser feito automaticamente, sem qualquer intervenção humana. Se requer intervenção humana, então não é realmente alto altamente disponível. NoSQL databases, por serem bancos de dados que eles têm que lidar com armazenamento persistente de muitos dados, eles não fornecem esse reparticionamento dinâmico. E, está tudo bem para um NoSQL database. Mas, não é bom para uma loja na memória. O armazenamento na memória precisa ser muito mais rápido, muito mais ágil na movimentação para cima e para baixo em termos de número de servidores.
Replicação de WAN
Aqui está a alta disponibilidade em que você tem vários sites. Então, se você tem um cache distribuído no site 1, digamos em San Francisco e você quer ter o site 2, você pode ter um ativo-passivo ou um ativo-ativo. Costumávamos ver mais ativo-passivo, agora quase todo mundo está migrando para ativo-ativo por causa da nuvem. É muito mais fácil fazer a infraestrutura funcionar. Então, as pessoas só têm sites ativos-ativos.
E no desafio ativo-ativo é mais porque ambos os lados podem estar atualizando os mesmos dados, então deve haver algum recurso de resolução de conflitos embutido no cache distribuído que NCache tem, mas você precisa estar ciente de que, para obter alta disponibilidade real, você precisa ir além de um datacenter e entrar em vários datacenters.
Em muitas situações, dois datacenters podem não ser suficientes, portanto, se você tiver três ou mais datacenters, ainda precisará ter o mesmo recurso de replicação ativo-ativo. Portanto, se qualquer data center cair, os outros dois data centers devem ser capazes de assumir a carga e, em seguida, você deve ser capaz de trazer esse data center de volta e juntá-lo novamente, e seus usuários não devem ver nenhuma interrupção.
Se você pode atingir esse objetivo com um cache distribuído, tudo dinamicamente, sem nenhum humano... novamente, é claro que trazer um data center de volta precisa de intervenção humana. Mas, não deve haver intervenção humana quando um data center cair, para que a alta disponibilidade seja realmente alta. Se for até cinco minutos para baixo, não é aceitável.
Esse é o fim da minha conversa. Tentei mantê-lo o mais rápido que pude, apenas para que tenhamos algum tempo restante. Vou apenas dar-lhe alguns pensamentos resumidos. Acho que a principal coisa que eu queria transmitir é que, para cada aplicativo que você está desenvolvendo, eu recomendo fortemente que você tenha um cache distribuído na memória, para esses três casos de uso sobre os quais falei. E, idealmente, você também deve usá-lo para compartilhamento de dados em vários aplicativos. E, de qualquer forma, mesmo dentro do mesmo aplicativo, você deve tentar ter vários sites para garantir que você tenha a recuperação de desastres nisso.
E, eu estou falando sobre isso a partir de 15 anos de experiência. Nós temos feito isso. NCache está no mercado há mais de 15 anos e trabalhamos com vários bancos. Tradicionalmente, somos uma loja .NET, mas NCache agora suporta totalmente .NET e Java e Node.js. Ambos, código do lado do cliente e do lado do servidor para .NET e Java e Node.js sendo apenas a API do cliente. Esse é o fim da minha conversa.
Obrigado, Iqbal. Não posso enfatizar o suficiente que, à medida que nós da Wells Fargo seguimos o caminho da modernização, o quanto essa apresentação foi oportuna e relevante. Então, obrigado por isso. Equipe, vou lembrá-lo se você tiver alguma dúvida, vá em frente e pergunte no seu chat. Temos uma série de perguntas Iqbal. Muita equipe de perguntas está por perto, essa apresentação e o vídeo serão disponibilizados? A resposta é sim. Após a apresentação, isso será disponibilizado para você sob demanda. Enviaremos o link para você. Então, Iqbal, aqui estão algumas das perguntas que surgiram.
Como os caches distribuídos lidam com dados confidenciais? Tipo, criptografia transparente é uma questão.
Sim, acho que não tive tempo a não ser para entrar nisso, mas isso também é um aspecto muito importante. Um produto como NCache, por exemplo, fornece segurança em vários níveis. Existe a Autenticação, Autorização, Segurança. Existe a Criptografia. Então, vários algoritmos de criptografia. Alguns 128 bits, alguns criptografia de 256 bits. Existe o TLS, segurança de transporte. Então, o cache de um banco como o Wells Fargo tem que dar segurança e, por isso, porque trabalhamos com bancos. Esse é o recurso que temos há muito tempo. Assim, os dados podem ser criptografados. E, novamente, tudo isso é automático. Não há necessidade de programação para fazer isso. São apenas configurações. Mas, um cache distribuído deve abordar a segurança por meio desses diferentes recursos.
A próxima pergunta é: qual é a diferença em ter o banco de dados como objetos de cache e memória Oracle e ter outro cache de memória na frente do Oracle? Basicamente, posso obter o mesmo resultado alocando mais memória ao oracle?
Eu acho que a palavra-chave é 'distribuído'. Qualquer coisa que não seja distribuída, você pode ser rápido, mas não escalável. É por isso que meu primeiro slide foi a definição da palavra escalabilidade. Você pode ir de 1 caixa para 10 caixas para 50 caixas como uma implantação? Alguns de nossos clientes possuem um farm de servidores de aplicativos de 150 ou mais servidores de aplicativos. E, você sabe, também trabalhamos com... a propósito, o State Street Bank também é outro cliente nosso, e com isso, não há absolutamente nenhuma maneira de qualquer cache na memória por um único servidor de banco de dados poder lidar com isso. Sim, esse é um recurso muito importante para tornar o Oracle e o SQL Server e outros rápidos, mas eles não podem ser escaláveis. A escalabilidade só pode ser alcançada através da distribuição.
como funciona NCache desempenho em comparação com Redis, Coerência e outros produtos do mercado. E, então, a outra parte da pergunta é: você tem algum plano em seu roteiro para oferecer suporte a linguagens de programação adicionais, como Scala ou Python? Na verdade, deixe-me responder à segunda pergunta primeiro. Sim, vamos apoiar muito Scala e Python. Na verdade, vamos fazer isso este ano. Temos suportado Java nos últimos quase 10 anos. A maioria dos clientes que usam NCache, se for uma grande corporação, eles o usam para Java e .NET. Mesmo assim, eles podem comprá-lo de uma perspectiva .NET. Então, esse é o primeiro.
A segunda pergunta era: como NCache desempenho comparar com Redis e outros? Quero dizer, eles são todos rápidos. Não vou fazer ninguém parecer mal e acho que vocês deveriam fazer sua própria comparação, mas todos são rápidos. Eu acho que a única coisa que eu gostaria de alertar é que alguns dos jogadores, tipo, você sabe, dão a impressão errada de fazer os benchmarks. Por exemplo, os benchmarks que damos, eles incluem ida e volta completa. Portanto, se você estiver fazendo um cache.Get ou cache.Insert, a menos que essa operação de inserção retorne ao aplicativo, essa operação não será concluída. Mas, alguns dos outros fornecedores, eles realmente mostrariam a você um benchmark muito maior do que o nosso, mas eles farão o que chamam de fogo e esquecerão. Então, se eu for apenas enviar e não me preocupar com isso, obviamente posso fazer muito mais. E, de fato, no lado Java, Hazelcast e Redis Os laboratórios estão indo atrás um do outro exatamente no mesmo ponto. Então, vou deixar para isso.
Você trabalhou com outros bancos e outras coisas, outros problemas de conformidade em torno do uso de dados PCI de volta para os dados confidenciais no espaço de cache. Você encontrou algum problema de conformidade regulatória lá?
Na verdade não. Quero dizer, em primeiro lugar, o fato de fornecermos todos esses diferentes recursos de segurança de criptografia, tanto no nível dos dados. Porque você pode criptografar dados antes de armazená-los em cache e também no nível de transporte. Também temos autenticação e autorização na extremidade do servidor e esta é a extremidade do servidor de cache. E acho que isso é suficiente para… e além disso, um cache é executado em um datacenter seguro. Um cache não é algo acessível a qualquer entidade externa. Então, quando você combina tudo isso com o fato de que o cache é executado dentro, não tivemos nenhum e, você sabe, tivemos... quero dizer, por exemplo, o Citi Group e o Bank of America e o Barclays têm usado NCache há mais de uma década e não teve problemas.
Como funcionará com bancos de dados de mainframe?
Eu acho que um mainframe é algo que você... Digamos, que muito provavelmente vocês serão... você provavelmente tem web services hoje e provavelmente vai desenvolver alguns Microservices para permitir que aplicativos acessem o mainframe. O mainframe é outro caso em que buscar dados do mainframe é muito caro. Tanto em termos de velocidade quanto, às vezes, também, se o seu mainframe estiver hospedado fora, você pode até ter que pagar por transação ou por viagem. Portanto, se você puder armazenar em cache mais desses dados em sua camada Kubernetes ou Microservices, como eu disse, e fazer menos viagens ao mainframe, você não apenas ganhará desempenho, mas provavelmente também economizará muito dinheiro.
Como a consistência e a disponibilidade dos dados no cache distribuído na memória são garantidas quando os nós são adicionados e removidos?
Então, pelo menos eu posso falar sobre NCache que NCache garante que quando você adiciona ou remove nós, quaisquer atualizações que estão sendo feitas, quaisquer alterações que estão sendo feitas são concluídas com o fato de que estamos fazendo a transferência de estado, digamos, estamos movendo o particionamento e outras coisas, NCache está ciente de que precisa garantir que todas essas atualizações sejam aplicadas corretamente, certificando-se de que o nó está sendo adicionado e a transferência de estado, o que chamamos de transferência de estado, que é o balanceamento de dados para mover dados de uma partição para outra que também continua acontecendo. Então, NCache garante isso.
Ao ter Microsserviços distribuídos com seus próprios bancos de dados, como vi na foto, como eles podem proporcionar uma experiência omnicanal ao cliente?
Então, a parte do banco de dados distribuído, acho que o júri está decidido sobre como esses bancos de dados serão distribuídos. Como esses bancos de dados serão particionados. Porque, como eu disse na minha palestra, pelo menos em teoria todo micro serviço pode ter seu próprio banco de dados lógico, mesmo que fisicamente eles possam residir nos mesmos servidores de banco de dados, porque, quando você estiver implantando coisas, você não terá 100 servidores de banco de dados diferentes, cada um para cada micro serviço. Você terá alguns servidores de banco de dados consolidados. O fato de você ter separação provavelmente lhe dá um pouco mais de flexibilidade, assim como NoSQL mas o júri ainda não sabe o quanto você pode realmente se safar dessa limitação de um banco de dados relacional. Minha previsão é que você acabará com os mesmos servidores de banco de dados relacionais. Você pode ou não ter a separação lógica. Você pode ter esquemas separados ou pode ter o mesmo esquema, você está apenas conversando com tabelas diferentes, mas os servidores de banco de dados ainda serão os mesmos. Então, é o mesmo problema que você está enfrentando até mesmo em serviços da web, eles vão abordar em microsserviços. Acho que com o tempo acabando. Eu não posso agradecer o suficiente. Isso tem sido muito interessante. As perguntas continuam a surgir, mas claramente, não podemos chegar a todas elas. Então, com isso eu vou devolvê-lo de volta para você.