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
360
Введение в микросервисную архитектуру
Вводная лекция для студентов одной из проектных лабораторий НГУ
Vladimir Plizga
January 28, 2020
Tweet
Share
More Decks by Vladimir Plizga
See All by Vladimir Plizga
Заметки о беге
toparvion
0
100
Измерь меня полностью
toparvion
0
93
Экскурсия в бэкенд Интернета вещей
toparvion
0
200
Как внедрять тестовое поведениев чистовой код?
toparvion
0
250
Spring Boot «fat» JAR: Тонкие части толстого артефакта
toparvion
0
320
Краткий экскурс в Spring Security (core)
toparvion
0
250
Инъекция тестовых поведений: как выйти сухим из воды?
toparvion
0
260
HTTPs и его прикладные друзья
toparvion
0
130
Сетевой стек TCP/IP
toparvion
0
180
Other Decks in Programming
See All in Programming
StreamlitとTerraformでデータカタログを作った話
gussan0223
0
300
CA.swift19 恋するAIアプリ開発の裏側
oskmr
0
340
甘い香りに誘われてVanilla Extractを1年間運用してみた
miyahkun
1
110
Folding Cheat Sheet #3
philipschwarz
PRO
0
110
Ruby GitHub Packages
bkuhlmann
0
620
データアナリストが行うDatabricksを活用したETLの自動化事例
shinoa
0
250
Elm 0.19.0 Changes
bkuhlmann
0
480
GitHub Actionsで泣かないためにやっておきたい設定 / Recommended GHA settings to avoid crying
pinkumohikan
3
490
App Router への移行は「改善」となり得るのか?/ Can migration to App Router be an improvement
takefumiyoshii
8
2.1k
Front-end application development, Symfony-style(s)
dunglas
2
1.9k
CircleCIを活用して AWSへの継続的デリバリーを 実践する
coconala_engineer
1
230
Java 22 Overview
kishida
1
170
Featured
See All Featured
How GitHub Uses GitHub to Build GitHub
holman
468
290k
Debugging Ruby Performance
tmm1
70
11k
In The Pink: A Labor of Love
frogandcode
138
21k
Statistics for Hackers
jakevdp
789
220k
Designing the Hi-DPI Web
ddemaree
276
33k
Building an army of robots
kneath
300
41k
The Invisible Side of Design
smashingmag
294
49k
Infographics Made Easy
chrislema
237
18k
The Brand Is Dead. Long Live the Brand.
mthomps
48
28k
Code Review Best Practice
trishagee
54
15k
How to Ace a Technical Interview
jacobian
272
22k
The Art of Programming - Codeland 2020
erikaheidi
41
12k
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