Comments 47
«Майк нервными расстройствами не страдал, зато у него прорезалось чувство юмора. Правда, юмора низкопробного. Будь он человеком, вам пришлось бы постоянно держаться с ним начеку. Он счел бы верхом остроумия вывалить вас ночью из кровати или насыпать вам в скафандр порошок, вызывающий чесотку.
Поскольку проделать это он был не в состоянии, Майк забавлялся по-своему. Мог ни с того ни с сего дать ложный ответ, основанный на «вывернутой» логике. А недавно вдруг взял и выдал чек на выплату жалованья уборщику в офисе Администрации в Луна-Сити в размере 10 000 000 000 000 185,15 долларов-купонов, причем только пять последних цифр составляли правильную сумму.»
Вот ведь всего 20 лет прошло, но уже ничего не помню… Кроме заголовков блоков программы и зелёных терминалов :(
Кобол был первым языком, созданным специально для обработки данных в 1959 году. Грейс Хоппер по праву входит в тройку людей, которые радикально изменили подход к программированию, наравне с Джоном Маккарти (LISP) и Аланом Каем (Smalltalk).
С тем багажом знаний и набором инструментов, который у нее был, Хоппер сделала гениальный компилятор. Ну а по коэффициенту внедрения COBOL до сих пор лидирует с огромным отрывом от всех говноджав и говношарпов.
Вы точно хотите обвинить контра-адмирала ВМФ США Грейс Хоппер в некомпетентности?
У меня была (есть) книга «Кобол для Минск-32». Теперь думаю, может зря я её не читал?
Что самое печальное — я так и не понял, о чём речь. Может кто из знатоков рассказать, что это за "перемещение пробелов"?
Сегодня как раз с клиентами обсуждали об уходе с Мэйнфреймов и замене Cobol на Java. Нам пообещали, что лет десять ещё как минимум всем страдать. "И не мечтаете"
Ну и проблема в затратах на переписывание миллионов строк кода и полного ретеста тоже есть.
Много памяти — не согласен.
Фиксированная точка — снова не согласен ( BigDecimal).
А вот переписывание выглядит как реальная причина.
Ну вот представьте (правдивая история из жизни одной большой телефонной компании): стоит один пыльный мейнфрейм под VAX/VMS + Oracle8. крутит всяческий учет 600К сотрудников, довольно интенсивный (cobol хорошо умеет именно в трансформации данных, в частности из-за способа их хранения и операций, сводящихся к сдвигу или простому копированию).
Как, а главное зачем это менять на тяжеловесный, перегруженнный, многословный, и тоже уже медленно, но верно устаревающий язык?!
Потому, что людей найти невозможно на это дело. Одни пенсионеры остались и они уходят. Молодых приходится обучать самим, да и мало кто хочет связывать себя с этим.
Да, основная причина — куча кода и интерфейсов в другие системы. Все это переписывать дорогое дело, причем надо ещё найти таких, кто понимает Кобол и джаву одновременно. Или придется садить человека, что бы перевел кобол в псевдокод.
Плюс ещё проблемы с базой данных. DB2 на мейнфрейме со своими заморочками, там тоже не все как у людей. IBM там умудрились свой особенный мир создать.
Ну и плюс дорого все это. Из-за особенностей этих, приходится покупать поддержку у IBM и это дорого.
Сейчас все новые модули все равно на Яве пишутся. Остался да, темный угол с логикой кое какой. Обучили двух человек, теперь им лет на десять работа обеспечена ))
Плюс ещё проблемы с базой данных. DB2 на мейнфрейме со своими заморочками, там тоже не все как у людей. IBM там умудрились свой особенный мир создать.
Ну, во-первых, есть две платформы. IBM i (наследница System/32/34/36/38, ранее называвшаяся AS/400) и IBM z (наследница System/370/390). Это очень разные платформы. i действительно совсем другой мир — «все есть объект», TIMI, SLIC, одноуровневая память и все такое. DB2 for i позволяет работать с БД как «нативно» — посредством библиотеки RECIO для C/C++ или встроенных функций типа SetLL/SetGT/Chain/Read/Write/Update/Delete в RPG, так и обычным SQL, который можно встраивать непосредственно в код на C/C++ или RPG (оператор exec sql ...). И тот и другой подходы имеют свои преимущества и свои недостатки в каждом конкретном случае (одну или несколько записей из одного файла по индексу дешевле получить нативными функциями, сложные запросы по нескольким файла эффективнее сделать через SQL).
Но джава в высоконагруженных частях не используется совсем — не вытягивает она нужной производительности. Платформа IBM i радикально оптимизирована под многозадачность где одновременно крутится очень большое количество заданий (JOB). Ее особенность в том (в том числе за счет одноуровневой модели памяти с размерностью указателя 128бит — 64 на адрес и 64 на служебные поля) что там накладные расходы на переключение контекста между заданиями крайне низки по сравнению с другими системами. Но джавамашина во все это никак не вписывается и ломает всю картину.
Ну и плюс дорого все это. Из-за особенностей этих, приходится покупать поддержку у IBM и это дорого.
Да, дорого. Но в ряде случаев это окупается. Понятно, что для небольшой конторки все это не нужно. А для крупного банка с десятками миллионов клиентов — вполне.
Поддержка от IBM вполне работает. Они отвечают на все вопросы, связанные с тонкостями работы системы, у них можно заказать аудит производительности ситсемы — приедут, проведут, составят список узких мест…
У всего есть предел, и у IBM i — этот предел упирается тупо в человеческий ресурс, а у Java или других языков — в ресурсы облаков.
Если в IBM i есть какие-то процедуры, которые лучше всего выполняются только на DB2, и ни на одной другой БД, то пусть они там тогда и остаются, просто делаем внешние интерфейсы для подключения проектов на Java, которые будут получать/передавать нужные данные когда надо.
Всю бизнес логику предприятия дальше пилить и развивать на IBM I — вот это точно ошибка.
IBM i — это АБС (автоматизированная банковская система). «Ядро» банка. Она хранит все данные, обрабатывает все банковские операции и обеспечивает банковскую бизнеслогику — счета, проводки, клиенты, отчеты, платежи, различные проверки и все вот это вот. Прямого доступа извне туда нет. Все внешние системы обмениваются данными на уровне запросов. Через очередь (MQ) или вебсервисы.
Вебсервисы — вот тут уже джава вне конкуренции — фактически являются внешними АПИ для мобильного приложения и инетбанка. Ну и еще для ряда систем (той же Пеги).
Все, что работает на севере, написано на RPG (SQLRPG) и С/С++ на 90%
Все что вне его — там уже не в курсе (мы на сервере работаем, все остальное для нас «внешние системы» — нам задания приходят в виде «нужно сделать сервисмодуль под такой-то вебсервис» или «нужно сделать обработчик вот такого типа сообщений из MQ» или «нужно вот по такому событию посылать в MQ вот такое сообщение»)
Так что все верно — каждому овощу — свой фрукт.
Apache Kafka, например, не позволяет поверить, что на жабе ничего высокопроизводительного не пишут.
При всей крутости Кафки, я слабо могу себе представить, что кто-то в здравом уме станет применять её для обслуживания финансовых транзакций.
Это почему еще?
А, ну полагаться на единственный канал передачи информации для сообщений и подтверждений — нигде нельзя, даже в кхм телефонии же.
Да, нужна независимая архитектура аков и наков, но она же в любом случае нужна; верить в то, что у выбранной вами софтины нет issues — может только студент же ж. И встречный канал даже на той же кафке уже нивелирует проблему, а в ивент-сорс архитектуре (choreography, в orchestration другие сложности) — так и так придется прилепить watchdog для потерянных ивентов.
У нас с раббитом примерно те же потенциальные проблемы (хотя пока он ничего не терял) — если вдруг ивент пропадет (крыса выкусит из очереди) — система об этом узнает «извне» собственно брокера.
Так что это даже хорошо, что о таких проблемах вам сообщают на берегу, больше времени подготовиться будет.
RabbitMQ и деньги? Серьёзно?
Не, если вы модный молодёжный финтех, то ок. До первого крупного факапа. Тред то больше за банки с потенциальными транзакциями на миллиарды. Тот же упоминавшийся выше IBM MQ выглядит уже сильно предпочтительнее.
В «модном молодёжном финтехе», цена факапа зависит от транзакции, up to €40M на сегодняшний день.
Люди, работающие в банках, к сожалению, почти всегда очень крутые специалисты в чтении разной маркетинговой сопутствующей литературы и снобизме, но мало, что понимают в реальном мире и потенциальных точках отказа.
С факапами борятся так, как я написал выше, а не выбором «самого надежного инструмента», хотя бы потому, что абсолютно надежных инструментов не бывает, а рискуют эти «профессионалы» только рабочим местом.
Штраф может прилететь просто за то, что какая-то из критичных систем легла больше чем на установленное нормативами время. Вне зависимости от суммы транзакции. Просто по факту недоступности.
А лечь система может просто потому, что джавамашина не вовремя сборщик мусора запустила. Что привело с увеличению времени обработки ряда операций. Что в свою очередь привело к отвалу внешних систем по таймауту… Ну и посыпалось все одно за другим. Если отвалится МПК (модуль пластиковых карт), то это приведет к тому что в десятках тысяч магазинов по всей стране сотни тысяч людей при попытке расплатится картой будут получать «нет ответа от банка».
Что касается маркетинговой литературы — то на ее чтение просто нет времени. И сил. Слишком много технической документации приходится читать.
Вы удивитесь, если узнаете сколько одновременно процессов крутится на банковском сервере. И Сколько всего происходит для обработки одной единственной проводки. Это не считая всего того, что напрямую с деньгами не связано. Клиенты, субъекты, риски, комплаенс (да-да, каждая проводка, каждый клиент проверяются на легальность — не дай бог пропустить что-то, что фигурирует в списках росфина — тут санкции гарантированы на 146%).
Фактически на каждый чих вызывается куча разных проверок. И все это должно работать очень быстро и не грузить сервер сверх меры.
Так что за эффективность тут бьются в кровь. Все, что будет работать в фоне, проходит через нагрузочное тестирование. И редко когда с первого раза. Обычно выносятся предписания — тут закешировать чтобы два раза одну таблицу не читать, там обеспечить режим блочного чтения, здесь подумать как перестроит запрос чтобы более эффективно индексы использовались и т.п.
И аудит производительности с выявлением проблемных мест раз-два в год. И пул задач на оптимизацию.
Так что тут не все так просто. На уровне бэкенда.
Не, а понимаю, что можно взять ненадежный (зато дешевый, пусть и без поддержки) инструмент, а потом поверх него костылить еще один для отлова глюков.
А можно купить надежное (не абсолютно, но...), быстрое и с качественной поддержкой от производителя. И тогда контроль проще будет. Он есть. Но он проще.
По крайней мере пропадания сообщений из MQ мы не видели ни разу. Там есть некоторые проблемы с тем, что невозможно одновременно открыть в одном задании несколько менеджеров очереди, но это описано в документации и решается сопровождением путем запуска тех задач, которые постоянно что-то пишут в очередь в разных заданиях.
штраф от регулятора [...] лишение лицензии
Лично программистов штрафуют и лишают лицензии?
Штраф может прилететь просто за то, что какая-то из критичных систем легла больше чем на установленное нормативами время.
А нашем бизнесе это установленное время — 0. Только прилетает не штраф, а возмещение убытка (которое может исчисляться миллионами евро). Пока такой случай был один — одна из критичных систем легла на примерно полсекунды. Выводы сделаны.
А лечь система может просто потому, что джавамашина не вовремя сборщик мусора запустила.
Поэтому джава — сразу нет.
Что касается маркетинговой литературы — то на ее чтение просто нет времени. И сил. Слишком много технической документации приходится читать.
Дык вся литература по, например, той же джаве — маркетинговая. Отказоустойчивость и джава — вещи мало совместимые.
Вы удивитесь, если узнаете сколько одновременно процессов крутится на банковском сервере.
Я ж говорю, снобизм.
И сколько всего происходит для обработки одной единственной проводки.
Ну а мы, конечно, просто джейсончик из одного места в другое сложили — и готово.
да-да, каждая проводка, каждый клиент проверяются на легальность
Разумеется. У нас тоже.
Фактически на каждый чих вызывается куча разных проверок. И все это должно работать очень быстро и не грузить сервер сверх меры.
Да ладно, правда, что ли? Даже не верится. А все остальное может работать медленно и грузить сервер?
Так что за эффективность тут бьются в кровь.
А больше нигде не бьются, ибо кому оно надо в XXI веке, да?
Все, что будет работать в фоне, проходит через нагрузочное тестирование.
А все, что в прямом синхронном потоке — нет?
И аудит производительности с выявлением проблемных мест раз-два в год. И пул задач на оптимизацию.
Ух ты. Круто.
Так что тут не все так просто. На уровне бэкенда.
Спасибо, прямо раскрыли глаза.
можно взять ненадежный (зато дешевый, пусть и без поддержки) инструмент
А вот с этого места поподробнее. Я нигде не утверждал, что можно брать ненадежный инструмент. Я утверждал, что надежность инструмента не может быть fully trusted, если все то, что написано вами выше — реальность, а не бахвальство на хабре.
можно купить надежное (не абсолютно, но...)
А, вот и оговорочки. Так вот, мы не пальцем в небо ткнули, а сравнивали — и reliability, и chaos testing, и прямыми диверсиями.
быстрое
Ну-ну.
с качественной поддержкой от производителя
Ну-ну.
По крайней мере пропадания сообщений из MQ мы не видели ни разу.
Прямо победа, поздравляю! Мы тоже, впрочем.
Лично программистов штрафуют и лишают лицензии?
Вы, видимо, слабо себе представляете, что такое отзыв лицензии у банка и какие это влечёт последствия для всех его сотрудников.
Я нигде не утверждал, что можно брать ненадежный инструмент.
~200 не закрытых Critical+ тикетов — не самое надёжное решение как по мне.
Да, можно обмазать дублированиеми, проверками, дублированием проверок, etc. Но не стоит забывать, что каждый лишний наворот — это дополнительная потенциальная точка отказа.
При прочих равных, для процесса, цена реализации рисков в котором запредельно высока, имеет смысл сделать всё возможное для их закрытия. В том числе не выбирать продукты без внятной поддержки и с множеством(относительно) багов, которые потом придётся героически превозмогать своими силами (внося новые баги, ага).
Вы, видимо, слабо себе представляете, что такое отзыв лицензии у банка и какие это влечёт последствия для всех его сотрудников.
Вообще не представляю, но попробую угадать: придется оторвать жопу от стула и пойти искать новую работу?
~200 не закрытых Critical+ тикетов — не самое надёжное решение как по мне.
Я чё-то подзапутался слегка. Про ≈200 Critical+ я вообще ничего не скажу, мне кафка не подходит уже тем, что это джава, чужой стек, хрен чего в транк пропихнешь из нужного лично тебе, да и вообще.
Но ведь и вы спрашивали про то, в чем я немного разбираюсь — а именно про RabbitMQ, не? И где там ≈200 Critical+, стесняюсь спросить?
Но ведь и вы спрашивали про то
Напомню с чего начали
При всей крутости Кафки, я слабо могу себе представить, что кто-то в здравом уме станет применять её для обслуживания финансовых транзакций.
«Много незакрытых тикетов» без их тщательного анализа перед выбором брокера сообщений в нагруженном проекте — это пердёж в лужу.
В проприетарных брокерах «с поддержкой» их может оказаться в 100 раз больше. Или ни одного, потому что политика большинства таких компаний — заметение мусора под ковер.
Так что я так и не услышал внятного объяснения, что с кафкой не так. «Бесплатное и без поддержки» — это ПМ-ам хорошо втюхивать, мне не надо.
Много памяти — не согласен.
Увы, это так. Если не ошибаюсь, у нас под джаву (вебсервисы, которые являются апишками для фронт-систем) пришлось выделить один из серверов в кластере. Ибо на основном сервере оно начинает дико тормозить все остальные процессы.
Чтобы запстить самы мелкий апплет, нужно запустить джавамашину. А там начинается — работаетм себе и вдруг все начинает подтормаживать т.к. включился сборщик мусора… Для системы, где параллельно крутятся тысячи процессов, объемы таблиц исчисляются десятками миллионов записей, а самих таблиц тысячи и нагрузка на сервер оценивается примерно в 3млрд изменений (это не считая операций чтения) БД в сутки все это неприемлемо.
Кобола у нас, конечно, нет (система его поддерживает в рамках концепции ILE), мы используем более современный и пока развивающийся язык для коммерческих расчетов — RPG (RPGLE и его надмножество SQLRPGLE, позволяющее использовать SQL выражения непосредственно в RPG коде).
Фиксированная точка — снова не согласен ( BigDecimal).
К сожалению, не знаком со внутренней реализацией этого типа, так что не могу комментировать. Но в RPG есть два нативных типа данных с фиксированной точкой — ZONED и PACKED. Отличаются способом хранения данных — в первом 1 байт = 1 символ (фактически — число в стрковом представлении), во втором — 1 байт = 2 символа + полбайта на знак (фактически — BCD).
декларируются так:
dcl-s zndVar zoned(7 : 2); // 7 знаков, 2 после запятой
dcl-s pkdVar packed(15 : 2); // 15 знаков, 2 после запятой
Если смотреть «побайтно», то в памяти хранится целое число в «миноритарных единицах», количество знаков после запятой спрятано где-то в недрах системы в свойства объекта.
Т.е. это не эмуляция. Это реальная арифметика с фиксированной точкой, реализованная на уровне самой системы.
Про BigDecimal не совсем верно. Здесь вопрос не в ошибках (они как раз не накапливаются, потому что BigDecimal это именно что представление числа с фиксированной запятой), а в накладных расходах на операции с объектом вместо операций с примитивом. Но вы для своих целей можете сами собрать нужный вам объект для представления такого числа, и возможно операции с ним будут быстрее чем с BigDecimal.
Плюс сложные взаимосвязи между таблицами — изменение в одной тащит за собой каскад различных проверок и изменений в других.
Плюс все это должно работать быстро — многие операции ограничены таймаутами.
В целом все это достаточно сложная система.
Но вы для своих целей можете сами собрать нужный вам объект для представления такого числа, и возможно операции с ним будут быстрее чем с BigDecimal.
Есть нативный (на уровне ОС) объект. Зачем городить что-то поверх него?
Зачем вообще городить над ОС надстройку в виде джавамашины, когда можно работать без нее? Джавамашину придумали чтобы отвязаться от конкретной ОС. Когда нужно написать одно приложение, которое будет работать везде. В данном случае этого не требуется. Пишутся конкретные приложения для работы на конкретной платформе в конкретном окружении. Зачем плодить сущности?
Все равно вы не возьмете с улицы человека, который, не зная ваших бизнеспроцессов и специфики работы вашей АБС, сможет сделать что-то толковое. Это же не сайт, которые все работают примерно по одному принципу.
COBOL и $2 020 202,02