Как вы определяете, каким должен быть микросервис? - PullRequest
0 голосов
/ 10 июня 2018

Если я создаю масштабируемое приложение, которое следует микросервисной архитектуре, как вы решаете, какие компоненты приложения должны быть самостоятельной службой?Например, веб-сайт, такой как Facebook, может быть разделен на очень широкие сервисы, новостную ленту, мессенджер, поиск и т. Д., Или он может быть разделен на более мелкие сервисы для каждого из них.Как правильно разделить приложение на сервисы для обеспечения масштабируемости и эффективности?

Ответы [ 2 ]

0 голосов
/ 10 июня 2018

У разрушения микросервисов нет жестких правил.Это зависит от нескольких факторов.По моему опыту, это в основном зависит от этих двух ключевых факторов.

  • точка зрения зависимостей
  • точка зрения бизнеса

Давайте вернемся к нашей идее разрушения микросервисов.Мы хотели бы развернуть наши сервисы как независимые модули таким образом, чтобы доступность каждого была независимой.Таким образом, мы работаем над достижением цели: один сервис не работает, значит только один недоступен в это время.Другие доступны.

Теперь давайте рассмотрим два фактора, которые я упомянул.

(1) Зависимости (модели, библиотеки, базы данных и т. Д.)

Давайте рассмотрим простой сценарий, просто чтобы понять идею.Представьте, что есть платформа онлайн-ритейлера.Там у нас есть набор независимых (сегрегированных) таблиц БД для хранения данных запасов, связанных с одеждой.И это так, что труднее сломать дальше (например: различная сегрегация для женской одежды, мужской одежды и т. Д.).

Итак, здесь, когда мы собираемся разрабатывать API-сервисы, мы можем принять решение предоставить отдельный микросервис для одежды (поскольку у нас есть набор независимо разделенных таблиц для этого раздела), но не разбивать какие-либодалее как разделы одежды (так как не могут больше разделять эти таблицы).Обратите внимание, что здесь, поскольку у нас есть отдельное разделение БД для одежды, любой сбой БД для этого разделения не повлияет на другие службы (и наоборот).И просто подумайте, что произойдет, если мы сломаем сервисы дальше (отдельные микросервисы для женской одежды / мужской одежды и т. Д.).Поскольку у нас есть одна общая сегрегация БД для всех, если эта общая зависимость исчезнет, ​​все службы будут отключены.Так что нет смысла пытаться прорваться дальше, так как нет увеличения доступности.

(2) Бизнес

Я приведу приведенный выше пример здесьтакже.Давайте возьмем бизнес-операции, такие как клиентские платежи.Поскольку это важная часть бизнеса, большую часть времени мы можем сделать вывод, что собираемся сделать отдельный микросервис для платежей.Несколько минут недоступности клиентских платежей могут стоить бизнесу миллионы.Поэтому мы хотели бы сделать его отдельным независимым микросервисом и уделить ему особое внимание, когда речь идет о развертывании.

Наконец, поскольку вы упомянули о Facebook, я полагаю, что эти микросервисы сломаются..

  • Аутентификация / Авторизация
  • Управление данными пользователя
  • Управление медиа-контентом
  • Обмен сообщениями
  • Звонки
  • Платежи
  • Служба push-уведомлений
  • Платформа больших данных и т. Д.
0 голосов
/ 10 июня 2018

Извините, но с каждым из этих сценариев ответ зависит.Часть вашей роли как архитектора состоит в том, чтобы определить это на основе вашего сценария, и нет никаких реальных правил, только мнения.Кроме того, никто не будет стоять над этим судить вас.В конце концов, приложение просто должно быть полезным, масштабируемым, надежным и простым в обслуживании.Это эквивалентно тому, что строитель спрашивает, должны ли кирпичи быть круглыми, квадратными или прямоугольными.Это зависит.Если вы приравниваете это к дому, мы не говорим о том, как устроена кухня, больше похоже на трубы в подвале.В какой-то момент никто не будет заботиться.

...