Упс, не обратил внимания, что это перевод, а не ваш текст. В общем по поводу критики текста это не к вам, а к Dr Gideon Greenspan, не уверен правда, что он сюда заглядвает :)
Как-то вы не расскрыли свой посыл, как мне кажется.
Взаимодействие с внешними сервисами у вас в тексте так и не расскрыто почему это невозможно?
То есть мы имеем блокчейн, который по сути представляет из себя распеределенный реестр с консенсусом. Есть понятие смартконтракта позволяющего осуществлять транзакции в этом реестре.
То есть некто X выпускает смартконтракт, который в зависимости от наступления условия Y зачислит условно на ваш баланс Z% от некоторой суммы. Проверку наступления условий смартконтракт осуществляет обращаясь к оракулу, можно даже не одному, а нескольким, разным, и условие считается наступившим, только в случае если все оракулы ответили одинаково.
Есть ли в этом сценарии потеря децентрализаиции и появляются ли некоторые доверенные участники? Да. Но сам реестр продолжает быть таким каким он был, без потери своих свойств. То есть у нас просто есть смартконтракт, который по сути является программным кодом и представляет из себя аналог обычного бумажного контракта, только за его исполнением следит программный код. В этом и есть основная суть смартконтрактов. А вы как потребитель выбираете чей смартконтракт вам интересен и на чьи условия вы готовы согласиться.
В одном случае у вас есть некий централиованный участник, которому все верят, пусть это будет страховая компания и всякий раз вам придется бадаться именно с этим участником и его трактковками, то есть мы имеем того самого посредника, от которых нам предлагает избавиться вся эта движуха вокруг блокчейн технологий. Заменить центрального участника крайне сложно.
С другой стороны мы имеем программный код работу которого может проверить любой участник системы, то есть мы избавляемся от центрального посредника. Есть оракулы, в случае недобросовестного поведения которых их заменить на порядки проще нежели центрального посредника и при этом сама система не утратит своей работоспособности.
Оракулы имеют свою комиссию и поэтому предоставление некорректных данных поставит крест на его существовании, так как факт предоставления таких данных будет отражен в том самом распределенном реестре.
То есть в итоге смартконтракты служат для уменьшения посредников и повышения прозрачности.
Ну и раз уж я тут засветился, то хочу высказаться по поводу Wirex так как являюсь пожалуй одним из первых его пользователей. Это ведь ваш сервис, не так ли?
Ребята реализация на крайне низком уровне, и ладно бы черт с ним с глюками, но ваш подход зажать деньги пользователя объясняя это какими-то странными попытками системы застраховаться от скачков стоимости транзакции и при этом зажимаемая вами сумма является фактически не выводимой это уже очень странно. В моем понимании это эквивалентно краже средств пользователя, хотя конечно де-юре кражей не является. И понятно, что сумма крайне незначительная для отдельно взятого пользователя, но если с каждого по чуть-чуть то общая сумма выходит очень даже внушительной.
И вот мое мнение, что вся эта движуха с блокчейн технологиями вообще и смартконтрактами в частности как раз и стремится к избавлению от таких недобросовестных посредников как вы.
На счет запросов снаружи не совсем понял суть проблемы. Если имеется в виду как организовано общение с браузером клиента, то это примерно так: есть приложение SPA на Reactjs, которое общается с нашим API, которое доступно снаружи, API в свою очередь посылает события в диспетчер и точно также получает события из диспетчера по результатам, которых меняет свое состояние. Сейчас идем к тому, что API будет получая определенные события, отправлять сообщения на клиент посредством SSE.
В качестве песочницу у нас stage сервер, который максимально приближен по состоянию к проду, там можно погонять свои сервисы посмотреть как они себя поведут в реальной жизни.
Дефолтного ТЗ нет, мы стараемся не пользоваться шаблонами в таких вопросах как постановка задач, каждый раз это написание с нуля и продумывание деталей, зато с каждым разом мы открываем все новые и новые детали =)
Диспетчер от сервиса должен дождаться только подтверждения, что сообщение получено, задерживать диспетчер не хорошо, у него работы много =)
Да, есть блокирующиеся вызовы, это обращения напрямую от сервиса к сервису, такие у нас тоже есть, но их очень мало, как правило это получение каких-то данных, которые есть в другом сервисе. Мы иногда думаем над тем, чтобы заменить и такие вызовы, чем то вроде:
сервис А кидает сообщение в диспетчер что ему нужны данные Y (событие: «нужны данные Y»)
диспетчер посылает уведомление в сервисы/сервис которые обладают этими данными, на самом деле диспетчер не знает, кто обладает этими данными, диспетчер просто знает, что сервис B попросил уведомлять его о событиях «нужны данные Y»
сервис или сервисы B получив такое уведомление, формируют данные и в событии отправляют их в диспетчер, кто быстрее тот и молодец, диспетчер перенаправляет событие с данными в запросивший сервис А. Это позволит избежать ожиданий, когда один сервис висит ожидая данных от другого, к тому же есть возможность получить данные от того сервиса кто сделает это быстрее. Но пока мы в случае когда необходимо просто получить данные другого сервиса у нас выполняется прямой запрос из одного сервиса в другой, таких вызовов очень немного и м не хотим чтобы их кол-во росло, потому что сложнее за всем этим потом следить.
claygod извиняюсь за задержку.
в одном комментарии пожалуй все сразу не расскажешь. У нас есть некоторые требовавния к микросервисам, они должны предоставлять HTTP API, они должны слать метрики и должны слать логи. Эти требования обязательные. Все остальное в общем достаточно гибко, каждый микросервис может быть реализован на каком-то своем технологическом стеке, в том числе и каждый сервис сам решает нужна ли ему внутри очередь или нет. В какой то мере диспетчер выполняет роль очереди на уровне приложения, тем не менее каждый микросервис может использовать свои очереди, есть доступные инструменты, которые уже настроены и работают и которыми может воспользоваться любой сервис, например RabbitMQ.
Микросервисы у нас по своей природе асинхронные, более того все общение происходит через диспетчер, куда каждый микросервис посылает событие при изменившемся состоянии, на это событие могут реагировать другие сервисы в результате чего также изменят свое состояние и кинут свое событие в диспетчер.
на счет REST не могу сказать, что мы во всех микросервисах остались в рамках идеально чистого REST, но в целом это работает, что касается асинхронных задач, то в целом наш подход похож на описываемый здесь http://restcookbook.com/Resources/asynchroneous-operations/
вебсокеты не применяли, пока. В ближайшее время выкатим решение на SSE
Да, в некоторых случаях контейнеры слушают внешние интерфейсы железки и да это неудобно, согласен.
Когда начинали небыло столь широкого выбора инструментов готовых для запуска в проде, поэтому сделали так. Сейчас собираемся менять схему, пока не решили, что имено будем использовать, смотрим в сторону docker swarm и kubernets, так что этот выбор нам еще предстоит сделать. Ну а когда решим готовы поделиться опытом, ну и чужой опыт всегда ценим, лучше учиться на чужих ошибках, чем на своих
1. нет nginx не на каждом хосте, то есть возможны например варианты поднимаем инстанс на амазоне, запускаем в нем один контейнер, добавляем запись в апстрим, то есть по сути nginx может быть вообще один, который проксирует запросы контейнерам в том числе и на разных машинах, но на деле получается nginx не один. Админим не руками, ansible'ом, пока мы небольшие справляемся.
2. И тут ansible и опять же пока мы небольшие этого достаточно, но в целом экспериментируем и ищем пути большей автоматизации с целью большего исключения человеческого фактора. Переключаем тоже используя ansible, в идеале конечно настроить автоматическое переключение и откат в случае неудачи. То есть например при запуске нового контейнера (green) автоматом часть трафика заруливается на него, в течении какого то времени собираются метрики и если заданные пороговые значения не превышены, то старый контейнер (blue) выключается, а весь трафик заруливается на green, если же пороговые значения превышены, то весь трафик возвращается на blue. Но пока делаем это руками используя ansible
3. Мониторинг, тут есть какбы две стороны медали, первая сервис сам о себе шлет некоторый набор метрик — это первая сторона и вторая — это действительно нужен отдельный процесс, но не нужен в том же контейнере, у нас запущен в отдельном контейнере c -v /var/run/docker.sock:/var/run/docker.sock --pid=host чего в большинстве случаев достаточно для мониторинга, по крайней мере нам пока хватает.
А вот на счет идеологии докера, к сожалению мы иногда ее нарушаем, хотя стараемся этого не делать. Приведу пример плохой практики случавшейся у нас: — микросервис на php, который также требует запуска некоторой команды по расписанию, выполнено в виде контейнера с php-fpm и кроном. Сейчас наученные опытом мы избегаем таких решений, но тем не менее это случалось в нашей практике и до сих пор остались микросервисы работающие в таком исполнении.
4. и да и нет, сервисы свои логи пишут в логстеш, есть еще datadog, который имеет готовые решения для логирования некоторых событий докера
Ну на самом деле почти каждый из этих вопросов тянет на отдельную статью. Но если коротко, то:
1. docker-контейнеры на нескольких серверах — это вообще отдельная большая история в том числе и для нас, есть куда развиваться и что еще попробовать, но в общих чертах все запросы проходят через reverse proxy то есть поднимая еще одну копию сервиса в докер контейнере мы просто дописываем нужную запись в upstream у nginx, при этом физически два контейнера могут быть запущены на разных машинах
2. запускаем ли одинаковые микросервисы на одном хосте? Да, как минимум при деплое, я упоминал, что мы используем BGD технику, которая подразумевает в какой то момент работу параллельно двух контейнеров одного микросервиса.
3. Для мониторинга у нас используется DataDog, influxdb + grafana, но мы продолжаем экспериментировать в этом направлении, потому как мониторинг при нашем подходе очень важная составляющая, собираемся попробовать prometheus
4. Логируем logstash + Elastic но тоже продолжаем экспериментировать в этом направлении, эта связка не очень нравится своей громоздкостью, но пока не нашли достаточно надежной, обкатанной альтернативы
Диспетчер построен на базе RabbitMQ плюс некоторые свои обвязки позволяющие либо объединять некоторые потоки событий, либо наоборот дробить в зависимости от нагружености и потребностей. События диспетчер рассылает используя push подход, то есть сервису не нужно держать коннект с диспетчером.
Да, это бесспорно очень полезная фича, если работает как надо, думаю в шторме она хорошо работает. Но не знаю как у других, на моей практике выходит так, что во-первых «на 10 уровней» это как бы повод задуматься над кодом, в других случаях (где отсутствует 10-ти уровневая иерархия наследования) более простых инструментов навигации по коду вполне хватает, с подсказками при написании кода тоже самое, кто-то использует их и в виме, я не использую совсем, отвлекают.
Вполне могу допустить, что IDE будет выигрывать если меняешь проекты часто, скажем каждые пару месяцев.
В случае долго-живущих крупных проектов, в моем случае, выходит так что на первое место выходят другие фичи, которые необходимы, удобство и быстрота написания кода, гибкость в настройке под себя, взаимодействие с внешним миром (в виде различных сторонних утилит, сервисов и прочего) которые так же можно быстро настроить под себя или реализовать.
И да, мой случай это не только я :) но все те люди с которыми я либо работаю вместе, либо общаюсь весьма часто.
Ну в общем на вкус и цвет все фломастеры разные, думаю многое еще зависит от специфики работы вообще и проекта/ов в частности.
разные варианты анализаторов кода есть
автодополнение методов класса вряд ли, точно сказать не могу, не люблю подсказки во время написания кода (вообще никакие), так как пишу я быстро, большинство реализаций в виде выпадающих плашек отвлекают, а вот более полезные (на мой взгляд) снипеты есть думаю даже у самых примитивных текстовых редакторов.
опять же повторюсь IDE выиграет, когда программисту нужна помощь при написании кода, а когда такая навязчивая помощь чаще мешает, чем помогает, то хочется как можно меньше вторжений извне во время изложения идеи в коде.
За Sublime не скажу, потому как мы используем vim, сказал об этом выше, так вот vim позволяет настроить всё под свои привычки и максимально повысить продуктивность. Все кто у нас сейчас работают с vim и все кто у нас сейчас не работают, но продолжают использовать vim в других компаниях пришли к нему через использование тех или иных IDE, никто не вернулся обратно.
Сравнивать текстовый редактор с IDE как продукт, вообще не имеет смысла, а вот в рамках удобного использования и повышения продуктивности очень даже можно. В руках новичка, либо средней руки программиста IDE выиграет, а вот в руках опытного профессионального разработчика не факт. В случае с моим отделом IDE проигрывает в 100% случаев.
да, но зачастую в руках профессионала SublimeText выигрывает у PhpStorm.
у нас в отделе все работают в vim, не потому что он бесплатен, а потому что так уж сложилось, что он прижился проще и лучше остальных.
Да, «чтение», а вернее «прочитано» — это у меня вместо удаления, то есть если ссылку прочитали, то она больше не нужна в списке и поэтому удаляется.
Хотя наверное это запутывает :)
На счет языка описания моделей так теперь дается выбор: нравится Yaml пожалуйста, хотите использовать Xml — нет проблем, ну а если не хотите плодить конфиги, то можно сразу в классе самой модели все описать.
На счет *Table классов решение может кому-то покажется странным, но решение интересное надо просто в нем разобраться. Теперь не будет плодиться по несколько классов на одну модель, достаточно одного класса. При этом можно создать свой кастомный класс репозитория, который в общем будет выполнять ту же роль, что делали классы *Table, к тому же вы можете свой кастомный класс репозитория, который будет использоваться для нескольких моделей.
В общем если интересно, то очень рекомендую почитать документацию на Doctrine 2, это интересно.
> я столкнулся с проектами, где нельзя допускать ни одного логического бага
У нас ни на одном проекте нельзя допускать логических багов, любой баг нам может обойтись в копеечку (это очень большие копеечки), так как мы даем гарантию. Тесты, несколько уровней перед появлением в production, дают нам гарантию спокойствия, но даже в этой ситуации мы очень высоко ценим возможность быстро исправлять баги.
Если стала видимой закрытая категория, то скорее всего функционал попал в production не проверенным, тут фреймворк не причем, если честно.
> отвечу на вопросы:
Спасибо, но это были не вопросы, это были критерии, которым с ваших слов соответствуют ваши инструменты, о них то я (думаю и многие другие) и хотел бы услышать и более чем уверен что «любой говнокод-спагетти» вы не используете, так зачем приводить его в пример.
Тем более, что с утверждением что «любой говнокод-спагетти» является столь же гибким — я категорически не согласен, но спор на эту тему мне совсем не интересен.
> Ты, как и мы. программируешь на агиле
Нет, я программирую на PHP и Python в основном :) (это шутка).
> надеясь, что твой коллега, фреймворк и т.д. не подведут, это СТРАШНО
Это совсем не страшно. Про это можно написать целый пост, но думаю до меня это делали сотни людей.
Во многом фреймворк сильно выручает, когда несколько проектов разрабатывают на одном проверенном фреймворке я могу быть уверен, что программисту не придется неделю разбираться в проекте, я знаю, что подключая к работе менее опытного программиста фреймворк и принятые правила будут помогать ему не сбиться с пути и не нагородить огород изобретая свои велосипеды.
А если я не доверяю коллеге — то я с ним не работаю, если я не доверяю инструменту — то я его не использую.
> хороший код, это такой. который не меняет архитектуры со временем
Хороший код — код который делает именно то что надо и при этом легко читается и готов к изменениям. Но этим пожалуй не ограничивается, можно еще привести кучу параметров.
> Важно стабильное качество, а не красота архитектуры.
Для меня важно стабильное качество, красота архитектуры и общая успешность проекта. И на мой взгляд это не взаимоисключающие моменты.
При этом я согласен с тем, что архитектура может меняться, если это даст преимущества стоящие этих изменений.
Вы смеетесь что-ли? Нет, правда, может покажете инструмент или продукт в которых не всплывают баги? Правда, просто интересно очень.
Конечно же отсутствие багов — это просто супер как хорошо, но способность их быстро устранять — это очень ценно!
> Что это за архитектура, которую нужно переписывать из-за новинок языка
Вас удивляет, что многие проекты переписывали для перехода с php4 на php5? Вас удивляет когда разработчики используют новые возможности появившиеся в языке программирования? Вас удивляет, что проект развивается? Вы реально считаете, что лучший показатель, когда проект не изменяется и это говорит об идеальной архитектуре выбранной изначально?
Наверное у нас очень разный опыт.
> Я не вижу сферу применения Symfony, для визиток она тяжеловата
Знаете как оно иногда бывает, вы начинаете проект, простенький, он очень небольшой. Но потом у заказчика появляются новые идеи и что самое главное деньги на их реализацию и проект вырастает уже до средних размеров. Так вот Symfony дает возможность начать простенький проект отключив ненужный функционал, но и при его развитии у вас не возникнет проблем, так как в основе лежит гибкость предоставляемая фреймворком, которая позволит подключить недостающий функционал, либо заменить какие-то его части.
> для серьёзных проектов много багов
Я использую Symfony еще с версии 0.6, вот когда можно было говорить о приводящем в замешательство кол-ве багов, но сейчас уже исходя из опыта я могу сказать — Symfony зрелый, стабильный и очень достойный инструмент в том числе и для серьезных проектов.
> мы находимся в посте о RequestHandler
Поверьте, лично я помню :) и как раз на примере RequestHandler можно рассмотреть как можно использовать Symfony, если не для сайтов-визиток, так как обычно для этого есть готовые типовые решения, которые кстати могут быть также разработаны на Symfony, ну а хотя бы для очень простеньких проектов и при этом Symfony не будет как вы сказали «тяжеловата».
> но я считаю, что она слишком избыточна ради универсальности
Что ж возможно для вас архитектура Symfony избыточна, каждый имеет право на собственное мнение.
Было бы интересно узнать о вашем подходе к разработке об инструментах, которые вы используете и которые я так понимаю:
1) не менее гибки
2) менее избыточны
3) проще
4) позволяют писать меньше кода
5) более надежны для серьезных проектов
Уверен многие будут вам благодарны если вы напишете пост с рассказом о используемых вами инструментах.
Да что ж вы все про сложность Symfony то рассказываете. Не сложный он вовсе, не пугайте людей. У нас разработчики с ним осваиваются очень быстро и остаются довольны.
> ИМХО, Symfony для тех кто дорос до потолка php
Ну что вы, я видел как с ним лихо осваиваются весьма еще середнячки и при этом остаются довольны и расширяют собственные познания и учатся на хороших примерах.
>>в условиях толстого фреймворка php проиграет python
Знаете, я разрабатываю как на PHP + Symfony, так и на Python + Django и мне лично Python нравится больше, чем PHP, но это мое сугубо личное мнение и я не хотел бы здесь разводить холивары по поводу сравнения кто кому и где проиграет. Symfony — отличный фрейворк, очень хороший и гибкий инструмент и во-многих случаях оценивая по многим критериям я выбираю для проектов PHP + Symfony.
Сопоставляя
> очень давно работаю с доктриной
и
> и точно на ней не стал бы делать проект даже с 6-нулями
Ну вот правда в этой ситуации я могу вам только посочувствовать. Очень не хорошо, когда работа, которую делаешь настолько неприятна.
> тоже капитальное переписывание symfony, показывает неустойчивость позиций автора
Вы просто не в курсе, но делаете выводы, жаль. Это не совсем просто капитальное переписывание, в данном случае это развитие и развитие в сторону большей гибкости, развитие с учетом прошлого опыта и пожеланий, развитие с учетом серьезных изменений в языке программирования на котором написан фреймворк.
> доверите деньги годами отточенным компонентом java или свежепереписанному Symfony
Symfony доверяют такие гиганты как Yahoo, Dailymotion и др.
> К сожалению, из-за отсутствия стабильного флагмана приходится всё писать самим, на агиле, надеясь что пронесёт или тесты выручат.
Мы уже долгое время разрабатываем в том числе и на Symfony и не надеемся на «пронесёт» и при этом спим спокойно :)
А вот этап «приходится всё писать самим» к счастью остался далеко в прошлом и знаете это позволяет разрабатывать быстрее и стабильнее и не тратить время и силы на изобретение не нужных велосипедов.
> Гибкость это возможность добавления функционала или его изменения, когда от простого к сложному.
По-моему Symfony вполне соответствует этому определению.
> Вот данный компонент точно избыточный.
Какой конкретно?
Взаимодействие с внешними сервисами у вас в тексте так и не расскрыто почему это невозможно?
То есть мы имеем блокчейн, который по сути представляет из себя распеределенный реестр с консенсусом. Есть понятие смартконтракта позволяющего осуществлять транзакции в этом реестре.
То есть некто X выпускает смартконтракт, который в зависимости от наступления условия Y зачислит условно на ваш баланс Z% от некоторой суммы. Проверку наступления условий смартконтракт осуществляет обращаясь к оракулу, можно даже не одному, а нескольким, разным, и условие считается наступившим, только в случае если все оракулы ответили одинаково.
Есть ли в этом сценарии потеря децентрализаиции и появляются ли некоторые доверенные участники? Да. Но сам реестр продолжает быть таким каким он был, без потери своих свойств. То есть у нас просто есть смартконтракт, который по сути является программным кодом и представляет из себя аналог обычного бумажного контракта, только за его исполнением следит программный код. В этом и есть основная суть смартконтрактов. А вы как потребитель выбираете чей смартконтракт вам интересен и на чьи условия вы готовы согласиться.
В одном случае у вас есть некий централиованный участник, которому все верят, пусть это будет страховая компания и всякий раз вам придется бадаться именно с этим участником и его трактковками, то есть мы имеем того самого посредника, от которых нам предлагает избавиться вся эта движуха вокруг блокчейн технологий. Заменить центрального участника крайне сложно.
С другой стороны мы имеем программный код работу которого может проверить любой участник системы, то есть мы избавляемся от центрального посредника. Есть оракулы, в случае недобросовестного поведения которых их заменить на порядки проще нежели центрального посредника и при этом сама система не утратит своей работоспособности.
Оракулы имеют свою комиссию и поэтому предоставление некорректных данных поставит крест на его существовании, так как факт предоставления таких данных будет отражен в том самом распределенном реестре.
То есть в итоге смартконтракты служат для уменьшения посредников и повышения прозрачности.
Ну и раз уж я тут засветился, то хочу высказаться по поводу Wirex так как являюсь пожалуй одним из первых его пользователей. Это ведь ваш сервис, не так ли?
Ребята реализация на крайне низком уровне, и ладно бы черт с ним с глюками, но ваш подход зажать деньги пользователя объясняя это какими-то странными попытками системы застраховаться от скачков стоимости транзакции и при этом зажимаемая вами сумма является фактически не выводимой это уже очень странно. В моем понимании это эквивалентно краже средств пользователя, хотя конечно де-юре кражей не является. И понятно, что сумма крайне незначительная для отдельно взятого пользователя, но если с каждого по чуть-чуть то общая сумма выходит очень даже внушительной.
И вот мое мнение, что вся эта движуха с блокчейн технологиями вообще и смартконтрактами в частности как раз и стремится к избавлению от таких недобросовестных посредников как вы.
Все это мое оценочное суждение :)
В качестве песочницу у нас stage сервер, который максимально приближен по состоянию к проду, там можно погонять свои сервисы посмотреть как они себя поведут в реальной жизни.
Дефолтного ТЗ нет, мы стараемся не пользоваться шаблонами в таких вопросах как постановка задач, каждый раз это написание с нуля и продумывание деталей, зато с каждым разом мы открываем все новые и новые детали =)
Да, есть блокирующиеся вызовы, это обращения напрямую от сервиса к сервису, такие у нас тоже есть, но их очень мало, как правило это получение каких-то данных, которые есть в другом сервисе. Мы иногда думаем над тем, чтобы заменить и такие вызовы, чем то вроде:
сервис А кидает сообщение в диспетчер что ему нужны данные Y (событие: «нужны данные Y»)
диспетчер посылает уведомление в сервисы/сервис которые обладают этими данными, на самом деле диспетчер не знает, кто обладает этими данными, диспетчер просто знает, что сервис B попросил уведомлять его о событиях «нужны данные Y»
сервис или сервисы B получив такое уведомление, формируют данные и в событии отправляют их в диспетчер, кто быстрее тот и молодец, диспетчер перенаправляет событие с данными в запросивший сервис А. Это позволит избежать ожиданий, когда один сервис висит ожидая данных от другого, к тому же есть возможность получить данные от того сервиса кто сделает это быстрее. Но пока мы в случае когда необходимо просто получить данные другого сервиса у нас выполняется прямой запрос из одного сервиса в другой, таких вызовов очень немного и м не хотим чтобы их кол-во росло, потому что сложнее за всем этим потом следить.
в одном комментарии пожалуй все сразу не расскажешь. У нас есть некоторые требовавния к микросервисам, они должны предоставлять HTTP API, они должны слать метрики и должны слать логи. Эти требования обязательные. Все остальное в общем достаточно гибко, каждый микросервис может быть реализован на каком-то своем технологическом стеке, в том числе и каждый сервис сам решает нужна ли ему внутри очередь или нет. В какой то мере диспетчер выполняет роль очереди на уровне приложения, тем не менее каждый микросервис может использовать свои очереди, есть доступные инструменты, которые уже настроены и работают и которыми может воспользоваться любой сервис, например RabbitMQ.
Микросервисы у нас по своей природе асинхронные, более того все общение происходит через диспетчер, куда каждый микросервис посылает событие при изменившемся состоянии, на это событие могут реагировать другие сервисы в результате чего также изменят свое состояние и кинут свое событие в диспетчер.
на счет REST не могу сказать, что мы во всех микросервисах остались в рамках идеально чистого REST, но в целом это работает, что касается асинхронных задач, то в целом наш подход похож на описываемый здесь http://restcookbook.com/Resources/asynchroneous-operations/
вебсокеты не применяли, пока. В ближайшее время выкатим решение на SSE
Когда начинали небыло столь широкого выбора инструментов готовых для запуска в проде, поэтому сделали так. Сейчас собираемся менять схему, пока не решили, что имено будем использовать, смотрим в сторону docker swarm и kubernets, так что этот выбор нам еще предстоит сделать. Ну а когда решим готовы поделиться опытом, ну и чужой опыт всегда ценим, лучше учиться на чужих ошибках, чем на своих
2. И тут ansible и опять же пока мы небольшие этого достаточно, но в целом экспериментируем и ищем пути большей автоматизации с целью большего исключения человеческого фактора. Переключаем тоже используя ansible, в идеале конечно настроить автоматическое переключение и откат в случае неудачи. То есть например при запуске нового контейнера (green) автоматом часть трафика заруливается на него, в течении какого то времени собираются метрики и если заданные пороговые значения не превышены, то старый контейнер (blue) выключается, а весь трафик заруливается на green, если же пороговые значения превышены, то весь трафик возвращается на blue. Но пока делаем это руками используя ansible
3. Мониторинг, тут есть какбы две стороны медали, первая сервис сам о себе шлет некоторый набор метрик — это первая сторона и вторая — это действительно нужен отдельный процесс, но не нужен в том же контейнере, у нас запущен в отдельном контейнере c -v /var/run/docker.sock:/var/run/docker.sock --pid=host чего в большинстве случаев достаточно для мониторинга, по крайней мере нам пока хватает.
А вот на счет идеологии докера, к сожалению мы иногда ее нарушаем, хотя стараемся этого не делать. Приведу пример плохой практики случавшейся у нас: — микросервис на php, который также требует запуска некоторой команды по расписанию, выполнено в виде контейнера с php-fpm и кроном. Сейчас наученные опытом мы избегаем таких решений, но тем не менее это случалось в нашей практике и до сих пор остались микросервисы работающие в таком исполнении.
4. и да и нет, сервисы свои логи пишут в логстеш, есть еще datadog, который имеет готовые решения для логирования некоторых событий докера
1. docker-контейнеры на нескольких серверах — это вообще отдельная большая история в том числе и для нас, есть куда развиваться и что еще попробовать, но в общих чертах все запросы проходят через reverse proxy то есть поднимая еще одну копию сервиса в докер контейнере мы просто дописываем нужную запись в upstream у nginx, при этом физически два контейнера могут быть запущены на разных машинах
2. запускаем ли одинаковые микросервисы на одном хосте? Да, как минимум при деплое, я упоминал, что мы используем BGD технику, которая подразумевает в какой то момент работу параллельно двух контейнеров одного микросервиса.
3. Для мониторинга у нас используется DataDog, influxdb + grafana, но мы продолжаем экспериментировать в этом направлении, потому как мониторинг при нашем подходе очень важная составляющая, собираемся попробовать prometheus
4. Логируем logstash + Elastic но тоже продолжаем экспериментировать в этом направлении, эта связка не очень нравится своей громоздкостью, но пока не нашли достаточно надежной, обкатанной альтернативы
Вполне могу допустить, что IDE будет выигрывать если меняешь проекты часто, скажем каждые пару месяцев.
В случае долго-живущих крупных проектов, в моем случае, выходит так что на первое место выходят другие фичи, которые необходимы, удобство и быстрота написания кода, гибкость в настройке под себя, взаимодействие с внешним миром (в виде различных сторонних утилит, сервисов и прочего) которые так же можно быстро настроить под себя или реализовать.
И да, мой случай это не только я :) но все те люди с которыми я либо работаю вместе, либо общаюсь весьма часто.
Ну в общем на вкус и цвет все фломастеры разные, думаю многое еще зависит от специфики работы вообще и проекта/ов в частности.
автодополнение методов класса вряд ли, точно сказать не могу, не люблю подсказки во время написания кода (вообще никакие), так как пишу я быстро, большинство реализаций в виде выпадающих плашек отвлекают, а вот более полезные (на мой взгляд) снипеты есть думаю даже у самых примитивных текстовых редакторов.
опять же повторюсь IDE выиграет, когда программисту нужна помощь при написании кода, а когда такая навязчивая помощь чаще мешает, чем помогает, то хочется как можно меньше вторжений извне во время изложения идеи в коде.
Сравнивать текстовый редактор с IDE как продукт, вообще не имеет смысла, а вот в рамках удобного использования и повышения продуктивности очень даже можно. В руках новичка, либо средней руки программиста IDE выиграет, а вот в руках опытного профессионального разработчика не факт. В случае с моим отделом IDE проигрывает в 100% случаев.
у нас в отделе все работают в vim, не потому что он бесплатен, а потому что так уж сложилось, что он прижился проще и лучше остальных.
Хотя наверное это запутывает :)
На счет *Table классов решение может кому-то покажется странным, но решение интересное надо просто в нем разобраться. Теперь не будет плодиться по несколько классов на одну модель, достаточно одного класса. При этом можно создать свой кастомный класс репозитория, который в общем будет выполнять ту же роль, что делали классы *Table, к тому же вы можете свой кастомный класс репозитория, который будет использоваться для нескольких моделей.
В общем если интересно, то очень рекомендую почитать документацию на Doctrine 2, это интересно.
У нас ни на одном проекте нельзя допускать логических багов, любой баг нам может обойтись в копеечку (это очень большие копеечки), так как мы даем гарантию. Тесты, несколько уровней перед появлением в production, дают нам гарантию спокойствия, но даже в этой ситуации мы очень высоко ценим возможность быстро исправлять баги.
Если стала видимой закрытая категория, то скорее всего функционал попал в production не проверенным, тут фреймворк не причем, если честно.
> отвечу на вопросы:
Спасибо, но это были не вопросы, это были критерии, которым с ваших слов соответствуют ваши инструменты, о них то я (думаю и многие другие) и хотел бы услышать и более чем уверен что «любой говнокод-спагетти» вы не используете, так зачем приводить его в пример.
Тем более, что с утверждением что «любой говнокод-спагетти» является столь же гибким — я категорически не согласен, но спор на эту тему мне совсем не интересен.
> Ты, как и мы. программируешь на агиле
Нет, я программирую на PHP и Python в основном :) (это шутка).
> надеясь, что твой коллега, фреймворк и т.д. не подведут, это СТРАШНО
Это совсем не страшно. Про это можно написать целый пост, но думаю до меня это делали сотни людей.
Во многом фреймворк сильно выручает, когда несколько проектов разрабатывают на одном проверенном фреймворке я могу быть уверен, что программисту не придется неделю разбираться в проекте, я знаю, что подключая к работе менее опытного программиста фреймворк и принятые правила будут помогать ему не сбиться с пути и не нагородить огород изобретая свои велосипеды.
А если я не доверяю коллеге — то я с ним не работаю, если я не доверяю инструменту — то я его не использую.
> хороший код, это такой. который не меняет архитектуры со временем
Хороший код — код который делает именно то что надо и при этом легко читается и готов к изменениям. Но этим пожалуй не ограничивается, можно еще привести кучу параметров.
> Важно стабильное качество, а не красота архитектуры.
Для меня важно стабильное качество, красота архитектуры и общая успешность проекта. И на мой взгляд это не взаимоисключающие моменты.
При этом я согласен с тем, что архитектура может меняться, если это даст преимущества стоящие этих изменений.
Вы смеетесь что-ли? Нет, правда, может покажете инструмент или продукт в которых не всплывают баги? Правда, просто интересно очень.
Конечно же отсутствие багов — это просто супер как хорошо, но способность их быстро устранять — это очень ценно!
> Что это за архитектура, которую нужно переписывать из-за новинок языка
Вас удивляет, что многие проекты переписывали для перехода с php4 на php5? Вас удивляет когда разработчики используют новые возможности появившиеся в языке программирования? Вас удивляет, что проект развивается? Вы реально считаете, что лучший показатель, когда проект не изменяется и это говорит об идеальной архитектуре выбранной изначально?
Наверное у нас очень разный опыт.
> Я не вижу сферу применения Symfony, для визиток она тяжеловата
Знаете как оно иногда бывает, вы начинаете проект, простенький, он очень небольшой. Но потом у заказчика появляются новые идеи и что самое главное деньги на их реализацию и проект вырастает уже до средних размеров. Так вот Symfony дает возможность начать простенький проект отключив ненужный функционал, но и при его развитии у вас не возникнет проблем, так как в основе лежит гибкость предоставляемая фреймворком, которая позволит подключить недостающий функционал, либо заменить какие-то его части.
> для серьёзных проектов много багов
Я использую Symfony еще с версии 0.6, вот когда можно было говорить о приводящем в замешательство кол-ве багов, но сейчас уже исходя из опыта я могу сказать — Symfony зрелый, стабильный и очень достойный инструмент в том числе и для серьезных проектов.
> мы находимся в посте о RequestHandler
Поверьте, лично я помню :) и как раз на примере RequestHandler можно рассмотреть как можно использовать Symfony, если не для сайтов-визиток, так как обычно для этого есть готовые типовые решения, которые кстати могут быть также разработаны на Symfony, ну а хотя бы для очень простеньких проектов и при этом Symfony не будет как вы сказали «тяжеловата».
> но я считаю, что она слишком избыточна ради универсальности
Что ж возможно для вас архитектура Symfony избыточна, каждый имеет право на собственное мнение.
Было бы интересно узнать о вашем подходе к разработке об инструментах, которые вы используете и которые я так понимаю:
1) не менее гибки
2) менее избыточны
3) проще
4) позволяют писать меньше кода
5) более надежны для серьезных проектов
Уверен многие будут вам благодарны если вы напишете пост с рассказом о используемых вами инструментах.
В любом случае спасибо за ваше мнение.
> ИМХО, Symfony для тех кто дорос до потолка php
Ну что вы, я видел как с ним лихо осваиваются весьма еще середнячки и при этом остаются довольны и расширяют собственные познания и учатся на хороших примерах.
>>в условиях толстого фреймворка php проиграет python
Знаете, я разрабатываю как на PHP + Symfony, так и на Python + Django и мне лично Python нравится больше, чем PHP, но это мое сугубо личное мнение и я не хотел бы здесь разводить холивары по поводу сравнения кто кому и где проиграет. Symfony — отличный фрейворк, очень хороший и гибкий инструмент и во-многих случаях оценивая по многим критериям я выбираю для проектов PHP + Symfony.
> очень давно работаю с доктриной
и
> и точно на ней не стал бы делать проект даже с 6-нулями
Ну вот правда в этой ситуации я могу вам только посочувствовать. Очень не хорошо, когда работа, которую делаешь настолько неприятна.
> тоже капитальное переписывание symfony, показывает неустойчивость позиций автора
Вы просто не в курсе, но делаете выводы, жаль. Это не совсем просто капитальное переписывание, в данном случае это развитие и развитие в сторону большей гибкости, развитие с учетом прошлого опыта и пожеланий, развитие с учетом серьезных изменений в языке программирования на котором написан фреймворк.
> доверите деньги годами отточенным компонентом java или свежепереписанному Symfony
Symfony доверяют такие гиганты как Yahoo, Dailymotion и др.
> К сожалению, из-за отсутствия стабильного флагмана приходится всё писать самим, на агиле, надеясь что пронесёт или тесты выручат.
Мы уже долгое время разрабатываем в том числе и на Symfony и не надеемся на «пронесёт» и при этом спим спокойно :)
А вот этап «приходится всё писать самим» к счастью остался далеко в прошлом и знаете это позволяет разрабатывать быстрее и стабильнее и не тратить время и силы на изобретение не нужных велосипедов.
> Гибкость это возможность добавления функционала или его изменения, когда от простого к сложному.
По-моему Symfony вполне соответствует этому определению.
> Вот данный компонент точно избыточный.
Какой конкретно?