Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Harshkalep_Mitcon2019

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.
Avatar for Maksim Maksim
April 29, 2019

 Harshkalep_Mitcon2019

Avatar for Maksim

Maksim

April 29, 2019

More Decks by Maksim

Other Decks in Technology

Transcript

  1. 2 • 5+ years in Software Engineering • .NET, .NET

    Core and ASP.NET Core • Microservice-Oriented Architecture ALIAKSEI HARSHKALEP Delivery Manager, EPAM Gomel
  2. 3 Agenda • Domain Driven Design • Communication • Resiliency

    • Security • Infrastructure • DEMO!
  3. 4 Microservices Docker Containers Docker Image Docker Registry Docker Hub

    Azure Container Registry Bounded Context API Gateway Event Bus Commands Events Docker Host Azure Container Service Azure Service Fabric Kubernetes Docker Swarm Mesos DC/OS Linux Containers Windows Containers Domain Events Aggregates Domain Entity CQRS simplified Domain-Driven Design Message Brokers RabbitMQ Azure Service Bus NServiceBus MassTransit Hyper-V Containers Async. communication Brighter Stateful Services Actors Orchestrators Autonomous Decoupled Isolated Service Discovery Transient Failures Handling Resiliency Health Checks Retries with Exponential Backoff Circuit Breakers Polly Nomad & addressable services New Patterns and New Technologies
  4. 5 Traditional application approach Microservices application approach • A traditional

    application has layers and libraries • Scales by cloning the app on multiple servers/VMs App 1 • A microservice splits functionality into services. • Scales out by deploying each service independently App 1 App 2 Microservice vs Monolith
  5. 6 Data in traditional approach Data in microservices approach •

    Single monolithic database • Tiers of specific technologies • Graph of interconnected microservices • State typically scoped to the microservice • Remote Storage for cold data SQL DB or No-SQL Web Tier Services Tier Data Tier Cache Tier Stateful services Web presentation services Stateless services Mobile apps Stateless services with separate stores SQL […] Microservice vs Monolith. Data
  6. 9 Why Domain Driven Design? • Business Necessities Are Oriented

    • A Common Set of Terms and Definitions Used by the Entire Team • Better Code • Microservice = Bounded Context • Domain Events for Integration
  7. 12 DDD: Modeling • Depends on the Domain-Model Layer so

    it can: o Use entity objects o User Repository Interfaces/Contracts • Depends on the Infrastructure Layer (DI) so it can: o Use repository implementation classes (DI) • Ideally, it must NOT take dependency on any other layer • It implements: o Domain Entities, Aggregate-Roots, Value-Objects o Repository Contracts/Interfaces (to be used in DI) • Depends on the Domain-Model layer so it can: o Use entity objects o Like EF updating DB through mapped entities • Direct dependency on infrastructure frameworks like EF Core or any other database, cache or infrastructure API
  8. 13 DDD: Code Organization Ordering Microservice Project: • Ordering.API –

    entry point • Ordering.Domain – all business logic • Ordering.Infrastructure – infrastructure specific implementations
  9. 16 Key Patterns for Microservices • Direct communication vs. API

    Gateway • Health checks • Resilient applications: Retries with exponential backoff plus Circuit breaker • Async. pub/subs communication (Event Bus)
  10. 17 The API Gateway Pattern DIREC T CLIENT -TO-MICROSERVICE COMMUNICATION

    USING A SINGLE CUSTOM API GATEWAY SERVICE https://github.com/ThreeMammals/Ocelot
  11. 18 The API Gateway Pattern: Benefits • Minimize the number

    of requests to multiple microservices • Handle cross-cutting concerns such as authorization or data transformations • Communicate with services that use non-Internet-friendly protocols • A façade made for different apps, like mobile, SPAs and ect.
  12. 19 Health Checks API HealthChecks WatchDog app /health Microservice 2

    Microservice 1 /health https://github.com/dotnet-architecture/HealthChecks
  13. 20 Health Checks API Consumer A Consumer B Router API

    Gateway Service Registry query /health /health Microservice 2 Microservice 1 Usually Provided by the Orchestrator https://docs.microsoft.com/en-us/aspnet/core/host-and-deploy/health-checks https://github.com/Xabaril/BeatPulse
  14. 21 Building Resilient Applications Microservice 2 Microservice 1 Client WebApp

    MVC Container Container Web API Web API ASP.NET Core MVC Container Microservice 3 Container Web API Client SPA WebApp JavaScript / Angular.js API Gateway ASP.NET Core Web API Container Back end Traditional WebApp Browser HTML HTML JSON JSON HTTP Request/Response HTTP Request/Response Implement resilient communication With Retries w/ exponential backoff & Circuit-Breakers
  15. 22 Microservice 2 Microservice 1 Client WebApp MVC Web API

    Web API ASP.NET Core MVC Container Microservice 3 Web API API Gateway ASP.NET Core Web API Back end HTTP Request/Response HTTP Retries with Exponential Backoff and Circuit Breaker
  16. 24 Multiple HTTP requests Browser Submit Order page Backend /

    Orchestrator Web App Multiple Customers Dependency 1 Dependency 2 Dependency 3 Dependency 7 Dependency 8 Dependency 4 Dependency 5 HTTP request/response communication Dependency 6 Anti-patterns Risk of Partial Failure Amplified by Microservices
  17. 25 How to minimize exponential failures in microservices • Circuit-Breakers

    (i.e. Polly’s policies, etc.) • Avoid long Http call chains within the same request/response cycle
  18. 26 i.e. MVC app, API Gateway, etc. Http sync. request

    Http sync. request Http sync. request Http sync. request Http sync. response Http sync. response Http sync. response Http sync. response Same Http Request/Response cycle! Basket Ordering Catalog Other i.e. MVC app, API Gateway, etc. Http sync. request Http sync. response Basket Ordering Catalog Other Synchronous all req./resp. cycle Asynchronous Comm. across internal microservices (EventBus: i.e. AMPQ) “Asynchronous” Comm. across internal microservices (Polling: Http) i.e. MVC app, API Gateway, etc. Http sync. response Basket Ordering Catalog Other Http Polling Http Polling Http Polling Http sync. request Http Polling Anti-pattern Synchronous vs. Async communication across Microservices
  19. 27 Database Ordering Microservice Basket Microservice Database as Cache Service

    Service User-Profile Microservice Web API Service Database Backend UserUpdated event (Publish Action) Event Bus (Publish/Subscribe Channel) UpdateUser command UserUpdated event → Buyer info UserUpdated event → Buyer info Eventual consistency across microservices’ data based on event-driven async communication DB update Event Bus Abstractions/Interface Event Bus Implementations RabbitMQ Azure Service Bus Other: NServiceBus MassTransit etc. Asynchronous Event-Driven communication with an Event Bus
  20. 29 Security C E N T R A L I

    Z E D A U T H E N T I C AT I O N W I T H A N A P I G AT E WAY A U T H E N T I C AT I O N BY I D E N T I T Y M I C R O S E R V I C E ; T R U S T I S S H A R E D U S I N G A N A U T H O R I Z AT I O N TO K E N https://github.com/ThreeMammals/Ocelot https://github.com/IdentityServer/IdentityServer4 https://github.com/policyserver/policyserver.local
  21. 31 What infrastructure do I need and why? • Docker

    – for packaging the App • Docker-Compose + Scripts – for local development • Clusterization – for scaling • Orchestration – for managing clusters
  22. 32 Docker App 1 Bins/Libs Guest OS Hypervisor App 2

    Bins/Libs Guest OS App 3 Bins/Libs Guest OS App 1 Bins/Libs App 2 Bins/Libs App 3 Bins/Libs Container Engine DOCKER CONTAINERS VIRTUAL MACHINES