Если мы возьмем одно конкретное направление, то действительно все примерно так, как вы и сказали - единый стек технологий, который используют все разработчики этого направления для реализации типовых решений. Но если мы будем говорить о нестандартных ситуациях, то неправильно и вредно заставлять использовать инструмент, не подходящий для конкретной задачи, или инструмент, не удовлетворяющий требованиям задачи. Еще бывают ситуации, когда подходящего инструмента в нужном стеке нет вообще.
Для примера проиллюстрирую ситуацию. Мы создаем продукт и выбираем в качестве основной технологии Python, т.к. данный язык позволяет просто и быстро создать MVP продукта. Мы реализовали основные функции, однако на этапе разработки мы уже понимаем, что у нас есть одно узкое место, в котором нужен совершенно другого уровня язык - либо Go, либо С++. У нас микросервисная архитектура, поэтому не так важно на каком языке будет написан каждый сервис.
Точно так же, как и выбор СУБД. Для каждой задачи есть свой инструмент. Например, если мы создаем простой микросервис - в большинстве случаев подходит PostgreSQL, но это не означает, что PostgreSQL нужно использовать везде и всегда. Например, если нам важна транзакционность и скорость выполнения запроса, и при этом требуется построить большой кластер на терабайты данных, то скорее всего для этих целей подойдет сценарий, когда бизнес-логика будет расположена в процедурах Oracle DB или SQL Server. А если у нас большой объем данных и мы может осуществлять запись сразу большими порциями и мы знаем, что данные никогда не будут меняться, но при этом придется часто читать данные - для этих целей лучше подойдет ClickHouse. И таких ситуаций очень большое количество.
А так получится уйдет от вас программист который например на C# писал, а надо будет или расширить код или еще что-то....и возникнет большая проблема.
К счастью, такая ситуация крайне маловероятна, у нас много C# разработчиков.
Про фреймворки. Сравнение различных библиотек и фреймворков проходило в несколько этапов. Сначала получил полный список модулей, которые удовлетворяют нашему стеку. Далее была составлена небольшая сравнительная таблица, где учитывались различные факторы, например, дата последнего коммита, частота выхода релизов, количество открытых issue на github, наличие адекватной документации, размер сообщества. Затем были отобраны те модули, которые удовлетворяли внутренним требованиям. И заключительный этап - реализация нескольких типовых приложений на каждом фреймворке. Со всеми испытаниям справился только aiohttp, поэтому он был выбран как основной инструмент.
Про orjson и ujson. Некоторые наши сервисы работают под высокой нагрузкой, а количество инстансов каждого измеряется десятками. Поэтому сериализация и десериализация JSON одно из мест, которое можно оптимизировать. Как правило, (де-)сериализация используется в двух местах - при получении/отправке сообщений из/в Kafka в формате JSON и при обработке запросов/ответов веб-сервера. В первом случае все сильно зависит от приложения, а вот со вторым случаем ситуация прозрачнее. В среднем, в наших сценариях удалось получить прирост производительности веб-сервера на 5-10%. Если говорить о процедуре выбора, то все стандартно. Находим все интересующие библиотеки, пишем тест, прогоняем тесты и сравниваем результаты. По совокупности факторов выбираем желаемое.
Развитием и поддержкой описанных систем занимается отдельная команда, численность ~10 человек. Подробнее о платформе и о ее компонентах мои коллеги планируют рассказать в отдельной статье.
Если говорить о метриках приложений, то используются Prometheus/VictoriaMetrics и Grafana для отображения данных.
Но если мы говорим о различных данных тех или иных агрегатов из технологического сегмента, то тут все сильно сложнее. И поэтому как централизованное решение был создан отдельный внутренний продукт на базе ClickHouse, который позволяет решать большой спектр проблем. Подробнее об этом продукте, о причинах его создания и о принципах работы, мои коллеги расскажут в другой статьей.
Издержки моего рабочего времени сократились процентов на 20-30%.
Что касается команд, то тут все немного сложнее: стандарты, статьи, доклады и обмен опытом конвертируются в качество кода, а это достаточно субъективная оценка. Все, описанное в статье - это не про быстрый эффект, это про создание культуры разработки и унификацию подходов для снижения издержек не только прямо сейчас, но и в будущем.
Однако, все отзывы, которые я получал от разработчиков, руководителей проектов и высшего руководства, говорят об одном - стало лучше.
Благодарю за конструктивную критику. Однако столь широкую тему невозможно описать в одной статье. Начал с самого главного - людей и компетенций, в последующих статьях я и мои коллеги планируем затронуть более конкретные темы.
Все достаточно просто. Изначально приложение получало N сообщений из топика, и на каждое сообщение создавалась корутина. После происходило ожидание, пока все корутины не отработают. Затем я переписал приложение на несколько бэкгранудных задач, которые постоянно висят и ждут получения сообщений из локальных очередей - asyncio.Queue. А консьюмер закидывает сообщений в очередь на обработку и происходит обмен сообщениями/результатами между корутинами через асинхронные очереди. Как результат характер работы приложения стал ламинарным, а не пульсирующим. С другой стороны мы перестали ждать обработку самого долгого сообщений и можем выполнять обработку несколькими корутинами-воркерами.
Неявным является выбор конкретной реализации. Было бы лучше, если при использовании мы могли бы выбрать конкретную библиотеку. Например, если бы был метод setCodec() или useLZ4fCodec()
Благодарю за комментарий.
Если мы возьмем одно конкретное направление, то действительно все примерно так, как вы и сказали - единый стек технологий, который используют все разработчики этого направления для реализации типовых решений. Но если мы будем говорить о нестандартных ситуациях, то неправильно и вредно заставлять использовать инструмент, не подходящий для конкретной задачи, или инструмент, не удовлетворяющий требованиям задачи. Еще бывают ситуации, когда подходящего инструмента в нужном стеке нет вообще.
Для примера проиллюстрирую ситуацию. Мы создаем продукт и выбираем в качестве основной технологии Python, т.к. данный язык позволяет просто и быстро создать MVP продукта. Мы реализовали основные функции, однако на этапе разработки мы уже понимаем, что у нас есть одно узкое место, в котором нужен совершенно другого уровня язык - либо Go, либо С++. У нас микросервисная архитектура, поэтому не так важно на каком языке будет написан каждый сервис.
Точно так же, как и выбор СУБД. Для каждой задачи есть свой инструмент. Например, если мы создаем простой микросервис - в большинстве случаев подходит PostgreSQL, но это не означает, что PostgreSQL нужно использовать везде и всегда. Например, если нам важна транзакционность и скорость выполнения запроса, и при этом требуется построить большой кластер на терабайты данных, то скорее всего для этих целей подойдет сценарий, когда бизнес-логика будет расположена в процедурах Oracle DB или SQL Server. А если у нас большой объем данных и мы может осуществлять запись сразу большими порциями и мы знаем, что данные никогда не будут меняться, но при этом придется часто читать данные - для этих целей лучше подойдет ClickHouse. И таких ситуаций очень большое количество.
К счастью, такая ситуация крайне маловероятна, у нас много C# разработчиков.
Про фреймворки. Сравнение различных библиотек и фреймворков проходило в несколько этапов. Сначала получил полный список модулей, которые удовлетворяют нашему стеку. Далее была составлена небольшая сравнительная таблица, где учитывались различные факторы, например, дата последнего коммита, частота выхода релизов, количество открытых issue на github, наличие адекватной документации, размер сообщества. Затем были отобраны те модули, которые удовлетворяли внутренним требованиям. И заключительный этап - реализация нескольких типовых приложений на каждом фреймворке. Со всеми испытаниям справился только aiohttp, поэтому он был выбран как основной инструмент.
Про orjson и ujson. Некоторые наши сервисы работают под высокой нагрузкой, а количество инстансов каждого измеряется десятками. Поэтому сериализация и десериализация JSON одно из мест, которое можно оптимизировать. Как правило, (де-)сериализация используется в двух местах - при получении/отправке сообщений из/в Kafka в формате JSON и при обработке запросов/ответов веб-сервера. В первом случае все сильно зависит от приложения, а вот со вторым случаем ситуация прозрачнее. В среднем, в наших сценариях удалось получить прирост производительности веб-сервера на 5-10%.
Если говорить о процедуре выбора, то все стандартно. Находим все интересующие библиотеки, пишем тест, прогоняем тесты и сравниваем результаты. По совокупности факторов выбираем желаемое.
Развитием и поддержкой описанных систем занимается отдельная команда, численность ~10 человек. Подробнее о платформе и о ее компонентах мои коллеги планируют рассказать в отдельной статье.
Это очень интересный вопрос, благодарю!
Если говорить о метриках приложений, то используются Prometheus/VictoriaMetrics и Grafana для отображения данных.
Но если мы говорим о различных данных тех или иных агрегатов из технологического сегмента, то тут все сильно сложнее. И поэтому как централизованное решение был создан отдельный внутренний продукт на базе ClickHouse, который позволяет решать большой спектр проблем. Подробнее об этом продукте, о причинах его создания и о принципах работы, мои коллеги расскажут в другой статьей.
Издержки моего рабочего времени сократились процентов на 20-30%.
Что касается команд, то тут все немного сложнее: стандарты, статьи, доклады и обмен опытом конвертируются в качество кода, а это достаточно субъективная оценка. Все, описанное в статье - это не про быстрый эффект, это про создание культуры разработки и унификацию подходов для снижения издержек не только прямо сейчас, но и в будущем.
Однако, все отзывы, которые я получал от разработчиков, руководителей проектов и высшего руководства, говорят об одном - стало лучше.
Благодарю за конструктивную критику. Однако столь широкую тему невозможно описать в одной статье. Начал с самого главного - людей и компетенций, в последующих статьях я и мои коллеги планируем затронуть более конкретные темы.
Все достаточно просто. Изначально приложение получало N сообщений из топика, и на каждое сообщение создавалась корутина. После происходило ожидание, пока все корутины не отработают. Затем я переписал приложение на несколько бэкгранудных задач, которые постоянно висят и ждут получения сообщений из локальных очередей -
asyncio.Queue. А консьюмер закидывает сообщений в очередь на обработку и происходит обмен сообщениями/результатами между корутинами через асинхронные очереди.Как результат характер работы приложения стал ламинарным, а не пульсирующим. С другой стороны мы перестали ждать обработку самого долгого сообщений и можем выполнять обработку несколькими корутинами-воркерами.
Неявным является выбор конкретной реализации. Было бы лучше, если при использовании мы могли бы выбрать конкретную библиотеку.
Например, если бы был метод
setCodec()илиuseLZ4fCodec()При каждой итерации цикла происходило чтение сообщения из топика с последующим декодированием, вот как раз при декодировании ссылки и утекали.
В документации написано, что если вы возвращаете
Py_none, то самостоятельно должны следить за ссылками либо использоватьPy_RETURN_NONE.Все это описано в оф. документации, к сожалению, я не работаю с модулями на С и не могу более детально прокомментировать.