В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Android Cloud... точнее Cloud из Android / Охрименко Алексей (Acronis)Ontico
Вы когда-нибудь плакали, открывая Amazon EC2 калькулятор? Мучились ли вы над тем, куда поставить сервер — на балкон или в кладовку? Готовились ли вы морально платить по 100-200 тысяч рублей за самый примитивный вариант сервера? Из этой ситуации есть выход и это — Android-планшеты :)
Как установить Linux на ваш Android-планшет, как развернуть LAMP, MEAN stack, сколько RPS могут выдать Android-планшеты, как хорошо они масштабируются, map/reduce, готовы ли Android-планшеты для production?
Все это и многое другое вы узнаете из этого доклада.
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)Ontico
В докладе рассмотрим нашу старую архитектуру пайплайна машинного обучения, обратим внимание на ее недостатки как с точки зрения инфраструктуры и автоматизации, так и с точки зрения настройки моделей машинного обучения и проведения экспериментов. Разберемся с архитектурой Apache Spark, и почему мы решили его использовать. Подробно ознакомимся с новой архитектурой нашего пайплайна и тем, как она позволила оптимизировать обнаружение и устранение проблем, ускорила и упростила работу data scientist'ов по проведению экспериментов и доведения их до продакшена. Также затронем вопросы написания тестов и процесса разработки ПО на больших данных.
Тестирование через мониторинг или холакратия на практике / Максим Чистяков (U...Ontico
Чтобы быстро двигаться, надо быстро двигаться :-)
Скоростная разработка продукта невозможна без непрекращающегося выкатывания свежих изменений в боевое окружение. Именно это позволяет Ultimate-Guitar оставаться #1 world's guitar service.
Когда-то давным-давно мы приняли для себя, что "мы движемся очень быстро и иногда из-за этого что-то ломаем. Недоставленный пользователям продукт/непроверенная гипотеза хуже, чем временная неработоспособность части сервиса. Поэтому мы убираем преграды между новым кодом и продакшном: не тратим время ни на тестирование, ни на строгий релиз-менеджмент".
Многие возникающие проблемы касаются только обслуживания (датацентр, OS, каналы) и мониторинг, естественно, необходим. Ну, а раз уж у нас есть мониторинг, то давайте считать систему единым целым, которая может выходить из строя по различным причинам, одной из которых является ошибка в коде. Это привело нас к идее использовать мониторинг вместо тестирования. К чему это привело, почему мы любим Anturis, Graylog, Grafana, что главное в деплое - это быстрый откат и другие прелести управления звездолётом Ultimate-Guitar с дневным населением больше Москвы на скорости 10 деплоев/час - обо всё этом пойдёт речь в этом докладе:
- Про скорость и цену быстрого развития (Innovation Costs).
- Холакратия в бранчах, "сам себе релиз-инженер", ответственность и честность.
- Скорость отката > скорость деплоя.
- Как умер QA или демоны с tail и Graylog.
- Когда не нужны микросервисы: успеть за 30 секунд, медленный Mercurial и шустрое комбо Git + Capistrano + Ansible.
- Бесполезные фичи, бритва Оккама и пользователи, которые на самом деле любят изменения :-)
Архитектура поиска в Booking.com / Иван Круглов (Booking.com)Ontico
Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента.
При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса.
В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем:
1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции;
2) сервис поиска по отелям и проверки их доступности (availability);
3) система предрасчета цен.
Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL.
Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.
Docker в работе: взгляд на его использование в Badoo через год / Турецкий Ант...Ontico
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
+ 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
+ Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
+ Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
+ Лучшее ли место для тестирования production? Путь образа от сборки до Production.
+ baDocker: webUI своими руками: зачем и почему?
+ Как дать возможность управлять запущенными сервисами и их версиями разработчику.
+ Docker: мониторинг и анализ работающих контейнеров.
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)Ontico
Unity3D - это внушительный набор средств для кроссплатформенной разработки игр и 3D-приложений. Однако ряд его особенностей может привести к внезапному падению производительности продукта на мобильных платформах.
Где же прячутся подводные камни? Как обеспечить оптимальный user experience на старом смартфоне? Каких "граблей" стоит избегать при написании кода и подготовке графики? Рассмотрим на примере RPG "Гильдия Героев" для Android и iOS.
WebGL многими воспринимается как API для "быстрого" рисования. Но на практике нередко случается, что решение на WebGL выходит медленным, иногда даже медленнее решений на других API.
В этом докладе мы попробуем взглянуть на проблемы производительности, встречающиеся в работе с WebGL, и их решения на примере движка Панорам Яндекс.Карт.
Aviasales: миграция поискового движка в docker / Дмитрий Кузьменков (Aviasales)Ontico
* Yasen (Yet Another Search Engine) – первоначальная архитектура поискового движка.
* Немного о старой схеме деплоя и её боли – buildbot, chef, git, monit, haproxy.
* Docker – простота и мощь в одной команде.
* Настраиваем запуск демона – что нужно знать.
* Dockerfile – проблемы и решения.
* Swarm, Kubernetes, Rancher – обзор вариантов оркестрации.
* Простой путь – docker-compose, и как его готовить.
* Разбираемся с сетью – bridge, host, overlay, macvlan, none.
* Root или не root в контейнере? Выбираем подходящее решение.
* Shared volumes и проблема права доступа к файлам.
* User namespaces – как и зачем?
* Docker и linux capabilities – добавляем безопасности.
* Нюансы ограничения ресурсов контейнеру: memory, cpu, swap.
* Stateful & Stateless в docker
* Автоматизация деплоя через docker-compose.
* Итоговая архитектура и процесс выкатки в production.
Виртуализированные сетевые сервисы на line rate в серверном окружении / Алекс...Ontico
Технологии NFV идут вперед и никого уже нельзя удивить тем, что сетевые сервисы вместо специализированного оборудования запускают на обычных серверах с хорошей пропускной способностью. Мир уже привык к тому, что на сервере можно обрабатывать 100 Гбит сетевого трафика. Однако эти числа характерны только тогда, когда запускают единственный сервис на сервере, например, только коммутацию пакетов (vSwitch), только NAT, только балансировку нагрузки и т.п. Сейчас же появляется потребность в запуске нескольких сервисов на одной машине, выстраивать сложные pipeline, которые учитывают различные сетевые функции, ACL, L2, L3, QoS, интегрированных с виртуальными машинами и контейнерами.
Для этого в сообществах разрабатываются более сложные фреймворки по обработке сетевых сервисов, которые позволяют разбивать задачи на этапы (stage) — каждый со своей сложностью и временем обработки, автоматически распределять такие этапы по вычислительным мощностям, планировать обработку пакетов так, чтобы увеличить суммарную пропускную способность.
В докладе будет представлен сравнительный обзор таких фреймворков: Intel DPDK Packet Framework, FD.io, Open Dataplane, Open Virtual Network (от проекта Open vSwtich). Будут представлены числовые характеристики и рекомендованные сценарии применения. Также будет освещена интеграция с системами виртуализации.
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
В этом докладе я в подробностях расскажу о том, как устроено хранение фотографий в нашей компании (всего около ~1 Пб).
Наша система была устроена достаточно просто — сами фотографии хранятся на SAN Storages, которые подключены через Fiber Channel к отдельной группе серверов, "*photos". На photos-серверах смонтированы разделы на соответствующих сетевых блочных устройствах, которые с точки зрения пользователя выглядят, как обычная файловая система.
Мы не используем никакие «хитрые» системы для хранения фотографий и не храним всё в одном файле — каждый размер каждой фотографии представляет из себя обычный файл на файловой системе ext3/4. Фотографии отдаются через nginx напрямую из файловой системы.
Такой способ хранения больших объемов данных весьма дешев, но приводил к проблемам, когда соответствующие SAN «падали», вплоть до повреждения файловой системы с потерей части данных пользователей.
Поэтому, для решения этой проблемы, а также проблем с производительностью, мы решили сделать «софтверную репликацию» фотографий с кешированием данных на SSD.
Также, в качестве эксперимента, мы решили попробовать ещё один способ — хранение на локальных дисках вместо использования SAN. По стоимости решение значительно дороже, но зато надежнее и проще в поддержке. Также, для обеспечения устойчивости к выходу из строя любой машины из такого кластера, мы решили сделать возможной балансировку всех поступающих запросов на весь кластер, то есть, в современных терминах, сделать «распределенное, отказоустойчивое, высокодоступное облачное хранилище».
Android Cloud... точнее Cloud из Android / Охрименко Алексей (Acronis)Ontico
Вы когда-нибудь плакали, открывая Amazon EC2 калькулятор? Мучились ли вы над тем, куда поставить сервер — на балкон или в кладовку? Готовились ли вы морально платить по 100-200 тысяч рублей за самый примитивный вариант сервера? Из этой ситуации есть выход и это — Android-планшеты :)
Как установить Linux на ваш Android-планшет, как развернуть LAMP, MEAN stack, сколько RPS могут выдать Android-планшеты, как хорошо они масштабируются, map/reduce, готовы ли Android-планшеты для production?
Все это и многое другое вы узнаете из этого доклада.
Пайплайн машинного обучения на Apache Spark / Павел Клеменков (Rambler&Co)Ontico
В докладе рассмотрим нашу старую архитектуру пайплайна машинного обучения, обратим внимание на ее недостатки как с точки зрения инфраструктуры и автоматизации, так и с точки зрения настройки моделей машинного обучения и проведения экспериментов. Разберемся с архитектурой Apache Spark, и почему мы решили его использовать. Подробно ознакомимся с новой архитектурой нашего пайплайна и тем, как она позволила оптимизировать обнаружение и устранение проблем, ускорила и упростила работу data scientist'ов по проведению экспериментов и доведения их до продакшена. Также затронем вопросы написания тестов и процесса разработки ПО на больших данных.
Тестирование через мониторинг или холакратия на практике / Максим Чистяков (U...Ontico
Чтобы быстро двигаться, надо быстро двигаться :-)
Скоростная разработка продукта невозможна без непрекращающегося выкатывания свежих изменений в боевое окружение. Именно это позволяет Ultimate-Guitar оставаться #1 world's guitar service.
Когда-то давным-давно мы приняли для себя, что "мы движемся очень быстро и иногда из-за этого что-то ломаем. Недоставленный пользователям продукт/непроверенная гипотеза хуже, чем временная неработоспособность части сервиса. Поэтому мы убираем преграды между новым кодом и продакшном: не тратим время ни на тестирование, ни на строгий релиз-менеджмент".
Многие возникающие проблемы касаются только обслуживания (датацентр, OS, каналы) и мониторинг, естественно, необходим. Ну, а раз уж у нас есть мониторинг, то давайте считать систему единым целым, которая может выходить из строя по различным причинам, одной из которых является ошибка в коде. Это привело нас к идее использовать мониторинг вместо тестирования. К чему это привело, почему мы любим Anturis, Graylog, Grafana, что главное в деплое - это быстрый откат и другие прелести управления звездолётом Ultimate-Guitar с дневным населением больше Москвы на скорости 10 деплоев/час - обо всё этом пойдёт речь в этом докладе:
- Про скорость и цену быстрого развития (Innovation Costs).
- Холакратия в бранчах, "сам себе релиз-инженер", ответственность и честность.
- Скорость отката > скорость деплоя.
- Как умер QA или демоны с tail и Graylog.
- Когда не нужны микросервисы: успеть за 30 секунд, медленный Mercurial и шустрое комбо Git + Capistrano + Ansible.
- Бесполезные фичи, бритва Оккама и пользователи, которые на самом деле любят изменения :-)
Архитектура поиска в Booking.com / Иван Круглов (Booking.com)Ontico
Booking.com - популярный сервис по онлайн-бронированию отелей. Поиск отеля, отвечающего заданным характеристикам - это неотъемлемая часть бизнес-модели и основной инструмент для клиента.
При постоянном росте компании вопросу производительности и масштабируемости поиска уделяется много внимания. В результате за время своего существования архитектура поиска претерпела несколько глобальных переделок, начиная от простой базы в MySQL до многокомпонентного распределенного сервиса.
В своей текущей реинкарнации поиск в Booking.com состоит их трех подсистем:
1) сервис auto-complete и устранения неоднозначности (disambiguation) в геопозиции;
2) сервис поиска по отелям и проверки их доступности (availability);
3) система предрасчета цен.
Первые две системы - это высокопроизводительные приложения, написанные на Java. Сервис поиска хранит свои индексы в in-memory хранилище, а данные - во встраиваемой базе данных RocksDB. Логика системы предрасчета цен написана на Perl, а в качестве хранилища используется MySQL.
Приходите на мой доклад, и я расскажу вам, как эволюционировал поиск вместе с ростом компании. Мы подробно рассмотрим текущую архитектуру, и почему мы решили ее сделать именно такой. Ну и, конечно, с какими проблемами нам пришлось бороться и как мы это делали.
Docker в работе: взгляд на его использование в Badoo через год / Турецкий Ант...Ontico
Мы в Badoo используем Docker больше года и на нашем примере попробуем поговорить о возможных моделях его применения.
+ 85% наших сервисов работают в контейнерах: для чего и почему мы перенесли свои сервисы в контейнеры.
+ Как мы подходим к сборке образов? Базовый образ: используем слои, следим за системными обновлениями.
+ Автоматизация процесса сборки образов с нашими сервисами: Jira flow, Teamcity и другие страшные для админа слова.
+ Лучшее ли место для тестирования production? Путь образа от сборки до Production.
+ baDocker: webUI своими руками: зачем и почему?
+ Как дать возможность управлять запущенными сервисами и их версиями разработчику.
+ Docker: мониторинг и анализ работающих контейнеров.
OpenResty: превращаем NGINX в полноценный сервер приложений / Владимир Прота...Ontico
Все мы знаем, что NGINX – отличный прокси, который может качественно и эффективно распределять нагрузку между бэкендами и фильтровать запросы по определенным условиям. Но при этом часто на практике возникают задачи, которые не решаются его декларативной моделью описания конфигурации: иногда для принятия решения нам нужно сходить в базу данных (в Redis или даже в MySQL), другой сервис или произвести какую-то более сложную обработку запроса/ответа. Именно здесь к нам на помощь приходит мощь Lua и OpenResty.
Из доклада вы узнаете:
* зачем нам Lua внутри NGINX, и почему из седьмого айфона убрали разъем под наушники;
* в каких ситуациях NGINX в паре с Lua справятся с задачей лучше вашего любимого PHP/NodeJS/Ruby/Python/Visual Basic и о прелестях асинхронного ввода-вывода без callback'ов;
* как залезть к NGINX под капот, используя только высокоуровневый язык;
* при чем здесь Openresty, или как упростить себе жизнь;
* примеры бизнес-кейсов: от "умного" прокси до самостоятельного веб-приложения;
* как оно ведет себя в продакшне под большой нагрузкой.
Производительность Unity3D: подводные камни / Алексей Чубарь (BIT.GAMES)Ontico
Unity3D - это внушительный набор средств для кроссплатформенной разработки игр и 3D-приложений. Однако ряд его особенностей может привести к внезапному падению производительности продукта на мобильных платформах.
Где же прячутся подводные камни? Как обеспечить оптимальный user experience на старом смартфоне? Каких "граблей" стоит избегать при написании кода и подготовке графики? Рассмотрим на примере RPG "Гильдия Героев" для Android и iOS.
WebGL многими воспринимается как API для "быстрого" рисования. Но на практике нередко случается, что решение на WebGL выходит медленным, иногда даже медленнее решений на других API.
В этом докладе мы попробуем взглянуть на проблемы производительности, встречающиеся в работе с WebGL, и их решения на примере движка Панорам Яндекс.Карт.
Aviasales: миграция поискового движка в docker / Дмитрий Кузьменков (Aviasales)Ontico
* Yasen (Yet Another Search Engine) – первоначальная архитектура поискового движка.
* Немного о старой схеме деплоя и её боли – buildbot, chef, git, monit, haproxy.
* Docker – простота и мощь в одной команде.
* Настраиваем запуск демона – что нужно знать.
* Dockerfile – проблемы и решения.
* Swarm, Kubernetes, Rancher – обзор вариантов оркестрации.
* Простой путь – docker-compose, и как его готовить.
* Разбираемся с сетью – bridge, host, overlay, macvlan, none.
* Root или не root в контейнере? Выбираем подходящее решение.
* Shared volumes и проблема права доступа к файлам.
* User namespaces – как и зачем?
* Docker и linux capabilities – добавляем безопасности.
* Нюансы ограничения ресурсов контейнеру: memory, cpu, swap.
* Stateful & Stateless в docker
* Автоматизация деплоя через docker-compose.
* Итоговая архитектура и процесс выкатки в production.
Виртуализированные сетевые сервисы на line rate в серверном окружении / Алекс...Ontico
Технологии NFV идут вперед и никого уже нельзя удивить тем, что сетевые сервисы вместо специализированного оборудования запускают на обычных серверах с хорошей пропускной способностью. Мир уже привык к тому, что на сервере можно обрабатывать 100 Гбит сетевого трафика. Однако эти числа характерны только тогда, когда запускают единственный сервис на сервере, например, только коммутацию пакетов (vSwitch), только NAT, только балансировку нагрузки и т.п. Сейчас же появляется потребность в запуске нескольких сервисов на одной машине, выстраивать сложные pipeline, которые учитывают различные сетевые функции, ACL, L2, L3, QoS, интегрированных с виртуальными машинами и контейнерами.
Для этого в сообществах разрабатываются более сложные фреймворки по обработке сетевых сервисов, которые позволяют разбивать задачи на этапы (stage) — каждый со своей сложностью и временем обработки, автоматически распределять такие этапы по вычислительным мощностям, планировать обработку пакетов так, чтобы увеличить суммарную пропускную способность.
В докладе будет представлен сравнительный обзор таких фреймворков: Intel DPDK Packet Framework, FD.io, Open Dataplane, Open Virtual Network (от проекта Open vSwtich). Будут представлены числовые характеристики и рекомендованные сценарии применения. Также будет освещена интеграция с системами виртуализации.
Микросервисы: опыт использования в нагруженном проекте / Вадим Мадисон (М-Тех)Ontico
Мы прошли довольно большой путь в разработке через микросервисы.
Начинали разработку, когда это за рубежом только входило в тренд. По сути, не было никакой информации о том, как это делать правильно и, вообще, стоит ли это делать. Не было понятно, имеем ли мы дело с очередной модной штукой, или парадигма действительно решает часть проблем, характерных для больших нагруженных проектов.
Мы прошли путь от того, когда 100 микросервисов казалось много ... Сейчас цифры в 1000, 2000 кажутся чем-то обыденным.
В ходе доклада я постараюсь сделать упор на эксплуатацию системы, работающей на микросервисах. Расскажу, какой инструментарий показал себя хорошо на больших объемах, а от какого пришлось отказаться. Покажу на примерах, как эволюционировала наша система управления конфигурацией системы в целом и отдельными сервисами. Расскажу, как корректно предоставлять API сервиса и правильно поставлять его клиентские библиотеки, чтобы избегать внутренних и искусственных зависимостей. Покажу, как мы работаем с распределенными сервисами и обеспечиваем отказоустойчивость.
Разгоняем ASP.NET Core / Илья Вербицкий (WebStoating s.r.o.)Ontico
HighLoad++ 2017
Зал «Рио-де-Жанейро», 8 ноября, 18:00
Тезисы:
http://www.highload.ru/2017/abstracts/2905.html
Прошло более года с того момента, как Microsoft выпустила первую версию своего нового фреймворка для разработки web-приложений ASP.NET Core, и с каждым днем он находит все больше поклонников. ASP.NET Core базируется на платформе .NET Core, кроссплатформенной версии платформы .NET c открытым исходным кодом. Теперь у С#-разработчиков появилась возможность использовать Mac в качестве среды разработки, и запускать приложения на Linux или внутри Docker-контейнеров.
...
Андрей Карпов, Приватные байки от разработчиков анализатора кодаSergey Platonov
Доклад о редких нестандартных расширениях языка С++, про которые никто не знает, но которые надо поддерживать в анализаторе кода.
О магии Visual C++ с файлом stdafx.h, когда проект компилируется, хотя не должен. О том как зародился viva64 (предшественник PVS-Studio) для поиска 64-битных проблем. Как и почему исчез анализ кода, который одно время существовал в компиляторе Intel C++.
Статический анализ кода: борьба с удорожанием ошибокAndrey Karpov
Нет смысла говорить, что "надо писать код без ошибок". Ошибки были, есть и будут. Все хорошо понимают, что ошибки следует исправлять. Люди забывают, что ошибка должна быть исправлена с минимальными временными и денежными затратами!
ORM технологии в .NET (Nhibernate, Linq To SQL, Entity Framework)Pavel Tsukanov
Расскажу зачем они вообще нужны. Пройдемся по технологиям и промоем им косточки. Рассмотрим достоинства и недостатки, а также где и когда лучше всего применять ту или иную ORM.
4. ReSharper
• Тысячи анализов и инспекций
• Сотни рефакторингов
• Крутые навигация и поиск
• Форматирование и чистка кода
• Кодогенерация на все случаи
• C#, VB.NET, ASP.NET, JS
• Сотни тысяч пользователей
6. Project Rider = +
Windows
Mac OS
Linux
Первые 90% продукта было готово до официального начала разработки.
И вообще, мы уже 15 лет этот продукт пишем.
7. Kotlin
• Java interoperability
• Null safety
• Unchecked exceptions
• Extension functions
• Operator overloading
• String interpolation
• Zero-overhead lambdas
• Pattern matching
• Smart casts Можно писать в старом Java-стиле
Можно писать в новом функциональном стиле
Можно легко делать DSL
10. Как это работает
*И не забыть про порядок
Пользователь Frontend (IDEA) Backend (R#)
Alt+Enter Запускаем “Alt+Enter” Action
Готовим список действий
Создаём ViewModel
Отправка
Alt+Enter
Показываем
Popup
Inline Variable
Отправка
Inline Variable Запускаем “Inline” Action
Меняем документ
Формируем Changes
Показываем
новый документ
Но вот только всё это работает в 10 потоков, а порядок иногда лучше бы сохранять.
11. Дедупликация строк
Flag=0 Len=5 H E L L O
Flag=1 ID=#1 Len=5 R I D E R
Flag=2 ID=#1
Len=5 H E L L O
Было:
Стало:
Проблема:
По протоколу летает
много строк
Решение:
Дедупликация
Обыкновенная строчка (95%)
Дедуплицируем строчку (5%)
(Вероятностная)
Пересылаем только ID
13. R# на Mono: Проблемы, Часть 1
• COM & WPF
Хозяйке на заметку
COM и WPF как-то не очень
работают на Linux и MacOS.
Их нужно выпилить,
но при этом не сломать R#.
14. R# на Mono: Проблемы, Часть 2
• Unmanaged code
Хозяйке на заметку
Если структура не blittable,
то MS.NET и Mono могут
создавать разный
memory layout
15. R# на Mono: Проблемы, Часть 3
• rn vs n
Хозяйке на заметку
R# использует rn, а IDEA — n
А ещё, был у нас Python-скрипт,
в конце строк которого оказывались r,
а в строках были пути,
вот и собирай после этого под
Windows…
16. R# на Mono: Проблемы, Часть 4
• XBuild ≠ MSBuild
Хозяйке на заметку
XBuild при чтении csproj любит
заменять обратные слеши на
прямые.
Остерегайтесь регулярных
выражений прямо в csproj!
17. R# на Mono: Очень много проблем
• ParseFloatLiteral и неожиданный вызов внутри
OleAut32Dll.VarR8FromStr
• Ограничение на длину имени файла в UnzipFileInfo
new StringBuilder(128) → new StringBuilder(1024)
• Пустой AppDomainSetup.ConfigurationFile
"Could not allocate -6 bytes"
• Guid.NewGuid внутри финалайзеров
RNGCryptoServiceProvider из-за которого вешался AppDomain
Поэтому у нас своё Mono с блекджеком и шлю
18. CLR vs JVM: Примитивные типы
Тип CLR JVM
Guid MS GUID Structure RFC 4122
Int Short Short
Byte Byte Byte Byte Byte Byte Byte Byte
Byte Byte Byte Byte Byte Byte Byte Byte
Byte Byte Byte Byte Byte Byte Byte Byte
19. CLR vs JVM: Примитивные типы
Тип CLR JVM
Guid MS GUID Structure RFC 4122
Date 00:00:00 January 1, 0001 A.D.
1 tick = 100ns
00:00:00 January 1, 1970 A.D.
1 tick = 1ms
Int Short Short
Byte Byte Byte Byte Byte Byte Byte Byte
Byte Byte Byte Byte Byte Byte Byte Byte
Byte Byte Byte Byte Byte Byte Byte Byte
20. CLR vs JVM: Примитивные типы
Тип CLR JVM
Guid MS GUID Structure RFC 4122
Date 00:00:00 January 1, 0001 A.D.
1 tick = 100ns
00:00:00 January 1, 1970 A.D.
1 tick = 1ms
Byte [0..255] [-128..127]
Int Short Short
Byte Byte Byte Byte Byte Byte Byte Byte
Byte Byte Byte Byte Byte Byte Byte Byte
Byte Byte Byte Byte Byte Byte Byte Byte
21. CLR vs JVM: Примитивные типы
Тип CLR JVM
Guid MS GUID Structure RFC 4122
Date 00:00:00 January 1, 0001 A.D.
1 tick = 100ns
00:00:00 January 1, 1970 A.D.
1 tick = 1ms
Byte [0..255] [-128..127]
Uri > new Uri("http://code/ fest")
http://code/ fest
> URI("http://code/ fest")
java.net.URISyntaxException:
Illegal character
Int Short Short
Byte Byte Byte Byte Byte Byte Byte Byte
Byte Byte Byte Byte Byte Byte Byte Byte
Byte Byte Byte Byte Byte Byte Byte Byte
