В последнее время у нас в компании сформировался вектор развития, который мы хотим расширять и дальше. Основные направления, с которыми мы работаем:
- Высоконагруженные приложения
- Облачная инфраструктура (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, но в целом используются похожий набор инструментов.
Дальнейшее развитие
В перспективе мы планируем заниматься проектами еще сложнее и масштабнее, чтобы рост каждого члена команды повышал уровень компании в целом.
Интересными вещами занимаетесь. Может ещё используете активно в проектах CQRS & ES? А как на счёт найма удалённых сотрудников?
ОтветитьУдалитьАрхитектурно и CQRS, и ES используем в разных комбинациях. Каждый проекте по-своему уникален и для него подбираются (либо формируются эволюционным путем) разлиные дизайны.
ОтветитьУдалитьС удаленной работой у нас не получается, так как я очень ценю хорошую коммуникацию внутри команды. Под каждый проект формируется команда, которая садится в _отдельный_ кабинет, чтобы они постоянно общались.
"1000 операция в секунду, задержка в обработке ... не более 1 секунды"
ОтветитьУдалитьКакие подходы используете для подобного быстродействия? Сам на настолько масштабных проектах не работал, поэтому очень интересно как решаются подобные задачи.
Спасибо за информацию. Всегда интересно читать о внутреннем устройстве высоконагруженных приложений.
ОтветитьУдалитьТам на самом деле много нюансов было, но я не уверен, что NDA позволяет их открывать
ОтветитьУдалитьТебе серьезно нравится Half-Arsed Agile Manifesto? Это больше похоже на стеб над agile. Как иначе назвать, когда каждый принцип выворачивается наизнанку дополнением мелким шрифтом.
ОтветитьУдалитьЧтобы понять почему так сделали, предлагаю прочитать http://xprogramming.com/articles/beyond-agile-new-principles
ОтветитьУдалитьMANIFESTO FOR MINIMALIST SOFTWARE ENGINEERS
ОтветитьУдалитьhttp://minifesto.org/
Интересно. Рад что есть компании которые предпочитают расти интенсивно, а не экстенсивно. В провинциальных российских IT компаниях принято останавливаться в развитии,освоив пару технологий (обычно PHP+MySql), и начинать расширять клиентскую базу, беря на себя реализацию все большего и большего однотипных, простеньких проектов. Здорово что у вас не так. Но к вашим технологиям есть пара вопросов.
ОтветитьУдалитьВопрос один. В описаниях проектов я не нашел у вас следов использования серверов кеширования (Redis, Memcache), хранящих часто используемые данные в оперативной памяти. Почему вы не считаете нужным кешировать часто используемую информацию? Я читал, что для ускорения вы активно используете денормализацию и фанатично отлаживаете каждый запрос к БД, но, по моему опыту, денормализация снимает лишь часть проблем. У нас в проекте имена пользователей это часто используемая информация, которая требуется почти в каждом клиентском представлении. Join средствами БД использовать мы не можем из-за требований по горизонтальному масштабированию, денормализировать базу дублируя имена пользователей в каждой требуемой для работы таблице мы не можем, так как в случае смены имени пользователя количество update ко всем таблицам будет просто космическим. Единственное быстро работающее решение - это хранить имена пользователей в кеше (мы используем Redis). Как решаются подобные нюансы у вас?
И второй вопрос. У вас в технологиях есть MQ сервера. Пользуетесь ли вы уже готовыми абстракциями для работы с ними или пишите код сами?
> Почему вы не считаете нужным кешировать часто используемую информацию?... Как решаются подобные нюансы у вас?
ОтветитьУдалитьКэширование используется там, где это необходимо. Например, мы активно используем memcached, как на своих серверах, так и в облаке.
В описании проекта я перечислил ключевые библиотеки, если составить полный список, то он будет довольно длинным :)
> MQ сервера. Пользуетесь ли вы уже готовыми абстракциями для работы с ними или пишите код сами?
Каждая реализация MQ предоставляет свои провайдеры для работы. В RabbitMQ например можно использовать как низкоуровневое API, так и библиотку типа EasyNetQ. В основном используем высокоуровневое API, но есть случаи, когда переходим и на более низкий уровень.
Один из таких случаев - работа с очередью через CLR-процедуру в MSSQL 2008. Там поддерживается .NET 2.0 и ниже, поэтому EasyNetQ не работает. В этом случае пишем обвязку сами.
С другими реализациями MQ (Azure, AWS и др.) такая же история.
Я вас понял. Но под абстракциями я имел в виду не библиотеки для подключения, а абстракции более высокого уровня, практически полностью скрывающие детали работы с MQ сервером. Например, реализации паттерна ServiceBus, имеющие в виде транспорта MQ-сервер. NServiceBus для MSMQ или MassTransit для RabbitMQ.
ОтветитьУдалить> под абстракциями я имел в виду не библиотеки для подключения, а абстракции более высокого уровня
ОтветитьУдалитьВсё, понял. Делать абстракцию или нет зависит от проекта и его дальнейшего развития. У нас бывает и так и так.
Ну отлично. Но попользовавшись MassTransit-ом желание работать с RabbitMq сервером напрямую у меня отпало насовсем, и, даже если мне придется писать EventSource Hello World, лично я буду использовать MT. Но я понимаю, что есть случаи (например тот, который вы описали комментом выше) что иногда приходится работать напрямую.
ОтветитьУдалитьНу и последний вопрос. У вас (как и у нас впрочем) из технологий зоопарк. И как ваши администраторы администрируют все это? Мы, например, чтобы снизить расходы на адмиинистрирование, были вынуждены отказаться от использования MongoDb, и нам теперь приходится хранить данные в реляционной БД, пусть мы и храним их в nosql стиле.
Вы будете смеяться, но у нас есть только один администратор на все проекты и инфраструктуру компании :) Программисты сами стараются заботиться о настройке и поддержке проектов. Особенно мало проблем доставляет работа в облаках.
ОтветитьУдалитьВы тоже будете смеяться, но у нас ровно 1/2 админа. Иногда, когда мы задумываемся что будет если внезапно рухнет что-то инфраструктурно важное, нам становится страшновато) Хотя всякое бывало уже, но справлялись как то. Но не очень все это профессионально, но что делать - жизнь такая.
ОтветитьУдалитьАх, да, самое главное спросить забыл. Какое соотношение аналитик - программист - тестер в ваших проектах?
> Какое соотношение аналитик - программист - тестер в ваших проектах?
ОтветитьУдалитьОпять всегда разное, бывали проекты где программистов было меньшинство, бывали, что только 1 QA на 6 разработчиков.
Можно сказать о каком-то среднем:
- 1 аналитик
- 1 QA
- 3 разработчика
А теперь вы будете смеяться. У нас 8 разработчиков и 1 тестер)
ОтветитьУдалитьСудя по моим наблюдениям, .Net отделы во многих компаниях развиваются быстрее других. Скажите, пожалуйста, свое мнение по этому поводу, перспективное ли это направление? В сравнении с разработкой под Android, например. Насколько может Windows Phone конкурировать с Android? Спасибо.
ОтветитьУдалить.NET давно и прочно основался в корпоративных приложениях. Эта платформа преподается в университетах, MS ведет активную работу по снижению уровня вхождения в разработку. Я думаю, что направление достаточно перспективное.
ОтветитьУдалитьНа счет мобильной платформы пока рано говорить. Android набрал неверноятно большую популярность, но и MS не будет бросать Windows Phone.
EF 6 сам по себе работает хорошо в проекте, конкретно с NoTracking использовали ещё с 3м EF для построения отчётов. Правда там не было жёстких критериев по скорости и гибкости, поэтому к сожалению ничего полезного сообщить не могу.
ОтветитьУдалитьСпасибо, отличный стек технологий. А что можете сказать про SPA? Хотелось бы услышать ваше мнение насчет перспективности этого подхода. В своих новых проектах вы реализуете только SPA, или в определенных случаях отдаете предпочтение MPA?
ОтветитьУдалитьНаша команда последнее время активно использует подход написания клиентских SPA приложений, взаимодействуя с сервером по протоколу REST (WebApi), также мы остановили свой выбор на Angular.js в качестве клиентского MVW фреймворка.
Я могу много сказать про SPA, но главное, что про SPA говорят заказчики и пользователи продуктов :) Для клиентов само собой, что если приходит сообщение или обновляются данные в аналитике, то никаких перегрузок страницы нет. Все пользуются Facebook, VK и twitter. Эти приложения приучивают пользователя к определенным сценариям работы с системой.
ОтветитьУдалитьСамый простой сценарий из последних: плеер в приложении, который должен играть музыку при "переходе между страницами". Конечно в этом случае никаких страниц на самом деле нет.
Я думаю для текущих пользутелей, описанный вами подход самый действенный: SPA, WebApi и я бы добавил SignalR. Это становится еще более важным, когда нужно делать мобильные версии для ваших проектов.
Нашел еще один "The Reactive Manifesto" http://www.reactivemanifesto.org
ОтветитьУдалитьБуду еще одним рекомендующим. Использовал в трех средних проектах (в связке с MSSQL) и одном крупном (в связке с ORACLE). Все в PRD. Подкупает в нем именно возможность работать на достаточно высоком уровне абстракции (с кучей плюшек: кэширование, настраиваемый маппинг, ...), но, в случае необходимости, спускаться до ADO и управления провайдерами.
ОтветитьУдалитьМанифест работы с людьми http://www.stratoplan.ru/manifesto/
ОтветитьУдалитьв nuget коллекции пакетов лежит пакет QueryBuilder. как думаете - имеет ли смысл совмещать с QueryObject и QueryBuilder ?
ОтветитьУдалитьМы по-разному делаем в зависимости от ситуации. В последних проектах я совмещаю.
ОтветитьУдалитьДобрый день, прочитал вашу статью. Вопрос: она еще актуальна? Вы продолжаете использовать Dapper?
ОтветитьУдалитьДобрый день, Олег! Да, активно используем почти во всех проектах. БД у нас MSSQL и PostgreSQL.
ОтветитьУдалитьМожет в таком случае нужно разделить классы, которые используются для маппинга из базы и другие объекты?
ОтветитьУдалить