Каждый развивающий бизнес на определенном этапе своего жизненного цикла сталкивается с задачей масштабирования. Для монолитного приложения эта задача может оказаться сложнее, чем написать с нуля масштабируемую систему - потому что нужно учитывать миграцию данных и пользователей, а также недостаточные ресурсы. Мы попытаемся понять, в каких случаях монолит распиливать стоит, а когда можно применить более простые подходы. Рассмотрим преимущества и недостатки монолитной архитектуры и микросервисной. Разберем несколько стратегий распиливания монолита, а также аспекты, которые необходимо учесть во время этого процесса.

2. Software Craftsmanship
meetup #14 online
Splitting Monolith
Павел Вейник
CEO @ Hard & Soft Skills

3. Мы сегодня online
●Зарегистрировались более 180
человек
●Наш четвертый митап online
●При поддержке Sam Solutions
●Информационный партнер
dev.by
3

4. Цель митапов
● Опробовать материал для курса
“Технический лидер” DONE
○ hardsoftskills.by/techlead.html
● Отладить материал для других
курсов
4

5. План митапов
11. Мотивация и эффективность
разработчика
12. Highload системы
13. Многопоточные вычисления
14. Масштабирование монолита
15. Карьера разработчика
https://bit.ly/3cFSBAB
5

6. Что интересует вас по M
● М или мс?
● Тестирование мс
● Архитектура мс
● Плохой и
хороший опыт
● взаимодействие
мс
● Обзор подходов
● Примеры
● Когда пилить?
6

7. Цель этого митапа
Сделать обзор разделения
монолита на мс
7

8. План этого митапа
1.Монолит vs микросервисы
2.Бизнес-контекст. Когда пилить?
3.Зачем пилить?
4.Переходный период
5.Что учесть?
6.Планируем переход
8

9. 9

10. Монолит
● просто писать
● просто тестировать
● просто деплоить
● простое горизонтальное
масштабирование
10

11. Монолит
● ограничены размер и
сложность
● сложно быстро изменять
● долгий старт приложения
● полный деплой при
обновлении приложения
11

12. Монолит
● непредсказуемые
последствия изменения
● сложно сделать CI/CD/CD
● потенциальные конфликты
ресурсов
12

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

14. Микросервисы
● Снижают сложность
отдельных компонентов
● Каждый мс можно писать
независимо
● Проще применять новые
технологии
14

15. Микросервисы
● Проще настроить CI/CD/CD
● Каждый мс масштабируется
независимо
● Сложно вносить изменения,
затрагивающие несколько мс
● Сложный деплой
15

16. Микросервисы
● система с мс всегда
распределенная
● разделенная между мс бд:
распределенные tx или
eventual constistency
16

17. Контекст бизнеса
● Начало работы
● Больше клиентов
● Еще больше - не хватает
мощностей
● Больше фич, сложнее
система
17

18. Контекст бизнеса
● Быстрее релизить новые фичи
● Применить новые технологии
(и улучшить опр. параметры)
● Перейти в облако
18

19. Когда пилить?
● Высокая сложность
○ порог входа
○ новые технологии
○ невероятные баги
● Не хватает scale
● Медленные релизы
19

20. Рассмотрите опции
● Можно размножить монолит,
разделив данные
● Можно масштабироваться
вертикально
● Можно масштабировать
только бд
20

21. Масштабирование21

22. Мс не всегда лучше
● Можно размножить монолит,
разделив данные
● Можно масштабироваться
вертикально
● Можно смасштабировать
только бд
22

23. Подходы к разделению
● “Лижем мороженое”
○ меньше рисков
○ больше времени
○ длинный переходный
период
23

24. Подходы к разделению
● “Играем в лего”
○ быстрее
○ наследуем внутренние
проблемы монолита
○ больше рисков
24

25. Подходы к разделению
● Переписываем с нуля
○ продумываем все наново
○ синдром второй системы
○ период перехода, монолит
не развивается
25

26. На что обратить внимание
● Canary releases
● Работа с библиотеками
● Безопасность
● Логирование
● Мониторинг
● Версионность API
26

27. На что обратить внимание
● Коммуникации мс
○ Service mesh
● Разделение базы
● Availability
● Контейнеризация
● CI/CD/CD
27

28. На что обратить внимание
● Разделяемые решения о
языках, платформах,
технологиях, подходах…
● Границы мс расплываются со
временем и пониманием
(bounded context)
28

29. На что обратить внимание
● Управление конфигурациями
● Динамическое
масштабирование в облаке
● Отказоустойчивость by design
● Инструменты отладки
системы целиком
29

30. Canary releases30

31. Библиотеки
● пока есть М и мс - они
используют общие либы
● зависимости (либы) мс
убираем в длинной
перспективе, не сразу
31

32. Библиотеки
● Авторизацию и
аутентификацию выделяем в
либу или переделываем
● JWT
32

33. Безопасность
● Продумать заново
● Ручные настройки TLS
● Разделение на подсети
○ API Gateway
○ прокси
33

34. Логгирование
● Централизованное хранение
логов
○ ELK/Kibana
● Message/Request id
34

35. Мониторинг
● Создать health check для
каждого мс
● Устранить single points of f
● Исключить эффект домино
● Продумать обработку
ошибок
35

36. API versioning
● URI/headers/content/params
● Документация
● Зависимости между мс
36

37. Коммуникации мс
● Хореография
● Оркестрация
● Шина сообщений
● Форматы
37

38. Service mesh
● шаблон для общения мс
38

39. Availability
● Продумывать отдельно для
каждого мс
● Разные гео, датацентры и тп
39

40. Контейнеризация
● Docker
● Kubernetes
40

41. Бд и мс
● Общая или отдельные?
○ по мере перехода
● Транзакции
○ распределенные?
● Consistency
○ eventual?
41

42. Необходимые знания
● Network perfomance
● Контейнеризация
● API/RPC/socket/MQ
● Cloud
○ vendor lock
42

43. Составляем план
● Понимаем цель
● Определяем архитектуру мс
● Определяем стратегию
перехода
43

44. Составляем план
● Обеспечиваем тесты
○ unit
○ integration
● Смотрим на что обратить
внимание по списку выше
44

45. Составляем план
● Проектируем способ деплоя
○ prod
○ staging
○ test…
● Проектируем API versioning
45

46. Составляем план
● Проектируем документацию
○ форматы, версии, конф
○ SLA
○ общие для всех мс решения
46

47. Курсы
● Цель митапов - материалы для
различных курсов
● Для мидлов, сеньеров, лидов,
архитекторов, CTO
● 16-го июня первое занятие
“Технический лидер”
47

48. Ссылки
монолит vs микросервисы, общее
● https://martinfowler.com/articles/microservices.html
● https://articles.microservices.com/monolithic-vs-microservices-architecture-5c4848858f59
● http://www.antonkharenko.com/2015/06/notes-on-fallacies-of-distributed.html
● https://dev.to/alex_barashkov/microservices-vs-monolith-architecture-4l1m
разделение монолита
● https://buttercms.com/books/microservices-for-startups/should-you-break-up-your-monolithic-application
● https://martinfowler.com/articles/break-monolith-into-microservices.html#TheMicroserviceEcosystemDestination
● https://www.nginx.com/blog/refactoring-a-monolith-into-microservices/
● https://microservices.io/refactoring/
● https://dzone.com/articles/breaking-a-monolith-into-microservices-best-practi
● https://medium.com/@walkingtreetech/strategies-to-migrate-monolithic-application-to-microservices-b2028eb4873b
● https://medium.com/@NeotericEU/how-can-you-refactor-a-monolithic-application-into-microservices-2eef8e323840
● https://www.springboottutorial.com/breaking-a-monolith-into-microservices
● https://docs.microsoft.com/en-us/azure/architecture/microservices/migrate-monolith
● https://www.ben-morris.com/how-to-decompose-that-monolith-into-microservices-gently-does-it/
48

49. Ссылки
service mesh
● https://habr.com/ru/company/flant/blog/327536/
● https://www.redhat.com/en/topics/microservices/what-is-a-service-mesh
книги
● https://www.oreilly.com/library/view/monolith-to-microservices/9781492047834/
● https://www.oreilly.com/library/view/practical-microservices/9781680507782/
разделение бд
● https://www.oreilly.com/library/view/monolith-to-microservices/9781492047834/ch04.html
API versioning
● https://www.xmatters.com/blog/devops/blog-four-rest-api-versioning-strategies/
49