Mariusz Richtscheid: Masz już dosyć swojego monolitu? Rozważasz rozbicie go na mikroserwisy? Nie tak prędko. Zanim zaczniesz zmieniać architekturę, warto dowiedzieć się jakie problemy się z tym wiążą. Na szczęście większość bolączek można rozwiązać stosując odpowiednie wzorce i techniki, których część zostanie omówiona w trakcie prezentacji.

1. Microservices in
Mariusz Richtscheid
Gliwice, 10.10.2018
patterns and techniques

2. About me
• Full-Stack Developer in The Software House
• richtscheid@gmail.com
• linkedin.com/in/richtscheid
• github.com/barograf
Mariusz Richtscheid

3. Agenda
• Why microservices?
• Communication patterns
• Data management patterns
• Reliability and observability patterns
• Testing

4. Monolith
• Can be difficult to understand and modify
• Development and deployments slow down over time
• Modularity breaks down over time
• Quality of the code declines over time
• It is hard to change technology stack

5. Why microservices?
• Smaller services are easier to understand and test
• Services can be deployed more frequently
• Development in multiple teams
• Improved fault isolation
• Every service can have different technology stack

6. A lot of issues to address
How to decompose into services?
How to deploy?
How to handle configs, logging,
tracing, health checks, metrics?
How to communicate between services?
How do external clients
communicate with the services?
What about service discovery?
How to prevent failures?
How to maintain data consistency?
How to handle security? How to test it?
How to troubleshoot problems?
How to display data from multiple
services?

7. Solution: patterns!
Source: https://microservices.io/patterns/microservices.html

8. API Gateway

9. API Gateway overview
Service 1 Service 2
API GatewayClient Service 3
System
Client
✔
❌

10. API Gateway
• One entry point for the entire system
• Handles security - other services communicate freely
• Knows how to call other services - statically defined or with service
discovery
• Should not contain business logic

11. API Gateway - message format
export interface ISocketMessage {
serviceName: string;
serviceOperation: string;
payload: object;
}

12. API Gateway - handling requests
client.on('message', (data: ISocketMessage) => {
this.services[data.serviceName][data.serviceOperation]({
...data.payload
})
.then(result => {
client.emit('message', { payload: result });
})
.catch(error => {
/*
please log me
*/
});
});

13. Service discovery

14. Service discovery
Router
Service registry
Service 1
RegisterGet address
Request
Service 2
Request

15. • Solution to connect and configure applications across distributed
infrastructure
• Service discovery
• Health checking
• Provides useful UI

16. Consul UI - services

17. Consul UI - health checks

18. Running Consul server

19. Health check endpoint
const app = express();
app.get('/health', (req, res) => {
res.status(200);
res.send('ok');
res.end();
});

20. Service and health check registration
const consul = require('consul')();
consul.agent.service.register({
name: 'api-gateway',
address: process.env.HOST,
port: Number(process.env.PORT),
check: {
http: `http://${process.env.HOST}:${process.env.PORT}/health`,
interval: '30s',
}
}, err => { if (err) throw err });

21. Health check subscription
consul
.watch({
method: consul.health.service,
options: { service: 'translations' }
})
.on('change', function (data, res) {
const status = data[0].Checks[1].Status;
console.log(`translations service status: ${status}`);
});

22. Health check subscription

23. Communication between services

24. Remote procedure invocation
API GatewayClient
System
Service 1 Service 2
https://
Apache
Thrift

25. Message broker
API GatewayClient
Service 1
Message broker
Service 2
Pub/Sub
• Loose
coupling
• Buffering
messages

26. Data management

27. Shared database
Service 1
API GatewayClient Service 2
System
Shared
database

28. Database per service
Service 1
API GatewayClient Service 2
System
Service 1
database
Service 2
database
• Scaling
• Data
consistency
• Queries

29. Data consistency - Saga

30. Saga
• A service which coordinates sequence of local transactions across
multiple microservices
• Each local transaction updates the database
• If local transaction fails then the saga executes a rollback for all related
microservices

31. Rollback in saga
Service 1
Operation 1
Operation 2
Operation 3
Saga
Service 2
Service 3
Service 4
❌
✅
✅
Service 4Rollback✅ Error
Data changed
Data changed

32. Querying - API Composition

33. API Composition
API GatewayClient Service 1
System
Query Query Query
Service 2 Service 3 Service 4

34. Circuit breaker

35. Circuit breaker
• Mechanism for fast fail of requests towards unhealthy services
• Prevents unnecessary traffic and cascading fails
• Unhealthy services can recover safely

36. Circuit breaker
Service 2
API GatewayClient Service 1
System
Service 1
Error

37. Distributed tracing

38. Distributed tracing
• Logging is not enough in distributed system
• Tracing gives insight into code execution across services
• With tracing we know what, where and when something fails

39. Distributed tracing overview
Service 2
API GatewayClient
Tracing server
Service 1
System
Tracing ID (e.g. header)
Tracing ID

40. • Standard for distributed tracing
• Defines interfaces and data model for many programming languages
• Has no real implementation

41. • OpenTracing compatible implementation for distributed tracing
• Released as open source by Uber Technologies
• Available in Node, Go, Java, Python and C++
• Provides useful UI

42. Jaeger UI
traces list

43. Jaeger UI - trace details
Span

44. Jaeger UI - span details

45. Running Jaeger server

46. Initializing tracer
import { initTracer } from 'jaeger-client';
const tracer = initTracer(
{
serviceName: process.env.APP_NAME || 'Unknown app',
sampler: {
type: 'const',
param: 1,
},
reporter: {
logSpans: true,
agentHost: process.env.TRACING_SERVICE_HOST || 'localhost',
agentPort: Number(process.env.TRACING_SERVICE_PORT) || 6832,
},
},
{ logger }
);

47. Creating new span
const span = tracer.startSpan('name of the span');
span.addTags({ type: 'foo' });
/*
some code
*/
span.finish();

48. Sending tracing ID
import { FORMAT_HTTP_HEADERS } from 'opentracing';
const headers = {};
tracer.inject(span, FORMAT_HTTP_HEADERS, headers);
const tracingId = JSON.stringify(headers);
/*
send tracing ID to other service (with headers, as string value etc.)
*/

49. Receiving tracing ID
/*
receive tracing ID from other service
*/
const tracingIdString = '{"uber-trace-id":"d7ee8bcc3f4a1033:d7ee8bcc3f4a1033:0:1"}';
const spanFromOtherService = tracer.extract(
FORMAT_HTTP_HEADERS,
JSON.parse(tracingIdString)
);
const span = tracer.startSpan('name of the span', { childOf: spanFromOtherService });
/*
some code
*/
span.finish();

50. Testing

51. Testing
• Specs are not enough
• Write integration tests for parts of your infrastructure
• Run your infrastructure with one command
• Can be achieved with Docker Compose or PM2 ecosystem
• Different definitions for different parts of infrastructure

52. PM2 - ecosystem.json
{
"apps": [
{
"name": "API Gateway",
"script": "index.ts",
"cwd": "src/services/api-gateway"
},
{
"name": "Notifications service",
"script": "index.ts",
"cwd": "src/services/notifications"
}
]
}
• Requires mono-repository
• For Node scripts only

53. docker-compose.yml
version: '3'
services:
api-gateway:
image: org/api-gateway:latest
ports:
- "3000:3000"
depends_on:
- redis
notifications:
image: org/notifications:latest
depends_on:
- redis
postgres:
image: postgres
ports:
- "5432:5432"
• Images from various
repositories
• Can handle databases

54. Start infrastructure

55. System overview
API Gateway Notifications service
Client
application
https://https://

56. Integration test - arrange
import { connectors } from './connectors';
describe('Notifications service', () => {
it('sends and stores notification', async () => {
// Arrange
const api = await connectors.getApiGatewayConnector();
const db = await connectors.getDatabaseConnector();
await db.delete().from('notifications');
...
});
});

57. Integration test - act
...
// Act
const response = await api({
serviceName: 'notifications',
serviceOperation: 'send',
payload: {
title: 'My notification title',
message: 'My notification message',
}
});
...

58. Integration test - assert
// Assert
const schema = {
id: expect.any(String),
payload: {
title: 'My notification title',
message: 'My notification message',
}
};
expect(response.status).toEqual(200);
expect(response.json()).toEqual(schema);
expect(await db.from('notifications').count()).toBe(1);
expect(await db.select().from('notifications')).toEqual(schema);

59. Worth knowing
• Deployment patterns, e.g. serverless
• Decomposition patterns, e.g. DDD subdomains
• Microservice frameworks, e.g. Cote, Moleculer, Seneca
• Security patterns, e.g. access tokens

60. Thanks!
Any questions?