Комментарии 8
Здравствуйте. Спасибо за статью.
Расскажите про инструмент отображения зависимостей между сервисами. На картинке у вас Huginn
Приветствую!
Huginn - это название нашего внутреннего портала разработчика.
Зависимости мы отображаем в нем в разных представлениях:
1) Карта сервисов. Можно приблизить и посмотреть названия, можно в строке поиска найти свой сервис. Фактические связи - строятся на основании статистики реального взаимодействия, собранной с istio. Задекларированные связи - берутся из конфигов сервисов.
![Карта сервисов Карта сервисов](https://habrastorage.org/getpro/habr/upload_files/c61/0b4/aad/c610b4aad7f00c79f4f517d99360bf17.png)
2) На карточке сервиса указаны его зависимости - другие сервисы и базы данных.
![Зависимости в карточке сервиса Зависимости в карточке сервиса](https://habrastorage.org/getpro/habr/upload_files/365/9a4/3ef/3659a43ef4b626bd01dacdd432bb1157.png)
3) Карта связей топиков и сервисов
![Карта связей топиков и сервисов Карта связей топиков и сервисов](https://habrastorage.org/getpro/habr/upload_files/dd6/e56/01c/dd6e5601c167a1bf271c03b988db8444.png)
В рамках этого цикла статей планируем выпустить отдельную про Huginn.
помогает пользователям не отвлекаться от бизнес задач:
Если у пользователя есть биззадача - он от неё не отвлечется. (Не плодить сущности)
стандартизировать технологии и решения в компании и тем самым экономить усилия на поддержку инфраструктуры;
Всё уже стандартизировано до вас. (IEEE)
автоматически предупреждать проблемы стабильности;
Если есть проблема стабильности - выяснить корень и исключить его.
следить за всеми микросервисами как за единой системой.
Микросервисы должны умереть. (Не плодить сущности(см.п1)
Здравствуйте!
Да, в статье показано, как дорого обходится микросервисная архитектура. Много узлов отказа и обслуживания, ненадежное сетевое взаимодействие вместо надежного вызова метода в монолите... Так что один из полезных выводов, который следует вынести из статьи - если у вас нет веских причин переходить на микросервисы - не делайте этого.
С другой стороны, если у вас больше 50ти команд, которые разрабатывают монолит, то как бы вы организовали совместную работу с кодовой базой?
У вас, вероятно, очень большой опыт, судя по тону решений. Если не секрет, где вы его приобрели и на каких успешных проектах?
Думаю, что мне повезло оказаться в сильных командах - сперва в РСЯ Яндекса, затем в высоконагруженном Lazada.com. Это может быть рабочим подходом - выбирать команду не по зарплате, а по знаниям руководителя, и у него учиться.
Но есть и более управляемый способ - системно учиться по Teamlead roadmap: https://tlroadmap.io/.
NodeJS — язык для frontend-сервисов.
Я конечно извиняюсь, но когда это NodeJS стал языком?
PaaS два года спустя. Обзор инструментов и какие задачи они решают