Комментарии 7
Я думаю резонный вопрос, почему вы решили реализовать все сами, а не использовать множество из текущий решений вроде Kong или Tyk?
Мы работаем с SOAP запросами, нам приходится парсить и модифицировать XML запросы, а Kong, согласно этой информации, не умеет с ними работать.
В сторону Ocelot и Tyk не смотрели, поскольку с нашим набором условий (API-портал с зарегистрированными пользователями и огромная экосистема, построенная вокруг портала) показалось проще и надежнее сделать свой API Gateway. Вы их использовали? Поделитесь опытом?
Посмотрите на использование вместо fluentd на Vector.
Если первый писан на Rust, то второй на Golang, как результат минимум в два, а в некоторых ситуациях и до трех раз позволяет улучшить показатели конвертирования и отправки логов.
Так мной, некоторое время назад, были проведены тесты по экспортированию, с предобработкой, логов nginx в clickhouse, на файле объёмом в несколько ГБ, обоими средствами, по результату, нескольких замеров, в среднем в 2,5 раза Vector импортировал быстрее с меньшей нагрузкой на CPU, нежели это делал Fluentd.
Кроме того Vector менее восприимчив в неформату, так если Fluend зависал на "битых" строках данных, то Vector их игнорировал без дополнительных ухищрений в коде.
Посмотрите на использование вместо fluentd на Vector.
Если первый писан на Rust, то второй на Golang
вот так и распространяются мифы)))
МиФ это стиральный порошок, Вы бы некомпетентность в вопросе не пытались скрыть невежеством, если вы не в материале и не способны предоставить аргументировый ответ, то могу аргументированно предоставить доказательства о высокопроизводительности Vector, в сравнении с Fluentd.
Хотя, они таким персонажам не нужны, Вы истина в конечной инстанции.
Наш опыт создания API Gateway