Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Введение в микросервисную архитектуру
Search
Vladimir Plizga
January 28, 2020
Programming
0
420
Введение в микросервисную архитектуру
Вводная лекция для студентов одной из проектных лабораторий НГУ
Vladimir Plizga
January 28, 2020
Tweet
Share
More Decks by Vladimir Plizga
See All by Vladimir Plizga
Путеводитель по анализу памяти JVM
toparvion
0
43
Заметки о беге
toparvion
0
170
Измерь меня полностью
toparvion
0
160
Экскурсия в бэкенд Интернета вещей
toparvion
0
290
Как внедрять тестовое поведениев чистовой код?
toparvion
0
310
Spring Boot «fat» JAR: Тонкие части толстого артефакта
toparvion
0
400
Краткий экскурс в Spring Security (core)
toparvion
0
280
Инъекция тестовых поведений: как выйти сухим из воды?
toparvion
0
350
HTTPs и его прикладные друзья
toparvion
0
140
Other Decks in Programming
See All in Programming
asdf-ecspresso作って 友達が増えた話 / Fujiwara Tech Conference 2025
koluku
0
1.4k
DevFest - Serverless 101 with Google Cloud Functions
tunmise
0
140
Amazon Nova Reelの可能性
hideg
0
200
LLM Supervised Fine-tuningの理論と実践
datanalyticslabo
8
1.9k
週次リリースを実現するための グローバルアプリ開発
tera_ny
1
1.2k
はてなにおけるfujiwara-wareの活用やecspressoのCI/CD構成 / Fujiwara Tech Conference 2025
cohalz
3
2.7k
為你自己學 Python
eddie
0
520
見えないメモリを観測する: PHP 8.4 `pg_result_memory_size()` とSQL結果のメモリ管理
kentaroutakeda
0
940
PHPで学ぶプログラミングの教訓 / Lessons in Programming Learned through PHP
nrslib
4
1.1k
良いユニットテストを書こう
mototakatsu
11
3.6k
オニオンアーキテクチャを使って、 Unityと.NETでコードを共有する
soi013
0
370
Flatt Security XSS Challenge 解答・解説
flatt_security
0
730
Featured
See All Featured
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
Optimising Largest Contentful Paint
csswizardry
33
3k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
19
2.3k
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
356
29k
Building Flexible Design Systems
yeseniaperezcruz
328
38k
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Art, The Web, and Tiny UX
lynnandtonic
298
20k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Building Adaptive Systems
keathley
38
2.4k
The Invisible Side of Design
smashingmag
299
50k
The Power of CSS Pseudo Elements
geoffreycrofte
74
5.4k
Practical Orchestrator
shlominoach
186
10k
Transcript
Введение в микросервисную архитектуру НГУ, январь’20
Привет! Я – Владимир Плизгá ⬗ Java разработчик (backend) ⬗
TechLead серверной команды PrePaid ⬗ ≈8 лет в деле 2
1. Для начала Цели и вопросы
Что это такое? Оставим вопрос открытым. Пока нам достаточно интуитивного
понимания. 4
Цель – ответить на 1 вопрос: 5 НАФИГА? ДЛЯ ЧЕГО
ЭТО ВООБЩЕ НУЖНО?
“Всё познаётся в сравнении… 6
2. Традиционный подход Как учили нас деды
1 человек – 1 программа (aka 1:1) ⬗ Абсолютно нормальный
подход ⬗ Используется давно ⬗ Подходит многим ⬗ Вряд ли исчезнет 8
Масса позитивных примеров ⬗ Лабораторная/курсовая работа ⬗ Домашний сайт ⬗
Десктопная/консольная утилита ⬗ Telegram-бот ⬗ Мобильное приложение ⬗ (впиши своё) 9
Причины успеха ⬗ Программа умещается в 1 голове ⬗ Легко
меняется (даже вся) ⬗ Мало пользователей ⬗ Можно обновлять редко и полностью 10 Потому что маленький!
А что дальше? С ростом возможностей растут и сложности 11
12 1 000 5 000 10 000 500 000 0
2 000 4 000 6 000 8 000 10 000 12 000 14 000 Строк кода (LoC) Примерные размеры программ Курсач Хомяк Настолка Интернет-банк
1 000 5 000 10 000 500,000 1,000,000 5,000,000 0
1,000,000 2,000,000 3,000,000 4,000,000 5,000,000 Строк кода (LoC) Примерные размеры программ Курсач Хомяк Настолка Интернет-банк Биллинг АБС
Сложности большого приложения ⬗ Не помещается в 1 голове ⬗
Меняется всё труднее ⬗ Сложно разбираться 14
15
Сложности большого приложения ⬗ Не помещается в 1 голове ⬗
Меняется всё труднее ⬗ Сложно разбираться ⬗ Много неочевидных связей 16
17 https://twitter.com/glorphindale/status/1199663658193891328
Сложности большого приложения ⬗ Не помещается в 1 голове ⬗
Меняется всё труднее ⬗ Сложно разбираться ⬗ Много неочевидных связей ⬗ Страшно что-то менять 18
19
Следствия растущей популярности ⬗ Нужны обновления ⬗ Часто ⬗ Выборочно
⬗ Незаметно ⬗ Нужно масштабирование 20
21 Ситуация глазами разработчика ⬗ Трудно развивать приложение ⬗ Любая
правка чревата ⬗ Стек технологий фиксирован ⬗ Проект превращается в болото ☹ Зато болото большое!
3. Микросервисы Желанное спасение. Или нет.
Разделяй и властвуй Человеческая мудрость и инженерный подход в одном
флаконе 23
«Divide Et Impera» в действии Модули Классы и пакеты в
ООП. Помогают бороться с паразитными связями в исходном коде. Библиотеки JAR, DLL, PYM, … Помогают (частично) обновлять приложение частями. SOA Service Oriented Architecture. Помогает (частично) бороться с простоями. 24
Microservice Architecture (MSA) Декомпозиция приложения на отдельно разрабатываемые, поставляемые и
запускаемые модули. 25
Место MSA в арсенале декомпозиции 26 Классы/пакеты ≈ тысячи штук
Библиотеки ≈ сотни штук SOA/MSA ≈ десятки штук
монолит VS микросервисы 27 https://martinfowler.com/articles/microservices.html
28 Свойства микросервисов (1/3) ⬗ Построены вокруг бизнес-нужд ⬗ Одна
функция ≈ один сервис ⬗ Команда, которую можно накормить одной пиццей
29 Свойства микросервисов (2/3) ⬗ Соблюдают строгий контракт взаимодействия: ⬗
Общение только через API ⬗ У каждого своя БД (схема)
30 Свойства микросервисов (3/3) ⬗ 12 факторов cloud-native приложения ⬗
Упрощают разработку ⬗ Упрощают поставку (особенно в облако ☁) ⬗ Включают лучшие практики
31 Эти свойства возвращают лучшее ⬗ Программа умещается в 1
голове ⬗ Легко меняется (даже вся) ⬗ Можно обновлять редко и полностью Потому что маленький!
4. Прививки реальности Неочевидные особенности микросервисной архитектуры
И вот у нас микросервисы. Но так ли всё просто?
Photo by Kostiantyn Stupak from Pexels
1. Как направлять клиентский трафик? ⬗ В обычном приложении: ⬗
Клиент встроен ⬗ Сервер один ⬗ Адрес фиксирован 34
35
⬗ А что если: ⬗ Клиентов много? ⬗ Среди них
мобилки? ⬗ Серверов много? ⬗ Сервера реплицированы? 36 1. Как направлять клиентский трафик?
Точка входа (API Gateway) 37 https://docs.microsoft.com/en-us/azure/architecture/includes/images/microservices-logical.png
Точка входа (API Gateway) тащит 38 ⬗ Маршрутизацию ⬗ Безопасность
⬗ Трансляцию протоколов ⬗ Кэширование ⬗ Агрегацию запросов ⬗ Мониторинг
2. Как сервисам находить друг друга? ⬗ В обычном приложении:
⬗ Сервер знает, где он ⬗ Адрес фиксирован ⬗ Сервер один 39
2. Как сервисам находить друг друга? ⬗ А что если:
⬗ Сервисов много? ⬗ Сервисы реплицированы? ⬗ Адреса динамические? 40 Прописывать вручную уже не вариант
Реестр сервисов (Service Registry) 41 https://blog.mazarin.lk/wp-content/uploads/2016/08/microservices.png
Реестр сервисов помогает 42 ⬗ В упрощении конфигурации ⬗ В
работе в эластичной среде ☁ ⬗ В балансировке нагрузки ⬗ В мониторинге
Реестр сервисов участвует 43 https://www.eclipse.org/community/eclipse_newsletter/2017/september/images/image006_sm.png
Итог: +2 сервиса на ровном месте! ⬗ Каждый надо разработать*!
⬗ У каждого свой жизненный цикл ⬗ Каждый требует поддержки ⬗ И это еще не всё! * обычно на основе библиотеки 44
А для частых релизов ещё нужно… ⬗ Тестировать (постоянно!) ⬗
Учитывать окружения ⬗ Контролировать безопасность ⬗ Предоставлять мониторинг ⬗ Обеспечивать логирование 45
А для частых релизов ещё нужно… ⬗ Continuous Integration &
Delivery (CI/CD) ⬗ Контейнеризация (Docker) ⬗ Оркестрация (Kubernetes) ⬗ Культура (DevOps) 46
47 А ещё для частых релизов пригодится…
48
5. Примеры Связь с реальным миром
Да кому это вообще надо?!. 50 . . .
51 https://spring.io/blog/2015/07/14/microservices-with-spring
52 Пример с такси https://www.nginx.com/ blog/introduction-to-microservices/ По мотивам архитектуры UBER’а
55
6. Заключение Выжимки и выводы
“… you shouldn't start a new project with microservices, even
if you're sure your application will be big enough to make it worthwhile. 57 https://martinfowler.com/bliki/MonolithFirst.html Martin Fowler
Недостатки MSA ⬗ Накладные расходы на сеть ⬗ Сложность релиза
⬗ Трудоемкость мониторинга ⬗ Зоопарк технологий ⬗ … 58
Преимущества MSA ⬗ Компактность кода сервисов ⬗ Изоляция изменений ⬗
Гибкое масштабирование ⬗ Локальность обновлений ⬗ Соответствие командам ⬗ … 59
Выводы ⬗ MSA – не новшество ⬗ и не серебряная
пуля ⬗ Высокий порог вхождения ⬗ Единственный путь развития для одновременно мощных и гибких высоконагруженных приложений* 60
* это и есть ответ на вопрос: 61 НАФИГА? ДЛЯ
ЧЕГО ЭТО ВООБЩЕ НУЖНО?
Резюме 62 Микросервисы – ужасный способ построения сложных веб-приложений. Но
лучше пока ничего не придумано.
63 Спасибо! Время для вопросов Владимир Плизгá @toparvion Toparvion https://toparvion.pro/talk/2020/shift-nsu-winter/
Credits Special thanks to all the people who made and
released these awesome resources for free: ⬗ Presentation template and backgrounds by SlidesCarnival ⬗ Photographs by Unsplash & Pexels 64