Постановка задачи

В качестве примера буду использовать два реализованных проекта:

1. FATS — Быстрые телефонные сервисы на базе программной IP-PBX Asterisk
2. DBSync — синхронизатор баз данных в режиме 24/7/365

В первую очередь важно понять необходимость использования Twisted. Как уже говорилось ранее: “есть множество способов решить задачу”.

FATS:

Прецеденты:

1. Необходимо запускать множество средних\сложных сервисов на базе Asterisk
2. Сервисы работают со сторонними технологиями: Базы Данных, XML-RPC, Web
3. Удобство администрирования и обновления версий

Способы решения:

Стандартными средствами Asterisk, применяя макросы и запуск внешних команд на сервере(fork).

Очевидно, что способ имеет ряд недостатков для большого объема кода(сценария макроса) и более менее сложной логики.

плюсы:

1. Может писать администратор Asterisk, все в одних руках. Быстрый хак.

минусы:

1. Сложная логика, запутанный код - хак.
2. Не удобно вести отладку. Перезапускать план дозвона возможно не понадобится, но проверять приложение придется вручную.
3. Порожденные процессы будут нагружать CPU сервера Asterisk — тратить общие ресурсы. Запускаются на каждую сессию звонка с копированием контекста процесса.

На динамическом языке программирования, запускать на исполнение(fork) используя протокол AGI

плюсы:

1. Может писать администратор Asterisk, программист. Быстрый хак.
2. Можно использовать удобный язык программирования. Python очень хорошо подходит для таких задач.
3. Все в одном приложении, ясная картина.

минусы:

1. Запускается как процесс на сервере Астериск для каждой сессии звонка, расходует ресурсы CPU сервера.
2. Не удобно вести отладку. Перезапускать dialplan возможно не понадобится, но проверять приложение придется вручную.

Исполнять приложение удаленно используя FastAGI протокол (TCP\IP).

плюсы:

1. Можем исполнять приложение или много приложений на удаленном сервере. Оставляем ресурсы сервера для Asterisk.
2. Позволяет использовать динамические языки программирования.
3. Все в одном приложении, ясная картина.

минусы:

1. Необходимо повышать квалификацию администратора до программистов или нанимать программиста.

Twisted в студию

плюсы:

1. Минимальная нагрузка. Можем обрабатывать множество запросов в рамках одного процесса без блокировок. Приложение может работать на сервере вместе с Asterisk.
2. Масштабирование. Множество готовых протоколов для модернизации приложения, необходимо писать только нужный код. Никаких изобретений велосипедов!
3. Универсальность, красота. Python — понятный язык. Применяется как программистами, так и администраторами серверов.
4. Тестирование. Правильная реализация позволит тестировать работу кода в процессе разработки без использования рабочего сервера с программными телефонами(soft phone) в 98% задач.

минусы:

1. Нужно повышать квалификацию кадров или нанять специалиста. Эту проблему можно решить путем разового найма для решения возникшей задачи.

DBSync

Прецеденты:

1. Необходимо синхронизировать данные разных хранилищ с заданным интервалом времени
2. Хранилищем данных могут быть PostgreSQL, MySQL, MSSQL, Oracle, XML и т.д.
3. Данные могут передаваться по сети, путем чтения из файла, через web и т.д. Данные могут быть шифрованные: ssl, ssh и т.д.
4. Отношение сущностей в хранилищах разное
5. Структура данных может и будет меняться, множество разных конкурентных связей данных в рамках одной сессии синхронизации.
6. Сервис должен работать в режиме 24/7/365.
7. Нужно очень быстро адаптироваться к изменениям. Минимальные затраты на масштабирование и\или модернизацию.

Примечание:

Изначально ставилась “узкая” задача, поэтому проект работает в ее рамках. Синхронизация работает по сети, между различными БД. Кроме того на базе API решаются маленькие задачи с синхронизацией WEB - БД.

Способы решения:

Скрипт на любом удобном языке, запускать в cron сервера

плюсы:

1. Быстрая разработка для выполнения конкретной задачи

минусы:

1. Проблемная отладка. Можно написать тесты и решить эту проблему.
2. Не гибкое решение. С учетом изменений данных и типов хранилищ придется менять скрипт, копаться в куче кода.
3. С учетом нескольких подобных задач код будет либо дублироваться и создавать путаницу, либо превратится в библиотеку(некое API).
4. Скорее всего разработчик будет писать логику БД в коде приложения. В противном случае мы начинаем делать из первого способа второй и теряем плюс в быстрой разработке.
5. Распараллеливание задач в рамках сессии синхронизации. Очень похоже на изобретение велосипеда, странно выглядит, если написано с нуля. Противоречим нашему плюсу.

Скрипты на API с использованием ООП. Использовать ядро системы для создания отдельных сервисов

плюсы:

1. Гибкое решение. Грамотное API позволит легко масштабировать сервисы.
2. Перспектива быстрой и простой разработки подобных сервисов. Использую мозги, а не попу.

минусы:

1. Может превратиться в состояние вечной разработки. Нужен грамотный подход.
2. Время. Перспектива остается перспективой, возможно она и не понадобится.

3. Нанять кучу операторов, чтобы вносить данные вручную. Можно выписать “диких обизяян” у тети из Бразилии.

1. Читаем в других блогах, смотрим советское кино. %)

Twisted в студию:

плюсы:

1. Масштабирование. Наличие готовых компонентов для работы со множеством БД, протоколов и т.д.
2. Красота. Python — понятный язык. С учетом обработки массивов данных — это плюс(использование ORM усложнит задачу и уменьшит производительность).
3. Тестирование. Правильная реализация позволит тестировать работу кода в процессе разработки без использования реальных хранилищ.
4. Адаптация данных. Мы будем использовать zope.interface и адаптеры для наглядного модифицирования данных из одной сущности в другую.
5. Универсальность. В перспективе мы действительно сможем быстро делать сервисы синхронизации и быть уверенными в из работоспособности.

минусы:

1. Сроки реализации увеличатся.
2. Окончание проекта требует грамотного проектирования и реализации.

Проектирование \ Шаблоны проектирования

Twisted содержит очень много примеров грамотного кода, если следить за разработкой платформы, то можно видеть как происходит изменение системы и почему одним элементам уделяют много внимания, а другим нет. Как разработчики следят за стабильностью кода.

В Twisted активно используются шаблоны проектирования:

1. Фабрика методаFactory method. Фабрики порождают протоколы для каждой сессии соединения.
2. ФасадFacade. Скрывает реализацию и позволяет использовать интерфейсы для оптимизации и простоты доступа в подсистему Twisted.
3. ПодписчикObserver. Система логирования может подключать подписчиков для модернизации сбора информации и ее сохранения в разных хранилищах.
4. РеакторReactor. Ядро twisted для работы с событиями и управления отложенными задачами.
5. АдаптерAdapter. Позаимствовано у zope.interface. Позволяет регистрировать адаптеры и типизировать сложные данные, объекты за счет интерфейсов.
6. СтратегияStrategy. Позволяет выбрать стратегию алгоритма с учетом входных данных или требуемых выходных данных.

и так далее.

Нам важно использовать шаблоны на практике, чтобы не плодить лишний и не понятный код.

Для более детального изучения шаблонов могу посоветовать книгу “Применение UML и шаблонов проектирования”, автор Крэг Ларман.