A palavra "microsserviços" existe há alguns anos. A tecnologia está se desenvolvendo ativamente, as pessoas falam sobre ela em conferências online e nós as escrevemos todos os dias. Era uma vez, uma nova abordagem já se tornou uma rotina. Mas, como arquiteto Java, estou interessado em saber como o código era antes, como ele mudou, quais métodos de execução são populares agora e serão usados em 2021: assincronia, contêineres, FaaS.
Foi assim que este post nasceu em duas partes, que preparei para o Habr com base em meus artigos no blog BellSoft e na mesa redonda Joker 2020, onde discutimos o futuro do Java. A melhoria real do ecossistema para back-ends hoje não pode existir sem a compreensão de como criar microsserviços: escrever do zero ou cortar monólitos com um bisturi? Proponho na primeira parte falar sobre sua essência, e na segunda - decompor o contêiner de microsserviços em camadas e observar a contribuição de cada camada.
A principal vantagem está na estrutura
A grande maioria dos materiais na arquitetura de microsserviço compara-a aos monólitos em termos de estrutura. Como os componentes funcionam como um todo ou isoladamente. Os microsserviços são independentes uns dos outros e podem trocar dados pela rede por meio de protocolos arbitrários, como a API REST. O que isso nos dá? No mínimo, a liberdade de escolher qualquer ferramenta, sem olhar para o ESB, as restrições de esquema e as sutilezas de compatibilidade. A virtualização e a conteinerização também estão evoluindo, e agora pequenos contêineres com Alpine Linux permitem que você execute muitos componentes ao mesmo tempo em hardware anteriormente dedicado.
Tomemos um serviço simples, como reservar uma passagem ou recarregar uma conta. Mesmo antes do advento dos microsserviços, a abordagem CRUD foi usada para gerenciar o ciclo de vida de um objeto de dados em tais sistemas. Mas todas as funcionalidades que fornecem operações CRUD para alguma entidade podem ser facilmente isoladas. Então você pode lidar separadamente com escalonamento, controle de acesso e interação em geral, por exemplo, por meio de REST.
Tudo parece estar bem, qual é o truque?
Problemas e soluções
Partes diferentes de um aplicativo monolítico são executadas na memória compartilhada e todas as solicitações são enviadas para o mesmo servidor físico. Os microsserviços se comunicam por meio de protocolos, e isso dá origem, por exemplo:
dificuldade em gerenciar tráfego de rede e latência;
falhas de solicitações e outros erros;
a necessidade de serializar dados e criptografar conexões.
, API Kafka/Redis/RabbitMQ , . Kafka DevOps.
, , . . , , — . - .
:
(Kafka, Kinesis);
, service mesh (Istio, OSM);
.
— :
, , :
, . streaming platform (, Kafka) , .
, . , . , , .
Service mesh («c ») . , , Sidecar.
, JVM, , .
. , , Docker- .
-, , . , .
- . . , — SOA.
. . , — . , , REST.
Java? , . Java EE 20 . : , XML javadoc ; ; Java 5. . Java EE.
, Java EE (, JNDI), , , . Web 1.0 Web 2.0, . .
Container dependency injection
« ». , . « » — . . , : trailing lambdas Kotlin Ktor; data- , Java 14 record- ( Lombok).
. , /. , , , , . IDE, , . — .
Contexts and Dependency Injection (CDI). CDI Java EE JSR 299/365 Weld, WildFly. — (Inversion of Control, IoC).
: , , ( Spring Data) HTML. . — , . , Convention over Configuration ( « »), IoC- , BeanFactory Spring. .
Como prometi na introdução, este post se tornou uma pequena excursão na história da arquitetura de microsserviços - afinal, sem ela, em lugar nenhum. Estamos trabalhando com uma tecnologia excelente que já tem mais de 20 anos, mas ainda parece moderna. Isso ocorre porque os métodos estão em demanda e ao vivo, e não se transformam em legado.
Na segunda parte, analisarei as camadas do contêiner de microsserviço em detalhes, explicarei o que a escolha correta de tempo de execução afeta e explicarei como reduzir o consumo de recursos ao mínimo.