Монолит + микросервисы = любовь

Максим Филипенко (Marilyn, разработчик) @ Moscow Python Meetup 57
"Рассказ о том, как мы внедряли сервисную архитектуру в монолитный B2B-проект. Чем это было хорошо, чем это было плохо, как поменялся наш workflow".

Видео: http://www.moscowpython.ru/meetup/57/monolith-microservices-love/

Transcript

1. МОНОЛИТ + МИКРОСЕРВИСЫ = ❤ Филипенко Максим
2. mymarilyn.ru
3. Что было
5. Просто
6. Зачем менять?
7. Проблемы монолитов
8. • Кодовая база растет, её становится сложнее тестировать и поддерживать Проблемы монолитов
9. • Кодовая база растет, её становится сложнее тестировать и поддерживать • Связность между модулями может вызывать неожиданные баги Проблемы монолитов
10. • Кодовая база растет, её становится сложнее тестировать и поддерживать • Связность между модулями может вызывать неожиданные баги • Новым разработчикам сложно разобраться с проектом Проблемы монолитов
11. • Кодовая база растет, её становится сложнее тестировать и поддерживать • Связность между модулями может вызывать неожиданные баги • Новым разработчикам сложно разобраться с проектом • Выкатка занимает много времени (тесты!) Проблемы монолитов
12. • Кодовая база растет, её становится сложнее тестировать и поддерживать • Связность между модулями может вызывать неожиданные баги • Новым разработчикам сложно разобраться с проектом • Выкатка занимает много времени (тесты!) • Сложно обновляться и использовать новые технологии Проблемы монолитов
13. Python 2.7
14. Python 2.7
15. И всё?
16. Неразрешимые проблемы
17. • Переиспользование общей логики между командами с разным стеком Неразрешимые проблемы
18. • Переиспользование общей логики между командами с разным стеком • Использование несовместимых технологий Неразрешимые проблемы
19. Что мы стали использовать
20. Python 3.6+
21. Внутренние пакеты
22. • Где хранить Внутренние пакеты
23. • Где хранить • Как именовать Внутренние пакеты
24. • Где хранить • Как именовать • В каком случае нужно создавать Внутренние пакеты
25. • Где хранить • Как именовать • В каком случае нужно создавать • Версионирование Внутренние пакеты
26. • Где хранить • Как именовать • В каком случае нужно создавать • Версионирование • Changelog изменений Внутренние пакеты
27. deploy_pypi: stage: deploy only: - master script: … - echo "repository="$PYPI_REPO_URL >> ~/.pypirc - echo "username="$PYPI_USER >> ~/.pypirc - echo "password="$PYPI_PASSWORD >> ~/.pypirc - python3 setup.py sdist bdist_wheel upload -r pypi-internal Внутренние пакеты Тестируются и загружаются в локальный PyPI через Gitlab CI
28. Docker
29. Docker-compose
30. services: app: image: development build: context: . dockerfile: ./docker/development/Dockerfile depends_on: - base links: - postgres - redis environment: - REDIS_URI=redis://redis:6379/0 ports: - "5000:80" command: flask run --host=0.0.0.0 --port=80 postgres: image: postgres:10.0 ports: - "55432:5432" redis: ...
31. $ git clone path-to-git-repo $ cd path-to-git-repo $ docker-compose up ... app_1 | Running command: flask run --host=0.0.0.0 --port=80 app_1 | * Running on http://0.0.0.0:80/ (Press CTRL+C to quit) app_1 | * Restarting with stat app_1 | * Debugger is active! Начало работы над проектом
32. Swagger
34. Взаимодействие между сервисами
35. • HTTP JSON API Взаимодействие между сервисами
36. • HTTP JSON API • RESTful Взаимодействие между сервисами
37. • HTTP JSON API • RESTful • JWT Взаимодействие между сервисами
38. Gitlab
39. Gitlab CI или Jenkins?
40. stages: - build - test - cleanup - publish … test: stage: test script: - '$DOCKER_COMPOSE run app py.test -p no:cacheprovider’ publish master: stage: publish only: - master script: - 'docker build -f docker/base/Dockerfile -t $CI_REGISTRY_IMAGE/base-master .' ... - 'docker push $CI_REGISTRY_IMAGE/base-master' ...
41. Kubernetes
42. Тестирование Pytest + FactoryBoy
43. 100% code coverage
44. Тестирование: проблемы
45. • Тестировать – сложно Тестирование: проблемы
46. • Тестировать – сложно • Написать хороший тест – еще сложнее Тестирование: проблемы
47. • Тестировать – сложно • Написать хороший тест – еще сложнее • 100% code coverage не гарантирует НИЧЕГО (особенно когда есть внешние API) Тестирование: проблемы
48. • Тестировать – сложно • Написать хороший тест – еще сложнее • 100% code coverage не гарантирует НИЧЕГО (особенно когда есть внешние API) • Сложная логика между сущностями Тестирование: проблемы
49. Тестирование: решение
50. • Не пытаться протестировать все возможные ответы площадок Тестирование: решение
51. • Не пытаться протестировать все возможные ответы площадок • На каждый endpoint должны быть тесты Тестирование: решение
52. • Не пытаться протестировать все возможные ответы площадок • На каждый endpoint должны быть тесты • Для имитации сетевого взаимодействия использовать mock и responses Тестирование: решение
53. • Не пытаться протестировать все возможные ответы площадок • На каждый endpoint должны быть тесты • Для имитации сетевого взаимодействия использовать mock и responses • Декларативное создание сущностей (FactoryBoy) Тестирование: решение
54. • Не пытаться протестировать все возможные ответы площадок • На каждый endpoint должны быть тесты • Для имитации сетевого взаимодействия использовать mock и responses • Декларативное создание сущностей (FactoryBoy) Тестирование: решение
55. @pytest.fixture(scope="session") def session(db_fixture): db_fixture.session.begin() yield db_fixture.session db_fixture.session.remove() @pytest.fixture(scope="function") def transaction(session): session.begin(nested=True) try: yield session finally: session.rollback() @pytest.fixture(scope=“function") def mock_contextmanager(session): with patch('src.yourmodule.contextmanager') as mocked: mocked_context = MagicMock() mocked_context.__enter__.return_value = session mocked.return_value = mocked_context yield mocked
56. Новая функциональность: ⦿ монолит? ⦿ а может быть микросервис?
57. Когда НЕ НУЖНО заводить микросервис
58. • Нет понимания, что должен делать сервис Когда НЕ НУЖНО заводить микросервис
59. • Нет понимания, что должен делать сервис • Вынесение должно быть обоснованным Когда НЕ НУЖНО заводить микросервис
60. • Нет понимания, что должен делать сервис • Вынесение должно быть обоснованным • Если нужен простой CRUD Когда НЕ НУЖНО заводить микросервис
61. Что получилось
63. Сложно
64. Стало ли хуже?
65. Минусы
66. • Связи между сервисами накладывают определенную сложность Минусы
67. • Связи между сервисами накладывают определенную сложность • Сложность и особенности предметной области никуда не делись Минусы
68. • Связи между сервисами накладывают определенную сложность • Сложность и особенности предметной области никуда не делись • Тулинг пока отстает Минусы
69. • Связи между сервисами накладывают определенную сложность • Сложность и особенности предметной области никуда не делись • Тулинг пока отстает • Администрирование стало сложнее Минусы
70. Плюсы
71. • Удалось добиться переиспользования логики между командами Плюсы
72. • Удалось добиться переиспользования логики между командами • Можно работать над задачами не вникая в старый код Плюсы
73. • Удалось добиться переиспользования логики между командами • Можно работать над задачами не вникая в старый код • Можно быстро вносить и выкатывать изменения Плюсы
74. • Удалось добиться переиспользования логики между командами • Можно работать над задачами не вникая в старый код • Можно быстро вносить и выкатывать изменения • Легко подбирать подходящий инструмент под конкретную задачу Плюсы
76. prokaktus prokaktus mfilipenko@yandex.ru Филипенко Максим
77. Спасибо!