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

В наших решениях мы используем интеграцию и с помощью Kafka, и с помощью gRPC, и с помощью RabbitMQ.

В этой статье мы поделимся нашим опытом кластеризации RabbitMQ, ноды которого размещены в Kubernetes.



До RabbitMQ версии 3.7 его кластеризация в K8S была не очень тривиальной задачей, со множеством хаков и не очень красивых решений. В версии 3.6 использовался autocluster плагин из RabbitMQ Community. А в 3.7 появился Kubernetes Peer Discovery Backend. Он встроен плагином в базовую поставку RabbitMQ и не требует отдельной сборки и установки.

Мы опишем итоговую конфигурацию целиком, попутно комментируя происходящее.

Всем привет!

Сегодня расскажем об опыте одного из наших DevOps проектов. Мы решили реализовать новое приложение под Linux с использованием .Net Core на микросервисной архитектуре.

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

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

Поэтому использовали такие технологии:

• .Net Core для реализации микросервисов. В нашем проекте использовалась версия 2.0,
• Kubernetes для оркестрации микросервисов,
• Docker для создания образов микросервисов,
• шина интеграции Rabbit MQ и Mass Transit,
• Elasticsearch и Kibana для логирования,
• TFS для реализации конвейера CI/CD.

В этой статье поделимся подробностями нашего решения.



Это расшифровка нашего выступления на .NET-митапе, вот ссылка на видео выступления.

В этой серии статей вы познакомитесь с основными принципами функционального программирования и поймёте, что значит «мыслить функционально» и как этот подход отличается от объектно-ориентированного или императивного программирования.

Эта статья является переводом справочного руководства по переносу приложений из ASP.NET в ASP.NET Core 2.0. Ссылка на оригинал

Содержание

1. Требования
2. Выбор Фреймворка
3. Различия в структуре проекта
4. Замена Global.asax
5. Хранение конфигураций
6. Встроенный механизм Dependency Injection
7. Работа со статическими файлами

Требования

• .NET Core 2.0.0 SDK или более поздняя версия.

Выбор фреймворка

Для работы с ASP.NET Core 2.0 проектом, разработчику предстоит сделать выбор – использовать .NET Core, .NET Framework или использовать сразу оба варианта. В качестве дополнительной информации можно использовать руководство Choosing between .NET Core and .NET Framework for server apps (вкратце можно сказать что .NET core является кроссплатформенной библиотекой, в отличие от .NET Framework) для того чтобы понять, какой Фреймворк для вас окажется наиболее предпочтительным.
После выбора нужного Фреймворка в проекте необходимо указать ссылки на пакеты NuGet.
Использование .NET Core позволяет устранить многочисленные явные ссылки на пакеты, благодаря объединенному пакету (мета пакету) ASP.NET Core 2.0. Так выглядит установка мета пакета Microsoft.AspNetCore.All в проект:

0. Вступление

Цель данной статьи собрать в небольшую кучку основную информацию, минимально достаточную для того, чтобы начать работать с докер на ежедневной основе и удалить с рабочей машины локально установленные apache, mysql, virtualenv, python3, mongodb, memchaced, redis, php5, php7 и весь остальной зоопарк, который мы используем при разработке, и который зачастую еще и конфликтует между собой от версии к версии.

Привет, Хабр! Меня зовут Виталий Котов, я работаю в Badoo в отделе QA, занимаюсь автоматизацией тестирования, а иногда и автоматизацией автоматизации тестирования.

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

Репозиторий является посредником между слоем доступа к данным и доменным слоем,
работая как in-memory коллекция доменных обектов. Клиенты создают декларативные
описания запросов и передают их в репозиторий для выполнения.
  — свободный перевод Мартина Фаулера

EntityFraemwork предоставляет нам готовую реализацию паттернов Repository: DbSet<T> и UnitOfWork: DbContext. Но мне часто приходится видеть, как коллеги используют в своих проектах собственную реализацию репозиториев поверх существующих в EntityFraemwork.

Чаще всего используется один из двух подходов:

1. Generic Repository как попытка абстрагироваться от конкретного ORM.
2. Repository как набор запросов к выбранной таблице БД (паттерн DAO).

И каждый из этих подходов содержит недостатки.

Этот пост будет не о том, как «перевести» код с C# на F#: различные парадигмы делают каждый из этих языков лучшим для своего круга задач. Однако вы сможете оценить все достоинства функционального программирования быстрее, если не будете думать о переводе кода из одной парадигмы в другую. Настало время любопытных, пытливых и готовых изучать совершенно новые вещи. Давайте начнем!

Все материалы из серии переводов русскоязычного сообщества F#-разработчиков вы сможете найти по тегу #fsharplangru.

Вот и подоспели материалы с фестиваля РИТ++ 2017. Мы выступили там с докладами по темам machine learning, front-end и mobile разработки и провели отдельный тематический блок, посвященный микросервисам. Под катом – видеозаписи выступлений на этой секции наших докладчиков и коллег из других компаний. Обязательно загляните, чтобы узнать о подходах к работе с микросервисами и интересных приемах, которые реально использовать для решения ваших задач.

nopCommerce – это движок для создания интернет-магазинов с открытым исходным кодом и написанный на ASP.NET MVC. Разрабатывается проект нашими соотечественниками из города Ярославль, и на сегодняйшний день на его основе работает более 20,000 сайтов, включая такие бренды как Volvo, Turkish Airlines, Reebok.


Несколько дней назад вышла новая версия продукта 3.70, в которой разработчики добавли полную поддержку Windows Azure. В предыдущих версий владельцы магазинов могли использовать только один instance в Azure, теперь же была добавлена поддержка нескольких. Следовательно, по сути этот функционал можно использовать на веб фермах. Это открываем нам отличные возможности для масштабирования приложения.

Предположим, что вы уже скачали (http://www.nopcommerce.com/downloads.aspx) и установили (http://docs.nopcommerce.com/display/nc/Installing+nopCommerce) nopCommerce в Azure. Итак, что же было сделано для поддержки Azure, и как все это настроить и включить:

Около года назад я написал небольшую статью про использование превью версии Azure сервиса диагностики и мониторинга Application Insights (AI). С тех пор в AI появилось очень много интересных дополнений. И вот, чуть больше месяца назад, AI наконец получил General Availability.

Наверно каждый WEB-разработчик когда-либо сталкивался с проблемой отслеживания события resize на странице. И если для window это сделать сможет любой новичок, то для остальных элементов эта задача принесет немало головной боли. Если вы относитесь к этой категории людей, то добро пожаловать под кат.

Лежим

Заказчик, чьи сайты я поддерживал ранее, обратился с тем, что сайт лежит и отдает 500 ошибку. У него стандартный сайт на ASP.NET WebForms, не скажу, что очень нагруженный, но бывали проблемы с производительностью базы данных (MS SQL Server на отдельном сервере). Недавно сервер БД поменяли и перенесли данные.

Этот сайт не основной бизнес заказчика, поэтому практически не обслуживался. У него не настроено никакого мониторинга  и сбора метрик и вообще за ним особо не следят.

Данные телеметрии

Какие аномалии бросились в глаза:

1. Процесс w3wp использовал более 50% CPU (обычно сильно меньше).
2. Количество потоков в этом процесс стабильно прирастало (сайт не успевал обслужить клиентов).
3. Диск на сервере БД использовался на 100% (Active Time).
4. Длина очереди обращений к диску с базами проекта была большой (обычно в районе нуля-единиц).
5. Оперативная память на сервер БД использована полностью.
6. Профайлер показал, что есть один горячий метод, который ходит в БД.

Приступая к выполнению задачи я рассчитывал на легкую прогулку в тени дубового парка, созерцая природу и предаваясь размышлениям… Однако позже стало понятно, что это будет тернистый и сложный поход сквозь горные реки с подводными камнями, обледеневшими скалами и глубокими пещерами.
Через медитации, борьбу со стихиями и собственной тупостью преодоление себя я, все таки, достиг желанной нирваны.

В этой статье я не только предоставлю готовый набор правил, но и постараюсь максимально доступно объяснить почему и как именно они работают.


Конкретно в моем случае, нужно было настроить роутер так, чтобы web-сервер в локальной сети за ним был доступен по IP любого из 3-х провайдеров.

Введение

Linq to Entity позволяет очень выразительно со статической проверкой типов писать сложные запросы. Но иногда надо нужно сделать запросы чуть динамичнее. Например, добавить сортировку, когда имя колонки задано строкой.
Т.е. написать что то вроде:

var query = from customer in context.Customers
    select customer;
//ошибка! не компилируется.
query = query.OrderBy("name");
var data = query.ToList();

На помощь в этом случае придет динамическое построение деревьев выражений (expression trees). Правда одних выражений будет недостаточно, потребуется динамически находить и конструировать шаблонные методы. Но и это не так сложно. Подробности ниже.

Делюсь списком полезных источников по Angular 2. Подойдут как для начинающих, так и для тех, кто имеет опыт работы с фреймворком.

Универсальная интеграция 3CX с любой CRM системой

Сегодня мы расскажем о том, как решить, пожалуй, самую актуальную проблему современной телефонии – интеграцию со сторонними информационными системами, прежде всего, CRM системами. Необходимо отметить, что сейчас существует много облачных сервисов телефонии, предлагающих, также, базовый функционал CRM. С другой стороны, многие производители CRM пытаются интегрировать базовые функции телефонии непосредственно в интерфейс пользователя. Также существуют готовые системы “два-в-одном”, в которых уже при проектировании закладывались коммуникационные возможности.

Одним словом, производители этих решений услышали требования пользователей и двигаются в правильном направлении. В целом, так оно и есть. Однако подход “два-в-одном” имеет ряд недостатков, самый главный из которых – неудовлетворительная гибкость. Согласитесь, создание функциональной системы объединенных коммуникаций и первоклассной CRM требует совершенно разных компетенций. В результате пользователь сталкивается либо с ограниченными коммуникационными возможностями, либо с бесполезной “обрезанной” CRM с неясными перспективами развития.

В системах, где CRM изначально объединена с телефонией, также существует ряд недостатков:

Сегодня мы хотим поговорить о сокровенном — у нас есть API.

Мы писали, а затем переписывали его заново на протяжении четырех лет. И за это время прошли почти все классические стадии “принятия неизбежного”. Кроме одной — четвертой. И хотим поделиться нажитыми непосильным трудом выводами, что делать и не делать, если вы решите делать свой “мощный эпиай”.



Процесс создания API uCoz иногда напоминал сюжет сериала The Knick («Больница Никербокер») — с неудачными операциями, кишками и экспериментами на живых людях.

Стадия первая – Отрицание

Здравствуйте, меня зовут Евгений, и я веб разработчик. Несколько лет назад мне перепала функция DBA (Database Administrator), я получил по этому поводу несколько сертификатов и решал соответствующие задачи. Я давно хотел описать задачу версионирования базы данных, но мне казалось, что для этого должны быть какие-то беспроигрышные варианты, которые хорошо знают умелые дяди, а я просто чего-то недопонимаю. Вчерашнее собеседование и последующий поиск по тематическим ресурсам показал, что это не так, и задача действительно сложна, актуальна и не решается однозначно. Разберём её по пунктам.

Что мы версионируем

Мы используем контроль версий только для DDL (Data Definition Language) запросов. Сами данные нас не интересуют. Почему? Рассмотрим два крайних случая.

1. Данных мало (скажем, менее 50 мегабайт). В этом случае, мы можем просто периодически делать полный дамп базы и смело складывать его в репозиторий.
2. Данных много (больше гигабайта). В этом случае версионирование нам мало поможет, всё равно разобраться в этом будет довольно проблематично. Целесообразно в данном случае использовать стандартную схему с бекапами и архив логом, которая позволяет нам получить целостную версию базы на любой момент во времени.

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

Хотелось разобраться, что вообще в себя включает процесс создания архитектуры программы, какие задачи при этом решаются, какие критерии используются (чтобы правила и принципы перестали быть всего лишь догмами, а стали бы понятны их логика и назначение). Тогда будет понятнее и какие инструменты лучше использовать в том или ином случае.

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.