3. Цели
#msdevcon
Микросервисы Инструменты Чистый PaaS
Как управлять
микросервисной
архитектурой
На примере конкурса Мисс
Россия рассмотрим
возможности Azure
Зачем бизнесу
микросервисы?
Типовые проблемы
монолита
5. Цели бизнеса
Выбор лучшего решения для
бизнес-задачи без компромиссов
Нам нужна CRM
Покупаем SAP CRM
Но мы хотим SalesForce
Надо брать SAP CRM, потому что SAP у
нас уже есть, мы знаем, как с ним
работать, интеграция проще,
обновление проще и в целом SAP CRM
неплохая CRM-ка
Бизнес:
IT:
Бизнес:
IT:
Нам нужна CRM
Какая CRM лучше всего решит ваши
задачи?
SalesForce!
Ок, мы интегрируем SalesForce и текущей
инфраструктурой на SAP
Бизнес:
IT:
Бизнес:
IT:
6. Цели бизнеса
Поставка бизнес-ценности как можно
быстрее
Переходим с SAP CRM на BPM Online
Интеграция нового решения займет
полгода
Почему так долго?
<Объясняют какая паутина
взаимосвязей объединяет SAP CRM c
остальными приложениями в компании>
Бизнес:
IT:
Бизнес:
IT:
Переходим с SAP CRM на BPM Online
За неделю переключим точки интеграции
Что-то еще требуется для запуска?
Еще надо перелить данные и дописать
бизнес-функции, но это можно делать
параллельно с запуском новой CRM
Бизнес:
IT:
Бизнес:
IT:
7. Цели бизнеса
Дешево масштабировать сервисы, причем
только определенные и только когда это нужно
Сервис Тарификации к Черной пятнице
должен выдерживать нагрузку в 2 раза
больше обычной
Надо купить в 4 раза больше железа и
это даст ускорение на 30%
Почему так дорого и совсем не в 2
раза?
Ускорение в 2 раза будет стоить как вся
наша компания (прим. — при текущей
архитектуре)
Бизнес:
IT:
Бизнес:
IT:
Сервис Тарификации к Черной пятнице
должен выдерживать нагрузку в 2 раза
больше обычной
Ок, сейчас нажмем пару кнопок и
увеличим кол-во экземпляров сервиса,
чтобы масштабировать нагрузку.
Докупать что-то нужно?
Ресурсы в облаке, но только на время
нагрузки
Бизнес:
IT:
Бизнес:
IT:
8. АйТи берёт бизнес в заложники
«Монолитное» решение
становится вездесущим и
незаменимым для компании.
АйТи начинает диктовать
бизнесу свои условия в
выборе инструментов, сроков
и подходов к решению.
АйТи начальник
9. «Монолиты» берут компанию в заложники
UI
Business Logic
Database
Бизнес-функцию доработали, но она зависит от
других, поэтому ждем «большой заливки»
Можно эту бизнес-функцию заменить другим
решением, а остальное не трогать? Нет?
Скидки
Рассылки
10. Бизнесу плохо живется с
«монолитами».
Чувствуется это только в
условиях высокой конкуренции.
21. Service Discovery
Подскажет, где запущен «живой»
экземпляр требуемого сервиса
Умеет:
1. Регистрировать сервисы в своей базе
2. Проверять «жив» ли каждый
экземпляр сервиса
3. Балансирование нагрузки между
экземплярами одного сервиса
http://microservices.io/patterns/server-side-discovery.html
3
22. Легко масштабировать:
увеличивать и уменьшать
кол-во экземпляров
микросервиса
http://rabbitstack.github.io/cloud/microservices/from-monolithic-to-cloud-native-architectures/
23. Containers, Orchestration, IaC
Изолированная среда для разворачивания
микросервиса
Умеет:
1. 100% автоматизация
2. Инфраструктура, описанная кодом:
сравнение, расшаривание, повторяемость
при развертывании
3. Создание нужного окружения за
несколько минут
4. Управление сотнями контейнеров на
множестве серверов
5. Поддержка в Azure и AWS
6. Serverless
25. Задачи архитектора:
Добиться низкой связанности
микросервисов
Правильно распределить
ответственность между
микросервисами
Добиться полной автоматизации
27. Заработаем
1. Достижение бизнес-целей:
◦ Гибкость в выборе решений
◦ Ускорение поставок новых функций
◦ Гибкое масштабирование сервисов
2. Меньше людей, которые делают
ручную работу
3. Меньше железа, которое не приносит
деньги
28. Потратим
1. Вложение денег в переход
IT-инфраструктура, создание новых сервисов,
рефакторинг стартых сервисов
2. Переобучение сотрудников
3. Изменение орг. структуры
4. Дорогие специалисты с новыми
знаниями
5. Риск ошибиться в выборе
микросервисов
29. Выбор лучшего
решения для
бизнес-задачи без
компромиссов
Microservices, Microservices, Microservices!
Поставка бизнес-
ценности как
можно быстрее
Дешево
масштабировать
сервисы
35. Проблемы прошлой версии сайта
1. Медленно открывался во время конкурса из-за перегрузки
2. Выдавал 500-ошибку на главной и голосовании при перегрузки
любой части системы
3. Только вертикальное масштабирование
37. Как новой архитектурой достигнуть
бизнес-целей
1. Разделим приложение на (микро)ответственности
2. Каждая часть будет идеально исполнять свою роль
3. Каждая часть будет заботиться о своем
масштабировании
4. Тотальная автоматизация
38.
39. Графики нагрузочных тестов
• Нагружали через сеть с пропускной способностью 1Гбит/с.
• После ~5450 RPS видим первые проблемы с ответами сервера.
• Время ответа не превышало 1000 мс.
40. .NET Core и Kestrel
Kestrel под нагрузкой отвечал кодом 502.3, приложение
падало и не оживало до перезапуска.
Проблема в версии Kestrel (версия 1.1.0):
• https://github.com/aspnet/IISIntegration/issues/323
• https://github.com/aspnet/IISIntegration/issues/311
Проблема ушла после выхода пакета
Microsoft.AspNetCore.Server.Kestrel v1.1.1
41. CDN
1. Картинки кэшируются на 7 суток,
HTML обновляется 1 раз в час.
2. JavaScrpit и CSS новых версий
автоматом попадают в CDN, каждая
версия кэшируется отдельно.
3. Включено сжатие.
4. Можно вручную сбросить кэш.
5. Поддерживает только домены 3-го
уровня
missrussia.ru -> www.missrussia.ru
42. CDN Akamai vs Verizone
1. Akamai усиливает партнерские отношения с Российскик
интернет провайдерами.
ТТК договорился с Akamai Technologies, Inc. на размещение на новом узле оператора в Москве
кеш-серверов CDN-провайдера. (источник: http://www.comnews.ru/node/80287#ixzz4eUkmQKPe)
2. Быстрое развертывание нового endpoint-а:
• ~1 минута на Akamai
• >90 минут на Verizone
43. WebApp
1. Web и API развернуты в отдельных WebApp
2. Во время конкурса на тарифе S3, после
конкурса на тарифе S1
3. При изменении нагрузки:
• Scale Up: повышать/понижать мощность
сменой тарифа
• Scale Out: увеличивать кол-во инстансов
44. SQL Database
Что хорошего:
1. Сервис автоматически выполняет
резервное копирование каждые 5
минут.
2. Легко масштабировать за пару кликов
как вверх так и вниз.
3. Управление через веб-интерфейс.
4. Легко настраиваются различные
алерты.
До 50 rps с тарифом Standard 0
45. Service Bus vs Queue Storage
Требования к очереди:
• Обмен сообщениями небольшого размера с
коротким временем обработки;
• Отсутствие необходимости в транзакциях и
поддержки очередности обработки сообщений;
• Наличие клиента под .NET Core.
Решение проблем с производительностью:
• Подняли очереди в том же регионе, что и WebApi;
• Увеличили мощность серверов с WebApi;
• Зарегистрировали клиент Service Bus как Singleton.
46. WebJob и проверка голосов
1. Горизонтальное
масштабирование очередей
2. Горизонтальное
масштабирование WebJob
3. Сложные и тяжелые проверки
«накруток» масштабировались, не
влияя на основной сайт.
4. Выключаются из инфраструктуры
(платы) после голосования.
47. Service Fabric vs WebJob
WebJob
Для написания WebJob можно не
использовать специализированные SDK.
По сути WebJob — консольное приложение и
деплоить его достаточно просто.
Service Fabric
Для работы через Service Fabric под .NET
Core нужно устанавливать SDK из
специального репозитория Ubuntu. Это
создает проблемы и при деплое и при
разработке.
https://github.com/Azure/azure-content-
ruru/blob/master/articles/service-
fabric/service-fabric-create-your-first-linux-
application-with-java.md
Остальные статьи по этой теме предлагали
использовать .NET Framework v4.5.2, что
для нас было не приемлемо.
48. Continuous Delivery из коробки
1. При каждом пуше в Git-репозиторий в
ветку production начинается деплой
новой версии.
2. Web, API и сервисы голосования
собираются и разворачиваются
независимо.
3. Каждый деплой можно отследить через
панель Azure, посмотреть лог процесса и,
в случае необходимости, переразвернуть
предыдущие версии.
50. Выводы
Грамотная архитектура позволяет:
• Давать больше ресурсов на нагруженные
части, меньше на ненагруженные.
• Убрать влияние частей системы друг на друга.
• Под каждую часть выделяются ресурсы
только тогда, когда это требуется.
52. Выбор лучшего
решения для
бизнес-задачи без
компромиссов
Microservices, Microservices, Microservices!
Поставка бизнес-
ценности как
можно быстрее
Дешево
масштабировать
сервисы
53. Полезные ресурсы
#msdevcon
Подробнее в моих статьях
1. Useful Tools for Managing Complexity of Microservice Architecture
2. Clouds, iPaaS, Citizen Integrator and Why India’s Outsourcing Is Losing Money
3. Стратегия крупного ретейлера по изменению IT-архитектуры и процессов
54. Полезные ресурсы
#msdevcon
База знаний о микросервисах
1. Microservices Resource Guide
Martin Fowler
2. Microservice archite`cture patterns and best practices
Chris Richardson
56. Отзывы💖
Помогите нам стать лучше!
На вашу почту отправлена индивидуальная ссылка на электронную анкету.
Заполните анкету! Нам очень важно ваше мнение.
#msdevcon
Оставляйте отзывы в социальных сетях. Мы все читаем. Спасибо вам!