Индустрия программного обеспечения еще раз осознает, что сложность убивает.
Церковь сложности
Есть довольно известный скетч, в котором инженер объясняет руководителю проекта, как работает слишком сложный лабиринт микросервисов, чтобы узнать день рождения пользователя — и все равно не может этого сделать. Сцена точно описывает абсурдность состояния нынешней технологической культуры. Мы смеемся, но поднимать этот вопрос в серьезном разговоре равносильно профессиональной ереси, делая вас практически непригодным для работы.
Как мы здесь оказались? Как наша цель заключалась не в решении поставленной задачи, а в поджоге кучи денег путем решения проблем, которых у нас нет?
Идеальный шторм
В недавней истории есть несколько вещей, которые, возможно, способствовали нынешнему положению. Во-первых, целая армия разработчиков, пишущих JavaScript для браузера, начала идентифицировать себя как «full-stack», погружаясь в серверную разработку и асинхронный код. JavaScript — это JavaScript, верно? Какая разница, что вы создадите с его помощью — пользовательские интерфейсы, серверы, игры или встроенные системы. Верно? Node все еще был своего рода учебным проектом одного человека, а JavaScript тогда был крайне проблематичным выбором для разработки серверов. Указание на это, еще зеленым разработчикам серверной части, обычно приводило к большому раздражению и пыхтению. В конце концов, это все, что они знали. Мира за пределами Node фактически не существовало, путь Node был единственным известным путем, и это послужило источником упрямого, догматического мышления, с которым мы имеем дело по сей день.
А затем постоянный поток ветеранов FAANG начал сливаться с рекой стартапов, обучая новоиспеченных и очень впечатлительных молодых серверных инженеров JavaScript. Апостолы Церкви Сложности настойчиво заявляли, что «то, как они действовали в Google», было неоспоримым и правильным, даже если это не имело смысла в нынешнем контексте и размере. Что значит, что у вас нет отдельной службы пользовательских настроек? Это просто не масштабируется, братан!
Но во всем этом легко обвинить ветеранов и новичков. Что еще происходило? Ах да, легкие деньги.
Что вы делаете, когда у вас полно венчурного капитала? Конечно, вы не гонитесь за прибылью! Я не раз получал электронные письма от руководства, в которых просили всех быть в офисе, наводить порядок на своих столах и выглядеть занятыми, поскольку по офису собирались пройти парадом жилеты Patagonia. Инвесторам нужно было увидеть взрывной рост, но не прибыльность, нет. Им просто нужно было посмотреть, как быстро компания сможет нанять сверхдорогих инженеров-программистов, чтобы сделать… что-нибудь.
И теперь, когда у вас есть эти разработчики, что вы с ними делаете? Они могли бы создать более простую систему, которую легче развивать и поддерживать, или они могли бы создать чудовищное созвездие «микросервисов», которое никто толком не понимает. Микросервисы — новый способ написания масштабируемого программного обеспечения! Собираемся ли мы просто притвориться, что понятия «распределенные системы» никогда не существовало? (Опустим весь разбор нюансов о том, что микросервисы не являются настоящими распределенными системами).
В те времена, когда технологическая индустрия не была таким уж раздутым фарсом, распределенные системы уважали, боялись и вообще избегали, оставляя их только как оружие последней инстанции для особо серьезных проблем. В распределенной системе все становится более сложным и трудоемким — разработка, отладка, развертывание, тестирование, устойчивость. Но я не знаю — может быть, сейчас все супер просто, потому что у нас есть соответствующий инструментарий.
Не существует стандартного инструментария для разработки на основе микросервисов — нет общей среды. В 2020-х годах работа над распределенными системами стала лишь незначительно проще. Dockers и Kuberneteses мира сего не устранили волшебным образом сложность, присущую распределенной установке.
Мне нравится ссылаться на этот отчет о 5-летнем аудите стартапов, поскольку он наполнен здравыми выводами, основанными на веских доказательствах (и платных идеях):
…Проверенные нами стартапы, которые сейчас преуспевают лучше всего, обычно придерживаются почти наглого подхода к проектированию «сохраняйте простоту». Ум ради ума ненавидели. С другой стороны, компании, в которых мы говорили: «Ого, эти люди чертовски умные», по большей части исчезли.
Буквально – «сложность убивает».
Аудит выявил интересную закономерность: многие стартапы испытывали своего рода синдром коллективного самозванца, создавая понятные, простые и производительные системы. Существует догма, запрещающая начинать работу с микросервисами с первого дня, независимо от проблемы. «Все занимаются микросервисами, а у нас есть единый монолит Django, поддерживаемый всего несколькими инженерами, и экземпляр MySQL — что мы делаем не так?». Ответ был почти всегда: «ничего».
Точно так же опытные инженеры часто испытывают колебания и неадекватность в современном мире технологий, и хорошая новость в том, что нет, вероятно, это не вы. Команды часто притворяются, будто занимаются «веб-масштабированием», прячась за библиотеками, ORM и кешем — будучи уверенными в своих знаниях (они разгромили этот Leetcode!), но они могут даже не знать об основах индексации баз данных. Вы действуете в море неоправданной самоуверенности, расточительства и Даннинга-Крюгера, так кто же здесь на самом деле самозванец?
В монолите нет ничего плохого
Идея о том, что невозможно расти без системы, похожей на печально известную диаграмму военной стратегии в Афганистане, во многом является мифом.
Dropbox, Twitter/X, Facebook, Instagram, Shopify, Stack Overflow — эти и другие компании начинали как монолитные базы кода. Многие по сей день имеют в своей основе монолит. Stack Overflow вызывает гордость за то, как мало оборудования им нужно для работы огромного сайта. Shopify по-прежнему остается монолитом Rails, использующим проверенный и надежный Resque для обработки миллиардов задач.
WhatsApp стал сверхновой благодаря монолиту Erlang и 50 инженерам. Как?
WhatsApp сознательно сохраняет небольшой штат инженеров — всего около 50 инженеров.
Отдельные инженерные группы также невелики и состоят из 1–3 инженеров, и каждая группа обладает значительной автономией.
Что касается серверов, WhatsApp предпочитает использовать меньшее количество серверов и вертикально масштабировать каждый сервер в максимально возможной степени.
Instagram был приобретен за миллиарды — с командой из 12 человек.
И вы представляете себе Threads как проект, охватывающий весь Мета-кампус? Неа. Они следовали модели Instagram, а это вся команда Threads:
Возможно, утверждение, что ваша конкретная проблемная область требует чрезвычайно сложной распределенной системы и открытого офиса, доверху набитого турбо-гениями, просто переходит в высокомерие, а не в гениальность?
Не решайте проблемы, которых у вас нет
Простой вопрос – какую проблему вы решаете? Это масштаб? Откуда вы знаете, как разбить все это на масштаб и производительность? Достаточно ли у вас данных, чтобы показать, какая услуга должна быть отдельной и почему? Распределенные системы созданы с учетом размера и устойчивости. Может ли ваша система масштабироваться и быть устойчивой одновременно? Что произойдет, если одна из служб выйдет из строя или выйдет из строя? Просто увеличьте масштаб, да? А как насчет других служб, которые будут перегружены нагрузкой? Вы участвовали в бесконечных перестановках вещей, которые могут и могут пойти не так? Есть ли обратное давление? Автоматические выключатели? Очереди? Джиттер? Разумные тайм-ауты на каждой конечной точке? Существуют ли надежные средства защиты от простого изменения, которые не приведут к сбою всего? Ручки, о которых вам нужно знать и настраивать, бесконечны, и все они зависят от особенностей использования и трафика вашей системы.
Правда в том, что большинство компаний никогда не достигнут огромных размеров, которые фактически потребуют создания настоящей системы распределения. Ваша игра в Amazon и Google — без их масштаба, опыта и бесконечных ресурсов — скорее всего, просто вопиющая трата денег и времени.
Единственная вещь сложнее распределенной системы — это ПЛОХАЯ распределенная система.
«Но каждая команда… но отдельная… но API»
Попытка внедрить распределенную топологию в структуру вашей компании — благородное усилие, но оно почти всегда приводит к обратным результатам. Распространенным подходом является разбиение проблемы на более мелкие части и последующее решение их одну за другой. Итак, если разбить один сервис на несколько, все станет проще, верно?
Теория приятна и элегантна: каждый микросервис строго поддерживается специальной командой, окруженной красивым API с обратной совместимостью и версионированием. На самом деле, все настолько жестко, что вам даже редко приходится общаться с этой командой — как если бы микросервис обслуживался сторонним поставщиком. Это просто!
Если это звучит вам незнакомо, то это потому, что такое случается редко. На самом деле наши каналы Slack переполнены сообщениями от команд, сообщающих о выпусках, ошибках, обновлениях конфигурации, критических изменениях и рекламных объявлениях. Каждый должен быть всегда на высоте. И если это не было здорово, то вполне нормально, когда одна и без того раскритикованная команда недооценивает несколько микросервисов вместо того, чтобы отлично работать над одним, часто меняя владельцев по мере того, как люди приходят и уходят.
Чтобы выиграть гонку, мы не строим одну хорошую гоночную машину — мы строим парк дерьмовых гольф-каров.
Что вы теряете
При создании микросервисов существует множество подводных камней, и часто это минное поле либо не осознается в полной мере, либо просто игнорируется. Команды тратят месяцы на написание узкоспециализированных инструментов и изучение уроков, совершенно не связанных с основным продуктом. Вот лишь некоторые аспекты, которые часто упускают из виду…
Попрощайтесь с DRY
После десятилетий обучения разработчиков написанию кода «Не повторяйся», кажется, мы вообще перестали об этом говорить. Микросервисы по умолчанию не являются DRY, поскольку каждый сервис наполнен избыточным шаблоном. Очень часто накладные расходы на такую «сантехнику» настолько велики, а размер микросервисов настолько мал, что средний экземпляр сервиса имеет больше «услуги», чем «продукта». А как насчет общего кода, который можно вынести за рамки?
Есть общая библиотека?
Как обновляется общая библиотека? Хранить везде разные версии?
Регулярно устанавливать обновления, создавая десятки запросов на включение во все репозитории?
Хранить все это в монорепозитории? Это сопряжено со своими проблемами.
Разрешить некоторое дублирование кода?
Забудьте об этом, каждая команда каждый раз изобретает велосипед.
Каждая компания, идущая по этому пути, сталкивается с этим выбором, и хороших «эргономичных» вариантов не существует — приходится выбирать свой вариант боли.
Эргономика разработчиков ухудшится
«Эргономика разработчика» — это трение, количество усилий, которые должен приложить разработчик, чтобы что-то сделать, будь то работа над новой функцией или устранение ошибки.
При использовании микросервисов инженер должен иметь мысленную карту всей системы, чтобы знать, какие сервисы использовать для выполнения той или иной конкретной задачи, с какими командами общаться, с кем разговаривать и о чем. Принцип «надо все знать, прежде чем что-то делать». Как вам удается оставаться на высоте? Spotify, компания с оборотом в несколько миллиардов долларов, потратила, вероятно, немало внутренних ресурсов на создание Backstage, программного обеспечения для каталогизации своих бесконечных систем и сервисов.
Это должно, по крайней мере, дать вам понять, что эта игра не для всех, и цена поездки высока. Так что насчет инструментов? Те, кто не являются Spotify в мире, остаются создавать что-то со своими собственными решениями, о надежности и портативности которых вы, вероятно, можете догадаться.
А сколько команд реально упрощают процесс запуска YASS — «еще одного дурацкого сервиса»? Это включает в себя:
Права разработчика в GitHub/GitLab
Переменные среды и конфигурация по умолчанию
CI/CD
Проверка качества кода
Код ревью
Правила работы с ветками и защита
Мониторинг и наблюдаемость
Тестирование
IoT
И, конечно же, умножьте этот список на количество языков программирования, используемых во всей компании. Может быть, у вас есть полезный шаблон или runbook? Может быть, систему, позволяющую запустить новый сервис с нуля в один клик? Чтобы устранить все недостатки такой автоматизации, требуются месяцы. Итак, вы можете либо работать над своим продуктом, либо работать над инструментарием.
Интеграционные тесты - LOL
Как будто повседневной работы с микросервисами недостаточно, вы также теряете душевное спокойствие, обеспечиваемое надежными интеграционными тестами. Ваши одиночные и модульные тесты проходят успешно, но остаются ли ваши критические пути нетронутыми после каждого коммита? Кто отвечает за общий набор интеграционных тестов, в Postman или где-то еще? Есть ли такой?
Интеграционное тестирование распределенной системы — практически неразрешимая задача, поэтому мы практически отказались от нее и заменили ее другой — Observability. Точно так же, как «микросервисы» — это новые «распределенные системы», «наблюдаемость» — это новая «отладка в производстве». Конечно, вы не напишете настоящее программное обеспечение, если не сделаете…. наблюдаемость!
Наблюдаемость стала отдельным сектором, и за него вы заплатите, как немалыми деньгами, так и временем разработчика. Это также не предполагает «подключи и плати» — вам нужно понимать и внедрять канареечные выпуски, флаги функций и т. д. Кто этим занимается? Один уже перегруженный инженер?
Как видите, дробление проблемы не облегчает ее решение: вы получаете другой набор еще более сложных проблем.
А как насчет просто «сервисов»?
Почему ваши сервисы должны быть «микро»? Что плохого в обычных сервисах? Некоторые стартапы дошли до того, что создали сервис для каждой функции, и да, «разве это не похоже на Lambda» будет справедливым вопросом. Это дает вам представление о том, как далеко зашел этот неконтролируемый карго-культ.
Так что же нам делать? Начать с монолита — один из очевидных вариантов. Во многих случаях также может работать шаблон «trunk and branches», где основному монолиту «meat and potatoes» помогают branch-сервисы. Branch-сервис может быть сервисом, который заботится о четко идентифицируемой и отдельно масштабируемой нагрузке. Сервис изменения размера изображений, требовательный к процессору, имеет гораздо больше смысла, чем сервис регистрации пользователей. Или у вас столько регистраций в секунду, что это требует независимого горизонтального масштабирования?
Примечание: во времена CVS и Subversion в системе контроля версий мы редко использовали «master» ветки. У нас был «trunk and branches», потому что, знаете ли, деревья. «Master» ветки появились где-то по пути, и когда GitHub решил покончить с довольно неудачным соглашением об именах, среднестатистический инженер был слишком молод, чтобы запомнить шаблон «trunk/branches», и поэтому появилось общее «main» значение по умолчанию.
Маятник качнулся назад
Однако ажиотаж, похоже, утихает. Денежный кран венчурного капитала ужесточается, и поэтому компании были скорректированы рынком и вынуждены принимать решения, основанные на здравом смысле, признавая, что, возможно, тратить деньги на архитектуру веб-масштаба, когда у них нет проблем веб-масштаба, не является устойчивым.
В конечном счете, когда вам необходимо поехать из Нью-Йорка в Филадельфию, у вас есть два варианта. Вы можете либо попытаться построить очень сложный космический корабль для спуска по орбите к месту назначения, либо просто купить билет на поезд Amtrak и совершить 90-минутную поездку. Вот и всё!
Комментарии (42)
mishamota
12.09.2023 10:21+3(Опустим весь разбор нюансов о том, что микросервисы не являются настоящими распределенными системами)
А ведь многие свято уверено в обратном ;-(
Под этот "нюанс" прямо отдельную статью хочется накатать, начав всего лишь с определений базовых уровней консистентности распределённых систем.PS Отличная статья!
edwgiz2
12.09.2023 10:21+3The issue with over-engineering is that, quite simply, most engineers aren't really concerned about the company's spendings, and top management often shares the same perspective. It falls on the investors and owners to have a clear understanding of why such complexity is necessary. Unfortunately, they often lean towards hoping that others will deliver substantial profits in return for their salaries.
Many engineers acknowledge that they often engage in unnecessary work, but few are eager to raise questions about efficiency and effectiveness when they're enjoying a steady and yammy paycheck
courage_andrey
12.09.2023 10:21+1few are eager to raise questions about efficiency and effectiveness
... because they don't want to be fired.
event1
12.09.2023 10:21+5Уважаемые переводчики! А можно хоть немножко напрячься и выдать что-то за пределами автоперевода? Ну, пожалуйста. А то, глаза кровоточат от внезапной сантехники
Очень часто накладные расходы на такую «сантехнику» настолько велики, а размер микросервисов настолько мал
Ну серьёзно. Русский язык достаточно богат околоинженерными и околонаучными метафорами. И даже нематерными.
bel1k0v Автор
12.09.2023 10:21+2Здравствуйте, во-первых, я тут один. Во-вторых это не автоперевод, хоть и с использованием средств автоматизации. В третьих, "plumbing" - сантехника. В четвёртых, вы можете указать на ошибку, отправив личное сообщение, где можете предложить своё слово, а не только высказывать критику, подкреплённую вашим воображением и некомпетентностью.
event1
12.09.2023 10:21+1Ну во-первых, я тут один.
обращение ко всем переводчикам
Во-вторых это не автоперевод, хоть и с использованием средств автоматизации.
Проблема не в том, как технически это сделано. Проблема в том, что автопереводчик не знает контекста. В данном случае человеческий переводчик проявил себя так же
В третьих, "plumbing" - сантехника.
Только если вы меняете дома унитаз. Plumbum — это свинец на латыни. Из него раньше делали водопроводные трубы. Соответственно, практически любые работы связанные с водопроводом — plumbing. А вот plumber — это действительно сантехник.
В четвёртых, вы можете указать на ошибку, отправив личное сообщение, где можете предложить своё слово,
Пожалуйста, используйте те слова, которые считаете нужными. Это просьба не калькировать английские метафоры, а использовать наши. Тем более, что их вполне достаточно. Потому что, английские надо сначала перевести, чтобы понять что имел ввиду автор, а это усложняет чтение и понимание.
bel1k0v Автор
12.09.2023 10:21+1Проблема в том, что вы не отвечаете на поставленные вопросы, выдавая свою точку зрения за единственно верную. Причём контекст из-за слова в кавычках, с использованием синонима, явно не был нарушен. Я бы на вашем месте начал с правильного обращения, я, повторюсь, один, вы даже это во внимание не берёте, как и многие другие детали, показывая мне, что вы не ведёте диалог, а тешите своё эго. Вы не туда попали.
event1
12.09.2023 10:21+7Проблема в том, что вы не отвечаете на поставленные вопросы
Вы не задали ни единого вопроса.
Причём контекст из-за слова в кавычках, с использованием синонима, явно не был нарушен.
Когда англоговорящие программисты говорят plumbing про всякие скрытые технические детали реализации, они имеют ввиду отнюдь не сантехнику (раковины, унитазы и т.п.) а вовсе даже трубное хозяйство в стенах. Потому что в красивой, сверкающей зеркалами и свежим кафелем ванной, внутри стен спрятаны скучные пластиковые трубы по которым течёт вода. Их не видно, но без них ванная комната не работает. Более того, качество ванной комнаты определяется именно тем, как положены трубы. А ещё унитаз или даже кран легко заменить, а чтобы менять трубы в стенах надо все сломать и построить заново. Именно об это метафора plumbing. По-этому понять, что имелось ввиду в данном выражении, можно только после обратного перевода.
Я бы на вашем месте начал с правильного обращения
Спасибо, обязательно воспользуюсь вашей рекомендацией
bel1k0v Автор
12.09.2023 10:21+1Я так понимаю, что вы больше имеете дело с англоговорящим населением. Лично мне понравилась больше "сантехника", чем "водопровод", а вообще сегодня для определения примерно того же самого использовал слово "зоопарк", хотя оно хуже подходит для статьи. Нужен какой-то объективный критерий для ошибки перед основной русскоговорящей и читающей аудиторией, которой данный момент ошибкой не показался.
Опять же в контексте микросервисов, не только трубы имеют место быть. Нет, оно даже лучше походит, чем водопровод. Брать какой-то русский аналог не всегда получается, это наверное, самый сложный момент.
event1
12.09.2023 10:21+11Нужен какой-то объективный критерий для ошибки перед основной русскоговорящей и читающей аудиторией, которой данный момент ошибкой не показался.
Высокое искусство, какой тут может быть объективный критерий
Лично мне понравилась больше "сантехника", чем "водопровод", а вообще сегодня для определения примерно того же самого использовал слово "зоопарк"
Я знаю аналогичные метафоры: "под капотом", "шестерёнки" и "приводные ремни". Последние две, по-моему, более уместны в не технических текстах. С капотом перевод получается таким: "очень часто накладные расходы на то, что «под капотом» настолько велики..."
bel1k0v Автор
12.09.2023 10:21+1Это если вам ближе автомобильная тема, допустим если бы вы были фермером в душе, то "хозяйство", а если шеф-поваром, то "кухня", они в этом случае тоже имеют право на жизнь. Но есть авторское "plumbing", которое переводится, как "сантехника" или "водопровод", в промышленном масштабе хотелось использовать слово, дающее чуть более широкий взгляд на вещи.
poimtsev
12.09.2023 10:21Имхо стоит обратить внимание на модель модульного монолита - rails engines, elixir umbrella applications и так далее. В принципе каждый модуль представляет свой собственный домен, при этом не покидая единую кодовую базу
bel1k0v Автор
12.09.2023 10:21+1Этот подход реализован практически в каждом промышленном фреймворке, но как раз для поддержания монолита, со временем становится неудобно синхронизировать релизы каждого компонента, особенно, если они выделены в отдельный репозиторий.
Al_Pollitruk
12.09.2023 10:21Вообще интересная тема для научной работы - проверить правило сохранения сложности для ПО. Взять идентичные по функционалу системы (или старую и переписанную) на микросервисной и "монолитной" основе и оценить с помощью разных методов сложность этих двух вариантов.
NIKEtoS1989
12.09.2023 10:21Ну это было бы объективнее чем огульно хейтить микросервисы)
И возможно, что тогда мы бы увидели более сдержанный результат
sYB-Tyumen
12.09.2023 10:21+1А ещё можно взаимодействие микросервисов делать через RESTful API поверх HTTPS. И терять на каждом согласовании ключей и алгоритмов больше времени, чем сервис тратит на вычисление и собственно передачу результата.
Algrinn
12.09.2023 10:21+1При начале разработки сервера есть очень важный вопрос, это stateless сервер или statefull сервер. Дело в том, что stateless HTTP сервер элементарно масштабируется, достаточно запустить десяток параллельных серверов, а потом настроить nginx или HAProxy в качестве лоад балансера. И для опытов над новой версией сервера можно обновить только один сервер из десяти и пускать туда только небольшой процент пользователей. И очень гибко можно настраивать на какие HTTP эндпоинты ходят на каких серверах в кластере. Со stateless монолитом не очень сложно работать и его поддерживать и его масштабировать.
Другое дело, если это statefull сервер или сокетный сервер. Такой сервер масштабировать и поддерживать на порядок сложнее и тут уже просится Event-driven архитектура с микросервисами.
ВЫВОД: если у вас один, два серверных программиста и stateless HTTP сервер нет никакой необходимости делать микросервисы, это только усложнит жизнь программистам. Если у вас десяток, два десятка серверных программистов и statefull сервер и это без шуток масштабная система, то можно подумать о микросервисах, Event-driven архитектуре и шине данных.
bel1k0v Автор
12.09.2023 10:21Стейт можно хранить в памяти, которая масштабируется примерно по тем же принципам, что и трафик. Вывод такой себе, не подкреплён реальными фактами или личным опытом.
Algrinn
12.09.2023 10:21+1Тип приложения интернет магазин. 1-2 программиста, stateless система, микросервисы не нужны.
Тип приложения сервер стартапа, андроид программы 1-2 программиста, stateless приложение, микросервисы не нужны.
Банковое приложение, какой-нибудь документооборот, 3-4 клиент-серверных программиста, опять таки, микросервисы не нужны. Там автоматически система разбивается на много серверов, потому что есть много команд, у которых свои сервера и с которыми нужно взаимодействовать. Команды даже не знакомы с друг-другом, а просто дёргают API серверов по HTTP у друг-друга.
Древняя legacy система, которой 20 лет и над ней работало 200 человек, которую страшно трогать и даже тяжело определить, это stateless или statefull, все сходят с ума и мечтают о микросервисах. Тут микросервисы желательно нужны, (а половина системы на них написана), но всё равно не проще. Желательно такое хорошо проектировать и разделять на части.
Мессенджер, statefull. 3 программиста. Тут микросервисы нужны на вебсокетах, а HTTP наоборот не нужен.
bel1k0v Автор
12.09.2023 10:21Нет - стейт в памяти, например в редиске, масштабируется так же, как и БД, я поддерживал такой сервис. Даже в Интернете работает публичном прямо сейчас. Ссылку могу лично отправить, если интересно. На PHP
Algrinn
12.09.2023 10:21+1Нам достался от людей на Java Open Source stateful сервер с кластеризацией на Hazelcast и сказали что он работает плохо при нагрузочных тестах и нужно всё переделать на Redis Stream. Знакомый всё переделал на Redis Stream. Нагрузочные тесты показали, что там огромное количество блокировок потоков по всей системе и чтобы всё исправить и ничего не повредить, это ещё с ума сойдёшь, переделывать всё на асинхронные вызовы. Такое лучше всего сразу делать на Kafka с микросервисами. Но можно и на Redis Streams и на Hazelcast если всё по уму делать.
bel1k0v Автор
12.09.2023 10:21Можно, но необходимо себя переучить "асинхронно" думать. Идея в том, что у приложения есть главное хранилище, будь то память или диск и вот как раз они масштабируются в первую очередь, а не код, который сложно поддерживать.
Dynasaur
Самая лучшая архитектура, которую я в жизни видел - у SAP. Не знаю как она называется. Это монолит и "наносервисы" одновременно. Всё в единой БД, в единой кодовой базе на одном языке. Но при этом каждый элемент кода (модуль) и объект БД управляется и обновляется независимо. Сотни разработчиков, десятки проектов на разных континентах могут одновременно работать в одной системе почти не мешая друг другу. Почему больше никто такое не применяет - непонятно. Когда после САПа я попытался разобраться в системке на микросервисах, которая в тысячи раз меньше (по объёму кода) - это был кромешный ад.
olku
А можно чуть подробнее, в чем отличие от системы плагинов?
Dynasaur
Повторю свой комментарий из раннего обсуждения тут
Ru6aKa
Проблема микросервисов в том что сложно поддерживать контракт, независимо от транспорта. Если же использовать БД в виде шины данных для общения микросервисов, тогда контракт поддерживать становиться намного легче. Вот такую архитектуру и применяет САП, при этом ядро тоже является сервисом (но уже не микро и не нано).
bel1k0v Автор
Идея статьи, как раз в том, что адепты этой секты всё то же самое назвали другими словами, добавив лишний уровень абстракции, увеличив стоимость и сложность разработки и поддержки "утилитки для копирования байтов из одного источника в другой". В итоге всю плюются, а бизнес платит, и вы в том числе. Проблема не в реализации, а в цене в первую очередь. Ехать хочется, а не "шашечки" (в продолжении автотематики). KISS
Ru6aKa
ИМХО суть статьи в том что любую идею можно довести до абсурда. Это могут быть требования доведенные до абсурда, или архитектурный подход или любой другой аспект разработки ПО.
stone_evil
SAP это учетная система, там большой нагрузки на эту одну БД никогда не будет (и то есть миддл-решения, чтобы сделать распределенный SAP для совсем больших структур). И то, разбираться в тоннах своеобразного abap-кода с немецкими комментариями и искать в 32 000 таблиц информацию - это удовольствие не для каждого.
Вы попробуйте какому-нибудь банку\брокеру предложить завести одну БД и для учета, и для десятков тысяч онлайн-запросов в секунду от клиентов. На вас будут странно смотреть.
А до модульных изменений монолита уже, мне кажется, даже 1С8 доросла.
bel1k0v Автор
Я не имею опыта работы с SAP, но обладаю информацией (и вы т.ч. - она написана в Вики), о том, что:
SAP - это компания-разработчик, предлагающая решения для среднего и крупного бизнеса, в т.ч. в части учёта финансов. Вы какой программный продукт имеете ввиду? Поделитесь опытом неудачного внедрения, если у вас такой имеется. Почему 32000? А не 32001?
Это как-то помогло? Снизило стоимость? Улучшило наблюдаемость?
SlavaHU
>> Вы какой программный продукт имеете ввиду? Поделитесь опытом неудачного внедрения, если у вас такой имеется.
Вопрос был не мне, но напишу.
Когда пишут про SAP, обычно говорят про R/3, которую потом переименовывали в ERP, а потом в S/4 (про эту уже ничего не знаю, кроме названия). Ну, и как версию для малого бизнеса Business One.
По поводу опыта неудачного внедрения - я 10 лет работал в фирме, которая как раз имела бизнес за счет неспособности SAP в realtime обрабатывать поток информации непосредственно с устройств на производстве. Хотя как бы претендовала на это. Несмотря на огромную стоимость модуля PP (Production Planning) и интеграции с PI? MII? (уже точно не помню, как назывался модуль для контроля устройств), оборудования под нее и еще большую стоимость внедрения, система затыкалась на данных, поступающих с конвейеров, весов, сканнеров и т.п.
Наша система работала как middleware между SAP PP и устройствами в цеху/... Серьезные расчеты ресурсов SAP вела обычно по ночам в пакетном режиме, а наша система получала от нее крупные задачи, и возвращала результат. И делала это на оборудовании раз так в дцать более слабом, чем то, на котором дохла SAP.
Dynasaur
SAP это не учётная система :-))) Это ERP
Спорить об остальном даже не хочу. Если вы не видите разницы, то и спорить не о чем :-)
stone_evil
Глубина ответа поражает. А в ERP вести учет нельзя?
Буду иметь в виду, а то на предприятиях и SAP R\3 внедрял, и 1С ERP, а не догадывался, что они не для учета созданы, а для чего-то видимо более высокого. Согласен, дальше общаться особо не о чем, буду подтягивать свой уровень.
Dynasaur
На капоте автомобиля тоже можно пиво пить, но это не стол :-)))
Путать учётную систему с системой управления [ресурсами предприятия] это всё равно, что путать прошлое с будущим :-) Или путать бортовой компьютер, управляющий полётом самолёта с бортовым регистратором :-)
ERP смотрит вперёд, принимает решения, планирует, прогнозирует, оптимизирует, влияет на будущее. Учётная система посмертно регистрирует случившиеся факты и не влияет ни на что.
Жаль, что ERP внедряют внедренцы, не понимающие что они внедряют и зачем.
stone_evil
Что ты несёшь, чел. Удачи.
stitrace
Предположу вариант, потому что SAP потребовалось для этого написать собственную СУБД SAP HANA, которая держит все данные в памяти (много терабайт бизнес данных), а многие не могут себе позволить оплатить разработку собственной СУБД, не говоря уже о миллионах долларов на оборудование, на котором эта СУБД сможет только запустится в минимальной комплектации. Многие современные прокты выросли из "гаражных" стартапов и инвесторы, думаю, в последнюю очередь хотели бы от них услышать, что начнут они с разработки собственной субд и собственного ЯП.
Dynasaur
HANA тут ни при чём. Она появилась грубо говоря 10 лет назад. А архитектура, о которой я говорю, появилась лет 40 назад. И начиналась тоже с гаражного стартапа на покупных БД. 1С тоже создал свой ЯП и тоже начинался с гаражного стартапа. Так что не надо путать архитектуру и то, что с ней не связано.
SlavaHU
не говоря уже про то, что не далее как месяц назад при обсуждении внедрения SBO для одного проекта сами SAP-шники НЕ рекомендовали ставить SAP поверх HANA, типа еще не отработанная система (но мы это вам не говорили)
comerc
Это модульный монолит.