16. Service Discovery
• Service Registry:
• Services registers at startup and provide heartbeats.
• Registry knows location of each services (all instances).
• Services access services directly, Registry is an address-book, not proxy.
17. Load Balancing with Service Discovery
• Server-side Load Balancing:
• Discovery Server returns a single instance (e.g. round-robin).
• Client-side Load Balancing:
• Client fetches list of all instances and decides which to use.
18. Discovery Cluster
• Single point of failure:
• Discovery Server (service registry) may fail.
• Discovery Server Cluster is required.
43. Implementation Details
• Roles available:
• User, Client;
• Auth Service;
• Service Provider;
• Common concerns:
• Latency;
• Bottlenecks;
• Statelessness;
• Single Sign-On;
• Fine-grained authorization;
• Exposure of user credentials;
44. Capability-Based
• A capability (key) is a communicable, unforgeable token of authority.
• It references an object along with an associated set of access rights.
• It is used to access another object.
45. Protection Rings
• System is secured using protection rings.
• Diametrically opposite to capability-based security.
47. Direct
• Services communicate with other services directly:
• Coordinated by a discovery server for dynamic scalability.
• Client-side load balancing option available.
• Requires strict contract.
• Remote services should be highly available.
• May cause data loss in case if requests fail.
48. Decoupled
• Services communicate though a middleware:
• Coordinated by the middleware.
• Scaled using such concepts as Partitioning & Consumer Groups.
• Data-oriented, almost contract-free.
• Middleware should be highly available.
• No data loss, middleware can keep it.
49. Synchronous
• Block and wait for answer upon request.
• Standard model to fetch data.
• Blocking API.
53. Data Microservices
• Basic properties:
• A lightweight data-oriented service;
• Has an input and/or output;
• May play role of sink, source or processor;
Source O SinkIProcessorI O
54. Data Microservices
• Advanced properties:
• Almost contract-free (no methods, just data);
• Decoupled (know nothing about others);
• Reusable (anytime, anywhere);
• Used in composition of pipelines (workflow);
55. Data Microservices: Scalability
• Consumer Groups.
• Scale the architecture at consumer side when there is a demand for more
computational power (high volume of incoming messages, slow consumer).
Publisher
Group: Grey
Consumer 1
Group: Yellow
Consumer 1 Consumer 2Consumer 2
56. Data Microservices: Scalability
• Partitioning.
• Scale the architecture at producer side when there is a demand for more
parallelism at middleware.
Publisher 2
Group: Grey
Consumer 1
Group: Yellow
Consumer 1 Consumer 2Consumer 2
Publisher 1 Publisher 3
1 2 3
61. Transactional Consistency
• Using a transaction manager:
• We heavily depend on it;
• It delays the processing of our transactions (potential bottleneck);
• Complex to implement;
• More complex when we need to communicate with another system.
62. Transactional Consistency
• When dealing with transactions:
• Think about different approaches for different business processes;
• A transaction manager with two phase commit is not always required;
• Actor/event oriented approaches are available as well.
• Coffee shop example.
63. Eventual Consistency
• Event Sourcing:
• Save events of state changes instead of state itself.
• Reconstruct an entity’s state by replaying events.
• Saving an event is a single operation, it is inherently atomic.
Create Account Edit User Name Delete Account
64. Eventual Consistency
• Event Store:
• Events are immutable, store full history, provide a detailed audit trail.
• Events are published to subsystems notifying about the changes to the state.
• Rewind to the state of the system at any previous point in time.
Event Store
Group: Grey
Consumer 1
Group: Yellow
Consumer 1 Consumer 2Consumer 2
65. Eventual Consistency
• Retrieval of state is time consuming.
• Have to replay events to rebuild the state.
• Solution is to maintain two separate models:
• write model — the event store.
• read model — the database.
• A different handler is responsible for updating the read model, once an event
is persisted in the event store (write model).
Write
Model
Read
Model
Events
66. Eventual Consistency
• CQRS:
• every method should either be a command that performs an action,
• or a query that returns data to the caller.
• Return a value only if there are no side effects.
• If you have a return value you cannot mutate state.
• If you mutate state your return type must be void.
Command Query
67. Eventual Consistency
• Event Sourcing + CQRS
Command
Service
Query
Service
Event
Store
Data
Store
Event
Processor
68. Eventual Consistency
• Event Sourcing + CQRS
• Consistency:
• Write model is consistent, events are ordered, transactions are simple.
• Most systems can be eventually consistent on the Query side.
Command
Service
Query
Service
Event
Store
Data
Store
Event
Processor
69. Eventual Consistency
• Event Sourcing + CQRS
• Consistency:
• Write model is consistent, events are ordered, transactions are simple.
• Most systems can be eventually consistent on the Query side.
• Data Storage:
• Normalized data on the Command side (e.g. a relational structure).
• Denormalized data on the Query side (e.g. to minimize the number of joins).
Command
Service
Query
Service
Event
Store
Data
Store
Event
Processor
70. Eventual Consistency
• Event Sourcing + CQRS
• Consistency:
• Write model is consistent, events are ordered, transactions are simple.
• Most systems can be eventually consistent on the Query side.
• Data Storage:
• Normalized data on the Command side (e.g. a relational structure).
• Denormalized data on the Query side (e.g. to minimize the number of joins).
• Scalability:
• Scale Command and Query sides separately.
Command
Service
Query
Service
Event
Store
Data
Store
Event
Processor
73. Summary
• Think about:
• Security
• High Availability
• Communication
API Gateway
Discovery
Servers
Command
Service
Query
Service
Event
Store
Data
Store
Data
Store
Command
Service
Command
Service
Query
Service
Query
Service
75. Live Coding
• Phase 1: Application.
• Endpoint to Hello a user by name.
• Endpoint to Hello the world.
Hello
App
Mood
Ext. Service
76. Live Coding
• Phase 2: Service-Oriented.
• API Gateway.
• Service Discovery.
• Load Balancing.
Hello
API Gateway
Mood
Ext. Service
Hello World
Service
Hello
Service
Discovery
Mood
API Service
77. Live Coding
• Phase 3: Eventually Consistent.
• Event Sourcing.
• CQRS.
• Post-Redirect-Get.
Hello
API Gateway
Mood
Ext. Service
Hello World
Service
Hello Query
Service
Discovery
Mood
API Service
Hello
Command
Service
Hello
Decorator
Mood
Decorator
Data
Store