Recommended
More Related Content
Viewers also liked
Viewers also liked (12)
Similar to Инструкция по созданию самопального биллинга, Михаил Крестьянинов (Новотелеком)
Similar to Инструкция по созданию самопального биллинга, Михаил Крестьянинов (Новотелеком) (13)
More from DevDay
More from DevDay (20)
Инструкция по созданию самопального биллинга, Михаил Крестьянинов (Новотелеком)
- 1. Инструкция по созданию самопального биллинга Крестьянинов Михаил Новотелеком
- 2. О себе
- 5. Подключение абонента Биллинг Абонент Монтажник Оператор Оборудование
- 15. Архитектура биллинга Абоненты/Услуги Тарификация Приём платежей Нотификация Интерфейс администратора Оборудование Интерфейс оператора Интерфейс абонента
- 16. Архитектура биллинга Тарификация Приём платежей Нотификация Абоненты/Услуги Интерфейсы Оборудование
- 17. Архитектура биллинга Тарификация Приём платежей Абоненты/Услуги Нотификация Интерфейсы Оборудование
- 18. Архитектура биллинга Абоненты/Услуги Тарификация Приём платежей Нотификация Оборудование ESB
- 19. База Данных
- 21. Базы данных
- 23. Архитектура биллинга Абоненты/Услуги Тарификация Приём платежей Нотификация Das Sybase Интерфейс администратора Интерфейс оператора Оборудование Интерфейс абонента
- 25. Тестирование
- 27. Mock them all! Mock для Mock для Тарификация Нотификация Абоненты/Услуги Mock для Mock для работы приёма платежей с оборудованием
- 29. Прочее
- 34. Вопросы? email: mikhail.krestjaninoff@gmail.com www: krestjaninoff.ru
Editor's Notes
- Картинка (?) Добрый день! Меня зовут Крестьянинов Михаил. Работаю я в компании Новотелеком, где занимаюсь системой биллинга и внутренней автоматизацией.
- О себе. Для начала чуть-чуть скучной и никому неинтересной информации о себе. Вот небольшой список тех компаний, где мне платили зарплату (появляются компании). А так же всего, что я достиг в этой жизни (появляются сертификаты) . Вот. Ну а теперь начнём
- Что такое Enterprise? Картинка (АСР ) . Кому-нибудь эта картинка что-нибудь напоминает? Нет? А я вот каждый день вижу . И так, все мы знаем (ну или по крайней мере догадываемся), что представляют собой такие направления разработки как webdev, gamedev... популярный в последнее время mobiledev. Однако, далеко не всем известно, что же представляет собой разработка enterprise (или в переводе на великий и могучий — корпоративных) приложений ? Как видно с этой картинки, занятие это довольно увлекательное, насыщенное разными технологиями, проблемами и их решениями :) Но что бы ответить на этот вопрос серьёзно, давайте представим себе, что у нас есть некая относительно крупная компания ... например, Новотелеком. Жизнь в этой компании бурлит, цветёт и пахнет: подключаются абоненты, оплачиваются услуги, предоставляется интернет, списывается абонентская плата... ну и всё по новой :) Однако, если бы всё это делалось вручную, с помощью специально обученных бабушек или иной биоробототехники, к успеху бы компания шла очень долго и скорее всего никогда бы не дошла. Что бы автоматизировать все эти бизнес процессы (и списывать ещё больше денег) как раз и используются приложения, именуемые корпоративными: биллинг, система учёта клиентов и т. д. Иначе говоря, корпоративные приложения — это ПО, призванное решать задачи автоматизации бизнес процессов компании.
- Автоматизация БП . Давайте рассмотрим пример конкретного бизнес-процесса , что бы чуть более лучше понимать, что собой представляет бизнес-процесс, и так ли сильно его нужно автоматизировать .
- Автоматизация БП. Картинка (Диаграмма подключения абонентов). В качестве примера возьмём процесс подключения абонента в НТК . Первым делом счастливый абонент ( появляется абонент ) звонит по телефону (или иным образом) сообщает оператору ( появляется оператор ), что хочет подключится. Его контактные данные сохраняются в CRM ( появляется CRM ) и на их основе создаётся заявка в Issue Tracker ( появляется Jira ). Заявка в трекере проходит некоторые бюрократические и технические этапы — например установку оборудования монтажником ( появляется монтажник ). После этого абонент заводится в биллинге ( появляется АСР ) и конфигурируется на оборудовании ( появляется оборудование ). Как вы видите, только в одном , довольно обобщённом, сценарии подключения абонента задействовано четыре системы . Четыре приложения которые нужно разработать/купить и сынтегрировать вместе . На первый взгляд, процесс довольно прост , и не совсем понятно, так ли здесь нужно что-то автоматизировать . Однако, если посмотреть на него более детально ...
- Автоматизация БП. Картинка (Процесс подключения абонента из Jira ). Думаю, ответ становится очевиден :)
- Платформа для корпоративных приложений . И так, мы ответили на вопрос – Зачем нам корпоративные приложения? Перейдём к вопросу – Откуда берутся корпоративные приложения?
- Платформы для EA. Картинка (Рынок ПО). Современный рынок корпоративного ПО предлагает огромнейшее количество решений для автоматизации практически любых задач. Тем не менее практически в каждой более менее крупной компании есть свой отдел, занимающийся разработкой корпоративного ПО . Почему? Ответов тут два .
- Платформы для EA. Картинка (Где-то в Oracle ). Во первых — это стоимость . Приложения из Oracle E-Business Suite стоят в среднем от 5 до 20 килобаксов , плюс поддержка где-то ешё на тысячу /полторы. С учётом того, что большая часть его функциональности вам не пригодится, покупка его может быть оправдана только в случае компаний неимоверных масштабов. Конечно же есть и более пролетарские решения . В качестве примера можно взять продукты компании N a umen из ЕКБ. Однако, в данном случае мы наступаем на другую сторону медали — …
- Платформы для EA. Картинка (Кастомизация). … кастомизируемость, адаптируемость продукта под нужды компании . В случае с НТК система биллинга дорабатывается под нужды маркетинга практически непрерывно : каждую неделю внедряется какая-нибудь новая фича, порожденная богатым воображением наших внутренних заказчиков. Понятно, что ни одна сторонняя система не сможет обеспечить абсолютной гибкости настроек, а держать основное ПО компании на аутсорсе мягко говоря рискованно.
- Архитектура корпоративных приложений . И так, мы решили писать своё enterprise- приложение. Какой подход выбрать? Вариантов тут на мой взгляд три.
- Платформы для EA. Картинка (Банк). Первый подход я назвал «Банковским», потому что его реализацию можно встретить практически в любом банке . В основе него лежит святая святых — БД Oracle за несколько сотен килобаксов . Большая часть логики при этом реализована в виде хранимых процедур на PL/SQL. Говорить о недостатках этого подхода смысла нет , так как споры об эффективности процедурной разработки в свете наличия ООП вроде бы давно утихли и остались в прошлом . Понятно, что это наследие прошлого , которое необходимо поддерживать и развивать . Которое приносит деньги .
- Платформы для EA. Картинка (Сервер Приложений). Далее идут сервера приложений . Довольно интересный подход, который тем не менее редко можно встретить на рынке НСК. Суть его заключается в использовании специального ПО — сервера приложений (типа Jboss, WebSphere), который берёт на себя все аспекты работы с БД, контроля транзакций, авторизации, кластеризации . Разработчику при это остаётся только самое главное — описывать бизнес-логику. Причина непопулярности данного подхода у нас скорее всего кроется в их цене (до $5К) и относительно невысокой производительности (обусловленной не всегда востребованными накладными расходами ). Поэтому зачастую их можно встретить только в крупных компаниях, которые покупали брендовые сервера «под ключ»: с заранее установленной брендовой ОС и сервером приложений . Например, IBM System I c AIX и WebSphere на борту. В качестве более-менее удачного примера использования можно рассмотреть АльфаКлик от АльфаБанка ( судя по их вакансиям работает на WebSphere под AS/400) . Ну а что же делать, если не хочется писать хранимые процедуры и нет веры в EE-сервера? Правильно, писать своё — с нуля. На самом деле — шучу. Почти с нуля.
- Платформы для EA. Картинка ( Framework ). Для разработки корпоративных приложений прекрасно подходят языки со строгой типизацией и мощным фреймворком/комьюнити. Примерами таких языков являются Java с замечательным Spring FrameWork и C# с не менее замечательным .NET. У нас в НТК мы используем как раз Java + Spring, чему очень рады.
- Архитектура EA. Рисунок (Диаграмма поэтапного создания биллинга) . Но бог с ней, с теорией — давайте перейдём к практике и попробуем спроектировать своё enterpri s e - приложение. С блэкджеком и прочими фичами. Как следует из заголовка доклада - это будет биллинг. Заодно я покажу, как он устроен у нас в НТК. Первым делом давайте определимся с тем, что же должен уметь биллинг. Как минимум хранить информацию об абонентах и предоставляемых им услугам ( появляется сервис Абоненты/Услуги ).Что бы предоставлять услуги, например, доступ в интернет, придётся научиться конфигурировать оборудование ( появляется сервис Оборудование ). Раз у нас появились абоненты, которым мы предоставляем услуги, — пора начинать списывать с них деньги! ( появляется сервис Тарификация ). Что бы абоненты могли пополнять свой баланс и приносить компании ещё больше денег, дадим им возможность пополнять баланс ( появляется сервис Приём Платежей ). Так же мы должны уметь оповещать абонентов ( появляется сервис Нотификации ). И предоставить web-интерфейсы для абонентов, операторов и администраторов ( появляется сервисы Интерфейсов ). И так мы декомпозировали наш биллниг на несколько относительно независимых служб, реализующих свой модуль бизнес логики. Каждая из них достаточно самостоятельна, что бы быть представлена отдельным приложением с 2х/3х-звенной архитектурой и, потенциально, со своей БД ( появляются базы данных ). Такой подход называется сервисно-ориентированным или SOA . Его преимущества достаточно очевидны: кластеризация бизнес-логики, упрощение доработок и рефакторинга, потенциальное масштабирование, и главная ценность для больших систем — порядок!
- Архитектура EA. Рисунок (Диаграмма поэтапного создания биллинга) . Следующим шагом является связывание наших сервисов друг с другом. Интерфейс должен знать об абонентах и оказываемых услугах, Тарификатор должен уметь оповестить абонента об окончании денег на его счету. Связать службы можно несколькими способами: 1. Напрямую ( появляются прямые связи ). Самый простой и самый эффективный способ . По крайней мере при небольшом количестве служб . Спектр возможных протоколов тут крайне широк, но зачастую речь идёт об REST или SOAP . В нашем случае используется крайне специфичный бинарный протокол Hessian , но его наличие обусловлено чисто историческими причинами :)
- Архитектура EA. Рисунок (Диаграмма поэтапного создания биллинга) . 2. Второй способ - Очереди Сообщений ( появляется схема с MQ ). Тут существует несколько возможных протоколов: Java Message Service, Advanced Message Queuing Protocol, ну и конечно же Microsoft Message Queuing – лозунг “Not invent here” никто не отменял У каждого протокола есть свои реализации (наиболее популярные приведены на слайде) , но суть у них одна - асинхронный обмен сообщениями без явного необходимости указания адресата и адресанта. Например, в нашем биллинге такая схема (на основе ActiveMQ ) используется для отработки события подключения абонента. Как только служба работы с оборудованием зафиксирует факт подключения абонента — она отправит сообщение об этом в соответствующий топик. Все другие службы и системы, которые хотят быть в курсе этого события (Учёт Абонентов, Нотификация, JIRA) получат это сообщение и сделают соответствующие выводы. Относительно предыдущего способа у данного есть 3 явных преимущества : - всегда можно подписать или отписать ещё одну службу на некоторое событие, - время работы вызывающей службы не зависит от времени работы вызываемых служб, - работа системы в целом не зависит от доступности вызываемых служб, в виду гарантии доставки сообщения.
- Архитектура EA. Рисунок (Диаграмма поэтапного создания биллинга) . 3. И последний способ — через сервисную шину предприятия, Enterprise Service Bus ( появляется схема с ESB ). ESB , как и вариации Message Queuing является стандартом, но уже не обмена сообщениями, а интеграции корпоративных систем. Что бы понять его предназначение, давайте представим себе компанию в которой одна служба имеет интерфейс SOAP, другая — SMTP, а третья — вообще работает только по собственному XML протоколу поверх TCP. Что бы свести всё это к единой схеме, единой шине нам как раз и пригодится ESB приложение ( например , eMule) , на основе которого мы напишем коннекторы ( появляется JIRA и 1С с коннекторами ) ко всем службам по всем нужным протоколам, не изменяя при этом ни строчки кода этих служб . Какой же способ выбрать? Всё зависит от ваших задач. Мы в своей работе используем все три способа. Прямые связи, так как это дёшево и эффективно (тут правда стоит отметить, что большинство наших служб и сервисов самописаны и поддерживают единый протокол Hessian). JMS — в тех случаях, когда бизнес процесс явно подразумевает асинхронную модель поведения. ESB — в качестве моста между Hessian-службами и чужеродными нам Jira/1C.
- База Данных . Вот мы, пожалуй и добрались до самого главного — БД. Данные — это пожалуй одна из самых главных ценностей любой IT компании, а способ из хранения — ценнейшая тайна :) На самом деле нет :) Но давайте к сути. Какую БД выбрать для вашего приложения?
- Базы данных. Рисунок ( Oracle vs Postgres ) . Обычно всё уже давно выбрано за нас, причём давно :) Однако, если попытаться ответить на этот вопрос теоритически... Понятно, что модный пару лет назад NoSQL стоит оставить Хипстерам . Ограничения целостности и строгая структурированность данных — крайне важные вещи, при работе с серьёзными данными…
- Базы данных. Рисунок (Реляционные БД) . … Что же касается реляционных БД... то тут почти у каждой есть своя Success Story в крупных проектах : MySQL — YouTube, Postgres — Skype, Sybase — SUP, MsSQL — все партнёры Microsoft, Oracle — так вообще корпоративный стандарт. В общем холиварить тут можно долго . Точно можно сказать, что количество success story и размер comunity у Oracle просто огромны . Однако, он стоит денег — 47 килобаксов за процессор (и это без поддержки!) . Что, согласитесь, не мало. Из бесплатных БД лично нам наиболее импонирует Postgres. ..
- Базы данных. Рисунок ( PostgreSQL ) . Мы умеем с находить с ним общий язык. Он хорошо зарекомендовал себя в плане работой под нагрузкой в проекте CN.ru . Он умеет партицирование и репликацию , которые так же успешно опробованы как у нас, так и в других российских компаниях , в том же Яндексе. В общем – мы любим и верим в Postgres. Если же говорить о выборе, то уникального рецепта тут нет. Попробуйте всё сами, сравните и выберите наиболее удобное и эффективное для вас решение.
- Базы данных. Рисунок (Структура сервисов биллинга НТК) . Однако, как я уже говорил выбирать зачастую не приходится — скорее всего всё уже выбрано за вас! :) Помните, пару слайдов назад я показывал вам, как выглядит структура сервисов нашего биллинга? Так вот - я соврал Мы хотим, что бы она так выглядела На самом деле все выглядит так ( Спецэффект ). В нашем случае в качестве основной БД мы имеем купленный много лет назад вместе в первым биллингом Sybase .
- Базы данных. Рисунок (This is Sybase). Недавно у него было день рождение. Ему исполнилось 12 лет. Я в его возрасте в первый раз попробовал пиво :) Нет, это очень хорошая СУБД... для своего времени :) Количество параметров конфигурации и объёмы документации превышают пожалуй размеры любой современной open source БД. Там даже есть партицирование БД (правда только по первичному ключу). Но! В нём нём крайне скудны возможности SQL (минимум агрегатных функций, ни какой рекурсии или оконных функций), работы с триггерами и т. д. Но это не основная проблема — всегда можно найти какой-то workaround . Основная беда кроется в том, что архитектура БД устарела — нельзя заставить СУБД 12 летней давности эффективно использовать ресурсы современных серверов. Так как в качестве решения проблемы Sybase предлагает купить последнюю версию их БД по цене не сильно отличающейся от стоимости Oracle , мы решили медленно но верно переезжать на Postgres. Кстати о переезде . Более менее безболезненный переезд стал возможен как раз благодаря сервисно-ориентированной архитектуре биллинга . Поскольку логика работы с каким-то определённым аспектом инкапсулирована в одной службе , нам относительно безболезненно удалось взять часть таблиц, относящихся к финансам и тарификации и унести их из Sybase в Postgres — к производительности и партицированию, так что остальные службы даже ничего не заметили :)
- Тестирование . И так, мы определились с архитектурой и БД. Давайте теперь подумаем, как же тестировать наше приложение?
- Тестирование . Рисунок (Песочница). Когда приложение состоит из одного модуля — всё просто: установили, протестировали. Но что делать, если приложение, сервис зависит от других сервисов? Ответ прост, как и всё гениальное — для каждого тестировщика создавать собственное окружение с блекджеком и полным набором сервисов. Тоже самое будет касаться и различных БД для сервисов . Правда в нашем случае есть БД, чей объём превышает 1 00ГБ , что делает её актуализацию несколько затратной . В данном случае можно идти по пути обновления не всей базы, а отдельных таблиц или даже дельт этих таблиц.
- Тестирование . Рисунок (Служба и моки вокруг). Отдельно хотел бы упомянуть модульные тесты... :) Мы все знаем, что TDD - это круто... но давайте смотреть правде в глаза :) Кто из вас положа руку на грудь, скажет что ведёт разработку полностью в рамках этой религии ? Писать моки для БД и множества соседних служб, конечно очень увлекательно, но имхо крайне неэффективно. Тем более, если учесть существование тестов интеграционных. В нашей разработке модульные тесты используются только для математики/алгоритмов и некоторых утилит . Всю остальную логику в случае сервисно-ориентированной архитектуры лучше возложить на интеграционные тесты – тут вам и проверка логики и работы с БД, плюс полная имитация всех внешних взаимодействий по всем протоколам, плюс проверка интерфейсов с помощью Selenium .
- Тестирование . Рисунок (Hudson). Для того, что бы автоматизировать процесс тестирования до конца удобно использовать системы непрерывной интеграции, например Hudson . Однако его настройка, это тема для отдельного доклада . Скажу только, что самое сложное при работе с ним — это не забить на него и его репорты. Это требует действительно большой ответственности и силы воли :)
- Прочее . Фух! Потихоньку подбираемся к концу
- Деплоймент. Риунок (План внедрения). Вкратце затрону процесс выкладки служб на боевые сервера. Если бы у нас был сервер приложений — то вопрос выкладки и хостинга сервисов отпал бы автоматически. Но у нас OpenSource и Spring :) Поэтому каждую нашу службу мы оформляем виде самостоятельного приложения и пакуем в deb-пакет. Тем самым используя виртуалки с Linux'ом в качестве контейнеров для служб нашего биллинга. Подход немного нестандартен, но при наличии некоторых утилит для мониторинга весьма эффективен.
- Нагрузки. Рисунок (Ослик). Я думаю, это печальная тема для многих из нас :) Как я уже говорил выше главная проблема в нашем случае это моральна устаревшая БД . Ну и чего уж греха таить, порой не всегда оптимальный код . Но что в обоих случаях мы идём к успеху: в первом случае к Postgres ’ у, во втором — к просветлению :) Если говорить о цифрах, то это примерно 150К абонентов, 300К финансовых проводок в сутки и 150ГБ данных. Кстати про данные. Мало кто знает, но одной из причин появление в 2008 году безлимитных тарифов на интернет в НСК стал тот факт, что с ростом числа абонентов обрабатывать и хранить данные по потреблению трафика стало довольно неоправданно напряжно :)
- Проблемы. Рисунок (Троллфайс). Проблемы есть у всех. В случае enterprice-разработки они мало чем отличаются от общих по отрасли :) Самая главная проблема на мой взгляд — это внутренний заказчик . С одной стороны это хорошо: всегда можно в полной мере обсудить задачу и уточнить неясные моменты. С другой — это ад, потому что требования будут меняться каждый день, если не час: ведь продумать всё сразу необязательно — всегда можно подойти и сказать: «я тут подумал...» :) В любой компании есть быдлокод оставшейся с времён, когда компания только начинала развиваться и думать о качестве кода не приходилось . История НТК, например, начиналась с купленного биллинга средней руки на JSP и хранимых процедурах БД и bash скриптах. Сейчас от того биллинга уже ничего не осталось В мире корпоративной разработки есть очень много интересных технологий. Однако, далеко не все нужно использовать. А хочется, ибо круто :) Такую болезнь иногда называют Resume Driven Development. В своей компании видеть такого мне не приходилось, но вот в других порой встречается :)
- Отказоустойчивость. Рисунок (Нет!). Ну и конце своего доклада хотелось бы ответить на вопрос, который наверное интересует всех — как сделать так, что бы всё работало и никогда не ломалось? Да никак! Чудеса бывают только в сказках и платных мастер-классах. Помните пару месяцев назад свалился процессинг СберБанка? Даже Сбер с его многомиллионными бюджетами, почти полной редакцией Oracle 11g, наикрутешим аккаунтом в саппорте Oracle словил вполне тривиальную ошибку. Не срабатывает процесс создания резервной копии (check point) БД, переполняется лог транзакций, встаёт запись в базу. Точка. Полностью защититься от беды нельзя, но можно значительно снизить риски. И рецепты тут давно известны — мониторинг с помощью того же Zabbix/Monit и резервирование !
- На этом у меня всё. Вопросы?