O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Magento Developer Talk. Microservice Architecture and Actor Model

465 visualizações

Publicada em

Magento Developer Talk. Microservice Architecture and Actor Model


Publicada em: Engenharia

Magento Developer Talk. Microservice Architecture and Actor Model

  1. 1. Agenda • Task Based UI • Service Oriented Architecture • Micro services • Actor Model
  2. 2. CRUD Based UI Forms over data
  3. 3. Task Based UI
  4. 4. Task Based UI
  5. 5. CQRS и REST API
  6. 6. Monolithic Architecture • Three parts oClient-side user interface o Server-side application oDatabase This server-side application is a monolith. Any changes to the system involve building and deploying a new version of the server-side application. All your logic for handling a request runs in a single process You can horizontally scale the monolith by running many instances behind a load-balancer.
  7. 7. Micro services • Single application as a suite of small services • Each running in its own process and communicating over HTTP • Services are built around business capabilities and independently deployable • Do one thing and do it well”
  8. 8. • Each Micro service belongs to own Bounded Context (DDD) o A Bounded Context encapsulates the details of a single domain and defines the integration points with other bounded contexts/domains. • As decoupled and as cohesive as possible
  9. 9. Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. -- Melvyn Conway, 1967
  10. 10. Smart endpoints and dumb pipes • REST API over HTTP • Message bus (RabbitMQ) The biggest issue in changing a monolith into microservices lies in changing the communication pattern. A naive conversion from in- memory method calls to RPC leads to chatty communications which don't perform well. Instead you need to replace the fine-grained communication with a coarser -grained approach.
  11. 11. • Remote calls are more expensive than in-process calls, and thus remote APIs need to be coarser-grained oFine Grained Services oCoarse Grained Services
  12. 12. Synchronous calls considered harmful Any time you have a number of synchronous calls between services you will encounter the multiplicative effect of downtime. Simply, this is when the downtime of your system becomes the product of the downtimes of the individual components. You face a choice, making your calls asynchronous or managing the downtime. At www.guardian.co.uk they have implemented a simple rule on the new platform - one synchronous call per user request while at Netflix, their platform API redesign has built asynchronicity into the API fabric.
  13. 13. REST API and Asynchronicity Please, repave the street Server’s response ‘202 Accepted’
  14. 14. SOA vs Microservices Microservices must be independently deployable, whereas SOA services are often implemented in deployment monoliths. So, SOA is an architectural pattern in which application components provide services to other components. However, in SOA those components can belong to the same application.
  15. 15. Actor Model
  16. 16. http://www.reactivemanifesto.org/ Reactive is
  17. 17. • Responsive: The system responds in a timely manner if at all possible. Responsiveness is the cornerstone of usability and utility. Responsive systems focus on providing rapid and consistent response times. • Resilient: The system stays responsive in the face of failure. This applies not only to highly-available, mission critical systems — any system that is not resilient will be unresponsive after a failure. Resilience is achieved by replication, containment, isolation anddelegation. • Elastic: The system stays responsive under varying workload. Reactive Systems can react to changes in the input rate by increasing or decreasing the resources allocated to service these inputs. • Message Driven: Reactive Systems rely on asynchronous message- passing to establish a boundary between components that ensures loose coupling, isolation and location transparency.
  18. 18. Actor • An actor is the primitive unit of computation. It’s the thing that receives a message and do some kind of computation based on it. • The idea is very similar to what we have in object-oriented languages: An object receives a message (a method call) and do something depending on which message it receives (which method we are calling). The main difference is that actors are completely isolated from each other and they will never share memory. It’s also worth noting that an actor can maintain a private state that can never be changed directly by another actor.
  19. 19. What actors do When an actor receives a message, it can do one of these 3 things: • Create more actors; • Send messages to other actors; • Designates the behavior to be used for the next message it receives (implies state). oKeep mutable state internal and communicate with each other through asynchronous messages
  20. 20. Small Demo
  21. 21. Actors vs Micro services