По материалам конференции .NET разработчиков http://dotnetconf.ru/materialy/microservices

1. микросервисы: взгляд
сверху и в бок
Акуляков Артём
12-я конференция .NET разработчиков
15 мая 2016
dotnetconf.ru

2. обо мне
- dotnet
- python
- f(ƛ) в свободное время
- докладчик dotnetconf, dev2dev, codefest
- соорганизатор dev2dev
2

3. архитектурный
шаблон
3

4. проблема
решение
вывод
4

5. проблема
5

6. монолитная архитектура
6

7. проблемы
- сложно понять
7

8. проблемы
- сложно понять
- сложно развивать
8

9. проблемы
- сложно понять
- сложно развивать
- сложно внедрять новые технологии
9

10. проблемы
- сложно понять
- сложно развивать
- сложно внедрять новые технологии
- унаследованный код
10

11. решение
11

12. тотальная
декомпозиция
12

13. было
13

14. стало
14

15. вывод
15

16. хорошо
- жесткие границы сервисов
16

17. хорошо
- жесткие границы сервисов
- сервисы независимы
17

18. хорошо
- жесткие границы сервисов
- сервисы независимы
- можно писать на самой подходящей технологии
18

19. хорошо
- жесткие границы сервисов
- сервисы независимы
- можно писать на самой подходящей технологии
- легко разворачивать
19

20. хорошо
- жесткие границы сервисов
- сервисы независимы
- можно писать на самой подходящей технологии
- легко разворачивать
- независимое масштабирование
20

21. хорошо
- жесткие границы сервисов
- сервисы независимы
- можно писать на самой подходящей технологии
- легко разворачивать
- независимое масштабирование
- легко понятьпереписать
21

22. плохо
- сложно разбираться с системой в целом
22

23. плохо
- сложно разбираться с системой в целом
- тяжело эксплуатировать
23

24. плохо
- сложно разбираться с системой в целом
- тяжело эксплуатировать
- медленно
24

25. плохо
- сложно разбираться с системой в целом
- тяжело эксплуатировать
- медленно
- нестабильно
25

26. как?
26

27. виды
- messagebus
27

28. message bus
28

29. виды
- messagebus
- rpc (service discovery)
29

30. rpc
30

31. service registry
- dns
- consul
- eureka
- zookeeper
- etcd
31

32. регистрация в sr?
32

33. регистрация
- self registration
33

34. регистрация
- self registration
- 3rd party registration
34

35. rpc
35

36. api gateway
- предоставляет удобное api для клиентского кода
- скрывает сложность системы
- плюшки
- security
- service discovery
- load balancing
- logging
- facade + decorator
36

37. виды
- messagebus
- rpc (service discovery)
- hybryd
37

38. как с данными?
38

39. данные
39

40. проблемы +1
40

41. плохо
- сложно разбираться с системой в целом
- тяжело эксплуатировать
- медленно
- нестабильно
- консистентность в конечном счете
41

42. опыт
42

43. enterprise

44. много приложений одной компании
44

45. данность
- интеграции приложений между собой
45

46. данность
- интеграции приложений между собой
- пользователи = сотрудники компании
46

47. данность
- интеграции приложений между собой
- пользователи = сотрудники компании
- высокие требования безопасности
47

48. данность
- интеграции приложений между собой
- пользователи = сотрудники компании
- высокие требования безопасности
- высокие требования к отказоустойчивости
48

49. дублирование кода и данных
49

50. решения
- выносим общую функциональность в повторно
используемые библиотеки
- собственный nuget сервер
50

51. дублирование
данных
51

52. микросервис =
данные + код
52

53. микросервис =
единица повторного
использования
53

54. микросервисы
- авторизация и аутентификация
- структура компании и корпоративная иерархия
- фотографии пользователей(аватарки)
- логирование
- мониторинг
- рассылка уведомлений
54

55. технологии
- с#
- webapi, odata, aspnet mvc, ef, dapper
- windows server, ms sql server, iis
- vmware
55

56. получили
56

57. хорошо
- повторное использование данных и кода
57

58. плохо
- сложно
58

59. плохо
- сложно
- дорого
- но это не проблема =)
59

60. faq
60

61. sizeof(microservice)?
61

62. sizeof(microservice)
- 50-150-200-N loc
62

63. sizeof(microservice)
- 50-150-200-N loc
- метод двух пиц
63

65. sizeof(microservice)
- 50-150-200-N loc
- метод двух пиц
- метод одной головы
65

67. sizeof(microservice) & microservice.content
- 50-150-200-N loc
- метод двух пиц
- метод одной головы
- один сервис = одна бизнес операции
67

68. sizeof(microservice) & microservice.content
- 50-150-200-N loc
- метод двух пиц
- метод одной головы
- один сервис = одна бизнес операции
- один сервис = управление одним ресурсом
68

69. sizeof(microservice) & microservice.content
- 50-150-200-N loc
- метод двух пиц
- метод одной головы
- один сервис = одна бизнес операции
- один сервис = управление одним ресурсом
- один сервис = один связанный контекст
- hello from DDD =)
69

70. версионность?
70

71. версионность?
- http://foo.bar/v14/someaction
71

72. версионность?
- http://foo.bar/v14/someaction
- service registry
72

73. shared db?
73

74. shared db
- да
- но лучше нет
74

75. shared code?
75

76. shared code
- да
- но лучше нет
- возможно что-то пошло не так
76

77. как от монолита к
микросервисам?
77

78. monolith -> microservices?
- постепенно
- рефакторинг
- реализация новых функций через микросервисы
78

79. начинать проект на
микросервисах?
79

80. новый проект на микросервисах?
- нет
80

81. Мартин Фаулер
- сначала монолит, а потом, если потребуется,
микросервисы
- у плохих команд микросервисы выходят много хуже
монолитов
81

82. readlist
- http://martinfowler.com/articles/microservices.html
- http://martinfowler.com/microservices/
- https://habrahabr.ru/post/249183/
- https://habrahabr.ru/post/261689/
- http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html
- http://microservices.io/patterns/index.html
82

83. D2D
vk.com/dev2dev

84. конец
dev2dev.ru
vk.com/oxffaa
akulyakov.artem@gmail.com