Principais conclusões
1. Microsserviços: Serviços pequenos e autônomos que trabalham juntos
Microsserviços são serviços pequenos e autônomos que trabalham juntos.
Fundamento dos microsserviços. A arquitetura de microsserviços é construída com base no princípio de desenvolver software como um conjunto de pequenos serviços independentes. Cada serviço é focado em fazer uma coisa bem, executa em seu próprio processo e se comunica por meio de mecanismos leves como APIs HTTP/REST. Essa abordagem permite maior flexibilidade, escalabilidade e manutenção em comparação com arquiteturas monolíticas.
Benefícios e desafios. As principais vantagens dos microsserviços incluem:
- Melhoria na modularidade
- Facilidade na escalabilidade de componentes individuais
- Diversidade tecnológica
- Melhor isolamento de falhas
- Ciclos de implantação mais rápidos
No entanto, os microsserviços também introduzem desafios como:
- Aumento da complexidade operacional
- Preocupações com sistemas distribuídos (por exemplo, latência de rede, tolerância a falhas)
- Consistência de dados entre serviços
2. Arquitetura evolutiva: Adaptando-se a requisitos em mudança
O papel do arquiteto é olhar para o quadro geral e entender esse equilíbrio.
Abraçando a mudança. A arquitetura evolutiva enfatiza a necessidade de sistemas se adaptarem a requisitos em mudança ao longo do tempo. Essa abordagem reconhece que é impossível prever todas as necessidades futuras, então foca em criar uma base flexível que possa evoluir.
Princípios chave:
- Mudança incremental: Fazer pequenas atualizações frequentes em vez de grandes e infrequentes
- Mudança guiada: Usar princípios e práticas para guiar decisões arquitetônicas
- Múltiplas arquiteturas: Reconhecer que diferentes partes do sistema podem evoluir em ritmos diferentes
Arquitetos nesse modelo atuam mais como planejadores urbanos, estabelecendo diretrizes e restrições, em vez de ditar cada detalhe. Isso permite que as equipes tomem decisões locais enquanto garantem a coesão geral do sistema.
3. Modelagem de serviços: Definindo limites e contextos
Focamos nossos limites de serviço em limites de negócios, tornando óbvio onde o código reside para uma determinada funcionalidade.
Design orientado ao domínio. Modelar serviços de forma eficaz requer um entendimento profundo do domínio de negócios. O design orientado ao domínio (DDD) fornece conceitos valiosos para definir limites de serviço:
- Contextos delimitados: Áreas do domínio com limites claros
- Linguagem ubíqua: Uma linguagem comum compartilhada por desenvolvedores e especialistas do domínio
- Agregados: Conjuntos de objetos de domínio tratados como uma unidade
Identificando limites de serviço:
- Alinhar com capacidades de negócios
- Encapsular dados e comportamento
- Minimizar dependências entre serviços
- Considerar a estrutura da equipe e padrões de comunicação
Limites bem definidos levam a serviços mais coesos e acoplamento mais frouxo entre eles, facilitando o desenvolvimento e implantação independentes.
4. Estratégias de integração: Escolhendo a abordagem certa para comunicação
Seja conservador no que você faz, seja liberal no que aceita dos outros.
Importância da integração. A integração eficaz é crucial para que os microsserviços funcionem juntos sem problemas. A escolha da tecnologia de integração impacta significativamente a flexibilidade, desempenho e manutenção do sistema.
Padrões chave de integração:
- Comunicação síncrona: REST, gRPC
- Comunicação assíncrona: Filas de mensagens, streaming de eventos
- Gateways de API: Para roteamento e composição de solicitações
- Malha de serviços: Para lidar com comunicação entre serviços
Melhores práticas:
- Use protocolos agnósticos de tecnologia (por exemplo, HTTP)
- Implemente leitores tolerantes para lidar com mudanças de forma graciosa
- Projete para falhas com disjuntores e compartimentos
- Considere arquiteturas orientadas a eventos para acoplamento frouxo
A estratégia de integração certa depende do seu caso de uso específico, requisitos de desempenho e expertise da equipe.
5. Dividindo o monólito: Transição para microsserviços
Pense no nosso monólito como um bloco de mármore. Poderíamos explodir tudo, mas isso raramente termina bem. Faz muito mais sentido apenas ir esculpindo-o incrementalmente.
Abordagem incremental. A transição de uma arquitetura monolítica para microsserviços é melhor feita gradualmente. Isso permite que as equipes aprendam e se adaptem enquanto minimizam riscos.
Passos para dividir um monólito:
- Identificar costuras no código existente
- Extrair contextos delimitados em módulos separados
- Refatorar estruturas de dados e bancos de dados compartilhados
- Criar APIs para comunicação entre módulos
- Extrair módulos em serviços separados
- Implementar novos recursos como microsserviços
Desafios a considerar:
- Dependências de dados entre serviços
- Integridade transacional entre limites de serviço
- Impacto de desempenho da comunicação de rede
- Complexidade operacional de gerenciar múltiplos serviços
Comece com as extrações mais fáceis e menos arriscadas para ganhar confiança e experiência antes de enfrentar partes mais complexas do sistema.
6. Técnicas de implantação: Garantindo confiabilidade e escalabilidade
Se fazer algo é certo, mas difícil, devemos nos esforçar para tornar as coisas mais fáceis.
Implantação automatizada. Implantação confiável e escalável é crítica para o sucesso dos microsserviços. Práticas de Integração Contínua e Entrega Contínua (CI/CD) são essenciais para gerenciar a complexidade aumentada de implantação.
Técnicas chave de implantação:
- Infraestrutura como Código (IaC)
- Containerização (por exemplo, Docker)
- Plataformas de orquestração (por exemplo, Kubernetes)
- Implantações azul-verde
- Lançamentos canário
Considerações de implantação:
- Descoberta de serviços e gerenciamento de configuração
- Monitoramento e registro
- Segurança e controle de acesso
- Migrações de banco de dados e consistência de dados
Invista em ferramentas e automação para tornar as implantações mais fáceis, rápidas e confiáveis. Isso permite que as equipes implantem frequentemente com confiança, realizando todos os benefícios da arquitetura de microsserviços.
7. Testando microsserviços: Mantendo a qualidade em um sistema distribuído
Quanto mais partes móveis, mais frágeis nossos testes podem ser, e menos determinísticos eles são.
Estratégia abrangente de testes. Testar microsserviços requer uma abordagem em várias camadas para garantir tanto a qualidade individual do serviço quanto o comportamento geral do sistema.
Pirâmide de testes para microsserviços:
- Testes unitários: Testes rápidos e focados para componentes individuais
- Testes de integração: Verificar interações entre serviços
- Testes de contrato: Garantir que os serviços atendam às interfaces acordadas
- Testes de ponta a ponta: Validar o comportamento de todo o sistema
Desafios de teste:
- Complexidade aumentada devido à natureza distribuída
- Gerenciamento de dados de teste entre serviços
- Simulação de ambientes semelhantes à produção
- Manipulação de interações assíncronas
Enfatize ciclos de feedback rápidos com testes unitários e de integração, enquanto usa menos testes de ponta a ponta, cuidadosamente escolhidos, para validar caminhos críticos. Considere usar contratos orientados pelo consumidor para gerenciar dependências de serviços de forma eficaz.
8. Monitoramento e segurança: Mantendo microsserviços saudáveis e protegidos
Um bom registro, e especificamente a capacidade de agregar logs de múltiplos sistemas, não é sobre prevenção, mas pode ajudar a detectar e se recuperar de coisas ruins que acontecem.
Abordagem holística. Monitoramento e segurança eficazes são cruciais para manter um ecossistema de microsserviços saudável. Esses aspectos se tornam mais desafiadores e importantes em sistemas distribuídos.
Melhores práticas de monitoramento:
- Registro centralizado e agregação de logs
- Rastreamento distribuído (por exemplo, usando IDs de correlação)
- Alertas em tempo real e painéis de controle
- Monitoramento de Desempenho de Aplicações (APM)
- Monitoramento sintético para caminhos críticos
Considerações de segurança:
- Autenticação e autorização entre serviços
- Gateways de API para segurança de borda
- Gerenciamento de segredos
- Segmentação de rede
- Auditorias de segurança regulares e testes de penetração
Implemente uma estratégia de defesa em profundidade, protegendo tanto o perímetro quanto os serviços individuais. Use automação para garantir a aplicação consistente de políticas de segurança em todos os serviços.
9. Lei de Conway: Alinhando organização e design de sistema
A lei de Conway destaca os perigos de tentar impor um design de sistema que não corresponde à organização.
Impacto organizacional. A Lei de Conway afirma que o design do sistema espelha as estruturas de comunicação dentro de uma organização. Esse princípio tem implicações significativas para a arquitetura de microsserviços.
Alinhando equipes e serviços:
- Organize equipes em torno de capacidades de negócios
- Empodere equipes com propriedade de ponta a ponta dos serviços
- Minimize dependências entre equipes
- Fomente uma cultura de colaboração e responsabilidade compartilhada
Considerações:
- Tamanho e composição da equipe
- Padrões e ferramentas de comunicação
- Processos de tomada de decisão
- Desenvolvimento de habilidades e compartilhamento de conhecimento
Reconheça que a estrutura organizacional e a arquitetura do sistema estão interligadas. Evolua ambos em conjunto para criar um ambiente propício ao desenvolvimento e operação bem-sucedidos de microsserviços.
10. Escalando microsserviços: Lidando com crescimento e falhas
Em escala, mesmo que você compre o melhor equipamento, o hardware mais caro, você não pode evitar o fato de que coisas podem e vão falhar.
Projetando para escala e resiliência. Arquiteturas de microsserviços devem ser projetadas para lidar tanto com o crescimento na demanda quanto com falhas inevitáveis de forma graciosa.
Estratégias de escalabilidade:
- Escalabilidade horizontal (adicionando mais instâncias)
- Escalabilidade vertical (aumentando recursos por instância)
- Cache (em memória, distribuído)
- Fragmentação e replicação de banco de dados
- Processamento assíncrono e arquiteturas orientadas a eventos
Padrões de resiliência:
- Disjuntores para prevenir falhas em cascata
- Compartimentos para isolamento de falhas
- Timeouts e tentativas com recuo exponencial
- Degradação graciosa da funcionalidade
Considerações do teorema CAP:
- Consistência
- Disponibilidade
- Tolerância a partições
Entenda que são necessários trade-offs ao escalar sistemas distribuídos. Priorize com base em seus requisitos e restrições específicos. Implemente práticas de observabilidade e engenharia do caos para melhorar continuamente a resiliência do sistema.
Última atualização:
FAQ
What's Building Microservices by Sam Newman about?
- Microservices Architecture: The book explores microservices, which are small, autonomous services that collaborate to form a system. It highlights how this architecture can enhance software delivery speed and flexibility.
- Business Domain Focus: Microservices are modeled around business domains, aligning software design with business needs and avoiding issues of monolithic architectures.
- Practical Guidance: Sam Newman provides real-world examples from companies like Netflix and Amazon, offering a comprehensive guide for adopting or understanding microservices.
Why should I read Building Microservices by Sam Newman?
- Comprehensive Resource: It covers design, development, deployment, testing, and maintenance of microservices, making it ideal for those transitioning from monolithic systems.
- Real-World Examples: The book includes insights from organizations that have successfully implemented microservices, providing practical perspectives and lessons learned.
- Continuous Learning: It encourages embracing continuous learning to keep up with the fast-evolving nature of microservices technology and practices.
What are the key takeaways of Building Microservices by Sam Newman?
- Microservices Benefits: The book outlines benefits like improved scalability, resilience, and quick adoption of new technologies due to service autonomy.
- Loose Coupling and High Cohesion: Emphasizes designing services to be loosely coupled and highly cohesive, facilitating easier maintenance and updates.
- Integration Strategies: Discusses synchronous and asynchronous communication strategies, crucial for maintaining service autonomy and effective collaboration.
What is the definition of microservices according to Building Microservices by Sam Newman?
- Small, Autonomous Services: Defined as "small, autonomous services that work together," highlighting their independence and functionality without reliance on others.
- Business Functionality Focus: Each microservice handles a specific business capability, aligning with organizational goals and prioritizing work effectively.
- Decoupled Communication: Services communicate through well-defined APIs, maintaining loose coupling and enabling independent development and deployment.
How does Building Microservices by Sam Newman suggest modeling services?
- Bounded Contexts: Introduces bounded contexts from Domain-Driven Design to define service boundaries, with each context representing a specific responsibility.
- Loose Coupling and High Cohesion: Stresses that related functionality should reside within the same service, while unrelated functionality should be separated.
- Iterative Approach: Recommends refining service boundaries over time to accommodate changes in business requirements and technology.
What are the integration strategies discussed in Building Microservices by Sam Newman?
- Synchronous vs. Asynchronous: Contrasts synchronous communication, where a service waits for a response, with asynchronous communication, where services operate independently.
- Event-Driven Architecture: Advocates for event-driven architectures, where services emit events to signal state changes, promoting loose coupling.
- REST and RPC: Discusses RESTful APIs and Remote Procedure Calls for service communication, emphasizing technology-agnostic APIs for flexibility.
What are the challenges of deploying microservices as outlined in Building Microservices by Sam Newman?
- Increased Complexity: Warns of the complexity due to interdependencies between services, which can lead to deployment challenges without proper management.
- Continuous Integration and Delivery: Emphasizes robust CI/CD practices to manage microservices effectively, ensuring quick and reliable deployments.
- Monitoring and Management: Suggests comprehensive monitoring solutions to track the health and performance of each service independently.
How does Building Microservices by Sam Newman address testing in microservices?
- Types of Tests: Categorizes tests into technology-facing and business-facing, including unit, integration, and end-to-end tests for service reliability.
- Consumer-Driven Contracts: Introduces consumer-driven contracts to validate service interactions, ensuring changes in one service don't break dependent services.
- Automated Testing: Advocates for automated testing to maintain quality and speed in deployment, allowing confident release of changes.
What is the significance of Conway’s Law in Building Microservices by Sam Newman?
- Organizational Structure and Architecture: Discusses Conway’s Law, which states that system designs reflect the communication structures of organizations.
- Team Autonomy: Emphasizes organizing microservices around autonomous teams that own specific services, fostering accountability and ownership.
- Impact on Design: Highlights the importance of aligning team structures with service boundaries for effective collaboration and faster feature delivery.
What are the best quotes from Building Microservices by Sam Newman and what do they mean?
- Freedom to React: "Microservices give us significantly more freedom to react and make different decisions," highlighting agility compared to monolithic architectures.
- Service Autonomy: "The golden rule: can you make a change to a service and deploy it by itself without changing anything else?" emphasizes designing independent services.
- Postel's Law: "Be conservative in what you do, be liberal in what you accept from others," underscores flexibility in service interactions while maintaining strict internal standards.
What are some architectural safety measures discussed in Building Microservices by Sam Newman?
- Circuit Breakers: Prevent cascading failures by stopping further calls to a failing service, allowing it to recover without being overwhelmed.
- Bulkheads: Isolate different parts of a system to prevent a failure in one area from affecting others, enhancing resilience and stability.
- Timeouts: Setting appropriate timeouts for service calls to avoid hanging requests, ensuring services can fail fast and recover effectively.
How does Building Microservices by Sam Newman suggest handling service discovery?
- Dynamic Service Registries: Discusses using tools like Consul and Eureka for managing service discovery, allowing easy registration and discovery of services.
- DNS as a Solution: Mentions DNS for service discovery, though it may not suit highly dynamic environments, suggesting load balancers to mitigate limitations.
- Human-Friendly Interfaces: Emphasizes creating user-friendly interfaces for service discovery, aiding developers in finding and understanding available services.
Avaliações
Construindo Microsserviços recebe críticas mistas, com muitos elogiando sua visão abrangente dos conceitos de microsserviços e conselhos práticos. Os leitores apreciam a abordagem cautelosa do autor e os exemplos do mundo real. Os críticos apontam a falta de profundidade do livro em alguns tópicos e seu potencial para superestimar os microsserviços. Muitos o consideram valioso para iniciantes, mas menos útil para arquitetos experientes. O livro aborda vários aspectos dos microsserviços, incluindo design, implantação, teste e escalabilidade. Alguns leitores desejaram mais detalhes concretos de implementação, enquanto outros valorizaram sua perspectiva de alto nível sobre arquitetura de software.
Similar Books
