Comments 16
Благодарю вас за подробный отзыв. Очень рад, что вы во всем видите генерированный ИИ текст и искренне надеюсь, что этот генератор находится не с вами в одной комнате.
1. По поводу опечаток - спасибо. Исправили.
2. Про CAP теорему вы можете прочитать, найдя ссылку в любом поисковике и если вы когда-то касались архитектурных вопросов, то вам труда не составит понять, какую аналитику можно из нее вынести. Если же у вас с этим все-таки возникнут трудности постарайтесь почитать литературу, ссылку я могу дать в переписке.
Обмен сообщениями в энтерпрайзе сложно представить себе синхронным. Ну таков он энтерпрайз. Такова данность, опять же если у вас есть сомнения и вы просто никогда не работали в рамках крупного ИТ-проекта то я могу дать вам почитать пару книжек. Кстати, генератор ИИ тут не причем. Просто вы не понимаете сути написанного ввиду отсутствия какого-либо опыта.
По поводу релиза монолитов. Если у вас в монолите бардак, то проблемы с релизами будут обязательно. Фишка в том, что вы перенесете этот бардак в микросервисы и легче вам от переноса не станет.
CAP- теорема позволяет выбрать стек технологий. Более того, когда выбирают какую-то концепцию СУБД, часто только её и вспоминают. В частности noSQL подход. Я прекрасно осведомлен, о том что у CAP- теоремы, в прочем как у любой другой технической парадигмы, есть критика. Это нормально и CAP- теорема действительно не всегда может сработать. Но в энтерпрайзе, где речь идет о мессенджинге, работает почти всегда.
Асинхронность в контексте данной статьи, это то чего требует месседжинг (по Мартину Фаулеру) в SOA. Нам нужен гарантированный метод доставки сообщения (XML или JSON, а может и некой позиционной строки), такой чтобы пока сообщение доставлялось, отправитель спокойно мог дальше работать, а не ждать ответа.
Давайте так, метрики DevOps я не рассматривал в данной статье. Если вы укажете на них, то будет интересно изучить и дать вам ответ в вашем контексте. В любом случае, работать с одним компонентом (монолит) это быстрее, чем работать с набором компонентов (контейнеры). Понятны, ваши апелляции к тому, что внутри этого монолита. Но я же говорю, монолит получим из микросервисов, внутри такого монолита жеткое разделение на домены. Теоретически, все должно быть быстрее чем деплоить микросервисы.
да что говорите! вы пойдите куда-то, в какой-нибуль ВУЗ типа ВШЭ и скажите им так "Ребята, а вы не правильно учите, я вот знаю как надо правильно". И если с вами после этого станут разговаривать и прислушаются к вам, вот тогда я соглашусь, что формулировка неверная.
Опять же, вы говорите, что API это не есть архитектура, а её воплощение. Наверное, это действительно так. Но только я говорю, что перед API есть онтология, а онтология это есть архитектура. Возможно, это надо было как-то по четче выразить.
"Вытягивать весь объект целиком, как позволяет noSQL, проще." - Ну конечно "проще", но как это влияет на производительность? Если вам необходимо обновить один при признак объекта у которого их может быть сотни и они все могут обновляться в различных ситуациях? Т.е. (грубо говоря) вместо 16 байт данных вам придется сохранять весь "объект" в 128КB... И так для миллиона объектов и сотни их признаков. Где тут разум и логика?
то что вы говорите, это известный недостаток noSQL подхода. Конечно, если надо часто обновлять, к нему нужно относиться с опаской. И опять же, по нашему опыту ускорения при добавлении и обновлении это вопросы оптимизации.
А прощу в том что, представьте себе что вы идете на рынок и покупаете ингредиенты для супа. Вы ходите и ищете. И тут вам предлагают купить готовый суповой набор. Выв его быстренько берете и уходите с рынка.
:-) Это я к тому что "проще" - совсем не значит "оптимальнее"... Вы можете использовать сотни микросервисов на нескольких десятках серверов (поставщики ресурсов, разработчики и devops-ы этому будут только рады), хотя возможно вам вам вполне достаточно одного "монолита" на 3 серверах... Каждое оптимальное решение требует аналитики, оценки, проработки и тестирования под ваши конкретные требования и условия, но можно и "по agile" - "раз, два и в продакшен, а там видно будет...."
По-моему эту же мысль я и сказал в финале статьи. И "проще" значит путем наименьших потерь в настоящих условиях. Многие читатели не поняли, что я говорю про энтерпрайз, а в нем условия меняются очень быстро.
:-) Потерь для кого? Если "для разработчика" - то "чем дольше" будут появляться новые требования к ПО - тем больше "денег срубишь!", т.е. он не заинтересован делать "один раз и навсегда". Аналогично "для внедренцев" и devops и аналитиков. Ну а пользователи - "пусть страдают", как и бизнес который "дальше собственного носа не видит"... Как то так...
Как разработчик мобильных приложений, в т.ч. для финтеха, скажу, что статья, прочитанная по диагонали, заставила меня страдать и комплекс самозванца заиграл новыми красками. Впрочем, интуиция подсказывает мне, что я с автором расхожусь в понимании терминов до такой степени, что может эта статья и не касается мобильных разработчиков совсем.
Нужно быть благодарным хабру за то, что вы теперь можете у любое время дня и ночи рассказывать о своих страданиях миру.
Дядька, чё такой дерзкий? Эмоционально и необдуманно. Будто бы у хабра это ноу-хау - возможность рассказывать всему миру...
Ты лучше мне и остальным разработчикам мобильных приложений расскажи, какие таймауты-то использовать, в разрезе высоких нагрузок и построения экосистем?
в статье ясно написано о величине этих таймаутов. Более того, мною и коллегами проводились эксперименты и данная тема неоднократно выносилась на обсуждение. Если возник подобный вопрос, вам следует еще раз ознакомиться с сиквенс-диаграммой, приведенной в настоящей работе и прочитать на ней о величине необходимого таймаута. Если вы не понимаете сиквенс-диаграммы, то обратитесь к своему сеньору или мидлу, они вам расскажут как их читать.
Архитектура мобильного приложения в разрезе высоких нагрузок и построения экосистем