что такое операция паттерна
Что такое паттерны: двойная вершина и двойное дно и как они работают?
Трейдеры криптовалют позаимствовали весь арсенал инструментов технического анализа, который используется на традиционных рынках. Им не пришлось изобретать велосипед. Несмотря на то, что крипторынок все еще развивается и, следовательно, он очень волатилен, цены изменяются по тем же принципам, которые давно уже существуют. Поэтому двойная вершина и двойное дно, безусловно, должны быть известны каждому трейдеру.
Двойное дно и вершина могут точно показать разворот в направлении рынка, поэтому неудивительно, что они остаются популярными на всех рынках.
Начнем с того, что паттерн двойного дна (W-образная форма) является бычьим паттерном разворота на свечном графике, хотя он также может быть виден на диаграммах и даже линейных графиках. Его также называют зеркальным отражением паттерна двойной вершины (М-образная форма), который является медвежьим паттерном разворота.
Конечно, эти паттерны также могут быть связаны с психологией трейдеров, и они лучше всего подходят для промежуточного и долгосрочного анализа рынка. Но самое приятное заключается в том, что они исключительно хорошо работают для таких криптовалют, как биткоин и альткоины.
И все же, как их использовать в крипто торговле? Используются ли они на других рынках за пределами традиционного фондового рынка по-другому? Давайте разбираться.
Что такое двойное дно?
Паттерн двойного дна образуется, когда два ценовых дна расположены относительно на одном уровне, а вершина выступает в качестве сопротивления. Этот паттерн появляется в конце нисходящего тренда и сигнализирует о его развороте.
Как правило, трейдеры обычно ждут, когда цена пробьется выше линии выреза, чтобы открыть лонг позицию. Тем не менее, вы должны открывать её, только если вы в этом уверены. Потому что есть вероятность, что вы в конечном итоге будете торговать против тренда.
Главный принцип паттерна двойного дна заключается в том, что чем больше промежуток между двумя минимумами на графике, тем больше вероятность того, что паттерн графика сработает. Это также привело к тому, что этот индикатор технического анализа больше подходит для долгосрочных трейдов, поскольку он относится к паттернам, которые повторяются спустя какое-то время.
Тем не менее, есть ошибки, которых вы должны избегать, чтобы ваш анализ был более точен. Когда двойное дно используется правильно, получаются довольно впечатляющие результаты. Однако паттерн может сыграть не так, как нужно, если вы не будете осторожны. Итак, как они работают, и как вы вообще их находить?
Как найти паттерн двойное дно?
Найти двойное дно не так сложно, как только вы поймете основы. Это один из тех паттернов, который появляется регулярно. Двойное дно легко заметить, поэтому будет также легко понять его сигнал. Паттерн отличается тремя основными характеристиками:
• Первый минимум – это когда цена отскакивает назад в первый раз
• Второй минимум – это второй отскок цены
• Линия выреза – это временное сопротивление, которое образуется между минимумами.
Ниже представлена психология рынка за данным образованием:
• Первый минимум. Во время первого минимума рынок отскакивает и создает свинг-лоу. Вы можете подумать, что это обычная коррекция, проявляющаяся в нисходящем тренде.
• Линия выреза. Во время коррекции цена достигает точки сопротивления, а затем возвращается назад, чтобы снова протестировать вновь сформированную поддержку. Локальное сопротивление – это то, что мы называем линией выреза.
• Второй минимум. Медведи стремятся увидеть, обеспечивает ли первое дно достаточную поддержку. Если цена пробивается ниже первого минимума, паттерн не получится. Однако если вторая медвежья попытка потерпит неудачу вблизи поддержки, образованной первым минимумом, то мы увидим W на графике. Тем не менее, еще слишком рано выходить на рынок.
• Прорыв линии выреза. Как только рынок также отклоняет второй минимум, цена снова отскакивает. Если ему удастся пробиться выше линии выреза, которую мы ранее определили как сопротивление, то крипто трейдеры будут заинтересованы в том, чтобы открыть лонг, так как это знак того, что теперь быки контролируют ситуацию.
Вот и все! Так просто и легко работает паттерн двойное дно. Вот как он выглядит на графике:
Напомним, что паттерн двойного дна (W-образный) говорит нам о том, что существующий медвежий тренд, скорее всего заканчивается и цена вот-вот развернется.
Как использовать двойное дно?
Мы уже описали основной принцип действия, но есть еще кое-что, что нужно знать. Например, когда вы торгуете двойным дном, вы должны определить паттерны, в которых промежутки между минимумами больше. Такие паттерны, скорее всего, очень легко найти. Они увеличат шансы прорыва линии выреза и, следовательно, разворота.
Так как же это работает?
Техники на прорыве
В случае с торговлей с двойным дном большинство трейдеров входят в рынок сразу после прорыва цены выше линии выреза, но вы можете попробовать другой подход.
Вместо того чтобы ждать четкого прорыва, вы можете спокойно наблюдать за рынком – цена потенциально может развернуться вниз сразу после прорыва выше линии разрыва. Однако вам нужны бычьи признаки, а не колебания. Итак, вот как вы можете действовать:
• Найдите паттерн двойного дна
• Подождите, пока цена пробьется выше линии выреза
• Дождитесь отката – это может быть одна свеча из всего ряда
• Открывайте лонг, когда цена пробьет свинг-хай, который совпадает с линией выреза.
Другими словами, вы не должны спешить открывать ордер на покупку, когда цена пробивается выше линии выреза. Вместо этого стоит подождать, будет ли откат цены. Таким образом, вы убедитесь, что, когда вы войдете на рынок, быки будут значительно сильнее.
Когда использовать двойное дно?
Вы можете торговать двойным дном всякий раз, когда вы его замечаете, особенно когда существующий медвежий тренд достиг уровня перепроданности. Для этого вы можете использовать индикаторы технического анализа, такие как индекс относительной силы (RSI) или Стохастик.
Следует отметить, что эти два минимума не всегда могут находиться на одном уровне. Чаще всего второе дно может опуститься ниже, так как медведи стараются пробиться ниже предыдущего минимума. Но, если цене удается отскочить от второго минимума, паттерн остается в силе и заслуживает вашего внимания.
Пожалуйста, будьте имейте в виду, что иногда, когда появляется такой паттерн, медведи оказываются в ловушке, так как они открывают короткие позиции сразу после того, как цена пробивается ниже первого минимума. Это сигнал для быков, потому что медведи деморализуются, когда цена отскакивает назад.
Кроме того, когда второе дно ниже первого, имеет смысл проверить, не образует ли паттерн бычью дивергенцию с RSI, что станет для вас еще более сильным сигналом.
Что такое двойная вершина?
Двойная вершина – это медвежий разворотный паттерн, который сигнализирует об окончании восходящего тренда. Он образован двумя ценовыми максимумами, образующимися на одном уровне, и линией выреза, которая выступает в качестве локальной поддержки. Трейдеры будут ждать, пока цена пробьется ниже линии выреза, после чего они откроют шорт позиции.
Как найти паттерн двойная вершина?
Вы можете наблюдать двойные вершины довольно часто, хотя некоторые из них могут быть не идеальными. Рисунок состоит из трех основных элементов:
• Первый максимум – это когда цена отступает в первый раз;
• Второй максимум – это второй откат цены.
• Линия выреза – это временная поддержка, которая появляется между максимумами.
Как использовать двойные вершины?
Когда рынок достигнет уровня перекупленности, он может столкнуться с сопротивлением и сформировать паттерн двойной вершины. Он начинается с первого максимума, когда цена отступает до тех пор, пока не найдет локальную поддержку. В это время вы не можете обнаружить паттерн. После первой вершины цена откатывается назад до поддержки (линии выреза), а затем отскакивает назад, чтобы снова протестировать вновь сформированное сопротивление. Если цена не сможет пробиться выше него, она сформирует второй максимум. Именно тогда трейдеры настороженно относятся к тренду. Они должны быть готовы к открытию шорт позиции, когда цена пробьется ниже линии шеи.
Вы можете использовать те же техники на прорыве, что и в случае с двойным дном, но только наоборот.
Можно ли применять двойные дно и вершины в крипто торговле?
Определенно да! Эти два паттерна универсальны, и они хорошо работают на всех рынках, включая криптовалюту. Тем не менее, частота появления этих паттернов может быть ниже, чем, например, на рынке форекс. Однако они имеют одинаковую значимость, когда вы замечаете их на графике.
Трейдеры криптовалют очень полагаются на технический анализ, и графические паттерны могут давать самые мощные сигналы. Особенно так получается в сочетании с техническими индикаторами. Тем не менее, криптотрейдеры должны быть более осторожными, учитывая, что криптовалюты весьма волатильны и непредсказуемы.
Разница между двойным дном и двойной вершиной
Нет никакой фундаментальной разницы между двойной вершиной и двойным дном, за исключением того, что они являются полной противоположностью. Другими словами, то, что верно для быков в случае двойного дна, верно и для медведей в случае двойной вершины, поскольку последний является медвежьим сигналом разворота.
Двойная вершина состоит из двух максимумов, расположенных относительно на одном уровне, и выреза, который в это время представляет собой локальную поддержку.
При торговле криптовалютами на больших временных промежутках подход для каждого паттерна может отличаться, так как двойное дно должно появляться чаще, учитывая, что крипторынок стремится к расширению.
Преимущества и недостатки
Самое замечательное в этих двух паттернах то, что они эффективны на нескольких временных промежутках, будь то M15, H1, H4 или D1. Таким образом, ими могут пользоваться как дневные трейдеры, так и свинг трейдеры и даже позиционные трейдеры. Они также являются универсальными паттернами, которые хорошо работают с акциями, валютными парами, сырьевыми товарами и криптовалютами.
Как и любой другой технический паттерн, у них есть свои показатели, но они также имеют свои недостатки. Главный недостаток заключается в том, что ни двойная вершина, ни двойное дно не могут гарантировать закрепления вновь сформированного тренда. Например, в случае с двойным дном медведи могут толкнуть цены вниз в третий раз и даже попытаться пробиться ниже поддержки. Таким образом, трейдеры должны использовать такие инструменты управления рисками, как стоп-лосс.
Ошибки, которых стоит избегать
Одна из главных ошибок тех, кто торгует с двойным дном, заключается в том, что сразу после прорыва цены выше линии выреза паттерна они открывают лонг. В этом случае, если вы не будете осторожны, вы можете в конечном итоге торговать против более крупного тренда. Если рынок находится в середине сильного медвежьего движения и формирует «маленький» паттерн двойного дна, он, скорее всего, проигнорирует его и продолжит свой общий нисходящий тренд.
Чтобы избежать этого, вы должны добавить скользящую среднюю (MA) с периодом 20. Если цена находится ниже МА, вы не должны покупать на прорыве линии выреза. При торговле двойной вершиной цена не должна быть выше МА с периодом 20.
Итак, если вы будете следовать упомянутым правилам, вы, скорее всего, сможете достичь значительных результатов с этими паттернами, даже если вы новичок. Однако обязательно потренируйтесь на демо-счете, прежде чем торговать реальными средствами.
Попробуйте торговлю на демо-счете Bybit!
Управление рисками
Хотя двойная вершина и двойное дно являются одними из самых надежных моделей на графике, они не могут гарантировать разворот тренда во всех случаях. Чтобы избежать значительных потерь, которые могут повлиять на весь ваш баланс, вы должны применить некоторые основные методы снижения рисков.
Самый важный шаг – это выставить стоп-лосс, который уменьшит потенциальный убыток, если цена вдруг двинется против вас. Стоп-лосс должен быть установлен между прорывом (вырезом) и сопротивлением (в случае двойной вершины) или поддержкой (в случае двойного дна).
Чтобы способствовать стабильности и сосредоточиться на долгосрочных целях, вы не должны использовать более 1% своего баланса на один трейд. Это одно из золотых правил управления рисками.
Однако, если рынок волатилен, и вы испытываете искушение сорвать джекпот, на этот раз вам действительно может повезти, но вам не будет гарантирована такая же удача в долгосрочной перспективе, если такая практика превратится в привычку.
Заключение
Двойная вершина и двойное дно – это несколько удобных и надежных графических моделей, но их успех действительно зависит от вашей способности понимать их сигналы и использовать их для трейдов.
Чтобы улучшить свои торговые навыки с этими графическими моделями, вы можете попрактиковаться на демо-счете или на прошлых графиках. Не забывайте следить за техническими индикаторами, особенно за теми, которые измеряют уровни перекупленности и перепроданности.
26 основных паттернов микросервисной разработки
Несмотря на достоинства микросервисов, при их внедрении можно столкнуться с множеством проблем.
Изучение общих закономерностей в решении этих проблем привело к появлению паттернов микросервисной разработки (Microservices Patterns), или шаблонов проектирования микросервисов. Основная цель — предоставить проверенные временем решения для таких задач, как разработка микросервисной архитектуры, организация взаимодействия микросервисов друг с другом, клиентскими приложениями, базами данных, обеспечение их отказоустойчивости.
Рассмотрим несколько основных паттернов, разделив их на условные группы в зависимости от решаемой задачи.
Паттерны декомпозиции на микросервисы
Этот блок шаблонов предлагает решения для декомпозиции, то есть разделения приложений на микросервисы.
Один из наиболее известных способов разбиения на микросервисы — это определение бизнес-возможностей приложения и создание по одному микросервису на каждую из них. Бизнес-возможности представляют собой функции, которые будут доступны пользователям при работе с приложением.
Паттерн Decompose By Business Capability. Пример создания микросервисов на основе бизнес-возможностей для интернет-магазина
При разбиении по бизнес-возможностям могут появиться так называемые «божественные классы» (God Classes) — сущности, которые будут общими для нескольких микросервисов. Как правило, их очень сложно разделить.
Например, в приложении для интернет-магазина такой сущностью может стать заказ. В приведенном выше примере он используется сразу в нескольких сервисах: создание заказов (Orders Creation), доставка заказов (Orders Delivery), оповещения о заказах (Orders Alerts), предзаказы (Preorders).
Чтобы избежать появления God Classes, можно использовать альтернативный шаблон разложения на микросервисы — разбиение по поддоменам. Он основан на концепциях предметно-ориентированного проектирования (Domain-Driven Design, DDD).
DDD разбивает всю модель предметной области (домен) на поддомены. У каждого поддомена своя модель данных, область действия которой принято называть ограниченным контекстом (Bounded Context). Каждый микросервис будет разрабатываться внутри этого ограниченного контекста. Основная задача при использовании DDD-подхода — подобрать поддомены и границы между ними так, чтобы они были максимально независимы друг от друга.
Если вернуться к примеру с интернет-магазином, то все, что связано с заказами, можно рассматривать в рамках поддомена «Заказы» (Orders Subdomain) и именно внутри этого поддомена создавать микросервис по управлению заказами (Orders Service). Таким образом, можно сократить число микросервисов по сравнению с декомпозицией на основе бизнес-возможностей. В нашем сильно упрощенном примере четыре микросервиса были преобразованы в один.
Паттерн Decompose By Subdomain. Пример создания микросервисов на основе поддоменов для интернет-магазина: по сравнению с декомпозицией на основе бизнес-возможностей число микросервисов, так или иначе связанных с заказами, сокращено с 4 до 1
Паттерны рефакторинга для перехода на микросервисы
Эта группа шаблонов предназначена для организации взаимодействия с Legacy-приложениями и/или их постепенного перевода на микросервисную архитектуру.
Рассмотренные выше способы разбиения на микросервисы хорошо подходят для новых приложений, создаваемых с нуля. Однако на практике часто возникает необходимость перевести на микросервисную архитектуру уже существующие монолитные приложения. Разложение монолита на микросервисы требует времени и не может быть выполнено за одну итерацию. Поэтому и был разработан паттерн Strangler, названный по аналогии с лианой, которая постепенно душит обвиваемое ею дерево.
Этот шаблон означает миграцию монолитного приложения на микросервисную архитектуру путем постепенного переноса существующих функций в микросервисы. Настраивается маршрутизация запросов между устаревшим монолитом и микросервисами. Когда очередная функциональность переносится из монолита в микросервисы, фасад перехватывает клиентский запрос и направляет его к микросервисам. Новые функции при этом реализуются исключительно в микросервисах, минуя монолит. После переноса всех функций монолитное приложение полностью выводится из эксплуатации.
Паттерн не рекомендуется использовать при небольших размерах монолита. В таком случае лучшим решением будет его единовременный перевод на микросервисную архитектуру, так как добавление фасада увеличивает задержки и затрудняет тестирование.
При переводе Legacy-приложений на микросервисы рефакторинг некоторых подсистем может оказаться очень долгим либо вовсе невозможным. Но взаимодействовать с устаревшими подсистемами все равно нужно, несмотря на то, что в них, возможно, используются не самые современные технологии в части построения API, схем данных и так далее.
Для таких случаев отлично подходит паттерн Anti-Corruption Layer. Он предназначен для изолирования различных подсистем путем размещения между ними дополнительного уровня, который может быть реализован как компонент приложения или независимая служба. Этот уровень связывает две подсистемы, позволяя им оставаться максимально независимыми друг от друга. Он содержит всю логику, необходимую для передачи данных в обе стороны: при взаимодействии с каждой из подсистем используется именно ее модель данных.
Паттерн Anti-Corruption Layer
Паттерны управления данными в микросервисной архитектуре
Этот блок шаблонов описывает возможные варианты взаимодействия микросервисов с базами данных.
Основная рекомендация при переходе на микросервисы — предоставить каждому сервису собственное хранилище данных, чтобы не было сильных зависимостей на уровне данных. При этом имеется в виду именно логическое разделение данных, то есть микросервисы могут совместно использовать одну и ту же физическую базу данных, но в ней они должны взаимодействовать с отдельной схемой, коллекцией или таблицей.
Основанный на этих принципах паттерн Database Per Service повышает автономность микросервисов и уменьшает связь между командами, разрабатывающими отдельные сервисы.
У паттерна есть и недостатки: усложняется обмен данными между сервисами и предоставление транзакционных гарантий ACID. Паттерн не стоит применять в небольших приложениях — он предназначен для крупномасштабных проектов с большим числом микросервисов, где каждой команде требуется полное владение ресурсами для повышения скорости разработки и лучшего масштабирования.
Паттерн Database Per Service
Паттерну Database Per Service часто противопоставляют другой шаблон — Shared Database («Разделяемая база данных»). По сути, он представляет собой антипаттерн и подразумевает использование одного хранилища данных несколькими микросервисами. Его допускается использовать на начальных стадиях миграции на микросервисную архитектуру или в очень небольших приложениях, разрабатываемых одной командой (2–3 микросервиса).
Этот шаблон является одним из возможных вариантов получения данных из нескольких сервисов после применения к ним паттерна Database Per Service. Он предлагает создать отдельное API, которое будет вызывать необходимые сервисы, владеющие данными, и выполнять соединение полученных от них результатов в памяти. Паттерн можно рассматривать как вариант использования другого шаблона — API Gateway, о котором мы поговорим ниже.
API Composition — это самый простой способ получения данных из нескольких источников, но он может привести к неэффективному объединению больших наборов данных в памяти. Альтернативным решением является следующий шаблон CQRS.
Паттерн API Composition
Этот паттерн предлагает отделить изменение данных (Command) от чтения данных (Query). Шаблон CQRS имеет две формы: простую и расширенную.
В простой форме для чтения и записи используются отдельные модели ORM (Object-Relational Mapping), но общее хранилище данных.
Паттерн CQRS. Простая форма
В расширенной форме используются разные хранилища данных, оптимизированные для записи и чтения данных. Данные копируются из хранилища для записи в хранилище для чтения асинхронно. В результате хранилище для чтения отстает от хранилища для записи, но в конечном итоге является согласованным. Расширенный CQRS часто используется совместно с паттерном Event Sourcing, речь о котором идет далее.
Паттерн CQRS. Расширенная форма
Паттерн CQRS обеспечивает высокую доступность данных, независимое масштабирование систем чтения/записи и более быстрое чтение данных в микросервисах, управляемых событиями. Однако его использование увеличивает сложность системы и приводит к слабой согласованности данных. Паттерн подходит для сложных систем, где для чтения данных требуется запрос в несколько хранилищ или операции чтения и записи имеют разную нагрузку.
Приложения с микросервисной архитектурой часто используют асинхронные методы связи: сообщения или события. Для обеспечения атомарности операций в таких системах рекомендуется применять шаблон Event Sourcing.
В традиционных базах данных объект с текущим состоянием сохраняется напрямую. При использовании шаблона Event Sourcing вместо объектов сохраняются события, изменяющие их состояния. Итоговое состояние объекта можно получить путем повторной обработки серии событий, пришедших за определенное время. Различные службы могут воспроизводить события из хранилища событий, чтобы вычислить соответствующее состояние своих хранилищ данных. Для реализации хранилища событий обычно применяется шаблон CQRS.
Паттерн рекомендуется использовать в высокомасштабируемых транзакционных системах, управляемых событиями. Он не подходит для простых приложений, где микросервисы могут синхронно обмениваться данными (например, через API).
Паттерн Event Sourcing
Этот паттерн предназначен для управления распределенными транзакциями в микросервисной архитектуре, где применение традиционного протокола двухфазной фиксации транзакций (Two-phase commit protocol, 2PC) становится трудноосуществимым.
При использовании паттерна каждая локальная транзакция обновляет данные в хранилище в рамках одного микросервиса и публикует событие или сообщение, которые, в свою очередь, запускают следующую локальную транзакцию и так далее. Если локальная транзакция завершается с ошибкой, выполняется серия компенсирующих транзакций, которые отменяют изменения предыдущих транзакций.
Для координации транзакций существует два основных способа:
⠀
Использование шаблона обеспечивает согласованность транзакций в слабосвязанных распределенных системах, однако увеличивает сложность отладки. Saga отлично подходит для систем, управляемых событиями и/или использующих базы данных NoSQL без поддержки 2PC, но не рекомендуется при использовании баз данных SQL и в системах с циклическими зависимостями между сервисами.
Паттерны коммуникации микросервисов
Этот блок шаблонов охватывает способы внешних взаимодействий микросервисов: с клиентскими приложениями, удаленными сервисами и так далее.
Наиболее очевидный способ обращения к микросервисам — прямое обращение от клиента к сервису. И его вполне можно применять в небольших проектах. Однако в приложениях корпоративного масштаба с большим числом микросервисов рекомендуется использовать шаблон API Gateway.
Этот паттерн основан на применении шлюза, который находится между клиентским приложением и микросервисами, обеспечивая единую точку входа для клиента.
В зависимости от конкретной цели использования паттерна иногда выделяют следующие его разновидности:
Применение паттерна сокращает число вызовов, обеспечивает независимость клиента от протоколов, используемых в сервисах: REST, AMQP, gRPC и так далее, обеспечивает централизованное управление сквозной функциональностью. Однако шлюз может стать единой точкой отказа, требует тщательного мониторинга и при отсутствии масштабирования бывает узким местом системы.
Паттерн API Gateway
Этот паттерн является вариантом реализации шаблона API Gateway. Он также обеспечивает дополнительный уровень между микросервисами и клиентами, но вместо одной точки входа вводит несколько шлюзов для каждого типа клиента: Web, Mobile, Desktop и так далее.
С помощью паттерна можно добавить API, адаптированные к потребностям каждого клиента, избавившись от хранения большого количества ненужных настроек в одном месте. Но шаблон не стоит применять в тех случаях, когда разница в требованиях к API у разных типов клиентов незначительна либо приложение само по себе небольшое: это приведет лишь к дублированию кода и увеличению числа компонентов.
Паттерн Backends for Frontends
Паттерны построения пользовательского интерфейса
Эта группа шаблонов предлагает решения для отображения на одной странице или экране пользовательского интерфейса данных из нескольких микросервисов.
При использовании этого шаблона разметка HTML создается и обновляется непосредственно в браузере. Каждый экран/страница пользовательского интерфейса разбивается на фрагменты, данные для которых получают различные микросервисы. Каждый такой фрагмент, по сути, представляет собой мини-приложение, которое может отображать и обновлять свою разметку независимо от остальной части страницы.
Многие современные фреймворки, например AngularJS и ReactJS, помогают в реализации этого шаблона. Они используют принцип одностраничных приложений (Single-Page Application, SPA), позволяя обновлять отдельную область экрана, а не всю страницу целиком.
Паттерн Client-Side UI Composition
При использовании этого шаблона сборка фрагментов пользовательского интерфейса происходит на сервере, а клиентская часть получает уже полностью собранную страницу, благодаря чему достигается более высокая скорость загрузки. Сборка обычно выполняется отдельной службой, которая находится между браузером и серверами приложений: Nginx, Varnish, CDN.
Паттерн Server-Side Page Fragment Composition
Паттерны обнаружения сервисов в микросервисной архитектуре
Эта группа шаблонов описывает методы, которые могут использовать клиентские приложения для определения местонахождения нужных им сервисов. Это особенно важно в микросервисных приложениях, так как они работают в виртуализированных и контейнерных средах, где количество экземпляров сервисов и их расположение изменяются динамически.
Ключевым компонентом обнаружения микросервисов выступает реестр сервисов (Service Registry) — база данных с информацией о расположении сервисных экземпляров. Когда экземпляры запускаются и останавливаются, информация в реестре обновляется. Но взаимодействовать с реестром сервисов можно двумя путями, которые и легли в основу описанных ниже шаблонов.
Первый способ обнаружения сервисов — на стороне клиента. В этом случае сервисы и их клиенты напрямую взаимодействуют с реестром. Последовательность шагов следующая:
Ключевое преимущество обнаружения сервисов на стороне клиента — его независимость от используемой платформы развертывания. Например, если часть ваших сервисов развернута на K8s, а остальные работают в устаревшей среде, то обнаружение на уровне приложения будет лучшим вариантом, так как серверное решение на базе Kubernetes не будет совместимо со всеми сервисами.
К недостаткам подхода можно отнести необходимость использования различных клиентских библиотек для каждого языка программирования, а иногда и фреймворка. Кроме этого, на вашу команду ложится дополнительная нагрузка по настройке и обслуживанию реестра сервисов.
Паттерн Client-Side Service Discovery
Второй способ обнаружения сервисов — на стороне сервера. В этом случае за регистрацию, обнаружение сервисов и маршрутизацию запросов отвечает инфраструктура развертывания. Последовательность шагов следующая:
Все современные платформы развертывания, включая Docker, Kubernetes и другие, как правило, имеют встроенный реестр и механизмы обнаружения сервисов.
Основное преимущество паттерна состоит в том, что всеми аспектами обнаружения сервисов занимается сама платформа. Дополнительный код на стороне клиента или сервисов не требуется. Благодаря этому достигается независимость от используемых в приложении языков программирования и фреймворков.
Недостатком паттерна является невозможность его применения к сервисам, которые развернуты вне основной платформы, реализующей механизмы обнаружения. Несмотря на это ограничение, рекомендуется использовать обнаружение сервисов на стороне сервера всюду, где это осуществимо.
Паттерн Server-Side Service Discovery
Паттерны развертывания микросервисов
Этот блок шаблонов описывает возможные варианты развертывания разработанных микросервисов.
При переходе на микросервисную архитектуру рекомендуется проводить развертывание каждого экземпляра сервиса на собственном хосте (виртуальном или физическом). Паттерн Service Instance Per Host позволяет изолировать экземпляры сервисов друга от друга, избежать конфликтов версий и требований к ресурсам, максимально использовать ресурсы хоста, а также легче и быстрее проводить повторные развертывания. К недостаткам паттерна можно отнести потенциально менее эффективное использование ресурсов по сравнению с развертыванием нескольких экземпляров на хост.
Иногда выделяют разновидности описанного шаблона, наиболее часто используемые на практике: «Экземпляр сервиса на виртуальную машину» (Service Instance Per VM) и «Экземпляр сервиса на контейнер» (Service Instance Per Container). При их использовании каждый экземпляр сервиса упаковывается и разворачивается в виде отдельной виртуальной машины либо контейнера соответственно.
Паттерн Service Instance Per Host
Паттерн позволяет выполнить развертывание новых версий сервисов максимально незаметно для пользователей, сократив время простоя до минимума. Это достигается за счет запуска двух идентичных производственных сред — условно синего и зеленого цвета. Предположим, что синий — это существующий активный экземпляр, а зеленый — это новая версия приложения, развернутая параллельно с ним.
В любой момент времени только одна из сред является активной, и именно она обслуживает весь производственный трафик. После успешного развертывания новой версии — с прохождением всех тестов и так далее — трафик переключается на нее. В случае ошибок всегда можно вернуться к предыдущей версии.
Паттерн Blue-Green Deployment
Паттерны повышения отказоустойчивости
Эта группа шаблонов предназначена для повышения надежности приложений с микросервисной архитектурой.
При взаимодействии микросервисов не исключены ситуации, когда по какой-то причине один из сервисов перестает отвечать. Справиться с временными сбоями (медленное сетевое соединение, временная недоступность и так далее) помогают повторные вызовы. Однако при более серьезных сбоях, вызванных полным отказом сервиса, повторные вызовы будут лишь расходовать ресурсы.
В таких случаях рекомендуется использовать шаблон Circuit Breaker. Микросервис будет запрашивать другой микросервис через Proxy-сервер. Он подсчитывает количество недавних сбоев и на основе него определяет, разрешать ли выполнение последующих вызовов или немедленно возвращать исключение.
Proxy-сервер может находиться в трех состояниях:
Использование шаблона повышает отказоустойчивость и предотвращает каскадные сбои, но требует тщательной настройки и мониторинга.
Паттерн Circuit Breaker
Свое название паттерн получил благодаря переборкам, используемым в судостроении: они защищают корабль от полного затопления в случае повреждения отдельных его частей. Так же и в архитектуре приложения: переборки изолируют элементы приложения в пулы, чтобы в случае сбоя одного из них остальные продолжали функционировать.
Шаблон позволяет разделить ресурсы, чтобы гарантировать, что ресурсы, используемые для вызова одного сервиса, не влияют на ресурсы, используемые для вызова другого сервиса. Пример — использование отдельного пула соединений для каждого из нижестоящих сервисов.
Вариант применения паттерна Bulkhead — разделение ресурсов, например пула соединений, между сервисами
Еще один вариант использования шаблона — назначение каждому клиенту сервиса отдельного экземпляра сервиса. В таком случае, если один из клиентов сделает слишком много запросов, перегрузив свой экземпляр, другие клиенты смогут продолжить работу.
Вариант применения паттерна Bulkhead — назначение каждому клиенту отдельного экземпляра сервиса
Использование этого паттерна предотвращает каскадные сбои и изолирует критически важные ресурсы, но приводит к дополнительной сложности и менее эффективному использованию ресурсов.
Паттерны мониторинга микросервисов
Этот блок шаблонов охватывает возможные варианты построения мониторинга работы микросервисов.
Хорошей практикой при разработке микросервисов считается ведение логов каждым экземпляром сервиса. Логи могут содержать ошибки, предупреждения, информационные и отладочные сообщения. Но с увеличением числа сервисов анализ логов, разнесенных по различным хостам, становится затруднительным.
Паттерн Log Aggregation предлагает использовать централизованную службу ведения логов, которая будет собирать логи от каждого экземпляра сервиса. Это предоставит пользователям единую точку для поиска, анализа логов и настройки предупреждений, которые будут запускаться при появлении в них определенных сообщений.
Паттерн Log Aggregation
В микросервисной архитектуре для выполнения клиентских запросов может потребоваться работа нескольких взаимосвязанных микросервисов. Каждый сервис обрабатывает запрос путем выполнения одной или нескольких операций, включая обращение к базе данных, публикацию сообщений и так далее. С увеличением числа сервисов становится все сложнее отследить место возникновения ошибок.
Паттерн Distributed Tracing разработан для решения этой проблемы. Он предлагает назначать каждому внешнему запросу уникальный идентификатор (TraceId), который будет передаваться всем сервисам, участвующим в обработке запроса, и фиксироваться в журналах. Это позволит разработчикам видеть, как обрабатывается отдельный запрос, путем поиска в агрегированных журналах его внешнего идентификатора.
Паттерн Distributed Tracing
Иногда экземпляр сервиса, более не способный обрабатывать внешние запросы, остается доступен для других подсистем. Например, сервис может исчерпать пул соединений к базе данных — фактически он становится неработоспособным, но принимать внешние запросы по-прежнему в состоянии, хоть и без последующей корректной обработки. В таких случаях система мониторинга должна выдавать своевременное предупреждение, а балансировщик нагрузки, реестр служб и другие подсистемы не должны направлять запросы на отказавший экземпляр.
Для решения этой задачи предназначен паттерн Health Check. Он предлагает определить для каждого сервиса конечную точку, которую можно использовать для проверки работоспособности, например /health. Этот API должен проверять статус хоста, подключение к другим сервисам, инфраструктуре и любую иную бизнес-логику. Клиент — служба мониторинга, реестр служб или балансировщик нагрузки — будет периодически обращаться к конечной точке для проверки работоспособности экземпляра сервиса.
Паттерн Health Check
Прочие паттерны проектирования микросервисов
Здесь рассмотрим наиболее важные шаблоны из иных групп.
Приложениям и сервисам часто требуются общие функции, относящиеся к мониторингу, ведению журналов, настройкам безопасности, сетевым службам и так далее. Однако в микросервисной архитектуре отдельные сервисы могут быть построены с помощью различных языков и технологий — следовательно, они могут иметь свои зависимости и требовать определенных языковых библиотек. Паттерн Ambassador предлагает помещать клиентские фреймворки и библиотеки для решения периферийных задач внутрь вспомогательного сервиса, выступающего в роли Proxy между клиентским приложением или основным сервисом и прочими частями системы.
Применение паттерна Ambassador позволяет:
Так как добавление Proxy пусть и незначительно, но увеличивает сетевые задержки, шаблон Ambassador не рекомендуется использовать, когда время задержки критично. Также паттерн лучше не применять в случаях, когда можно обойтись стандартной клиентской библиотекой — например, если используется всего один язык или нет возможности выделить общие периферийные задачи.
Развернуть Proxy можно как демон или службу. Если основной сервис является контейнерным, Proxy также разворачивается как отдельный контейнер на том же хосте, для этой цели используется другой паттерн — Sidecar.
Паттерн Sidecar предлагает помещать периферийные задачи, связанные с мониторингом, безопасностью, отказоустойчивостью и так далее, в отдельный компонент и развертывать его внутри собственного процесса или контейнера. Так обеспечивается однородный интерфейс для сервисов основного приложения, которые могут быть написаны на разных языках.
Sidecar не обязательно является частью приложения, но связан с ним: для каждого экземпляра приложения рядом развертывается экземпляр Sidecar. Sidecar имеет тот же жизненный цикл, что и основное приложение.
Преимуществами паттерна являются независимость вспомогательного компонента от платформы основного приложения, возможность их доступа к одним и тем же ресурсам, минимизация задержек из-за их близкого расположения и возможность независимого обновления. К недостаткам можно отнести накладные расходы на создание дополнительного компонента. Шаблон не рекомендуется использовать для небольших приложений, а также в тех случаях, когда можно обойтись библиотеками и стандартными механизмами расширений.
Это один из стилей тестирования, который рекомендуют использовать в крупномасштабных проектах, где несколько команд работают над различными сервисами. Суть паттерна в том, что набор автоматизированных тестов для каждого сервиса (Provider Microservice) пишется разработчиками других сервисов (Consumer Microservice), вызывающих проверяемый сервис. Каждый такой набор тестов является контрактом, проверяющим, соответствует ли сервис провайдера ожиданиям потребителя. Сами тесты включают в себя запрос и ожидаемый ответ.
Паттерн Consumer-Driven Contract Testing увеличивает автономность команд и позволяет своевременно обнаруживать изменения в сервисах, написанных другими командами. Но его применение может потребовать дополнительной работы по интеграции тестов, так как команды могут пользоваться различными инструментами тестирования.
Паттерн Consumer-Driven Contract Testing
Практически все приложения во время работы используют разнообразные конфигурационные параметры: адреса служб, строки подключения к базам данных, учетные данные, пути к сертификатам и так далее. При этом параметры будут отличаться в зависимости от среды выполнения: Dev, Stage, Prod и так далее. Хранить конфигурации локально — в файлах, развертываемых вместе с приложением, — считается очень плохой практикой, особенно при переходе на микросервисы. Это приводит к серьезным рискам безопасности и требует повторного развертывания при каждом изменении конфигурационных параметров.
Поэтому в приложениях корпоративного уровня рекомендуется использовать шаблон External Configuration, предлагающий хранить все конфигурации во внешнем хранилище. В качестве такого хранилища может выступать облачная служба хранения, база данных или другая система.
В результате применения шаблона процесс сборки будет отделен от среды выполнения, а риски безопасности будут сведены к минимуму, так как конфигурации для производственной среды перестанут являться частью кодовой базы.
Паттерн External Configuration
Почему важно применять шаблоны проектирования в микросервисной архитектуре
При переходе на микросервисы предстоит принимать множество архитектурных решений, от которых будет зависеть эффективность итогового продукта. Знание и правильный выбор подходящих паттернов во многом упрощают и ускоряют этот процесс. Ведь всегда лучше полагаться на многолетний опыт других разработчиков, чем пытаться изобрести собственное решение с нуля.
Вот лишь некоторые преимущества, которых можно достичь, используя паттерны проектирования микросервисов: