The document discusses the microservices architectural style, emphasizing the development of applications as a suite of small, independently deployable services that communicate over lightweight mechanisms, often HTTP APIs. It outlines key principles such as loose coupling, encapsulation, and process segregation, and addresses the complexity involved in managing multiple programming languages and data sources within microservices. The presentation also touches on the importance of centralized tools for effectively handling distributed applications while preserving business logic and domain objects.

1. WILD microSERVICES
18+

2. @tolkv
2

3. @aatarasoff
3

4. WILD microSERVICES
18+

5. DISCLAIMER
No warranty guarantee
5

6. Agenda
1. Theory
2. Practice
3. Q&A
6

7. 7

8. 8

9. 9

10. Ball of Mud
10

11. SOA Principles
1. standardized service contract
2. loose coupling
3. encapsulation
4. reusability
5. autonomy
6. statelessness
7. discoverability
11

12. 12

13. 13

14. Никто не любит “некрасивые” технологии
поэтому они умирают

15. 15
Про тренды

16. In short, the microservice architectural style is an approach to developing
a single application as a suite of small services, each running in its own
process and communicating with lightweight mechanisms, often an HTTP
resource API. These services are built around business capabilities and
independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services,
which may be written in different programming languages and use
different data storage technologies.
-- James Lewis and Martin Fowler
Что такое микросервисы?
16

17. In short, the microservice architectural style is an approach to developing
a single application as a suite of small services, each running in its own
process and communicating with lightweight mechanisms, often an HTTP
resource API. These services are built around business capabilities and
independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services,
which may be written in different programming languages and use
different data storage technologies.
-- James Lewis and Martin Fowler
Что такое микросервисы?
17

18. Размер имеет значение?
● Method/Function = Microservice?
● 10-300 LOC = Microservice?
● 1 week = Microservice?
● 1 developer = Microservice?
18

19. Размер не имеет значения*
● Single Responsibility
● One capability
● Bounded context
“In your organization, you should be thinking not in terms
of data that is shared, but about the capabilities those
contexts provide the rest of the domain.”
– Sam Newman, Building Microservices
*до разумных пределов конечно
19

20. Domain-Driven Design
20

21. In short, the microservice architectural style is an approach to developing
a single application as a suite of small services, each running in its own
process and communicating with lightweight mechanisms, often an HTTP
resource API. These services are built around business capabilities and
independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services,
which may be written in different programming languages and use
different data storage technologies.
-- James Lewis and Martin Fowler
Что такое микросервисы?
21

22. Process segregation
22

23. In short, the microservice architectural style is an approach to developing
a single application as a suite of small services, each running in its own
process and communicating with lightweight mechanisms, often an HTTP
resource API. These services are built around business capabilities and
independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services,
which may be written in different programming languages and use
different data storage technologies.
-- James Lewis and Martin Fowler
Что такое микросервисы?
23

24. Независимый деплой
build test
24

25. In short, the microservice architectural style is an approach to developing
a single application as a suite of small services, each running in its own
process and communicating with lightweight mechanisms, often an HTTP
resource API. These services are built around business capabilities and
independently deployable by fully automated deployment machinery.
There is a bare minimum of centralized management of these services,
which may be written in different programming languages and use
different data storage technologies.
-- James Lewis and Martin Fowler
Что такое микросервисы?
25

26. Language/technology segregation
26

27. Data segregation
27

28. Team segregation
28

29. Принцип LSD
- L языков программирования
- S в среднем фреймворков на язык
- D типов источников данных
complexity = L * S * D
29

30. Пример
- три языка программирования
- два в среднем фреймворка на язык
- семь типов источников данных
- legacy WS, mongo db
- хранимые процедуры, JDBC-templates
- elasticsearch, neo4j
- мишкина база
complexity = 3 * 2 * 7 = 42 (!)
30

31. Чем нельзя жертвовать?
min (L * S * D) -> ?
31

32. Закон трёх букв
min (L * S * D) -> max (D)
32

33. Почему Spring Boot/Spring Cloud?
33

34. А теперь попробуем
34

35. Demo

36. Demo -> Deploy Time

37. Service Discovery
37

38. Demo -> Time to Discover

39. Где мой порт?
39

40. 40

41. Какие есть варианты?
● Nginx/Haproxy + consul template
● Haproxy + bamboo (need marathon)
● Netflix Zuul (Java way!!!)
● Custom Servlet <- все с этого начинают!
41

42. Netflix Zuul
42

43. Demo -> Gateway Time

44. Безопасность
44

45. Защита на уровне сервиса
45

46. Защита на уровне сервиса #2
46

47. Опять этот gateway
47

48. REST/HTTP
Authorization: Bearer <TOKEN>
ClientID: <ID>
48

49. Thrift API Gateway
service InternalTestService {
SomeReturnData getSomeData(
1: UserData userData,
2: RequestData requestData
) throws (1: SomeException e);
}
49

50. Thrift API Gateway
service InternalTestService {
SomeReturnData getSomeData(
1: UserData userData,
2: RequestData requestData
) throws (1: SomeException e);
}
service ExternalTestService {
SomeReturnData getSomeData(
1: AuthToken authData,
2: RequestData requestData
) throws (1: SomeException e,
99: UnauthorizedException ue);
}
50

51. 51

52. Springway
@SpringBootApplication
@EnableThriftGateway
public class Application {
public static void main(String[] args) {
SpringApplication.run(Application.class, args);
}
}
52

53. Demo -> Thrift the Ripper

56. Demo -> Hystrix the Saviour

57. Типичная микросервисная архитектура
57

58. 58

59. А что в этих ваших интернетах?

60. 60
DDDD (4D)

61. Выводы
61
● Микросервисы - это просто

62. Выводы
62
● Микросервисы - это просто
● Микросервисы - это сложно

63. Парадокс (де)централизации микросервисов
Чтобы эффективно работать с распределенными
приложениями, нужно иметь очень хорошие
централизованные библиотеки/инструменты
Например: логирование, health-чеки, метрики,
обработку программных ошибок
63

64. Парадокс (де)централизации микросервисов
Чтобы эффективно работать с распределенными
приложениями, нужно иметь очень хорошие
централизованные библиотеки/инструменты
Но: не выносите бизнес-логику или доменные объекты
64

65. LSD вам в помощь
min (L * S * D) -> max (D)
65

66. Ссылки
Оригинальное исполнение
https://github.com/bsideup/thrift-spring-boot-starter
Крутой плагин для Gradle
https://github.com/bsideup/GradleThrift
Forward2Docker
https://github.com/bsideup/forward2docker/releases
66
@bsideup

67. Code. Better. Together.
Spring Thrift Client
https://github.com/aatarasoff/spring-thrift-starter
Thrift API Gateway
https://github.com/aatarasoff/thrift-api-gateway-core
https://github.com/aatarasoff/spring-thrift-api-gateway
Примеры сегодняшнего дня
https://github.com/lavcraft/jug-samples
67

68. Высокие теории
Sam Newman “Building Microservices”
Martin Fowler “Microservice TradeOff” “Microservices”
“The Twelwe-Factor App” http://12factor.net
Hystrix: managing failures in distributed systems - Tomasz Nurkiewicz https:
//www.youtube.com/watch?v=JadVts_prtA
68

69. Спасибо! Готовы ответить на ваши вопросы
@tolkv
@aatarasoff
69