Ответ
High Cohesion (высокая связность) в контексте микросервисной архитектуры означает, что каждый микросервис должен быть сфокусирован на выполнении одной четко определённой бизнес-возможности (business capability) или поддомена (bounded context). Все его компоненты (код, данные, конфигурация) тесно связаны между собой и работают для достижения этой единой цели.
Принцип на практике:
- Сервис "Заказы" (Order Service) отвечает только за жизненный цикл заказа: создание, изменение статуса, история.
- Сервис "Оплата" (Payment Service) отвечает только за обработку платежей и взаимодействие с платёжными шлюзами.
- Сервис "Доставка" (Shipping Service) отвечает только за логистику и отслеживание посылок.
Преимущества High Cohesion в микросервисах:
- Упрощение понимания и разработки: Разработчик работает в чётко очерченном контексте.
- Независимое развёртывание: Изменения в сервисе "Заказы" не требуют пересборки и перезапуска сервиса "Оплата".
- Гранулярное масштабирование: Можно масштабировать только тот сервис, который испытывает высокую нагрузку (например, "Оплата" в час пик).
- Повышение отказоустойчивости: Сбой в одном сервисе не обязательно приводит к падению всей системы.
Как достичь High Cohesion? Применяя Domain-Driven Design (DDD) для выявления bounded context и следуя Принципу единственной ответственности (SRP) на уровне сервиса. Сервис должен меняться только по одной причине — из-за изменений в его конкретном бизнес-домене.
Ответ 18+ 🔞
Э, слушай, давай разберёмся с этой вашей "высокой связностью", а то как будто на дворе 2002-й год и все только про модульные монолиты говорят.
Представь, что у тебя есть три чувака в одной квартире-коммуналке. Один — Сервис "Заказы". Его работа — только заказы. Получил заявку, создал ордер, статус поменял — всё, его дело сделано. Он не лезет в холодильник к соседу, не пытается посчитать сдачу и уж тем более не знает, как доставлять посылку до Урюпинска. Его контекст — заказ, и всё, ебушки-воробушки. Чётко, ясно, ни хуя себе как просто.
Второй — Сервис "Оплата". Это тот самый тип, который только про деньги и думает. Карты, шлюзы, инвойсы, откаты транзакций — его вотчина. Ему да похуй, что заказали — пиццу или бульдозер. Его работа — деньги списать или вернуть. И всё.
Третий — Сервис "Доставка". Ну, тут и ежу понятно: треки, склады, курьеры, маршруты. Он знает, где сейчас твой заказ, но понятия не имеет, сколько за него заплатили.
Вот это и есть High Cohesion, ёпта. Каждый сервис — как хитрая жопа, которая знает своё место и делает только своё, одно, но овердохуища хорошо. Не лезет в дела других, не создаёт бардак.
А теперь, почему это круто, а не просто модное словечко:
- Разработчику проще. Не нужно держать в голове всю систему, как будто ты гугл-карты. Зашёл в свой сервис — и ты в своей песочнице. Твой контекст, твои правила. Волнение ебать — ноль.
- Задеплоить можно по одному. Поправил баг в "Оплате"? Выкатил только её. Не нужно всю эту махину из 50 сервисов пересобирать, терпения ноль ебать на это.
- Масштабируется точечно. Чёрная пятница, все платят? Гони побольше инстансов "Оплаты"! А "Доставка" пусть себе потихоньку работает. Не нужно всю систему раздувать, как пузырь.
- Отказоустойчивость. Если "Доставка" накрылась медным тазом на полчаса, это не значит, что люди перестанут делать заказы или платить. Система-то жива, просто одна функция временно в ауте.
Как этого добиться? Да не выдумывать велосипед, бля. Берёшь Domain-Driven Design (DDD), находишь эти самые bounded context'ы (границы ответственности, проще говоря) и для каждого лепишь свой микросервис. И следишь, чтобы он следовал Принципу единственной ответственности (SRP), но уже на уровне сервиса. Меняться он должен только по одной причине — если поменялись требования именно в его зоне, в его домене. Не потому что в соседнем что-то поменялось, а потому что тут бизнес-логику переписали.
Короче, смысл в том, чтобы сервисы были как хорошие специалисты — узкие, но глубокие, а не как распиздяи, которые везде суют свой нос и в итоге нихуя не делают как следует.
