sbh
Зря вы так думаете. Смысл сказанного мной выше в том, что задавать вопросы "не работает" - это пустая трата времени.
Я не спорю, Влад Животнев угадал, молодец, пирожок ему вкусный за это.
Но есть нюанс: тот же fpm могут падать по миллиону причин.
Решение любой проблемы начинается с ее локализации, в этом вопросе она началась только в комментариях.
В текущем виде формулировка вопроса никуда не годится. Это тоже самое что спросить: у меня все работало, а теперь ничего не работает, уточняю: на компьютре.
Сделай запрос к другому сервису вручную и посмотри, что отвечает (проставь таймаут 3 минуты). Если к логам сервиса доступа нету - обращайся к его вендорам.
> Поделитесь мыслями - почему вам было бы удобнее так работать, какие преимущества вы получили бы при таком подходе?
Многие из системы предрасположены к репликации. Например: почтовые рассылки (Z). В случае повышения нагрузки не составит труда поднять еще несколько нод под это дело. При этом даже в случае, если X ведет себя не корректно - Z будет работать корректно.
Пример из жизни: есть задача по вытягиванию платежных данных пользователя и отправки их партнерам. Я использовал один из классов соседней подсистемы, которая это дело умеет. Но как результат - не работает. Оказалось, что этот класс оставлен только для обратной совместимости и более не используется. В случае разделения на сервисы подобная ситуация невозможна, потому как спецификация API обязана быть, как документ.
Основной плюс подобного подхода - это независимая разработка сервисов. Например фронт сайты требуют что бы быстро (на вчера), красиво, ну и качество так себе. Сервис платежей разрабатывается в более медленном темпе и должна быть: безопасной, 100 раз перепроверенной. Сервис чатов живет тоже в своем темпе, он не на столько безопасен, как платежи, но должен выдерживать огромную нагрузку.
Так же плюсом является то, что каждый из сервисов определяет свои собственные требования к окружению. Например фронт сайтики - вполне ок на php, тяп-ляп и в продакшн. Платежи - ява. Чаты - нода, или erlang. Чатонить специфическое, например тегирование пользователей - можно на golang.
Как следствие есть возможность делать такой финт ушами: концепты писать на одном стеке, и в случае успеха - быстро переписать на другом.
@kazhuravlev
> лишь бы разработчики могли сосредоточиться на бизнесе а не на выравнивании контрактов и интерфейсов
))) Разработчики не занимаются бизнесом, а имплементируют бизнес логику. Контракты и интерфейсы нужно выдерживать в любом случае, иначе система будет вести себя не предсказуемо.
Еще раз: один репозиторий вас ни капли не спасет.
Как пример функция login($login, $pass): я залью туда "" и ресурс, что произойдет? По хорошему я должен словить исключение, и это будет контрактом.
Поймите, один репозиторий - вас рано, или поздно приведет к монолиту, что бы вы не делали. И в один прекрасный момент при заливке только сервиса Х вы будете обязаны заливать всю систему, со всеми вытекающими.
kazhuravlev
> если бы все сервисы находились бы в одном репозитории, все было бы проще - изменил модель, от которой все наследуются - и все готово.
Никто не мешает общие классы и хэлперы вынести в общий репозиторий, который будет зависимостью каждого из микросервисов.
Правда как и в случае с одним репозиторием: изменение одной сущности может привести к непредсказуемым последствиям.
kazhuravlev увы, от этого вы не сможете застраховаться.
Все изменения должны быть задекларированы в спецификациях API каждого из сервисов. Если X перешел на новую версию API, а Z с ней работать не умеет - в интеграционных тестах смысла нет потому как контракт у вас выполняться не будет в любом случае.
Если это ошибки в имплементации API одного из сервисов - это должно вылезти в тестах этого же сервиса.
Конкретно связь X и Z проверяется уже в масштабах системы во время подготовки к релизу. Это значит, что в релиз попасть новая версия X и старая Z не могут.
Безусловно есть очень большой минус в данном подходе: 7-меро одного таки ждут.
Инструкции для CI вполне можно хранить в заранее оговоренном виде, например как у того же travis: .travis.yml
> В жтом случае необходимо будет для каждого микросервиса прописывать зависимости от других микросервисов, которые необхоимы для тестирования текушего.
Тут - только эмуляторы, на основании спецификации. В отличии от SOA тут нет понятия "я работаю с сервисом А", вместо этого "я пытаюсь работать по спецификации с неизвестным сервисом". Подход микросервисов предполагает, что связанные с ними могут в любой момент отвалиться по любым причинам.
Что касается релиза системы в целом, и интеграционных тестов: создается общий репозиторий с фиксированными зависимостями от конкретных версий микросервисов И набором интеграционных тестов. Конкретной бизнес логики там нет, его задача - собрать все в кучу. При этом каждый из сервисов живет своей независимой жизнью.
Общий релиз в данном случае - обновление зависимостей.
На счет настроек в массивах такой подход тоже имеет право на жизнь, но есть подводный камень: когда их будет реально много - ориентироваться по нему станет не просто.
На счет констант: когда я впервые увидел этот подход - сначала думал, что эт какой-то шлак, но на деле оказалось очень здорово то, что вам нет необходимости прописывать геттеры, IDE константы само подтягивает + в случае если что-то забыли - сразу четко знаем что. В случае с массивом - обязательно необходимо выполнять проверку существования, иначе будет бида.
На счет iframe смысл был в том, что это полностью ваше приложение, а сайт - это мое приложение. Пользователь, зайдя ко мне может это отличить. Для меня прозрачность в том, что ваш сервис мне не навредит.
> Анализ сообщений задача исключительно клиентская.
да, да расскажите это internal модераторам любого популярного форума.
> Не хотите чтобы пользователь увидел что–то плохое, все в ваших руках.
Ок, еще раз, какой смысл в вашем сервисе? Если транспортировка и pub/sub - nodejs+redis в полной мере решают задачу. Если что-то еще, что я упустил - укажите.
Да все просто: ваш сервис должен в полной мере реализовывать прозрачную переписку в отдельном брендированном iframe.
Ваши клиенты должны быть оповещены через API о каждом из сообщений с возможностью верификации.
Например один пользователь другого на*** послал: вы должны сказать клиенту вот есть такой пользователь, он отправил другому сообщение, но это сообщение содержит какой-то стремный контент, вы даете апрув на передачу другому пользователю?
При этом для каждого пользователя (в случае http) текст шифруется сесионным ключом.
Так же уберите тему с пожертвованиями с сайта. Абсолютная часть подобных программ (не обязательно IT) - чистой воды обман
Я не спорю, что присутствует)) Но есть нюанс, что мне в js очень не понравился: send_message, вы в начале метода не делаете жесткую проверку типа msg. В случае, если передать туда строку - шифрование не будет выполняться, но строка отправится.
В chat.js вы этим пользуетесь, строка 57
В случае, если ключ хранится на клиенте - получаем довольно интересную штуку (конечно если я праивльно понял как работает ваш сервис):
У 1-го И у 2-го клиента должны быть одни и те же ключи для шифровки/дешифровки, на сервер - тоже.
Что вам мешает 1 раз зайти на мой сайт и узнать этот ключ, домен у вас есть?)) Как результат - это только видимость защиты.
Я знаю, что не взламываемых систем не бывает, цель любой защиты - сделать ее взлом не выгодным.
В случае с вашим сервисом - защита только на уровне доверия.
> Есть нюанс: объективно программирование - скучная, сложная, монотонная, ответственная, созидательная работа.
Но вы не найдете ни одного Мидла/Синьйора, которому она не нравится
