« Rev
@oop_ru   79
Fwd »


Sergey
че это?
Sergey
ну и как бы soa это тип "ну чувак теперь тебе придется делать это на ивентах/сообщениях")
invariance
че это?
Потому что каждый сервис должен работать как отдельный процесс
Sergey
и чем пхп не подходит?
invariance
А в php как бы все кучей исполняется
Sergey
Потому что каждый сервис должен работать как отдельный процесс
никто не оговаривал что процесс не должен умирать
Sergey
в смысле кучей?)
Sergey
А в php как бы все кучей исполняется
если у тебя каждый "сервис" является самодостаточным приложением со своей базой данных... то нет никакой разницы
Sergey
просто слегка глупо
invariance
Делать сервисную архитектуру на php - это странно, т.к. придется для каждого сервиса юзать отдельный php процесс
invariance
В общем-то в монолите - нет
invariance
Я наверное неясно выразился
Sergey
В общем-то в монолите - нет
окей, тогда давай так. SOA в контексте монолитной архитектуры не имеет ровным счетом никакого смысла
Sergey
особенно если вспомнить в контексте какого вопроса ты про нее вспомнил
invariance
Астанавись
Sergey
микросервисы - полезный вид SOA
invariance
ты не понял меня
Sergey
я не понял тебя)
Sergey
там Ольга правильную ссылку кинула
invariance
Под процессом php я подразумевал отдельную php-машину на каждый процесс
Sergey
Под процессом php я подразумевал отдельную php-машину на каждый процесс
я опять не понял. Что, почему отдельная машина, зачем это?
Sergey
и давай мыслить "контейнерами" (мы же модные?)
invariance
Да
invariance
Мало ли, вдруг ты про докер не слышал
invariance
Ну так вот, в SOA, каждый сервис - является контейнером по сути
invariance
и между ними по ресту (или RPC, или еще чему угодно) гоняются сообщения
invariance
Ну так вот, в чем суть моего посыла, лучший вариант для модульности - SOA
Sergey
делал и soa (где rabbitmq между компонентами был шиной) и микросервисы
invariance
Там же было сообщение выше, что типо разграничить логику
Sergey
окей, как бы ты в рамках soa архитектуры делал бы то что я описывал?
Sergey
скорее всего по звершению транзакции регистрации юзера ты бы кидал RPC запрос на другой сервис что бы тот что-то делал
Sergey
так?
invariance
Неужели ты сам не догадываешься, как тут использовать принцип SOA?)
invariance
например если кто-то регистрируется в системе указав своего реферального пользователя, мне надо запустить отдельную бизнес логику которую я хотел бы вынести в отдельный модуль и полностью отделить от всей системы
invariance
как минимум потому что... мне нужно будет в будущем очень часто менять этот кусок системы вплодь до того что придется отключать отдельные ее элементы из конфига
invariance
то есть как бы... есть второстепенная логика которую мне хочется тригерить ивентами в основной системе
Sergey
Неужели ты сам не догадываешься, как тут использовать принцип SOA?)
неужели ты не увидел что этот способ ничем не отличается от старых добрых событий? Код выйдет абсолютно одинаковым
Sergey
вот только нет гемороя с поддержанием распределенного приложения
invariance
Ой, ну кто как называет. Кому то разделение обязанностей не кажется гемороем
Sergey
Ой, ну кто как называет. Кому то разделение обязанностей не кажется гемороем
поддержка, деплоймент, раскидывание контейнеров по сервакам... ну и такой момент что вся команда разработчиков должна прекрасно понимать что делает и сроки не должны быть ужаты в край)
Sergey
распределенные архитектуры крутые, не спорю, но у меня прям дикий батхерт когда люди просто так говорят "да не парься, заюзай SOA/микросервисы"
Sergey
как буд-то бы это решение всех проблем и у нее нет своих минусов
Sergey
а точнее не то что минусов... цены
invariance
Ну ты не вырывай из контекста) Ты сказал про модульность, я упомянул про SOA - все логично вроде бы
Sergey
а не про модульность
Sergey
у меня уже есть система, и ивенты хороший промежточный этап для дальнейшего разделения приложения на более четкие контексты
invariance
Объясни джуну, как эвенты могут выглядеть, как SOA
Sergey
Объясни джуну, как эвенты могут выглядеть, как SOA
вот смотри, мой пример ты рассмотрел, предложил SOA
Sergey
у тебя в рамках одной будут два компонента - users и referral system
Sergey
так?
invariance
Да
Sergey
вот а теперь скажи, как бы ты с SOA сделал бы так, что бы users ничего не знало о referral system но при этом дергало бы его при успешной регистрации пользователя при определенных условиях
Sergey
хотя бы примерно
Sergey
где и кто дергал бы кого по RPC/HTTP/etc
invariance
А зачем юзеру дергать реферальную систему?
invariance
ну, в смысле, оно вроде по другому работает
invariance
сначала дергается реферальная система
Sergey
Другой контекст это другое приложение с другим сабдоменом
ну там примерно так и есть. У меня есть регистрация пользователей, и приглашать людей можно в рамках оной. И есть другое приложение по сути которое позволяет строить рейтинги юзеров по куче критериев.
Sergey
потом на основе этой статистики можно бонусы раскидывать в другие части системы
Sergey
то есть полностью независимые контексты. Если я отрублю реферальную систему - другие компоненты об этом не должны даже знать
Ale
бл?
Бизнес- логики, тупаю команда в дпугую сисиему
Sergey
эм.... ну говорю ж, логика разделена по контекстам
Sergey
есть инвайтер юзера. Он нужен не только для рефералки
Sergey
рефералка постоянно раскидывает людям в бэкграунде какие-то бонусы
Sergey
сейчас у меня на нее завязано пара компонентов системы но я это дело буду развязывать на след неделе
Sergey
и по сути всей остальной части плевать каким образом бонусы были собраны
Sergey
ну и еще там есть всякие рейтинги юзеров в этом компоненте
Sergey
ну то есть самодостаточное приложение
Sergey
я в своем проекте где-то 5 таких вот самодостаточных контекстов выделил которые вообще не влияют друг на друга (то есть это цель, сейчас по коду есть зависимости)
Sergey
и пока я неделю кручу в голове доменные ивенты и мне дико нравится
Sergey
ну и по поводу дебагов и прочего - доменные ивенты весьма легко трекать
« Rev
@oop_ru   79
Fwd »