Roinet.Net

Нужен ли Python в .Net стеке?

Август 12, 2010 – 1:04 пп

Недавно наткнулся на статью Дмитрия Нестерука “Нужно ли полиглотное программирование в стеке .Net?”, где была высказана жалоба, что нет успешных историй использования IronPython. В этом блоге есть несколько статей по поводу особенностей использования DLR в небольшом, но очень ответственном проекте (платежный брокер по доставке платежей поставщиками услуг в рамках процессинговой системы CityPay). Однако не было статей, объясняющих причины использования python. Попробуем это исправить.

В начале проекта у меня имелся 1 год (1.5-2 года в IT) опыта использования cPython 2.5 в проектах далеких от web-сайтов, а у моего ПМ-а 10 лет опыта в IT – можно видеть, как минимум у одного человека трезвая и расчетливая голова должна была быть на плечах. Теперь о специфике проекта. В требования входило следующее:

• Не менее 100 бизнес-транзаций/сек.
• 100% реентрантности (большинство денежных провайдеров не имеет функции отката платежей, так что можно было один и тот же платеж отправить несколько раз).
• Легкость в разворачивании нового экземпляра – для масштабируемости.
• Высокая скорость вносимых изменений (необходимо было по той же причине что и пункт 2) – если в коде отвечающем за доставку платежа находится ошибка, её нужно исправить как можно быстрее.

Разработка брокера велась с 08-2009 по 09-2009 включительно, внедерение – с 10-2009 по 12-2009 включительно. Брокер был успешно внедрен и избавил компанию от большого кол-ва головной боли в новогодние праздники. Брокер состоит из ядра на языке C# и скриптов на IronPython. В качестве основной хост-платформы выбран IIS 6.0 (как в последствии оказалось, не самое лучшее решение, однако писать собственное времени не было).
В задачи ядра входит:

• Обеспечение работы с базой данных (Firebird 2.1)
• Поддержка общей схемы бизнес-процесса.
• Управление DLR, IronPython, пулами скомпилированных скриптов.
• Организация API для скриптов.

В задачи скриптов входит:

• Реализация протоколов конкретных поставщиков услуг (Киевстар, Билайн, MTS и т.д.)
• Способность восстановить процесс проводки платежа в любой момент (т.к. система работает на IIS).
• Всеми возможными способами избежать повторной проводки платежа.

Когда разработка только начиналась, были взяты DLR 0.91 и IronPython 2.6 Beta 1 (на данный момент это DLR 1.0, IronPython 2.6.1). За время разработки было выявлено немало ошибок в DLR и IronPython, найдены решения позволяющие обойти их.

В результате все заявленные требования были выполнены. К плюсам данной системы можно отнести:

• Относительно высокая скорость работы (150 бизнес-транзакций/сек).
• Высокая скорость внесения изменений (достаточно залить исправленный скрипт и все)
• Из-за простого синтаксиса относительно быстрый ввод в курс дела новых людей – у вновь прибывших студентов не возникает никаких проблем кроме того, что не понимают объема отвественности. Отдел тестирования в этом плане очень сильно помогает.

Естественно, не обошлось и без минусов:

• Большой объем потребляемой памяти (для обеспечения 10 бизнес-транзакций/сек требуется примерно 1 Гб оперативной памяти)
• IIS иногда зависает по непонятным причинам (при текущей нагрузке приходится перезагружать два раза в сутки)
• Проблемы с многопоточностью в DLR и IronPython. Для обхода были использованы пулы интерпретаторов, что и повлекло за собой увеличение потребляемой оперативной памяти.

Кроме того специфика применения DLR и IronPython позволяет в любой момент перейти на использование сборок в отдельных доменах.