"Автоматизация разработки микросервисной архитектуры на Node.JS с использованием современных инструментов"
Докладчик: Senior JS Developer @light-it - Дмитрий Куликов
3. Развитие монолитного приложения
сложность системы постоянно растет
система переходит из поколения в поколение, ни один разработчик не знает
систему полностью;
отслеживание и устранении ошибок занимает все больше времени;
дорого вносить изменения;
“застревание” на технологиях;
монолит трудно “разобрать” для тестирования;
приложение тесно связано с выбранной технологией реализации.
4. Что же такое микросервисная архитектура?
Это архитектурный шаблон, в котором сервисы:
1. маленькие: один сервис - одна бизнес-задача,
2. сфокусированные: cервис решает только одну бизнес-задачу, и решает ее
хорошо,
3. слабосвязанные: изменение одного сервиса не требует изменений в другом,
4. высокосогласованные: сервис содержит все нужные методы решения
поставленной задачи.
5. Микросервисы - за и против
+
● меньше кода
● можно выбрать оптимальную
технологию для каждой задачи
● гибкое масштабирование
● простое добавление unit-тестов
● легкость обновления
● управление небольшой командой
разработчиков
● модульность
-
● множество сетевых взаимодействий
● большое количество асинхронных
операций
● высокие требования к devOps команде
● сложность тестирования всего
приложения
● необходим мониторинг
согласованности данных
● средства обеспечения безопасности
для микросервисной архитектуры
находятся в стадии разработки
11. Сообщение в Seneca
Много небольших процессов, которые выполняют единственную задачу и
делают это хорошо. Общаются друг с другом при помощи асинхронных
сообщений.
“Tweet a message” выполняемый
TwitterService
{
command: “tweet”,
message: “Hello, World!”,
author: “Me”
}
TwitterService
Видит command: “tweet”.
Это мое сообщение!
Не важно как оно доставлено,
остальные детали также не
имеют значения.