Pull to refresh
0
0
Александр @var1ap

.Net

Send message

Blue-Green Deployment на минималках

Reading time15 min
Views45K

В этой статье мы с помощью bash, ssh, docker и nginx организуем бесшовную выкладку веб-приложения. Blue-green deployment — это техника, позволяющая мгновенно обновлять приложение, не отклоняя ни одного запроса. Она является одной из стратегий zero downtime deployment и лучше всего подходит для приложений, у которых один инстанс, но есть возможность загрузить рядом второй, готовый к работе инстанс.


Допустим, у Вас есть веб-приложение, с которым активно работает множество клиентов, и ему совершенно никак нельзя на пару секунд прилечь. А Вам очень нужно выкатить обновление библиотеки, фикс бага или новую крутую фичу. В обычной ситуации, потребуется остановить приложение, заменить его и снова запустить. В случае докера, можно сначала заменить, потом перезапустить, но всё равно будет период, в котором запросы к приложению не обработаются, ведь обычно приложению требуется некоторое время на первоначальную загрузку. А если оно запустится, но окажется неработоспособным? Вот такая задача, давайте её решать минимальными средствами и максимально элегантно.


Disclaimer: Большая часть статьи представлена в экспериментальном формате — в виде записи консольной сессии. Надеюсь, это будет не очень сложно воспринимать, и этот код сам себя документирует в достаточном объёме. Для атмосферности, представьте, что это не просто кодсниппеты, а бумага из "железного" телетайпа.


Читать дальше →
Total votes 14: ↑13 and ↓1+15
Comments36

Обновление базы данных и zero-downtime deployment

Reading time4 min
Views9.5K
Про обновление систем «на лету» без их остановки (zero-downtime deployment) написано немало статей и многие аспекты этого подхода является достаточно очевидными. На мой взгляд, наиболее сложная часть деплоймента в этом случае — обновление хранилищ данных, в случае если их контракт (схема) изменился. Именно этот аспект я бы и хотел рассмотреть в этой статье.
Читать дальше →
Total votes 12: ↑11 and ↓1+10
Comments6

Распределенное логирование и трассировка для микросервисов

Reading time18 min
Views27K
Логирование — важная часть любого приложения. Любая система логирования проходит три основных шага эволюции. Первый — вывод на консоль, второй — запись логов в файл и появление фреймворка для структурированного логирования, и третий — распределенное логирование или сбор логов различных сервисов в единый центр.

Если логирование хорошо организовано, то позволяет понимать, что, когда и как идет не так, как задумано, и передавать нужную информацию людям, которым предстоит эти ошибки исправлять. Для системы, в которой каждую секунду отправляется 100 тысяч сообщений в 10 дата-центрах на 190 стран, а 350 инженеров каждый день что-то деплоят, система логирования особенно важна.



Иван Летенко — тимлид и разработчик в Infobip. Чтобы решить проблему централизованной обработки и трассировки логов в микросервисной архитектуре при таких огромных нагрузках, в компании пробовали различные комбинации стека ELK, Graylog, Neo4j и MongoDB. В итоге, спустя много грабель, написали свой лог-сервис на Elasticsearch, а как БД для дополнительной информации взяли PostgreSQL.

Под катом подробно, с примерами и графиками: архитектура и эволюция системы, грабли, логирование и трассировка, метрики и мониторинг, практика работы с кластерами Elasticsearch и их администрирования в условиях ограниченных ресурсов.
Total votes 38: ↑37 and ↓1+36
Comments3

Domain-driven design: рецепт для прагматика

Reading time21 min
Views71K

Почему к DDD обычно подходят не с той стороны? А с какой стороны надо? Какое отношение ко всему этому имеют жирафы и утконосы?

Специально для Хабра — текстовая расшифровка доклада «Domain-driven design: рецепт для прагматика». Доклад был сделан на .NET-конференции DotNext, но может пригодиться не только дотнетчикам, а всем интересующимся DDD (мы верим, вы осилите пару примеров кода на C#). Видеозапись доклада также прилагается.
Total votes 45: ↑44 and ↓1+43
Comments29

Async/await в C#: концепция, внутреннее устройство, полезные приемы

Reading time24 min
Views229K
Доброго времени суток. В этот раз поговорим на тему, в которой начинал разбираться каждый уважающий себя адепт языка C# — асинхронное программирование с использованием Task или, в простонародье, async/await. Microsoft проделали хорошую работу — ведь для того, чтобы использовать асинхронность в большинстве случаев нужно лишь знание синтаксиса и никаких других подробностей. Но если лезть вглубь, тема довольно объемная и сложная. Ее излагали многие, каждый в своем стиле. Есть очень много классных статей по этой теме, но все равно существует масса заблуждений вокруг нее. Постараемся исправить положение и разжевать материал настолько, насколько это возможно, не жертвуя ни глубиной, ни пониманием.


Читать дальше →
Total votes 34: ↑32 and ↓2+30
Comments27

Параллелизм против многопоточности против асинхронного программирования: разъяснение

Reading time4 min
Views140K
Хочу представить вашему вниманию перевод статьи Concurrency vs Multi-threading vs Asynchronous Programming: Explained.

В последние время, я выступал на мероприятиях и отвечал на вопрос аудитории между моими выступлениями о Асинхронном программировании, я обнаружил что некоторые люди путали многопоточное и асинхронное программирование, а некоторые говорили, что это одно и тоже. Итак, я решил разъяснить эти термины и добавить еще одно понятие Параллелизм. Здесь есть две концепции и обе они совершенно разные, первая синхронное и асинхронное программирование и вторая – однопоточные и многопоточные приложения. Каждая программная модель (синхронная или асинхронная) может работать в однопоточной и многопоточной среде. Давайте обсудим их подробно.
Читать дальше →
Total votes 35: ↑24 and ↓11+13
Comments59

CQRS. Факты и заблуждения

Reading time10 min
Views195K

CQRS — это стиль архитектуры, в котором операции чтения отделены от операций записи. Подход сформулировал Грег Янг на основе принципа CQS, предложенного Бертраном Мейером. Чаще всего (но не всегда) CQRS реализуется в ограниченных контекстах (bounded context) приложений, проектируемых на основе DDD. Одна из естественных причин развития CQRS — не симметричное распределение нагрузки и сложности бизнес-логики на read и write — подсистемы Большинство бизнес-правил и сложных проверок находится во write — подсистеме. При этом читают данные зачастую в разы чаще, чем изменяют.

Не смотря на простоту концепции, детали реализации CQRS могут значительно отличаться. И это именно тот случай, когда дьявол кроется в деталях.
Читать дальше →
Total votes 31: ↑30 and ↓1+29
Comments108

Распределенная трассировка запросов в .NET

Reading time20 min
Views19K


В любой системе возникает задача понять, как взаимодействуют компоненты между собой. Особенно важно это в распределённых системах. Как понять, какие компоненты обработали запрос, сколько времени это заняло, какой был порядок обработки. Всё это можно узнать, но нужно добавить немного инфраструктуры.

Егор Гришечко — работал разработчиком в компании Insolar. Команда Егора делает полностью распределенную систему, и поэтому они сталкиваются с большинством проблем, которые присущи распределенным системам. Сейчас Егор трудится в Uber и занимается разработкой инфраструктуры.

Под катом — текстовая расшифровка и видео доклада Егора с конференции DotNext 2019 Moscow. Доклад будет полезен разработчикам микросервисных систем, которые смогут для себя открыть эти технологии. А также будет интересен бэкенд-разработчикам, интересующимся метриками и мониторингом.
Total votes 27: ↑27 and ↓0+27
Comments3

А ваша служба является RESTful? Все что необходимо/обязательно знать про веб службы и REST

Reading time18 min
Views150K

Введение


Вот не люблю я изобретать велосипед и статью я бы эту не написал, но пришлось. Про REST сказано уже довольно много. Многие поставщики веб служб готовы клясться, что их службы являются RESTful. Во время собеседования вы точно услышите хотя бы несколько вопросов про REST, независимо от того это собеседования для бэкенд, мобайл или фронтенд разработчика. Я вот помню как-то во время одного собеседования меня задали такой вопрос: «Вот вы написали в своем резюме, что знайте REST․ Ответьте пожалуйста, какой HTTP код вы получите, если при запросе к RESTful сервису ресурс не найден?». Ответ 404 был принят единогласно. Если честно, я так и не понял, как этот вопрос помог понять знаю ли я REST или нет, но одно могу уверенно сказать: REST понимают далеко не все. Вот некоторые вопросы, которые мучали меня долгое время:

  1. Зачем REST стал таким трендовым? Это архитектура была же предложена еще в 2000 году?
  2. Что я получу если моя служба будет RESTful?
  3. Как определить является ли служба RESTful или нет?
  4. Как правильно должны создаваться URL REST служб?
  5. Какие http методы и коды должны быть использованы в RESTful службе?

Если вы не можете дать исчерпывающего ответа хотя бы на один из этих вопросов, то продолжайте чтение. Если вы можете однозначно ответить на все эти вопросы, можете привести формат правильного URL, считайте, что GET, POST, PUT, DELETE обязательно должны соответствовать CRUD операциям с ресурсами, то вам обязательно надо продолжать чтение.
Читать дальше →
Total votes 43: ↑37 and ↓6+31
Comments125

Как готовить Cake, используя только Frosting

Reading time4 min
Views4K

Итак, Cake. Многие слышали, многие хотели попробовать, но откладывали. Конечно, если ты все время работал на TeamCity или на Jenkins и продолжаешь, то зачем переизобретать то, что уже отлично работает? Люби свою жизнь и радуйся. Но вот, допустим, в твоей любимой жизни появился новый проект, новый дедлайн, минимум сторипойнтов до релиза, а опыта с новым сборщиком нет? Мне в этом случае и пригодился Cake.

Я сразу оговорюсь, что эта статья не подтолкнет сразу на использование Cake, как меня, и многих моих коллег не подтолкнули статьи, которые выходили ранее. По большей части потому что на него нет смысла переходить в проекте, который не приносит боль и который работает стабильно. Собираете в своем любимом Jenkins и все идет нормально. Но пусть после этой статьи в голове отложится, что Cake существует. Он в очередной раз никуда не делся, он умеет уже многое и работать с ним все проще. Гораздо проще, чем было раньше.

На что похож Cake? Наверное, любой разработчик, не погрязший в мире .Net, найдет свою аналогию: gradle, gulp, golang make. Make-системы не откровение в 2020 году. Это всегда было удобно, а значит — нужно и правильно. Мир .Net долгое время был обделен такими средствами. Фактически был и есть до сих пор MSBuild, но у него есть очень-очень много недостатков. Основной - кто вообще умеет им пользоваться из рядовых разработчиков? И какова целесообразность его освоения? Какие-то базовые и нужные всем вещи явно проще делать на билд-сервере. Наверное, кому-то он и удобен, но я уверен, что значимая часть коммьюнити предпочтет MSBuild'у освоить новый билд-сервер. Один раз написать конфиг и забыть как страшный сон.

А что если бы существовала make-система с DSL на C#, автокомплитом и прочими фишками типизированного языка? Да, я про Cake. В частности сейчас пойдет разговор про библиотеку Cake.Frosting, являющуюся одним из раннеров make-системы.

Подробней про доступные раннеры можно прочитать тут: Cake Runners

С Frosting все привычно — самодокументирующийся Api с которым почти сразу находишь общий язык. Методы расширения, загружаемые из Nuget — на любой случай жизни, структура проекта, похожая на смесь тестов или бенчмарков и хоста Asp. Все решения угадываются сразу, все как дома.

Читать далее
Total votes 7: ↑7 and ↓0+7
Comments12

Учимся проектировать на основе предметной области (DDD: Domain Driven Design)

Reading time8 min
Views219K

1. Введение



В данной статье я хотел бы рассказать об этих трёх буквах, постоянно находящихся на слуху, но для многих являющихся тайной за семью печатями, а так же привести ряд ресурсов, с которыми неплохо было бы познакомиться при желании продолжить развитие в проектировании на основе предметной области (DDD: Domain Driven Design).


Читать дальше →
Total votes 66: ↑54 and ↓12+42
Comments25

Information

Rating
Does not participate
Location
Калининград (Кенигсберг), Калининградская обл., Россия
Registered
Activity