Comments 80
Оверхэд может быть только за счет использования дополнительных инстансов nginx-а. Ну мол не из-за контейнеров а потому что nginx-ов много. Можно взять nginx-proxy например и на основе него сделать единый nginx для того что бы разруливать все в пределах одной машины. А можно еще просто использовать в качестве транспорта zeromq.
Именно так, таким образом мы создаем меньше промежуточных слоев и размер образа становится чуточку меньше.
Точно так же весьма спорная штука — контейнер для исходников. К сожалению есть масса проблем с этим. Выражаются эти проблемы в том, что при пересоздании контейнера с исходниками на хосте ничего не поменяется и наши контейнеры с php будут использовать старые исходники.
Я предпочита просто хранить исходники прямо в PHP контейнере.
В моей компании тоже все на микросервисах, только счастья это не приносит:
если ищу причину какого-то бага, то в большинстве случаев где-то по ходу анализа исходника приложения натыкаешься на вызов очередного endpoint-а, приходится скачивать его исходники тоже, а там опять endpoint куда-то еще, и т.д. О локальном дебаге речь вообще даже не поднимается, так как слишком много приложений-микросервисов придется локально конфигурировать. В итоге баги ищутся, в основном, путем смотрения на код.
микросервисы, как правильно заметил автор, зачастую написаны на разных версиях разных языков, что делает локальный дебаг трудным или невозможным
особенно странно видеть, как зоопарк микросервисов на разных версиях разных языков оперирует с одними и теми же логическими связанными данными. Я, конечно, понимаю, что хотели делать масштабируемо, но на уровне данных все SQL-запросы в итоге идут к одним и тем же базам данных, от чего БД становятся узким местом. Но отмасштабировать БД, как правило, намного труднее.
иногда базы данных пытаются сделать масштабируемыми путем разбиения на логически независимые базы. Микросервисы тогда зависимы только от своей БД, и чувствуют себя отлично, но при этом возникает необходимость в процессах копирования данных между БД, синхронизация, ETL и все такое, что тоже немалый источник хлопот.
при необходимости внесения изменений в микросервис в большой компании зачастую представляет проблему выявить и, тем более, протестировать, все приложения-юзеры, его использующие. Поэтому часто всместо внесения изменений в существующий микросервис, просто создается очередной модифицированный клон, который делает почти то же самое. В итоге подход, призванный снизить избыточность кода, дает ровно обратный эффект.
микросервисы, когда вызывают другие микросервисы по HTTP, работают существенно медленнее, чем если бы тот же код исполнялся из одного процесса, что часто приводит к необходимости все переделывать без микросервисов
- если любой из нужных микросервисов недоступен, то как правило пользоватетель получает не частично, а полностью неработающее приложение. Это из области мифив, что приложением можно будет пользоваться, но с ограниченниями. Я таких приложений не видел.
В общем идея микросервисов красиво выглядит на презентациях и в книжках. В реальной жизни лучше сто раз подумать, а надо ли.
но при этом возникает необходимость в процессах копирования данных между БД, синхронизация, ETL и все такое, что тоже немалый источник хлопот.
Это не особо большая проблема, на самом деле. В целом если у вас выходит так что одни и те же данные хранятся в рамках разных микросервисов, возможно границы разделены неверно? Так же можно организовать CQRS и по изменению данных отправлять в очередь событие на перестройку read model всех сервисов (а сервисы уже сами все разрулят).
В итоге подход, призванный снизить избыточность кода, дает ровно обратный эффект.
микросервисы призваны раздробить систему. А проблема с сохранением обратной совместимости частично решается версионизацией API. Ну и опять же, если нужно много поменять на самом деле проще рядом завести еще один микросервис, хотя как по мне это скорее должно быть редким решением.
работают существенно медленнее, чем если бы тот же код исполнялся из одного процесса
что собственно более чем логично, но никто вам не мешает переделать транспорт на что-то более эффективное.
если любой из нужных микросервисов недоступен
single point of failure это называется. Это проблема не микросервисов а конкретной реализации. Критически важные вещи должны дублироваться.
В реальной жизни лучше сто раз подумать, а надо ли.
А вот тут соглашусь полностью. Далеко не у всех над одним проектом будет трудиться пара десятков разработчиков что бы была необходимость дробить систему. Но в целом подход с микросервисами очень даже хорошо подходит для реально больших проектов.
А вот тут соглашусь полностью. Далеко не у всех над одним проектом будет трудиться пара десятков разработчиков что бы была необходимость дробить систему.
Жизнь проекта разработкой не ограничивается. Потом начинается саппорт и мелкие доделки силами саппорта. У нас, например, в саппорте примерно человек 5, а количество микросервисов я даже не знаю сколько, думаю за сотню. И когда расследуешь баг, то не получается просто проследить всю последовательность вызовов до операций с БД, а приходится переключаться между разными частями раздробленной системы. Это замедляет расследование багов во много раз. Получается, сэкономили на разработке, но потеряли на саппорте.
Почти все продукты, которые используют микросервисы, подразумевают что работа над ними будет продолжаться довольно продолжительное время. А вот ситуации когда продукт переходит в суппорт и над ним трудятся всего 5 человек не означают что проект прекратил развитие?
Это продукт для внутреннего пользования, его разработали, внедрили, и теперь им все пользуются. "Развитие" происходит только если какие-то бизнес-юзеры требуют новый функционал. В этом случае подключается отдельный девелоперский отдел и ведет всю разработку. Разработчики и бизнес-аналитики, кстати, все по уму делают: рисуют модели бизнес процессов, описывают сущности, генерируют структуры данных и WSDL-интерфейсы, кодят, в общем все по книжке. Но почему-то когда есть выбор пойти в БД напрямую, или через микросервис, они всегда выбирают микросервис. В результате получается ад микросервисов, в котором среднее время расследования бага во много раз больше, чем в просто большом приложении.
если ищу причину какого-то бага, то в большинстве случаев где-то по ходу анализа исходника приложения натыкаешься на вызов очередного endpoint-а, приходится скачивать его исходники тоже, а там опять endpoint куда-то еще, и т.д. О локальном дебаге речь вообще даже не поднимается, так как слишком много приложений-микросервисов придется локально конфигурировать. В итоге баги ищутся, в основном, путем смотрения на код.
Тут налицо сильная связность и неполное разделение ответственности. Сервис должен быть изолированным, дабы была возможность отлаживать его не устанавливая весь остальной landscape.
микросервисы, как правильно заметил автор, зачастую написаны на разных версиях разных языков, что делает локальный дебаг трудным или невозможным
Бывает, что поделать. Docker в помощь
особенно странно видеть, как зоопарк микросервисов на разных версиях разных языков оперирует с одними и теми же логическими связанными данными. Я, конечно, понимаю, что хотели делать масштабируемо, но на уровне данных все SQL-запросы в итоге идут к одним и тем же базам данных, от чего БД становятся узким местом. Но отмасштабировать БД, как правило, намного труднее.
У каждого сервиса — свое хранилище, общих БД должно быть по минимуму
иногда базы данных пытаются сделать масштабируемыми путем разбиения на логически независимые базы. Микросервисы тогда зависимы только от своей БД, и чувствуют себя отлично, но при этом возникает необходимость в процессах копирования данных между БД, синхронизация, ETL и все такое, что тоже немалый источник хлопот.
Опять же — неправильное разделение ответственности между сервисами. Плюс приложения в такой архитектуре обычно проектируют с учетом толерантности к eventual consistency и не самым свежим данным.
при необходимости внесения изменений в микросервис в большой компании зачастую представляет проблему выявить и, тем более, протестировать, все приложения-юзеры, его использующие. Поэтому часто всместо внесения изменений в существующий микросервис, просто создается очередной модифицированный клон, который делает почти то же самое. В итоге подход, призванный снизить избыточность кода, дает ровно обратный эффект.
Если вам требуется внести изменения в микросервис да так что при этом отвалятся все клиенты (т.е. никакой обратной совместимости) — то налицо проблема в проектировании API, а конкретно — в версировании. Обновление одного сервиса не должно каскадно вызывать одновременное обновление еще кучи других от него зависящих.
микросервисы, когда вызывают другие микросервисы по HTTP, работают существенно медленнее, чем если бы тот же код исполнялся из одного процесса, что часто приводит к необходимости все переделывать без микросервисов
Не обязательно использовать HTTP, или вообще решить проблему изменив deployment (например развернуть сервисы в одном сегменте сети или вообще на одних машинах) вместо переписывания кода.
если любой из нужных микросервисов недоступен, то как правило пользоватетель получает не частично, а полностью неработающее приложение. Это из области мифив, что приложением можно будет пользоваться, но с ограниченниями. Я таких приложений не видел.
Обычно это работает на уровен фич. Простой пример — оплата. Если сервис обслуживающий PayPal упал, то Яндекс.Деньги например все еще могут работать. Или блок комментариев к статье — если сервис, обслуживающий комментарии лежит, то это не значит что статья не должна отображаться. Терпимость к ошибкам должны быть заложена в архитектуре.
Вообще лучший подход — это представить что ваш микросервис — абсолютно самостоятельный продукт и должен работать независимо от всех остальных частей приложения.
внезапно тесты на взаимодействие между микросервисами тоже нужно проводить
Да. интеграционные и end-to-end тесты нужно проводить. Но это не сложно и на это можно хоть отдельную команду QA выделить. Но эти тесты будут выявлять именно баги при интеграции микросервисов, то есть ошибки взаимодействия в одном микросервисе, как он формирует запросы.
То есть в принципе те же проблемы и для монолита, но их решать чуть сложнее поскольку при увеличении числа разработчиков будет увеличиваться энтропия. Когда у вас много маленьких команд — этим управлять удобнее и контролировать процесс так же удобно. При том что далеко не все команды будут взаимодействовать между собой.
Я занимаюсь разработкой API для мобильных приложений и у меня эти же проблемы (обратная совместимость, отсутствие контроля за клиентами) и эти же задачи встают чуть ли не каждый день и они решаемы.
Но, как мне кажется, стоимость нормальной железки для программиста не должна влиять на архитектуру приложения.
У меня на одном проектике из-за ошибки проектирования есть один микросервис, который потребляет 140 гигов оперативки. Ну это я так, к вопросу стоимости железок.
Связность в монолите можно контролировать. Собственно и микросервисы могут быть сильно связными.
Можно контролировать. Точно так же как и в случае микросервисов. То есть в случае монолита подавляющее большинство забивают болт. А в случае микросервисов это "забиваение болтов" ооочень быстро приведет к проблемам и они всплывут весьма рано.
и если вы не можете сделать нормальный монолит, то до микросервисов вы еще не доросли.
в точку. Вот только в случае микросервисов количество людей которые могут сделать нормальный монолит может быть значительно меньше чем в случае собственно монолита. Проще вводить новых людей, проще менять команды. Именно это подразумевается под "масштабированием".
Ну а если у нас большая команда людей, не способных написать монолит, да, профита от микросервисов мы тем более не получим. Разве что быстрее придем к тому что нужно нанимать кого-то более компетентного.
Ну там мифический человеко-месяц, все такое…
> Всеравно в монолите есть некие подсистемы отдельные. у этих подсистем есть публичный интерфейс.
Это у Вас очень крутой монолит, представляющий собой набор независимых сервисов, работающих в одном адресном пространстве :) Я бы предпочел работать именно с таким «монолитом», нежели с «микросервисами», сидящих поверх одной реляционной БД.
Обычно под монолитом понимают приложение, концептуально представляющее собой некое глобальное состояние + кучу методов для его изменения.
если любой из нужных микросервисов недоступен, то как правило пользоватетель получает не частично, а полностью неработающее приложение. Это из области мифив, что приложением можно будет пользоваться, но с ограниченниями. Я таких приложений не видел.
У вас не микросервисы, а просто распределенный монолит. Общение между микросервисами должно происходить полностью асинхронно, через какую-нибудь кафку например. Это решит проблему продолжения работы всего приложения при одном умершем сервисе. Он просто обработает данные из кафки позже, когда восстановится, а остальные этого даже и не заметят.
При асинхронном общении между сервисами приходится еще что-то выдумывать, чтобы помечать состояния сущностей, которые находятся в обработке и ожидают ответа какого-то микросервиса — ведь юзерам надо показать, что его действие уже исполняется, чтобы он еще раз Submit не нажимал. А если еще надо обработать асинхронный ответ какого-то микросервиса — то вот уже и в нашем микросервисе надо заводить еще один endpoint (ну или subscriber), который будет это событие слушать. И где здесь простота и элегантность? А как в этом ловить баги, или дебажить локально?
Но вообще-то, говоря о полностью неработающем приложении я имел в виду тот факт, что любая ошибка в нужных сервисах не даст пользователю возможности сделать то, что он хотел. Ему, по большому счету, без разницы, видит он ошибку 500, или красивую надпись "сервис ХХХ недоступен". В обоих случаях это будет тикет в саппорт. Пример блога с неработающим сервисом комментариев от реальной жизни несколько оторван.
У нас, кстати, есть MQ (Websphere), иногда приходится дебажить и там тоже, и это еще больше усложняет саппорт. Но видимо совсем без MQ не получится, т.к. много разнородных систем.
Сервисы бывают разные. Приведу пример расследования бага из недавнего...
Внешний пользователь на лендинг-странице не может ввести свою информацию — системе не нравится его емайл. Иду в приложение лендинг-страницы. Вижу, что приложение проверяет инфу, введенную пользователем, путем вызова микросервиса, в котором хранятся все внешние потенциальные клиенты. Скачиваю исходники этого микросервиса. Вижу, что емайл он проверяет вызовом еще одного микросервиса проверки емайлов. Скачиваю его исходники тоже. Вижу, что там у нас вообще-то есть приложение, которое используется отделом маркетинга, где они в числе прочего ведут небольшую базу правил для емайлов, чтобы иметь возможнось делать черные/белоые/серые списки. Вижу, что для емайла определяется список, и если это серый список, то наш микросервис вызывает микросервис проверки емайлов из сторонней компании, которая проверяет емайл уже путем коннекта по SMTP и отправки всяких там HELO заголовков, но без отправки письма.
Все красиво и логично, не прикопаться. Но на поиски бага ушел день с лишним, так как всю эту архитектуру пришлось постигать самостоятельно. В моем случае была ошибка в базе правил черных/белых/серых списков.
у вас явный затык в архитектуре.А мне кажется наоборот, архитектура очень даже продуманная, вполне годится для презентаций по микросервисам.
задача микосервиса хранить клиентов или валидировать мейлы?Задача — хранить информацию обо всех внешних пользователях, которые еще не стал клиентами, но которые каким-то образом к нам обращались и у нас есть о них какая-то, как правило частичная, информация: кто-то заполнил форму на лендинге, кто-то оставил контакты на промо-акции, кто-то позвонил, и т.п. В виде сервиса (слово «микро» тут не очень подходит) сделано потому, что им пользуемся не только мы, но и наши дилеры партнеры. Они могут сделать свой промоушен, лендинг, рассылку и т.п, но данные в итоге поступают в наш сервис. По-моему очень даже умно придумано.
вот, оказывается для проверки мейлов естьсервис, но вы к нему не обращаетесь почемутоДа, в самом лендинг приложении мы ничего не делаем, потому что задача состоит еще и в том, чтобы по неполной информации попытаться определить есть ли у нас этот клиент в базе, и если да, то не создавать клона. Отдел маркетинга, кроме прочего, ведет базу правил для нечетких совпадений, и это все для того, чтобы не плодить копии и не раздражать одного и того же клиента по разным каналам. Понятно, что лучше всю эту логику сделать в одном месте, а не кодить по новой для каждого нового лендинга.
это списки дял маркетингаЭто списки правил валидации емайлов, которым пользуется сервис валидации емайлов. Сами емайлы у них тоже есть, но в других базах/приложениях.
тогда почему у этого сервиса есть ендпойнты для валидации мейлаУ него нет своих ендпоинтов для валидации емайла. Он вызывает отдельный микросервис если ему надо отвалидировать емайл. В микросервисе валидаций емайлов есть небольшая база с правилами валидации. В общем все разбито на независимые части, примерно так как вы и пишете. Только трудоемкость саппорта от этого получается слишком высока.
Если есть хотя бы простенькая диаграмма с описанием связей, то ваше расследование превращается в 10 минутный просмотр такой диаграммы и исправление бага.
Если такой диаграммы нет — по моему логично потратить неделю на её создание чем тратить каждый раз тратить день на поиск 1 простого бага.
особенно странно видеть, как зоопарк микросервисов на разных версиях разных языков оперирует с одними и теми же логическими связанными данными. Я, конечно, понимаю, что хотели делать масштабируемо, но на уровне данных все SQL-запросы в итоге идут к одним и тем же базам данных, от чего БД становятся узким местом. Но отмасштабировать БД, как правило, намного труднее.
иногда базы данных пытаются сделать масштабируемыми путем разбиения на логически независимые базы. Микросервисы тогда зависимы только от своей БД, и чувствуют себя отлично, но при этом возникает необходимость в процессах копирования данных между БД, синхронизация, ETL и все такое, что тоже немалый источник хлопот.
Если принято решение делить базу между сервисами (большой плюс — простое обеспечение ссылочной целостности), то очень облегчает жизнь принцип «у каждой схемы/таблицы/столбца только один владелец, имеющий право INSERT/UPDATE/DELETE, остальные только SELECT» (лучше зафиксировать через права на уровне СУБД). Это позволит считать SELECT запросы лишь ещё одним дополнительным транспортом (на HTTP API мир клином не сошёлся) на query запросы к сервису-владельцу.
Если же у сервисов свои базы, то нужно очень стремиться копировать не данные, а только идентификаторы. На моей практике для операционной деятельности (включая оперативные отчёты) вполне достаточно когда одна (пускай даже денормализованная в целях оптимизации скорости/памяти) база выделяется под один сервис, оперирующий одной (или несколькими логически очень близкими) сущностью, её агрегатами и справочниками, ссылаясь на другие лишь по идентификатору, а аналитические отчёты по произвольным разрезам и периодам строятся средствами DWH или другими агрегаторами, умеющими собирать и связывать данные (и по запросу от потребителя, и по расписанию, и по событиям от сервиса-владельца) из многих разнотипных источников.
Эмм… У вас и близко никакие не микросервисы.
del
Навскидку:
«в кратце»: «вкратце» пишется слитно
«все зависит от вашего конертного случая»: от «конкретного» случая, надо полагать?
«одну с нашим микрофремворком»: «микрофреймворком»
«существующего контролера»: «контроллера», надо полагать — не билеты же он у вас во фреймворке проверяет
«Незабываем посылать токен»: «не забываем» пишется раздельно
Я всё понимаю, что и стиль изложения должен быть весь из себя стремительный, но хоть каплю уважения, блин, к читателям!
«Извините, если кого обидел».
Вообще, если пользоваться до степени доверия компьютерной проверкой слов, лучше всего перейти на упрощенный вариант языка, где больше одного варианта у слова нет, и нет мешающих стремительности мысли «похожестей» вроде «в кратце»/«вкратце» )
А когда контейнеров становится слишком много, то получается вот так:
Т.е. теперь пованивает не только код, но и вообще всё, включая администрирование. Мы сами себе создали дополнительные проблемы. Ведь для каждого сервиса надо выполнить следующее:
- накодить сервис
- оттестировать сервис
- документировать сервис
- оттестировать 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 Не забывайте про вариант с самописной системой контейнеризацией и/или инфраструктурой вокруг этого на том или ином уровне (в конце концов у вас может быть в наличии админ с достаточными знаниями). Один день на гуглинг и пара дней на обработку его результатов может сэкономить месяцы и даже годы разработки.
В вашем случае я бы сделал так
Я напомню, что эта задача чисто академическая, с непреодолимым желанием попробовать именно микросервисы.
Кроме того стоит рассмотреть различные другие крутые штуки, которые делают контейнеризацию и инфраструктуру вокруг контейнеров. rkt/CoreOS, LXC/LXD, OpenVZ, kvm, OpenStack и другие. Тысячи их. Одно из сравнений можно посмотреть вот тут: https://coreos.com/rkt/docs/latest/rkt-vs-other-projects.html Не забывайте про вариант с самописной системой контейнеризацией и/или инфраструктурой вокруг этого на том или ином уровне (в конце концов у вас может быть в наличии админ с достаточными знаниями). Один день на гуглинг и пара дней на обработку его результатов может сэкономить месяцы и даже годы разработки.
Я не очень понял как отказ от докера в пользу самописных контейнеров или даже каких-то других поможет сэкономить мне время. Докер настолько плох?
Докер настолько плох?
Все с ним хорошо. У меня он уже пол года в продакшене и я счастлив.
Я не очень понял как отказ от докера в пользу самописных контейнеров или даже каких-то других поможет сэкономить мне время. Докер настолько плох?
Я не говорю, что докер плох (хотя об этом можно поспорить тоже). Я говорю о том, что совершенно не ясно, какие задачи вы пытаетесь им решить. Академическая задача? Так явно напишите об этом.
Безусловно, это задача ради задачи, но хочется отметить что даже в таком варианте, это работать будет и будет работать неплохо (быстро и без проблем).
Да и еще в паре мест. Суть в том, что я хотел написать маленький и как следствие, максимально простой продукт (но работающий минимальным функционалом) на микросервисах, чтобы на примере было несложно понять (и мне в том числе) как же собственно все это выглядит? Еще хотелось услышать мнение обо всем этом тех людей, которые реально работают с сотнями микросервисов, и я их кстати услышал, за что им огромное спасибо.
Это сложно.
Это сложнее чем монолит. Но чем больше проект тем меньше становится технических проблем и тем больше организационных. Скоординировать работу 40-а разработчиков над одним проектом знаете ли тоже весьма сложная задача.
Я имею ввиду, что надо тщательно прорабатывать всю архитектуру, вооружившись такими полезными орудиями труда, как Бритва Оккама, принцип KISS и здравый смысл.
И Здравый смысл рано или поздно подскажет что проще разделить проект на маленькие проекты со своей командой разработчиков, что бы процесс стал более управляем.
На мой взгляд гораздо лучше использовать большие и толстые сервисы. В вашем случае я бы сделал так:
это называется монолит. И при работе большого количества разработчиков у вас будут проблемы с управлением этой командой. А проблемы проектирования архитектуры будут не менее критичны чем в случае микросервисов.
Это дешевле. Это работает быстро. Это не требует много ума. Это достаточно безопасно. Это неплохо документируется. Это вполне масштабируемо.
До определенных масштабов. Проблема монолитных приложений в том, что они очень быстро выйдут из под контроля и код скорее всего превратится в кашу. Микросервисы же позволяют изолировать говнокод. Это существенно снижает риски при разработке новых фич так как все изолировано.
А проблемы с документированием у вас будут примерно одинаковые.
В дальнейшем сюда может добавиться контейнер для небезопасного кода.
вы путаете контейнеры и микросервисы как мне кажется. Я вот монолиты с докером делаю, и меня все устраивает.
всё, что небезопасно (например код третьих лиц сомнительного качества) стоит порезать на сервисы
Фреймворки типа? для отделения инфраструктурного кода от остального придумали гексагональную архитектуру. Микросервисы решают другие проблемы.
если для поддержки сервиса требуется более 5-15 человек, то подумать о разделении этого на два-три сервиса
более 3-х как по мне. При команде больше 5-ти человек энтропия разьест проект.
если нам нужно симулировать бурную деятельность и/или освоить бюджет (под эту причину вполне подходит статья, которую я комментирую)
Проекты с "бюджетом" никто не делает на микросервисах. Это больше нужно для продуктов которые планируется достаточно долго развивать.
Кроме того стоит рассмотреть различные другие крутые штуки, которые делают контейнеризацию и инфраструктуру вокруг контейнеров.
Зачем? Docker дефакто стандарт индустрии, им пользуются тысячи разработчиков, проще найти devops-ов. И не забывайте что сила докера (да и рокет о котором вы говорите) не в самой контейнеризации, оно там LXC просто использует, а в возможности делать образы системы и наследовать их. То есть если у меня есть 100 образов отнаследованных от 3-4 мне будет существенно проще поддерживать систему с точки зрения администрирования.
Не забывайте про вариант с самописной системой контейнеризацией
Это мы снова про распиливание бюджета?
Один день на гуглинг и пара дней на обработку его результатов может сэкономить месяцы и даже годы разработки.
велосипеды спасут мир.
/me как раз цинично убивает велостоянку которая по возрасту скоро паспорт получить может, и это даже без разговоров о суммах на поддержку этой, кхм, стоянки
Про полезность статьи судить не Вам(возможно, что многим примеры будут полезны).
just for the sake of truth, это давно не так. Docker использует
libcontainer
, который работает с cgroups и namespaces напрямую.Конечно есть и свои минусу, но все эти минусы основаны на непонимании концепции разработки микросервисной архитектуры.
Ближайшие планы: при увеличении нагрузки на тот или иной микросервис, автоматически поднимать еще один инстанс
Особенно в рамках толстых сборщиков логов, вроде logstash какого
В нашем случае всё основано на роли пользователя, поэтому независимо от Id пользователя, если в кеше есть данные с определённой ролью, мы их возвращаем.
А если HTTPS это ещё + 100-200 ms на handshake.
Не лучше ли через unix sockets?
Все кто уперся в HTTP обычно переходят на очереди (zeromq в основном, хотя есть ребятки которые кафку используют). В этом случае, поскольку у нас приложение на PHP, он не должен умирать. И это налагает свои нюансы на разработчиков. Сейчас с этим не так плохо как скажем еще 2 года назад.
поправьте пожалуйста
Зачем на по две копии некоторых сервисов? Потому что с одной будет не интересно и не понятно.
Гораздо интересней использовать docker-compose scale, делегируя решать вопросы масштабирования, обнаружения сервисов и балансировки инфраструктуре докера, а не хардкодя её в коде и конфигах.
Готовим простой блог на микросервисах, пишем свой микрофреймворк на php и запускаем все на Docker с примерами