Ну да вы с технической и пракатической на это смотрите. Если я правильно понимаю то что вы описывате вы полностью прониклись идеей ;)
Я в свой фирме тоже в эту сторну толкаю, но люди привыкшие к монолитам пока с недоверием смотрят на мой проект ;)
Есть частный проектик, где я имею все свободы — и там я тоже руководствуюсь юниксовской филисофией ( do one thing and do it well)
Просто пару лет я был консалтером и мы продовали «Эндерпрайз СОА». И вот в этом мире другие вещи в фокусе.
Там речь идет о орхестрации сервисов и их подвешиванием к примеру в сьиты BPM или приочие штуке длай мэнеджмента.
При этом вопросы о архитектуре самих сервесов или их легковесности не в фокусе тематики…
И сервисом может оказаться вдруг какая-нибудь страшная API управляющая какими-то сущностями в SAP/R3 или прочее легаси…
Это конечно не лучшие примеры, но тоже СОА…
Присоединяясь к powerman дополню, что делить ради деления смысла то может и нет. Если не видите явных причин иметь отдельные сервисы то может не надо вам это…
В общем пережде чем делить в рамках SOA вам надо задать себе вопрос какую business capability (бизнесс-возможность/способность) должен олицетворять сервис.
Она должна быть осмысленна иммено с этой стороны. Например, сервис который знает что-то про запчасти, про сотрудников, третий про ресурсы, четвертый бух-учет, и т.д.
И даже если у сервиса сорудников и сервиса бугучета будут общие обьекты это совершенно не помешает вам (см: BoundedContext: martinfowler.com/bliki/BoundedContext.html )
Причем в моем понимании сервисы в корпоративной SOA это немног не о том… Можно конечно так её рассматривать. Но всеже…
Например можно иметь один достаточно сложный сервис в соа который будет сам по себе аппликацией сосотоящей из микросервисов.
В моем понимании парадигма микросервисов это скорее девелопер-дривен. А СОА это бизнес-дривен.
А сейчас надо делать публичную платформу, которую будут пытаться ломать, к которой скорее всего придётся прикручивать биллинг за вызовы API…
А мы вот именно с такой штуки стали делать с микросервисами… и биллинг и центральная аутнетикация…
Но архитектурных проблемы решаем по ходу дела…
Проблемы скорее в том что участники проекта не особо опытны и еще не вьехали зачем «столько сервисов»… Ну я новый в их команде… и тут сновыми идеями их учу…
Каменты типа… «слава богу что новый сервис не стали делать»… Что свидетельствую о том что народ пока не проникся… ;))
Дык не надо всю архитектуру сразу и доконца. ;)
В этом то и «геймчэнджер» что ошибки прощаются легче, и можно начинать с известных и понятных сервисов… (Аджайл!)
И все можно достаточно незатратно поменять в процессе, огхраничив последствия изменений в переделах одного сервиса (в идеале конечни).
А вот продеалть тоже в «Энтерпрайзном» монолите через годик работы — писец :)
Требования что эти микросервисы обязательно должны использовать лишь ассинхронную модель нет.
Хотя я согласен с вами, лучше сразу её закладывать. Тоже сталкивался с каким-то срахом у разработчиков перед таким подходом…
Но в принципе не обязательно и вовсе не везде…
Тут Кроме ассинхронности куча нестандартынх решений… Например людей приходится убеждать что
одна большая база данных это уже не торт как в 80/90 тых.
OSGI поидее скорее о модульности сервиса. Может в частном рассмотрении это конечно что-то вроде…
Но «true» микросервисы это разделении монолитной аппликации на сервисы (процессы) не на модули.
Если делат через фиг, с новой версией контейнера… то видимо он делает ран. выяснили… Спасибо…
Тоесть фиг редуцируется на удобописание запуска контейнеров…
Ок, интересно
На сколько я вижу там достаточно бесполезная команда restart…
Может с ней и работает, с ней я не пробовал…
А вот со stop и run не работает. Именно они однако и нужны при обновление версии зависимого контейнера… именно это частый паттерн… и тут линкинг не поможет.
Не то что бы умирает. Перерождается…
Да Докеры в плотную занялись Enterprise фичами. Docker Machine, Docker Swarm, Docker Compose
что у части комьюнити вызвало в прочем диссонанс… Что понесло за собой некий раскол и альтерантивный мув сосредотачивания на контейнерах и их стандартизации только (unix way).
См. Rocket от CoreOS
Клиенту всеравно… ему или ДНС имя или переменную окружения дай…
Но ни то ни то не сменится без перезапуска контейнера… И фиг в этом ничего не меняет… Это просто ограничения «оркестрации» с помощью докереовского линкования…
Поэтому в серьезном проекте надо что-то поинтереснее использовать. Представленное выше решени со Скай ДНС позволяет начальный уровень «оркестрации», но лишь начальный.
Вот вот. Что деградирует весь этот fig до уровня альтернативного (более удобного) описания запуска контейнеров, не имея никаких функций orchestration. :(
Может я что-то неправильно делал но если я перестартовывал аппликационный контейнер на ПХП то БД перестовала находится…
Все востанавливалось только после полной перестартовки всей цепочки… Может была специфика какая… но вот именно в этом фиг обломал меня…
Вы сами пробывали или доки цитируете?
Я использовал именно такую связку именно с ДБ но отказался от этого,
так как докеризированно мног ПХП приложени не кешировало соедиенение с БД и тем самым к каждому доступу к ДБ добавился запрос к СкайДНС…
Что мне очень не понравилось в этом конкретном случае… А так да как первое решение что-бы поиграть пойдет… Но я смотрю сейчас в сторону kubernetes
и вы попадете в бегущий контейнер…
Работает с версии 1.3.0 если не ошибаюсь… именно для того чтоб люди контейнеры SSH не засоряли.
P.S. пишу не только вам. Просто втреде не увидел ссылки на команду exec
Я в свой фирме тоже в эту сторну толкаю, но люди привыкшие к монолитам пока с недоверием смотрят на мой проект ;)
Есть частный проектик, где я имею все свободы — и там я тоже руководствуюсь юниксовской филисофией ( do one thing and do it well)
Просто пару лет я был консалтером и мы продовали «Эндерпрайз СОА». И вот в этом мире другие вещи в фокусе.
Там речь идет о орхестрации сервисов и их подвешиванием к примеру в сьиты BPM или приочие штуке длай мэнеджмента.
При этом вопросы о архитектуре самих сервесов или их легковесности не в фокусе тематики…
И сервисом может оказаться вдруг какая-нибудь страшная API управляющая какими-то сущностями в SAP/R3 или прочее легаси…
Это конечно не лучшие примеры, но тоже СОА…
В общем пережде чем делить в рамках SOA вам надо задать себе вопрос какую business capability (бизнесс-возможность/способность) должен олицетворять сервис.
Она должна быть осмысленна иммено с этой стороны. Например, сервис который знает что-то про запчасти, про сотрудников, третий про ресурсы, четвертый бух-учет, и т.д.
И даже если у сервиса сорудников и сервиса бугучета будут общие обьекты это совершенно не помешает вам (см: BoundedContext: martinfowler.com/bliki/BoundedContext.html )
Причем в моем понимании сервисы в корпоративной SOA это немног не о том… Можно конечно так её рассматривать. Но всеже…
Например можно иметь один достаточно сложный сервис в соа который будет сам по себе аппликацией сосотоящей из микросервисов.
В моем понимании парадигма микросервисов это скорее девелопер-дривен. А СОА это бизнес-дривен.
А мы вот именно с такой штуки стали делать с микросервисами… и биллинг и центральная аутнетикация…
Но архитектурных проблемы решаем по ходу дела…
Проблемы скорее в том что участники проекта не особо опытны и еще не вьехали зачем «столько сервисов»… Ну я новый в их команде… и тут сновыми идеями их учу…
Каменты типа… «слава богу что новый сервис не стали делать»… Что свидетельствую о том что народ пока не проникся… ;))
В этом то и «геймчэнджер» что ошибки прощаются легче, и можно начинать с известных и понятных сервисов… (Аджайл!)
И все можно достаточно незатратно поменять в процессе, огхраничив последствия изменений в переделах одного сервиса (в идеале конечни).
А вот продеалть тоже в «Энтерпрайзном» монолите через годик работы — писец :)
Хотя я согласен с вами, лучше сразу её закладывать. Тоже сталкивался с каким-то срахом у разработчиков перед таким подходом…
Но в принципе не обязательно и вовсе не везде…
Тут Кроме ассинхронности куча нестандартынх решений… Например людей приходится убеждать что
одна большая база данных это уже не торт как в 80/90 тых.
Но «true» микросервисы это разделении монолитной аппликации на сервисы (процессы) не на модули.
Dnsmasq по умолчанию какие-то логи замусориовает или тих?
Тоесть фиг редуцируется на удобописание запуска контейнеров…
Если на хосте то Зачем?
Если в контейнере то как?
На сколько я вижу там достаточно бесполезная команда restart…
Может с ней и работает, с ней я не пробовал…
А вот со stop и run не работает. Именно они однако и нужны при обновление версии зависимого контейнера… именно это частый паттерн… и тут линкинг не поможет.
Да Докеры в плотную занялись Enterprise фичами.
Docker Machine, Docker Swarm, Docker Compose
что у части комьюнити вызвало в прочем диссонанс… Что понесло за собой некий раскол и альтерантивный мув сосредотачивания на контейнерах и их стандартизации только (unix way).
См. Rocket от CoreOS
Но ни то ни то не сменится без перезапуска контейнера… И фиг в этом ничего не меняет… Это просто ограничения «оркестрации» с помощью докереовского линкования…
Поэтому в серьезном проекте надо что-то поинтереснее использовать. Представленное выше решени со Скай ДНС позволяет начальный уровень «оркестрации», но лишь начальный.
Все востанавливалось только после полной перестартовки всей цепочки… Может была специфика какая… но вот именно в этом фиг обломал меня…
Вы сами пробывали или доки цитируете?
так как докеризированно мног ПХП приложени не кешировало соедиенение с БД и тем самым к каждому доступу к ДБ добавился запрос к СкайДНС…
Что мне очень не понравилось в этом конкретном случае… А так да как первое решение что-бы поиграть пойдет… Но я смотрю сейчас в сторону kubernetes
и вы попадете в бегущий контейнер…
Работает с версии 1.3.0 если не ошибаюсь… именно для того чтоб люди контейнеры SSH не засоряли.
P.S. пишу не только вам. Просто втреде не увидел ссылки на команду exec