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

Microservice

98f8e6125c052c4ac3fcc94f97919371?s=47 Viney
August 26, 2020

 Microservice

Introduce microservice including the following items:
* Domain driven design
* event-driven architecture
* Saga pattern
* CQRS
* Event sourcing

98f8e6125c052c4ac3fcc94f97919371?s=128

Viney

August 26, 2020
Tweet

Transcript

  1. Microservice 17 Media Viney Shih, Sr. Engineering Manager

  2. None
  3. None
  4. Agenda • What’s Microservice and the relation with organization •

    What’s the challenge moving to Microservice • Distributed data • Event-driven messaging • Consistency • Summary • Q&A
  5. What’s Microservice

  6. When to Microservice

  7. Reference: https://andrebartholomeufernandes.com/why- software-is-eating-the-world/ In the future, every company will become

    a software company
  8. Deliver software rapidly, frequently and reliably • Velocity • Lead

    time: time from commit to deploy • Deployment frequency: deploys per developer per day • Reliability • Change failure rate: % of deployments that cause an outage • Mean time to recover from a deployment failure
  9. Needs to able to easily modernize applications • Successful applications

    often lives a very long time • Technology changes
  10. Success Triangle Deliver changes to long-lived applications rapidly, frequently and

    reliably Process Architecture Organization
  11. Success Triangle Deliver changes to long-lived applications rapidly, frequently and

    reliably Process: SRE, CI / CD, Automation Architecture: ??? Organization: Autonomous team
  12. • SRE (DevOps) • Autonomous team • Long-lived applications Required

    architectural quality attributes (.a.k.a ilities) • Testability • Deployability • Maintainability • Modularity • Evolvability
  13. Monolithic architecture

  14. Ilities of small monoliths • Testability ✅ • Deployability ✅

    • Maintainability ✅ • Modularity ✅ • Evolvability ✅
  15. But when keep growing … Development Team Application

  16. Keep growing … Application Development Team

  17. Keep growing … Development Team Application Development Team Development Team

  18. Reference: http://www.laputan.org/pub/foote/mud.pdf

  19. None
  20. Rapid, frequent and reliable delivery eventually becomes impossible Maintainability Testability

    Deployability Modularity Evolvability Time (Size complexity) Ilities required to be competitive Risk of disruption
  21. None
  22. The Scale Cube Reference: https://akfpartners.com/growth-blog/scale-cube

  23. Y axis scale

  24. X-Z axis scale Main Structure Replica set

  25. Homework • What’s X-Y axis scale? • What’s X-Y-Z axis

    scale?
  26. The microservice architecture is an architectural style that structures an

    application as a set of loosely coupled services
  27. Each Microservice is • Highly maintainable and testable • Loosely

    coupled (e.g. database) • Independently deployable • Organized around business capabilities • Owned by a small team
  28. Order Service Customer Service Product Service Notification Service

  29. Benefits of Microservice Deliver changes to long-lived applications rapidly, frequently

    and reliably Process: SRE, CI / CD, Automation Architecture: microservice Organization: Small, Cross-function, autonomous teams Testability Deployability Maintainability Modularity Evolvability Modularity
  30. Drawbacks of microservice: Complexity • Development: IPC, consistency, partial failure,

    distributed data • Testing: integration, end to end, … • Infra: monitoring, deploy, … • Correctly identifying service boundaries → bounded context • Refactoring a monolithic application to a microservice architecture
  31. Challenge I: How to apply it into domain model? •

    Object points to one to another. Order *Customer Address City Street OrderItem Quantity *Product Customer CreditLimit Product Price Name
  32. Challenge II: How to implement ACID transaction? BEGIN TRANSACTION …

    SELECT OrderTotal FROM Orders WHERE CustomerID = ? … SELECT CreditLimit FROM Customers WHERE CustomerID = ? … INSERT INTO Orders … … COMMIT TRANSACTION
  33. None
  34. Domain-Driven Design (.a.k.a DDD) • Entity • Value Object •

    Services • Repositories • Aggregates
  35. Aggregate • Cluster of objects that can be treated as

    a unit • Graph consisting of a root entity and one or more other entities and value objects.
  36. Aggregate (cont.)

  37. Aggregate: rule #1 • Reference other aggregate roots via identity.

    • Domain model → collection of loosely connected aggregates Order customerID Address City Street OrderItem Quantity productID Customer CreditLimit Product Price Name
  38. Aggregate: rule #2 • Process one command by one aggregate.

    • Aggregate scope = Transaction scope → Service Order customerID Address City Street OrderItem Quantity productID Customer CreditLimit Product Price Name Order Service Customer Service Product Service
  39. Aggregate granularity • If an update must be atomic, it

    must be handled by a single aggregate. • Granularity leads different consistency and scalability Customer Order Product Customer Order Product Order Customer Product Consistency Scalability
  40. Two-Phase Commit (.a.k.a 2PC) is not a viable option •

    Guarantees consistency • Not supported by many NoSQL and MQ • Impacts availability in CAP Theorem • …
  41. SAGA pattern from a 1987 paper

  42. How do the saga participants communicate? • Synchronous (e.g. REST,

    gRPC, …) • Availability(N) = Availability(N1) x Availability(N2) x Availability(N3) x … • Recovering mechanism: retry Order Service Customer Service createOrder() POST /order reseveCredit() PUT /customer/id/credit
  43. • Collaboration using asynchronous, broker-based messaging • eventual consistency •

    At least once delivery • Ordered delivery • Availability(N) = Availability(N1) Order Service Customer Service createOrder() POST /order reseveCredit() Message Broker
  44. Two patterns • Choreography: distributed decision making • Orchestration: centralized

    decision making
  45. Choreography-based Saga Status: Pending / Created / Rejected DB

  46. Choreography-based Saga (cont.)

  47. Benefits and drawbacks of Choreography • Benefits • Simple •

    Participants are loosely coupled • Drawbacks • Decentralized implement: difficult to understand • Cyclic dependencies • …
  48. Orchestration-based Saga

  49. Orchestration-based Saga (cont.)

  50. Benefits and drawbacks of Orchestration • Benefits • Centralized coordination

    logic is easier to understand • Reduce cyclic dependencies • Simplified the business logic • Drawbacks • smart orchestrator tells dumb services what to do
  51. Homework • Synchronous RESTful API initiates asynchronous SAGA • Rollback

    strategy • SAGAs are ACD → No Isolation
  52. How atomically update database and publish an event? • Dual

    write problem Service Database Message Broker ❓ ❓
  53. Data consistency in event-driven architecture • Application events (Transactional outbox):

    • eBay • one transaction two tables, and one app polling
  54. • Transaction log tailing: • LinkedIn • polling transaction log

    • MySQL binlog • Postgres WAL • AWS DynamoDB table streams • MongoDB change streams
  55. • Event Sourcing: • Persists an object as a sequence

    of events View id: 123 author: Jane Doe impact: 10
  56. Benefits and drawbacks of Event Sourcing • Benefits • Solve

    data consistency • Preserve history → replay whole data • Support temporal queries • Simplify retroactive correction • Built-in auditing • Drawbacks • Unfamiliar programming model • Evolving the schema of long-lived events • Only supports PK-based access → CQRS
  57. Command and Query Responsibility Segregation (.a.k.a CQRS) • Using events

    to update a queryable replica.
  58. Summary • Microservice enables whole business, team and architecture •

    Data is distributed which create challenges • Use event-driven architecture for eventual consistency • Use Sagas to maintain data consistency across service • Understand Event Sourcing and CQRS
  59. Q & A Thanks for your Time!