10 октября 2013 г.

Проекты моей компании

В последнее время у нас в компании сформировался вектор развития, который мы хотим расширять и дальше. Основные направления, с которыми мы работаем:

  • Высоконагруженные приложения
  • Облачная инфраструктура (AWS, Azure)
  • Data mining

Основные технологии:

  • .NET Framework
  • JavaScript (SPA)

Проекты

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

Ниже краткое описание проектов и технологий:

1. Компания: ForexClub

Проект: Разработан набор сервисов для онлайн-мониторинга состояния рынка и автоматического принятия решений по сделкам

Технологии: ASP.NET MVC, Silverlight, WCF, RabbitMQ, MSSQL

Основные цифры:

  • Цена ошибки в ПО от $100 тыс. до $100 млн.
  • 1 000 операций в секунду
  • Задержка в обработке поступающих данных и расчет аналитики не более 1 секунды

2. Проект: http://pandorama.com

Динамическое создание ленты новостей для пользователя, на основании его поведения на сайте

Технологии: ASP.NET MVC, RabbitMQ, MSSQL, MongoDB, JavaScript (SPA)

Описание архитектуры: http://habrahabr.ru/company/veeam/blog/193672

Основные цифры:

  • Ежедневно анализируется 35 тыс. англоязычных источников, статьи в них обрабатываются и кластеризуются
  • Обработка 50 тыс. статей в день

3. Проект: http://zakupki360.ru

Анализ гос. закупок в России с составлением прогнозов участников и цен, поиск похожих закупок и создание рейтингов поставщиков.

Технологии: ASP.NET MVC, вся инфрастуктура на AWS, MSSQL, IronMQ, Sphinx

Основные цифры:

  • Более 100 виртуальных серверов для обработки постоянных изменений и расчета аналитики
  • 50 тыс. изменений в закупках в день
  • 5,5 млн. закупок в архиве

4. Около полугода мы сотрудничали с компанией Медиалогия с целью реализации распределенной инфраструктуры для одного из их проектов.

Основные технологии, которые были использованы: MSSQL, ASP.NET MVC, RabbitMQ, backbone.js

Другие проекты пока нельзя описывать из-за NDA, но в целом используются похожий набор инструментов.

Дальнейшее развитие

В перспективе мы планируем заниматься проектами еще сложнее и масштабнее, чтобы рост каждого члена команды повышал уровень компании в целом.

30 комментариев:

  1. Интересными вещами занимаетесь. Может ещё используете активно в проектах CQRS & ES? А как на счёт найма удалённых сотрудников?

    ОтветитьУдалить
  2. Архитектурно и CQRS, и ES используем в разных комбинациях. Каждый проекте по-своему уникален и для него подбираются (либо формируются эволюционным путем) разлиные дизайны.
    С удаленной работой у нас не получается, так как я очень ценю хорошую коммуникацию внутри команды. Под каждый проект формируется команда, которая садится в _отдельный_ кабинет, чтобы они постоянно общались.

    ОтветитьУдалить
  3. "1000 операция в секунду, задержка в обработке ... не более 1 секунды"
    Какие подходы используете для подобного быстродействия? Сам на настолько масштабных проектах не работал, поэтому очень интересно как решаются подобные задачи.

    ОтветитьУдалить
  4. Спасибо за информацию. Всегда интересно читать о внутреннем устройстве высоконагруженных приложений.

    ОтветитьУдалить
  5. Там на самом деле много нюансов было, но я не уверен, что NDA позволяет их открывать

    ОтветитьУдалить
  6. Тебе серьезно нравится Half-Arsed Agile Manifesto? Это больше похоже на стеб над agile. Как иначе назвать, когда каждый принцип выворачивается наизнанку дополнением мелким шрифтом.

    ОтветитьУдалить
  7. Чтобы понять почему так сделали, предлагаю прочитать http://xprogramming.com/articles/beyond-agile-new-principles

    ОтветитьУдалить
  8. MANIFESTO FOR MINIMALIST SOFTWARE ENGINEERS

    http://minifesto.org/

    ОтветитьУдалить
  9. Интересно. Рад что есть компании которые предпочитают расти интенсивно, а не экстенсивно. В провинциальных российских IT компаниях принято останавливаться в развитии,освоив пару технологий (обычно PHP+MySql), и начинать расширять клиентскую базу, беря на себя реализацию все большего и большего однотипных, простеньких проектов. Здорово что у вас не так. Но к вашим технологиям есть пара вопросов.
    Вопрос один. В описаниях проектов я не нашел у вас следов использования серверов кеширования (Redis, Memcache), хранящих часто используемые данные в оперативной памяти. Почему вы не считаете нужным кешировать часто используемую информацию? Я читал, что для ускорения вы активно используете денормализацию и фанатично отлаживаете каждый запрос к БД, но, по моему опыту, денормализация снимает лишь часть проблем. У нас в проекте имена пользователей это часто используемая информация, которая требуется почти в каждом клиентском представлении. Join средствами БД использовать мы не можем из-за требований по горизонтальному масштабированию, денормализировать базу дублируя имена пользователей в каждой требуемой для работы таблице мы не можем, так как в случае смены имени пользователя количество update ко всем таблицам будет просто космическим. Единственное быстро работающее решение - это хранить имена пользователей в кеше (мы используем Redis). Как решаются подобные нюансы у вас?


    И второй вопрос. У вас в технологиях есть MQ сервера. Пользуетесь ли вы уже готовыми абстракциями для работы с ними или пишите код сами?

    ОтветитьУдалить
  10. > Почему вы не считаете нужным кешировать часто используемую информацию?... Как решаются подобные нюансы у вас?


    Кэширование используется там, где это необходимо. Например, мы активно используем memcached, как на своих серверах, так и в облаке.
    В описании проекта я перечислил ключевые библиотеки, если составить полный список, то он будет довольно длинным :)

    > MQ сервера. Пользуетесь ли вы уже готовыми абстракциями для работы с ними или пишите код сами?



    Каждая реализация MQ предоставляет свои провайдеры для работы. В RabbitMQ например можно использовать как низкоуровневое API, так и библиотку типа EasyNetQ. В основном используем высокоуровневое API, но есть случаи, когда переходим и на более низкий уровень.


    Один из таких случаев - работа с очередью через CLR-процедуру в MSSQL 2008. Там поддерживается .NET 2.0 и ниже, поэтому EasyNetQ не работает. В этом случае пишем обвязку сами.


    С другими реализациями MQ (Azure, AWS и др.) такая же история.

    ОтветитьУдалить
  11. Я вас понял. Но под абстракциями я имел в виду не библиотеки для подключения, а абстракции более высокого уровня, практически полностью скрывающие детали работы с MQ сервером. Например, реализации паттерна ServiceBus, имеющие в виде транспорта MQ-сервер. NServiceBus для MSMQ или MassTransit для RabbitMQ.

    ОтветитьУдалить
  12. > под абстракциями я имел в виду не библиотеки для подключения, а абстракции более высокого уровня


    Всё, понял. Делать абстракцию или нет зависит от проекта и его дальнейшего развития. У нас бывает и так и так.

    ОтветитьУдалить
  13. Ну отлично. Но попользовавшись MassTransit-ом желание работать с RabbitMq сервером напрямую у меня отпало насовсем, и, даже если мне придется писать EventSource Hello World, лично я буду использовать MT. Но я понимаю, что есть случаи (например тот, который вы описали комментом выше) что иногда приходится работать напрямую.
    Ну и последний вопрос. У вас (как и у нас впрочем) из технологий зоопарк. И как ваши администраторы администрируют все это? Мы, например, чтобы снизить расходы на адмиинистрирование, были вынуждены отказаться от использования MongoDb, и нам теперь приходится хранить данные в реляционной БД, пусть мы и храним их в nosql стиле.

    ОтветитьУдалить
  14. Вы будете смеяться, но у нас есть только один администратор на все проекты и инфраструктуру компании :) Программисты сами стараются заботиться о настройке и поддержке проектов. Особенно мало проблем доставляет работа в облаках.

    ОтветитьУдалить
  15. Вы тоже будете смеяться, но у нас ровно 1/2 админа. Иногда, когда мы задумываемся что будет если внезапно рухнет что-то инфраструктурно важное, нам становится страшновато) Хотя всякое бывало уже, но справлялись как то. Но не очень все это профессионально, но что делать - жизнь такая.
    Ах, да, самое главное спросить забыл. Какое соотношение аналитик - программист - тестер в ваших проектах?

    ОтветитьУдалить
  16. > Какое соотношение аналитик - программист - тестер в ваших проектах?


    Опять всегда разное, бывали проекты где программистов было меньшинство, бывали, что только 1 QA на 6 разработчиков.


    Можно сказать о каком-то среднем:
    - 1 аналитик
    - 1 QA
    - 3 разработчика

    ОтветитьУдалить
  17. А теперь вы будете смеяться. У нас 8 разработчиков и 1 тестер)

    ОтветитьУдалить
  18. Судя по моим наблюдениям, .Net отделы во многих компаниях развиваются быстрее других. Скажите, пожалуйста, свое мнение по этому поводу, перспективное ли это направление? В сравнении с разработкой под Android, например. Насколько может Windows Phone конкурировать с Android? Спасибо.

    ОтветитьУдалить
  19. .NET давно и прочно основался в корпоративных приложениях. Эта платформа преподается в университетах, MS ведет активную работу по снижению уровня вхождения в разработку. Я думаю, что направление достаточно перспективное.
    На счет мобильной платформы пока рано говорить. Android набрал неверноятно большую популярность, но и MS не будет бросать Windows Phone.

    ОтветитьУдалить
  20. EF 6 сам по себе работает хорошо в проекте, конкретно с NoTracking использовали ещё с 3м EF для построения отчётов. Правда там не было жёстких критериев по скорости и гибкости, поэтому к сожалению ничего полезного сообщить не могу.

    ОтветитьУдалить
  21. Спасибо, отличный стек технологий. А что можете сказать про SPA? Хотелось бы услышать ваше мнение насчет перспективности этого подхода. В своих новых проектах вы реализуете только SPA, или в определенных случаях отдаете предпочтение MPA?
    Наша команда последнее время активно использует подход написания клиентских SPA приложений, взаимодействуя с сервером по протоколу REST (WebApi), также мы остановили свой выбор на Angular.js в качестве клиентского MVW фреймворка.

    ОтветитьУдалить
  22. Я могу много сказать про SPA, но главное, что про SPA говорят заказчики и пользователи продуктов :) Для клиентов само собой, что если приходит сообщение или обновляются данные в аналитике, то никаких перегрузок страницы нет. Все пользуются Facebook, VK и twitter. Эти приложения приучивают пользователя к определенным сценариям работы с системой.


    Самый простой сценарий из последних: плеер в приложении, который должен играть музыку при "переходе между страницами". Конечно в этом случае никаких страниц на самом деле нет.


    Я думаю для текущих пользутелей, описанный вами подход самый действенный: SPA, WebApi и я бы добавил SignalR. Это становится еще более важным, когда нужно делать мобильные версии для ваших проектов.

    ОтветитьУдалить
  23. Нашел еще один "The Reactive Manifesto" http://www.reactivemanifesto.org

    ОтветитьУдалить
  24. Антон Окошкин23 марта 2014 г., 18:33

    Буду еще одним рекомендующим. Использовал в трех средних проектах (в связке с MSSQL) и одном крупном (в связке с ORACLE). Все в PRD. Подкупает в нем именно возможность работать на достаточно высоком уровне абстракции (с кучей плюшек: кэширование, настраиваемый маппинг, ...), но, в случае необходимости, спускаться до ADO и управления провайдерами.

    ОтветитьУдалить
  25. Манифест работы с людьми http://www.stratoplan.ru/manifesto/

    ОтветитьУдалить
  26. в nuget коллекции пакетов лежит пакет QueryBuilder. как думаете - имеет ли смысл совмещать с QueryObject и QueryBuilder ?

    ОтветитьУдалить
  27. Мы по-разному делаем в зависимости от ситуации. В последних проектах я совмещаю.

    ОтветитьУдалить
  28. Добрый день, прочитал вашу статью. Вопрос: она еще актуальна? Вы продолжаете использовать Dapper?

    ОтветитьУдалить
  29. Добрый день, Олег! Да, активно используем почти во всех проектах. БД у нас MSSQL и PostgreSQL.

    ОтветитьУдалить
  30. Может в таком случае нужно разделить классы, которые используются для маппинга из базы и другие объекты?

    ОтветитьУдалить