Комментарии 31
Спасибо, интересно было почитать. Но так же интересна и другая сторона:
"1500 микросервисов (около 200 из них критичных), 2500 баз данных и 3000 git-репозиториев" + "У каждого микросервиса может быть своя база данных, своя команда инженеров, свой техдолг, техлид, бэклог, capacity planning"
Как вы всем этим рулите в плане разработки? У нас цифры на порябок меньше, но уже проблемы с тем, что утекает экспертиза по какому-то конкретному сервису с уходом человека. Пролемы при одновременном переходе на что-то, скажем, на новую версию каких-то библиотек, потому что на старую кончилась лицезия. Что регулярно остаются забытыми какие-то из сервисов, про которые вообще никто уже особо ничего не помнит, поскольку их не трогали несколько нет, даже человек, что их писал когда-то. Что не смотря на низкую связанность, все одно есть какие-то общие части, и одна команда подсирает другой, а вылезает это через полгода....
У вас тысячи микросервисов, у других аналогичных компаний наверно тоже.
Может, пойти ещё дальше, и создать и делегировать всё неким профессиональным командам отвечающим за каждый сервис? И тогда каждой компании не надо будет тратиться на содержание больших команд. Реально так сделать, или все компании слишком уникальны?
Извините, нужно больше контекста в вопросе
Я так понял, посыл в том, чтобы не выдумывать своё, а всем сделать открытых штук типа https://imgproxy.net/ или https://www.yiiframework.com/ вложившись туда вскладчину и тем самым повысив и стабильность платформы, на которой выстроено несколько компаний и ещё и сэкономить прилично.
На схеме 6 реплик одного микросервиса, по которым равномерно будет распределять нагрузка.
А зачем в каждой реплике redis? Или у вас одна реплика мастер, а остальные 5 зеркала для чтения?
В целом, наверное, можно придумать ситуацию, в которой это разумно. Например, нужно кешить малое количество ключей с большим рейтом обращений и отсутствием требования консистентности.
Меня, лично, больше царапнуло наличие в каждой реплике связки nginx+php-fpm/go, а не отдельное скалирование nginx и отдельное скалирвоание go/php-fpm. Кажется, утилизация ресурсов в таком случает будет лучше.
Например, нужно кешить малое количество ключей с большим рейтом обращений и отсутствием требования консистентности.
Так-то для этого редис тоже не нужен, думается для любого языка есть какая-нибудь либа in-memory cache, либо в составе языка/фреймворка, либо как сторонняя библиотека, либо самому можно запилить за пару часов на хеш-таблице + линкед лист (если нужен кеш LRU). Будет все работать в пределах одного процесса на порядок, или порядки быстрее, чем однопоточный редис, через сетевой протокол и затратами на сериализацию/десериализацию.
Это для примера. Теоретически можно использовать как очень быстрый in-memory cache на уровне каждой реплики (да они не синхронизируются между собой)
Конечно можно подключить готовые библиотеки с реализаций, например, LRU в golang приложение. Но если сервис написан например на php - то можно рядом дополнительный кеш поднять. И это не замена централизованному общему кешу
У меня одного сложилось впечатление что из понятной и простой архитектуры с масштабируемой (горизонтально) архитектурой получилась масса сервисов и технологий, которые поддерживать довольно сложно?
По крайней мере на основании моего опыта в компании, бизнес которой основан исключительно на API и микросервисах.
Команды вроде должны быть независимы, в реалии ситуация усложняется - у нас масса disconnect между группами.
Очень полезная и интересная статья, все этапы собраны вместе, и о многих из них я не знал, что есть готовые решения. Надо будет изучить описанные технологии подробнее.
Наверное, микросервисная архитектура - это дорого именно для такого масштаба систем. А какая архитектура будет недорогой на аналогичных масштабах?
Микросервисы - это очень хороший подход, который, конечно, не лишён проблем, но очень разумен и удобен в работе. Хотя, как уже написали выше, экспертизу по всем блокам сохранять тяжело.
А как у вас устроен микросервис с PHP? Это nginx + php-fpm или другие решения?
да, каждый инстанс сервиса это nginx + php-fpm + pgBouncer (если есть зависимость база данных) + haproxy (если есть зависимости до внешнего redis) + enoy + служебные контейнеры по метрикам/статус чекам
Но обычные инженеры ничего этого не настраивают и не конфигурируют. Когда создаем новый сервис указываем что он на php+ему нужна база данных и все автоматически создается и разворачивается в prod/dev/staging/local окружениях.
Не используйте service mesh и любую форму software network routing. Вы тормозите в десятки раз всю свою экосистему.
Типичные задержки ethernet 10-100 микросекунд, инфинибенда 1-20 микросекунд.
Softwt routing это 1-10 миллисекунд.
Подскажите, как вы отлаживаете узлы, где несколько микросервисов имеют доступ к общему ресурсу (pg или redis), как определить "виноватого" и поймать специфический баг, невоспроизводимый в тестовом окружении?
Не туда
Это антипаттерн, когда два микросервиса имеют доступ к одному ресурсы. У нас встречается это, то только как переходное состояние (из тысячи миксросервисов может быть в 1-2 местах есть и везде описан план, как будем развязывать общие ресурсы)
By default в микросервис работает только со своей базой данных/кешами/sphinx etc. В чужую базу данных из коробки даже сходить нельзя, и доступы закрыты на уровне платформы.
Почему вы ничего не гоаорите о том, что микросервисы это не всегда хорошо? Почему не упомянули симбиоз монолита и микросервисов, который называется Цитаделью? Ведь не все следует выносить в микросервисы. А только то, что:
Точно будет меняться
Как булет меняться пока не ясно
Возможно потребует использование нового стека технологий.
Цикл обновления быстрее, чем у всего остального.
А все остальное пусть живет в монолите...
да я согласен, что микросервисы сложно и дорого (ресурсы и человекочасы). На мой взгляд в чистые микросервисы стоит идти только если штат 500+ инженеров
Так а зачем он нужен, если он раздувает штат? Вендор не лучше? Ну на самом деле, микросервис он тем и хорош, что может сопровождаться одним человеком, но... за микросервисами следует бардак. Это бардак в документации, в моделях данных, в используемых стеках. Да и если мы говорим о хайлоаде, то преобразование данных в понятный микросервису формат, требует времени. И если не контролировать атрибуты и топологию передаваемых сообщений , о вы только и будете делать, что преоьразовывать формамы и тратить на это основную вычислительную мощность. Поэтому, те пункты, которые я выделил можно исправить микросервисным подходом. Остальное же пусть живет в монолите.
вот интересно, зачем в бизнесе, процессы которого можно описать на одном листе бумаги, 500+ инженеров?
не переусложнили ли себе жизнь микросервисами, добившись падения производительности разработчика и раздувания штата на радость архитектору?
Микросервисы для чайников: как на них перейти с монолита с нуля