Если подразумевается: функциональное = с математическими функциями, где математическими = pipe, преобразующий одно значение в другое, то да, на функциональном языке под JVM в рамках задач на Hadoop кластере (преимущественно HDFS + Spark + Yarn + Hive), с полноценным MapReduce Big даты в виде всей истории + потока изменений новостей/статей/постов/комментариев/лайков/эмоций в 50000+ интернет СМИ + 20+ социальных сетях + 10000+ форумах.
Мне вот интересно модуль Y вообще не поддается спецификации в Вашей архитектуре? Что угодно подключили? И делает что угодно?
Ваши доводы приводят меня к такой мысли: когда ничего неизвестно, то и архитектура похожа на метод result doEverything(arg1), где arg1 все, что угодно, result - тоже, в таких условиях действительно невозможно написать сколько нибудь осмысленную систему ошибок, кроме как "что то делали, почему то не вышло из за какой то ошибки."
1 - единственно как я могу ответить на такое возражение - продумывание архитектуры и написание кода ее реализующего не должно порождать хаос второго порядка, в противном случае компании нужно что то делать с архитекторами и разработчиками, которые его породили. 2 - хм, есть много способов рабочий процесс вынести за рамки ручного управления. 3 - основное это внести определенность в принцип выбора интервала, от этого зависит его размер, если принцип - внешняя зависимость (облако, сервис, база, шина обмена событиями между сервисами etc.), то это один порядок, если - бизнес (не отработал сценарий 1, сценарий 2, сценарий 3 обработки пользовательского запроса и вся логика, пусть и вне сервиса, объединена по этому принципу), то другой. Степень неизвестности тем выше, чем менее ясно, что и зачем команда реализует в коде для бизнеса и что за архитектуру в решении планируется/получается заложить.
1 - любая система состоит из аспектов, модулей и т.д. главное, что не спагетти, есть какая то архитектура, объединение по какому либо принципы. 2 - повторюсь, интервалы могут быть больше, Вы архитектор, основываясь на своем обширном опыте не угадать с размером интервала сложно (даже если ошиблись по итогу 10 лет эксплуатации и развития на порядок, больше необходимого, это не проблема). 3 - см. 2 4 - принцип агрегации необходим, в противном случае будет хаос (в первом комментарии Вам привел пример), а когда "правила игры" известны, можно от чего то отталкиваться.
В качестве примера, писал оркестратор, 40+ интеграций со смежными системами, где за каждой единицей - отдельная система со своим протоколом и API (скрывающая 10+ других интеграций), придерживаясь описанного в статье принципа все сложилось в стройную картину, 5 лет прошло, сервис продолжает развиваться, заложились в интервалах с запасом, все четко, как часы, отдел сопровождения знает без обращения к разработке - что к чему и почему, быстро локализует проблему, клиентские решения тоже продолжают приростать - заложенная гибкость позволяет им писать рефлексию как описал выше, клиентами выступают как 1 разработчик со своим решением, так и целая компания в 100+ разработчиков, исключение - новые интеграции, в интервалах кодов негативных исходов с которыми не все еще прокопано.
1 - все зависит от бизнес потребностей, повторюсь, такой подход позволяет выбирать, смежник может ограничиться ошибками уровня протокола (GRPC/HTTP/WSS opt коды etc.), может отталкиваться от деталей твоего приложения на уровне интервала или на уровне интервала + совпадения по каким либо конкретным кодам. 2 - в современной парадигме микросервисной архитектуры сложно представить сервис, у которого будет больше 1000 ошибок (к примеру если клиент прислал поле с неверным типом - не обязательно каждому полю в огромном json-е при несовпадении типа присваивать свой код). 3 - для этого и нужен первый код в рамках интервала, он так сказать "слив" для всех неизвестных ошибок с каким либо смежником (опять же "смежник" это один из принципов объединения). 4 - объединение требуется только для того, чтобы привнести порядок в хаос, например если 1 - ошибка данных поля входящего json, 2 - таймаут на базе, 3 - невалидный сертификат от твоего сервиса в качестве ошибки от Кафки, 4 - клиент прислал не json, в то время как ожидается обратное, 5 - SELECT запрос на базе содержит неожиданное для таблицы поле (если к примеру клиент может присылать sql) etc. как видно все перемешано и в этом крайне сложно ориентироваться всем, тебе в том числе, тем сложнее, чем больше вариантов ошибок.
1 - с числом можно работать интервалами, если смежнику достаточно знать, что ошибка произошла и только, то он просто зашьется на факт получения кода. 2 - размер интервала приведен в качестве примера. 3 - главное иметь свой интервал на каждую, чтобы они были сгруппированы по смежникам, иначе ориентироваться в причинах будет сложно, особенно если смежников "неизвестное количество", что тоже странно, при написании кода ошибки можно сгруппировать по какому либо принципу, главное чтобы он был. 4 - см. 2 и 3.
VPS со всеми сервисами по всем протоколам взаимодействует с TLS/mTLS. В момент профилирования заметили, что JDK SSL генерит много объектов byte[]. Перешли на OpenSSL(BoringSSL если быть точным, форк). В первом случае на массивы (а они были в топе) аллоцировалось суммарно 9.82 Gb, во втором — 2.74Gb, да и по процу нагрузка снизилась процентов на 30. По метрике handshake time Netty сервера тоже было заметно улучшение. В нее только включена как блокирующая часть (криптография на твоей стороне), так и ожидание ответа от второй.
Netty сам увидит имплементацию и будет использовать вместо JDK-шной: api "io.netty:netty-tcnative-boringssl-static"
Если подразумевается: функциональное = с математическими функциями, где математическими = pipe, преобразующий одно значение в другое, то да, на функциональном языке под JVM в рамках задач на Hadoop кластере (преимущественно HDFS + Spark + Yarn + Hive), с полноценным MapReduce Big даты в виде всей истории + потока изменений новостей/статей/постов/комментариев/лайков/эмоций в 50000+ интернет СМИ + 20+ социальных сетях + 10000+ форумах.
Мне вот интересно модуль Y вообще не поддается спецификации в Вашей архитектуре? Что угодно подключили? И делает что угодно?
Ваши доводы приводят меня к такой мысли: когда ничего неизвестно, то и архитектура похожа на метод result doEverything(arg1), где arg1 все, что угодно, result - тоже, в таких условиях действительно невозможно написать сколько нибудь осмысленную систему ошибок, кроме как "что то делали, почему то не вышло из за какой то ошибки."
1 - единственно как я могу ответить на такое возражение - продумывание архитектуры и написание кода ее реализующего не должно порождать хаос второго порядка, в противном случае компании нужно что то делать с архитекторами и разработчиками, которые его породили.
2 - хм, есть много способов рабочий процесс вынести за рамки ручного управления.
3 - основное это внести определенность в принцип выбора интервала, от этого зависит его размер, если принцип - внешняя зависимость (облако, сервис, база, шина обмена событиями между сервисами etc.), то это один порядок, если - бизнес (не отработал сценарий 1, сценарий 2, сценарий 3 обработки пользовательского запроса и вся логика, пусть и вне сервиса, объединена по этому принципу), то другой. Степень неизвестности тем выше, чем менее ясно, что и зачем команда реализует в коде для бизнеса и что за архитектуру в решении планируется/получается заложить.
1 - любая система состоит из аспектов, модулей и т.д. главное, что не спагетти, есть какая то архитектура, объединение по какому либо принципы.
2 - повторюсь, интервалы могут быть больше, Вы архитектор, основываясь на своем обширном опыте не угадать с размером интервала сложно (даже если ошиблись по итогу 10 лет эксплуатации и развития на порядок, больше необходимого, это не проблема).
3 - см. 2
4 - принцип агрегации необходим, в противном случае будет хаос (в первом комментарии Вам привел пример), а когда "правила игры" известны, можно от чего то отталкиваться.
В качестве примера, писал оркестратор, 40+ интеграций со смежными системами, где за каждой единицей - отдельная система со своим протоколом и API (скрывающая 10+ других интеграций), придерживаясь описанного в статье принципа все сложилось в стройную картину, 5 лет прошло, сервис продолжает развиваться, заложились в интервалах с запасом, все четко, как часы, отдел сопровождения знает без обращения к разработке - что к чему и почему, быстро локализует проблему, клиентские решения тоже продолжают приростать - заложенная гибкость позволяет им писать рефлексию как описал выше, клиентами выступают как 1 разработчик со своим решением, так и целая компания в 100+ разработчиков, исключение - новые интеграции, в интервалах кодов негативных исходов с которыми не все еще прокопано.
1 - все зависит от бизнес потребностей, повторюсь, такой подход позволяет выбирать, смежник может ограничиться ошибками уровня протокола (GRPC/HTTP/WSS opt коды etc.), может отталкиваться от деталей твоего приложения на уровне интервала или на уровне интервала + совпадения по каким либо конкретным кодам.
2 - в современной парадигме микросервисной архитектуры сложно представить сервис, у которого будет больше 1000 ошибок (к примеру если клиент прислал поле с неверным типом - не обязательно каждому полю в огромном json-е при несовпадении типа присваивать свой код).
3 - для этого и нужен первый код в рамках интервала, он так сказать "слив" для всех неизвестных ошибок с каким либо смежником (опять же "смежник" это один из принципов объединения).
4 - объединение требуется только для того, чтобы привнести порядок в хаос, например если 1 - ошибка данных поля входящего json, 2 - таймаут на базе, 3 - невалидный сертификат от твоего сервиса в качестве ошибки от Кафки, 4 - клиент прислал не json, в то время как ожидается обратное, 5 - SELECT запрос на базе содержит неожиданное для таблицы поле (если к примеру клиент может присылать sql) etc. как видно все перемешано и в этом крайне сложно ориентироваться всем, тебе в том числе, тем сложнее, чем больше вариантов ошибок.
1 - с числом можно работать интервалами, если смежнику достаточно знать, что ошибка произошла и только, то он просто зашьется на факт получения кода.
2 - размер интервала приведен в качестве примера.
3 - главное иметь свой интервал на каждую, чтобы они были сгруппированы по смежникам, иначе ориентироваться в причинах будет сложно, особенно если смежников "неизвестное количество", что тоже странно, при написании кода ошибки можно сгруппировать по какому либо принципу, главное чтобы он был.
4 - см. 2 и 3.
Netty сам увидит имплементацию и будет использовать вместо JDK-шной:
api "io.netty:netty-tcnative-boringssl-static"