PHP
Программирование
Комментарии 80
0
К сожалению в данный момент сервер не доступен по этому урлу, но было бы интересно посмотреть. А вы что-то знаете про оверхед контейнеров? Мне кажется он настолько мал, что им можно пренебречь в некоторых масштабах.
0

Оверхэд может быть только за счет использования дополнительных инстансов nginx-а. Ну мол не из-за контейнеров а потому что nginx-ов много. Можно взять nginx-proxy например и на основе него сделать единый nginx для того что бы разруливать все в пределах одной машины. А можно еще просто использовать в качестве транспорта zeromq.

+1
Не уверен, но по моему RUN лучше однострочным делать, используя && и \
0
Вообще да, вы правы, чем меньше слоев, тем лучше. Но пока их меньше 120 с чем-то, особых проблем не будет :)
0

Именно так, таким образом мы создаем меньше промежуточных слоев и размер образа становится чуточку меньше.


Точно так же весьма спорная штука — контейнер для исходников. К сожалению есть масса проблем с этим. Выражаются эти проблемы в том, что при пересоздании контейнера с исходниками на хосте ничего не поменяется и наши контейнеры с php будут использовать старые исходники.


Я предпочита просто хранить исходники прямо в PHP контейнере.

0
Не так и сложно пересоздать все зависимые контейнеры. А насчёт плюсов такого подхода… наверное все в угоду парадигме «Один сервис — один контейнер»
0
Там проблемы с volumes всплывают, они заполняются только при создании тома, при пересоздании — нет. А использовать
docker-compose down --volumes
(удалять и тома, а не только контейнеры и сети) — будут удаляться тома персистентных хранилищ (субд, редис и т. п.)
0
.php (грубо) файлы в PHP-контейнере, а статику в nginx-контейнере?
0

именно так. У меня апишки и SPA так что проблем с разделением вообще нет.

+17

В моей компании тоже все на микросервисах, только счастья это не приносит:


  • если ищу причину какого-то бага, то в большинстве случаев где-то по ходу анализа исходника приложения натыкаешься на вызов очередного endpoint-а, приходится скачивать его исходники тоже, а там опять endpoint куда-то еще, и т.д. О локальном дебаге речь вообще даже не поднимается, так как слишком много приложений-микросервисов придется локально конфигурировать. В итоге баги ищутся, в основном, путем смотрения на код.


  • микросервисы, как правильно заметил автор, зачастую написаны на разных версиях разных языков, что делает локальный дебаг трудным или невозможным


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


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


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


  • микросервисы, когда вызывают другие микросервисы по HTTP, работают существенно медленнее, чем если бы тот же код исполнялся из одного процесса, что часто приводит к необходимости все переделывать без микросервисов


  • если любой из нужных микросервисов недоступен, то как правило пользоватетель получает не частично, а полностью неработающее приложение. Это из области мифив, что приложением можно будет пользоваться, но с ограниченниями. Я таких приложений не видел.

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

+3
но при этом возникает необходимость в процессах копирования данных между БД, синхронизация, ETL и все такое, что тоже немалый источник хлопот.


Это не особо большая проблема, на самом деле. В целом если у вас выходит так что одни и те же данные хранятся в рамках разных микросервисов, возможно границы разделены неверно? Так же можно организовать CQRS и по изменению данных отправлять в очередь событие на перестройку read model всех сервисов (а сервисы уже сами все разрулят).
В итоге подход, призванный снизить избыточность кода, дает ровно обратный эффект.


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


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


single point of failure это называется. Это проблема не микросервисов а конкретной реализации. Критически важные вещи должны дублироваться.
В реальной жизни лучше сто раз подумать, а надо ли.


А вот тут соглашусь полностью. Далеко не у всех над одним проектом будет трудиться пара десятков разработчиков что бы была необходимость дробить систему. Но в целом подход с микросервисами очень даже хорошо подходит для реально больших проектов.
+1
А вот тут соглашусь полностью. Далеко не у всех над одним проектом будет трудиться пара десятков разработчиков что бы была необходимость дробить систему.


Жизнь проекта разработкой не ограничивается. Потом начинается саппорт и мелкие доделки силами саппорта. У нас, например, в саппорте примерно человек 5, а количество микросервисов я даже не знаю сколько, думаю за сотню. И когда расследуешь баг, то не получается просто проследить всю последовательность вызовов до операций с БД, а приходится переключаться между разными частями раздробленной системы. Это замедляет расследование багов во много раз. Получается, сэкономили на разработке, но потеряли на саппорте.
0

Почти все продукты, которые используют микросервисы, подразумевают что работа над ними будет продолжаться довольно продолжительное время. А вот ситуации когда продукт переходит в суппорт и над ним трудятся всего 5 человек не означают что проект прекратил развитие?

+1

Это продукт для внутреннего пользования, его разработали, внедрили, и теперь им все пользуются. "Развитие" происходит только если какие-то бизнес-юзеры требуют новый функционал. В этом случае подключается отдельный девелоперский отдел и ведет всю разработку. Разработчики и бизнес-аналитики, кстати, все по уму делают: рисуют модели бизнес процессов, описывают сущности, генерируют структуры данных и WSDL-интерфейсы, кодят, в общем все по книжке. Но почему-то когда есть выбор пойти в БД напрямую, или через микросервис, они всегда выбирают микросервис. В результате получается ад микросервисов, в котором среднее время расследования бага во много раз больше, чем в просто большом приложении.

+10
Знаем, проходили. Все что вы описали — классический «distributed monolith» и о микросервисах тут речи не идет.
если ищу причину какого-то бага, то в большинстве случаев где-то по ходу анализа исходника приложения натыкаешься на вызов очередного endpoint-а, приходится скачивать его исходники тоже, а там опять endpoint куда-то еще, и т.д. О локальном дебаге речь вообще даже не поднимается, так как слишком много приложений-микросервисов придется локально конфигурировать. В итоге баги ищутся, в основном, путем смотрения на код.

Тут налицо сильная связность и неполное разделение ответственности. Сервис должен быть изолированным, дабы была возможность отлаживать его не устанавливая весь остальной landscape.

микросервисы, как правильно заметил автор, зачастую написаны на разных версиях разных языков, что делает локальный дебаг трудным или невозможным

Бывает, что поделать. Docker в помощь

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

У каждого сервиса — свое хранилище, общих БД должно быть по минимуму

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

Опять же — неправильное разделение ответственности между сервисами. Плюс приложения в такой архитектуре обычно проектируют с учетом толерантности к eventual consistency и не самым свежим данным.

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

Если вам требуется внести изменения в микросервис да так что при этом отвалятся все клиенты (т.е. никакой обратной совместимости) — то налицо проблема в проектировании API, а конкретно — в версировании. Обновление одного сервиса не должно каскадно вызывать одновременное обновление еще кучи других от него зависящих.

микросервисы, когда вызывают другие микросервисы по HTTP, работают существенно медленнее, чем если бы тот же код исполнялся из одного процесса, что часто приводит к необходимости все переделывать без микросервисов

Не обязательно использовать HTTP, или вообще решить проблему изменив deployment (например развернуть сервисы в одном сегменте сети или вообще на одних машинах) вместо переписывания кода.

если любой из нужных микросервисов недоступен, то как правило пользоватетель получает не частично, а полностью неработающее приложение. Это из области мифив, что приложением можно будет пользоваться, но с ограниченниями. Я таких приложений не видел.

Обычно это работает на уровен фич. Простой пример — оплата. Если сервис обслуживающий PayPal упал, то Яндекс.Деньги например все еще могут работать. Или блок комментариев к статье — если сервис, обслуживающий комментарии лежит, то это не значит что статья не должна отображаться. Терпимость к ошибкам должны быть заложена в архитектуре.

Вообще лучший подход — это представить что ваш микросервис — абсолютно самостоятельный продукт и должен работать независимо от всех остальных частей приложения.
+1
плюс пять копеек к тому, что лучше 100 раз подумать. надо ли — микросервисы — это по разспределенная система с сервисами, которые имеют тенденцию отвалится чаще, чем если бы бежали в рамках одного процесса. Дизайнить такую систему в разы сложнее, дороже и дольше, чем обычный монолит, а плюсы от микросервисов не всегда уж такие очевидные.
0
кстати, монолит с нормальным DI и лейзи инициализацией вполне норм масштабируется.
0
Разработка монолита нормально не масштабируется, вот в чем весь прикол микросервисов.
0
разработка то почему не масштабируется? Всеравно в монолите есть некие подсистемы отдельные. у этих подсистем есть публичный интерфейс. Проблемы только когда меняется интерфейс надо лезть в другие места исправлять. Но это все решаемо. В конце концов, если меняется интерфейс микросервисов, то все равно нужно лезть по пользователям сервиса и переключать на другую версию АПИ.
0
Как минимум потому что, даже если связанность модулей в монолите по факту нулевая (что большая редкость), то всё равно при любом изменении нужно проводить полный набор тестов, потому что сейчас она нулевая, а какой-то коммит может сделать её ненулевой. А полный набор тестов на большой системе — это долго и дорого. Да и тупо IDE может тормозить на больших проектах.
0
внезапно тесты на взаимодействие между микросервисами тоже нужно проводить. Да и вообще тестировать все нужно всегда.

внезапно, говно-коммиты не проходят код-ревью. и внезапно же, говнокоммиты могут быть и в микросервисах.

стоимость и длительность тестов косвенно указывает на качество кода. В случае микросервисов тестов будет даже больше, ведь нужно тестировать и взаимодействие микросервисов между собой.

в IDE можно исключить из индексации ненужные модули. Но, как мне кажется, стоимость нормальной железки для программиста не должна влиять на архитектуру приложения. Связность в монолите можно контролировать. Собственно и микросервисы могут быть сильно связными. и если вы не можете сделать нормальный монолит, то до микросервисов вы еще не доросли. не имею ввиду именно Вас, говорю в общем.
0
внезапно тесты на взаимодействие между микросервисами тоже нужно проводить


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

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

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


У меня на одном проектике из-за ошибки проектирования есть один микросервис, который потребляет 140 гигов оперативки. Ну это я так, к вопросу стоимости железок.
Связность в монолите можно контролировать. Собственно и микросервисы могут быть сильно связными.


Можно контролировать. Точно так же как и в случае микросервисов. То есть в случае монолита подавляющее большинство забивают болт. А в случае микросервисов это "забиваение болтов" ооочень быстро приведет к проблемам и они всплывут весьма рано.
и если вы не можете сделать нормальный монолит, то до микросервисов вы еще не доросли.


в точку. Вот только в случае микросервисов количество людей которые могут сделать нормальный монолит может быть значительно меньше чем в случае собственно монолита. Проще вводить новых людей, проще менять команды. Именно это подразумевается под "масштабированием".

Ну а если у нас большая команда людей, не способных написать монолит, да, профита от микросервисов мы тем более не получим. Разве что быстрее придем к тому что нужно нанимать кого-то более компетентного.
+2
> разработка то почему не масштабируется?

Ну там мифический человеко-месяц, все такое…

> Всеравно в монолите есть некие подсистемы отдельные. у этих подсистем есть публичный интерфейс.

Это у Вас очень крутой монолит, представляющий собой набор независимых сервисов, работающих в одном адресном пространстве :) Я бы предпочел работать именно с таким «монолитом», нежели с «микросервисами», сидящих поверх одной реляционной БД.

Обычно под монолитом понимают приложение, концептуально представляющее собой некое глобальное состояние + кучу методов для его изменения.
0
нежели с «микросервисами», сидящих поверх одной реляционной БД.


Я принципиально не хочу называть такую архитектуру микросервисами. Это ближе к ESB нежели к микросервисам. Высокая связанность от одной зависимости.
+2
если любой из нужных микросервисов недоступен, то как правило пользоватетель получает не частично, а полностью неработающее приложение. Это из области мифив, что приложением можно будет пользоваться, но с ограниченниями. Я таких приложений не видел.


У вас не микросервисы, а просто распределенный монолит. Общение между микросервисами должно происходить полностью асинхронно, через какую-нибудь кафку например. Это решит проблему продолжения работы всего приложения при одном умершем сервисе. Он просто обработает данные из кафки позже, когда восстановится, а остальные этого даже и не заметят.
0

При асинхронном общении между сервисами приходится еще что-то выдумывать, чтобы помечать состояния сущностей, которые находятся в обработке и ожидают ответа какого-то микросервиса — ведь юзерам надо показать, что его действие уже исполняется, чтобы он еще раз Submit не нажимал. А если еще надо обработать асинхронный ответ какого-то микросервиса — то вот уже и в нашем микросервисе надо заводить еще один endpoint (ну или subscriber), который будет это событие слушать. И где здесь простота и элегантность? А как в этом ловить баги, или дебажить локально?


Но вообще-то, говоря о полностью неработающем приложении я имел в виду тот факт, что любая ошибка в нужных сервисах не даст пользователю возможности сделать то, что он хотел. Ему, по большому счету, без разницы, видит он ошибку 500, или красивую надпись "сервис ХХХ недоступен". В обоих случаях это будет тикет в саппорт. Пример блога с неработающим сервисом комментариев от реальной жизни несколько оторван.


У нас, кстати, есть MQ (Websphere), иногда приходится дебажить и там тоже, и это еще больше усложняет саппорт. Но видимо совсем без MQ не получится, т.к. много разнородных систем.

+1
Идея в том, чтобы сервису для отдачи данных пользователю не нужно ползти в другие сервисы и что-то там дергать. Сервис просто сидит и ждет апдейтов которые приходят через шину от других. Это сильно уменьшит зависимости между сервисами, что позволит сосредоточиться на обеспечении доступности user-facing сервисов, и меньше думать про сервисы которые работают в фоне.
0

Сервисы бывают разные. Приведу пример расследования бага из недавнего...


Внешний пользователь на лендинг-странице не может ввести свою информацию — системе не нравится его емайл. Иду в приложение лендинг-страницы. Вижу, что приложение проверяет инфу, введенную пользователем, путем вызова микросервиса, в котором хранятся все внешние потенциальные клиенты. Скачиваю исходники этого микросервиса. Вижу, что емайл он проверяет вызовом еще одного микросервиса проверки емайлов. Скачиваю его исходники тоже. Вижу, что там у нас вообще-то есть приложение, которое используется отделом маркетинга, где они в числе прочего ведут небольшую базу правил для емайлов, чтобы иметь возможнось делать черные/белоые/серые списки. Вижу, что для емайла определяется список, и если это серый список, то наш микросервис вызывает микросервис проверки емайлов из сторонней компании, которая проверяет емайл уже путем коннекта по SMTP и отправки всяких там HELO заголовков, но без отправки письма.


Все красиво и логично, не прикопаться. Но на поиски бага ушел день с лишним, так как всю эту архитектуру пришлось постигать самостоятельно. В моем случае была ошибка в базе правил черных/белых/серых списков.

+2
у вас явный затык в архитектуре.
1. путем вызова микросервиса, в котором хранятся все внешние потенциальные клиенты. задача микосервиса хранить клиентов или валидировать мейлы?
2. Вижу, что емайл он проверяет вызовом еще одного микросервиса проверки емайлов.
вот, оказывается для проверки мейлов естьсервис, но вы к нему не обращаетесь почемуто
3. Скачиваю его исходники тоже. Вижу, что там у нас вообще-то есть приложение, которое используется отделом маркетинга, где они в числе прочего ведут небольшую базу правил для емайлов, чтобы иметь возможнось делать черные/белоые/серые списки.
это списки дял маркетинга, они сортируют клиентов для своих нужд? почему тогда их списки используются для валидации?

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

задача микосервиса хранить клиентов или валидировать мейлы?
Задача — хранить информацию обо всех внешних пользователях, которые еще не стал клиентами, но которые каким-то образом к нам обращались и у нас есть о них какая-то, как правило частичная, информация: кто-то заполнил форму на лендинге, кто-то оставил контакты на промо-акции, кто-то позвонил, и т.п. В виде сервиса (слово «микро» тут не очень подходит) сделано потому, что им пользуемся не только мы, но и наши дилеры партнеры. Они могут сделать свой промоушен, лендинг, рассылку и т.п, но данные в итоге поступают в наш сервис. По-моему очень даже умно придумано.

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

это списки дял маркетинга
Это списки правил валидации емайлов, которым пользуется сервис валидации емайлов. Сами емайлы у них тоже есть, но в других базах/приложениях.
+2
>> Задача — хранить информацию обо всех внешних пользователях, которые еще не стал клиентами, но которые каким-то образом к нам обращались и у нас есть о них какая-то, как правило частичная, информация: кто-то заполнил форму на лендинге, кто-то оставил контакты на промо-акции, кто-то позвонил, и т.п. В виде сервиса (слово «микро» тут не очень подходит) сделано потому, что им пользуемся не только мы, но и наши дилеры партнеры. Они могут сделать свой промоушен, лендинг, рассылку и т.п, но данные в итоге поступают в наш сервис. По-моему очень даже умно придумано.

тогда почему у этого сервиса есть ендпойнты для валидации мейла? имхо, логичней чтобы был сервис валидации мейлов, который принимает решение валидный мейл или нет на основании различных данных. чтото типа такого алгоритма:
1. проверяем мейл, что он валидный с точки зрения стандарта.
2. дальше запрашиваем у сервиса с потенциальынми клиентами, а не обращался ли к нам ктото с таким мейлом по какимто каналам.
3. дальше запрашиваем в какую категорию попадает мейл с точки зрения правил которые ведут маркетологи
4. Если есть сомнения (серый список), запрашиваем у стороннего сервиса валидации
5.…
6. PROFIT

какие плюсы:
— сервис делает одну четкую вещь и дает отет да/нет
— сервис постепенно использует все возможные способы проверки мейла
— вам не нужно перебирать мотор через выхлопную трубу

зы. идея микросервисов как раз в том, что они микро. они делают одну простую вещь.
ззы. запросы в пунктах 2 и 3 это запросы к другим микросервисам вашей системы
0
зззы. опционально можно исключить запросы к сервисам, с которых пришел запрос на валидацию. тобишь сервис хранящий партнеров неверняка спросит, а валидный ли это мейл перед тем как сделать новую запись, потому обращатсья к нему с впросом знает ли он такой мейл глупо. хотя ответ тогда всеравно будет что не знает, ведь запись еще не сделана.
но это уже детали реализации и небольшие оптимизации
0
тогда почему у этого сервиса есть ендпойнты для валидации мейла
У него нет своих ендпоинтов для валидации емайла. Он вызывает отдельный микросервис если ему надо отвалидировать емайл. В микросервисе валидаций емайлов есть небольшая база с правилами валидации. В общем все разбито на независимые части, примерно так как вы и пишете. Только трудоемкость саппорта от этого получается слишком высока.
+1
тогда я не понимаю как так вышло, что ваш изначальный сервис полез валидировать мейл в сервис потенциальных клиентов… ладно, что переливать из пустого в порожнее. у каждого своя точка зрения. моя в том, что если авторы микросервисов придерживаются unix way, то проблем возникать не должно
+2
Если проект уже сдан и находится на поддержке, то почему у вас нет документации по взаимодействию микросервисов?
Если есть хотя бы простенькая диаграмма с описанием связей, то ваше расследование превращается в 10 минутный просмотр такой диаграммы и исправление бага.
Если такой диаграммы нет — по моему логично потратить неделю на её создание чем тратить каждый раз тратить день на поиск 1 простого бага.
0
особенно странно видеть, как зоопарк микросервисов на разных версиях разных языков оперирует с одними и теми же логическими связанными данными. Я, конечно, понимаю, что хотели делать масштабируемо, но на уровне данных все SQL-запросы в итоге идут к одним и тем же базам данных, от чего БД становятся узким местом. Но отмасштабировать БД, как правило, намного труднее.

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


Если принято решение делить базу между сервисами (большой плюс — простое обеспечение ссылочной целостности), то очень облегчает жизнь принцип «у каждой схемы/таблицы/столбца только один владелец, имеющий право INSERT/UPDATE/DELETE, остальные только SELECT» (лучше зафиксировать через права на уровне СУБД). Это позволит считать SELECT запросы лишь ещё одним дополнительным транспортом (на HTTP API мир клином не сошёлся) на query запросы к сервису-владельцу.

Если же у сервисов свои базы, то нужно очень стремиться копировать не данные, а только идентификаторы. На моей практике для операционной деятельности (включая оперативные отчёты) вполне достаточно когда одна (пускай даже денормализованная в целях оптимизации скорости/памяти) база выделяется под один сервис, оперирующий одной (или несколькими логически очень близкими) сущностью, её агрегатами и справочниками, ссылаясь на другие лишь по идентификатору, а аналитические отчёты по произвольным разрезам и периодам строятся средствами DWH или другими агрегаторами, умеющими собирать и связывать данные (и по запросу от потребителя, и по расписанию, и по событиям от сервиса-владельца) из многих разнотипных источников.

0
> но на уровне данных все SQL-запросы в итоге идут к одним и тем же базам данных
Эмм… У вас и близко никакие не микросервисы.
+4
Косметическая придирка. Пользуйтесь хотя бы средствами проверки орфографии, что в самом браузере несложно включить. Чесслово, при такой концентрации уже глаз режет.

Навскидку:
«в кратце»: «вкратце» пишется слитно
«все зависит от вашего конертного случая»: от «конкретного» случая, надо полагать?
«одну с нашим микрофремворком»: «микрофреймворком»
«существующего контролера»: «контроллера», надо полагать — не билеты же он у вас во фреймворке проверяет
«Незабываем посылать токен»: «не забываем» пишется раздельно

Я всё понимаю, что и стиль изложения должен быть весь из себя стремительный, но хоть каплю уважения, блин, к читателям!

«Извините, если кого обидел».
0
Как раз такие ошибки орфопроверялка в браузере как раз и пропустит процентов на 70. Ей что «контролера», что «контроллера» — и то, и другое слово есть в словаре. Из приведенных поймает «конертного» да, внезапно, любой из вариантов «микрофремворк»/«микрофреймворком».

Вообще, если пользоваться до степени доверия компьютерной проверкой слов, лучше всего перейти на упрощенный вариант языка, где больше одного варианта у слова нет, и нет мешающих стремительности мысли «похожестей» вроде «в кратце»/«вкратце» )
0
Ну, сказано было «хотя бы». Вычитка другим человеком обычно достаточно эффективна — свои собственные опечатки — особенно, если орфографическая проверка их не укажет — заметить обычно сложнее.
+3

А когда контейнеров становится слишком много, то получается вот так:


Docker with shit


Т.е. теперь пованивает не только код, но и вообще всё, включая администрирование. Мы сами себе создали дополнительные проблемы. Ведь для каждого сервиса надо выполнить следующее:


  • накодить сервис
  • оттестировать сервис
  • документировать сервис
  • оттестировать api сервиса
  • документировать api сервиса
  • встроить сервис в систему сервисов
  • оттестировать работу сервиса вместе с другими сервисами
  • следить за адом явных и неявных зависимостей одних сервисов от других сервисов
  • администрировать всё это дело внутри и снаружи

Это сложно.


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


На мой взгляд гораздо лучше использовать большие и толстые сервисы. В вашем случае я бы сделал так:


  • Nginx
  • Контейнер приложения × несколько штук во имя возможности обновлять приложение без перезагрузки всего
  • Одна или несколько DB по вкусу

Это дешевле. Это работает быстро. Это не требует много ума. Это достаточно безопасно. Это неплохо документируется. Это вполне масштабируемо.


В дальнейшем сюда может добавиться контейнер для небезопасного кода. Например дать возможность постить юзерам webm, для чего может потребоваться дырявый ffmpeg или ещё что либо подобное. Или запилить рядом какой либо ещё сервис вроде wiki-платформы или irc-сервера (ну для примера).


Могу предложить примерно такой эврестический алгоритм отделения чего либо в отдельные сервисы:


  • всё, что небезопасно (например код третьих лиц сомнительного качества) стоит порезать на сервисы
  • если для поддержки сервиса требуется более 5-15 человек, то подумать о разделении этого на два-три сервиса
  • если нам нужно симулировать бурную деятельность и/или освоить бюджет (под эту причину вполне подходит статья, которую я комментирую)

Кроме того стоит рассмотреть различные другие крутые штуки, которые делают контейнеризацию и инфраструктуру вокруг контейнеров. rkt/CoreOS, LXC/LXD, OpenVZ, kvm, OpenStack и другие. Тысячи их. Одно из сравнений можно посмотреть вот тут: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html Не забывайте про вариант с самописной системой контейнеризацией и/или инфраструктурой вокруг этого на том или ином уровне (в конце концов у вас может быть в наличии админ с достаточными знаниями). Один день на гуглинг и пара дней на обработку его результатов может сэкономить месяцы и даже годы разработки.

0
В вашем случае я бы сделал так


Я напомню, что эта задача чисто академическая, с непреодолимым желанием попробовать именно микросервисы.

Кроме того стоит рассмотреть различные другие крутые штуки, которые делают контейнеризацию и инфраструктуру вокруг контейнеров. rkt/CoreOS, LXC/LXD, OpenVZ, kvm, OpenStack и другие. Тысячи их. Одно из сравнений можно посмотреть вот тут: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html Не забывайте про вариант с самописной системой контейнеризацией и/или инфраструктурой вокруг этого на том или ином уровне (в конце концов у вас может быть в наличии админ с достаточными знаниями). Один день на гуглинг и пара дней на обработку его результатов может сэкономить месяцы и даже годы разработки.

Я не очень понял как отказ от докера в пользу самописных контейнеров или даже каких-то других поможет сэкономить мне время. Докер настолько плох?
-2
Докер настолько плох?


Все с ним хорошо. У меня он уже пол года в продакшене и я счастлив.
0
Я не очень понял как отказ от докера в пользу самописных контейнеров или даже каких-то других поможет сэкономить мне время. Докер настолько плох?


Я не говорю, что докер плох (хотя об этом можно поспорить тоже). Я говорю о том, что совершенно не ясно, какие задачи вы пытаетесь им решить. Академическая задача? Так явно напишите об этом.
0
Вот тут я упомянул об этом

Безусловно, это задача ради задачи, но хочется отметить что даже в таком варианте, это работать будет и будет работать неплохо (быстро и без проблем).


Да и еще в паре мест. Суть в том, что я хотел написать маленький и как следствие, максимально простой продукт (но работающий минимальным функционалом) на микросервисах, чтобы на примере было несложно понять (и мне в том числе) как же собственно все это выглядит? Еще хотелось услышать мнение обо всем этом тех людей, которые реально работают с сотнями микросервисов, и я их кстати услышал, за что им огромное спасибо.
+1
Что-то у вас смешалось в кучу все.
Это сложно.


Это сложнее чем монолит. Но чем больше проект тем меньше становится технических проблем и тем больше организационных. Скоординировать работу 40-а разработчиков над одним проектом знаете ли тоже весьма сложная задача.
Я имею ввиду, что надо тщательно прорабатывать всю архитектуру, вооружившись такими полезными орудиями труда, как Бритва Оккама, принцип KISS и здравый смысл.


И Здравый смысл рано или поздно подскажет что проще разделить проект на маленькие проекты со своей командой разработчиков, что бы процесс стал более управляем.
На мой взгляд гораздо лучше использовать большие и толстые сервисы. В вашем случае я бы сделал так:


это называется монолит. И при работе большого количества разработчиков у вас будут проблемы с управлением этой командой. А проблемы проектирования архитектуры будут не менее критичны чем в случае микросервисов.
Это дешевле. Это работает быстро. Это не требует много ума. Это достаточно безопасно. Это неплохо документируется. Это вполне масштабируемо.


До определенных масштабов. Проблема монолитных приложений в том, что они очень быстро выйдут из под контроля и код скорее всего превратится в кашу. Микросервисы же позволяют изолировать говнокод. Это существенно снижает риски при разработке новых фич так как все изолировано.

А проблемы с документированием у вас будут примерно одинаковые.
В дальнейшем сюда может добавиться контейнер для небезопасного кода.


вы путаете контейнеры и микросервисы как мне кажется. Я вот монолиты с докером делаю, и меня все устраивает.
всё, что небезопасно (например код третьих лиц сомнительного качества) стоит порезать на сервисы


Фреймворки типа? для отделения инфраструктурного кода от остального придумали гексагональную архитектуру. Микросервисы решают другие проблемы.
если для поддержки сервиса требуется более 5-15 человек, то подумать о разделении этого на два-три сервиса


более 3-х как по мне. При команде больше 5-ти человек энтропия разьест проект.
если нам нужно симулировать бурную деятельность и/или освоить бюджет (под эту причину вполне подходит статья, которую я комментирую)


Проекты с "бюджетом" никто не делает на микросервисах. Это больше нужно для продуктов которые планируется достаточно долго развивать.
Кроме того стоит рассмотреть различные другие крутые штуки, которые делают контейнеризацию и инфраструктуру вокруг контейнеров.


Зачем? Docker дефакто стандарт индустрии, им пользуются тысячи разработчиков, проще найти devops-ов. И не забывайте что сила докера (да и рокет о котором вы говорите) не в самой контейнеризации, оно там LXC просто использует, а в возможности делать образы системы и наследовать их. То есть если у меня есть 100 образов отнаследованных от 3-4 мне будет существенно проще поддерживать систему с точки зрения администрирования.
Не забывайте про вариант с самописной системой контейнеризацией


Это мы снова про распиливание бюджета?
Один день на гуглинг и пара дней на обработку его результатов может сэкономить месяцы и даже годы разработки.


велосипеды спасут мир.
0
А убийство велосипеда спасет котика.

/me как раз цинично убивает велостоянку которая по возрасту скоро паспорт получить может, и это даже без разговоров о суммах на поддержку этой, кхм, стоянки
0
Про полезность статьи судить не Вам(возможно, что многим примеры будут полезны).


just for the sake of truth, это давно не так. Docker использует libcontainer, который работает с cgroups и namespaces напрямую.
+1
А что монолит не надо «кодить, тестировать, документировать и прочее»? На самом деле микросервис это подход для тех, кто уже понимает важность документации, тестов, стабильности библиотечных API. Для них выгода есть, для тех, кто привык кодить монолит в стиле «быстрее, быстрее» все это выглядит бредом.
0
Мы в компании импользуем микросервисы и они очень сильно облегчили нам жизнь. На каждый продукт создаётся микросервис с приватной и публичной частью. Всё это грамотно логирует ошибку, где зачастую понятно какой микросервис упал.

Конечно есть и свои минусу, но все эти минусы основаны на непонимании концепции разработки микросервисной архитектуры.

Ближайшие планы: при увеличении нагрузки на тот или иной микросервис, автоматически поднимать еще один инстанс
0
А можете сказать, насколько стоимость разработки выросла (ну или уменьшилась)?
+1
Уменьшилась поддержка, но увеличилась реализация. В целом получили профит в некоторых случаях до 20%. Тут главное правильно структурировать код, вынести всю инфраструктуру и инжектить её между проектами
0
С логами это правильно. Особенно когда по всем инстансам можно по конкретному идентификатору найти, что, собственно творилось.
Особенно в рамках толстых сборщиков логов, вроде logstash какого
+1
Мне интересно, а где во всех этих микросервисах находится контроль доступа к данным? Например, какие посты может пользователь видеть, а какие редактировать. Каждый сервис это по своему решает? Или у вас есть сервис, который права раздает/проверяет, а все остальные от него зависят?
0
Да, есть сервис auth, который пока что решает просто, если человек вообще авторизован, значит он что-то может. Модифицируя сервис auth можно добавить, права, роли, группы и прочее.
0
По хорошему это микросервис который работает с пользователем. Сервис получает права пользователя по роли, либо другим признакам, кеширует данные по определённому условию и при очередном обращении данные берутся из кеша.

В нашем случае всё основано на роли пользователя, поэтому независимо от Id пользователя, если в кеше есть данные с определённой ролью, мы их возвращаем.
0
И этот микросервис знает о всех правах в системе, то есть фактически о всех ее сущностях?
+1
не совсем. В той же symfony роли это всего лишь строка и это дело конкретного сервиса что он формально будет делать с результатами проверки
->isGranted($user, 'WRITE_POST')


тоесть сервис тупой до безобразия. Его спрашивают, для такогото токена такая строка. Он дает ответ да/нет, но при этом он понятия не имеет что такое WRITE_POST
0
Усложним.
Допустим форум разбит на разделы. Тему только в конкретном разделе может отредактировать сам автор в первые 5 минут (меняется как настройка раздела) после её создания. Какой микросервис будет проверять? Auth? Posts?
0
имхо, возможность редактировать в принципе — Auth. Задержки/Авторство — Post
+1
Микросервис работает с правами и знает только о них. А дальше вопрос реализации, либо вы определяете доступ по роли, либо по праву, либо еще что то…
+1
Доступ определяет тот сервис, который владеет данными (БД, например, в простейшем случае). Т.е. данные не отдаются на сторону для принятия решения. Никогда. А вот использовать ли один сервис для хранения ACL, вопрос очень любопытный.
0
Как раз сегодня начал читать упомянутую в посте книгу про создание микросервисов. И сразу же возник вопрос, стоит ли ориентироваться на микросервисы, если разрабатывается небольшой проект, который будет выполняться на одном сервере и не планируется для каждого микросервиса выделять свой сервер?
-1
Если готов изучить еще виртуализацию, решать новые проблемы в дополнение к старым и прочее, то почему бы и нет :)
0
А что делать с потерями на накладные расходы HTTP?
А если HTTPS это ещё + 100-200 ms на handshake.

Не лучше ли через unix sockets?
0
Я как-то ожидал чуть больше информации, например:

«а у меня микросервисы висят на persistent connections и я трачу время только при запуске или когда connection отвалился» :)
0
Ах если бы :) Дело в том, что у меня нет микросервисов на сокетах на продакшене. Но может быть кто-нибудь еще подскажет.
0

Все кто уперся в HTTP обычно переходят на очереди (zeromq в основном, хотя есть ребятки которые кафку используют). В этом случае, поскольку у нас приложение на PHP, он не должен умирать. И это налагает свои нюансы на разработчиков. Сейчас с этим не так плохо как скажем еще 2 года назад.

+1

Используйте личные сообщения для подобного, пожалуйста.

+1
Зачем на по две копии некоторых сервисов? Потому что с одной будет не интересно и не понятно.

Гораздо интересней использовать docker-compose scale, делегируя решать вопросы масштабирования, обнаружения сервисов и балансировки инфраструктуре докера, а не хардкодя её в коде и конфигах.
Только полноправные пользователи могут оставлять комментарии. , пожалуйста.