Микросервисы *

И снова здравствуйте. Несколько дней назад началось обучение в новой группе по курсу «Архитектор ПО», а сегодня мы хотели бы поделиться статьей, которую написал один из студентов курса — Плешаков Антон (руководитель направления разработки в компании «Программная логистика» и co-founder в Clusterra).

---

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

Важно также отметить, что на текущий момент очень важным фактором, влияющим на выбор стратегии разработки в пользу микросервисов, является — наличие всевозможных готовых инфраструктурных решений, берущих на себя решение проблем, связанных с дополнительными издержками на эксплуатацию распределенной системы. Речь идет о системах контейнерной оркестрации, service mash, средствах распределенной трассировки, мониторинга, логирования и прочее прочее. Можно смело утверждать что большинство факторов, ранее упоминавшихся как минусы микросервисного подхода, на сегодняшний день не имеют такого большого влияния, как пару лет назад.

Привет, Хабр! Представляю вашему вниманию авторский перевод статьи Microservices – Combinatorial Explosion of Versions.

Во времена когда мир IT постепенно переходит на микросервисы и инструменты вроде Kubernetes, все более заметной становится лишь одна проблема. Эта проблема — комбинаторный взрыв версий микросервисов. Все же IT сообщество полагает, что сегодняшняя ситуация значительно лучше, чем «Dependency hell» предыдущего поколения технологий. Тем не менее, управление версиями микросервисов весьма сложная проблема. Одним из доказательств этому могут служить статьи вроде «Верните мне мой монолит».

Привет, Хабр! В Монолите весь код должен быть в едином стиле, a в разных микросервисах можно использовать разные подходы, языки программирования и фреймворки. Для простых микросервисов с 1 — 2 контроллерами и 1 — 10 действиями особо смысла городить слои абстракций нет. Для сложных микросервисов с различными состояниями и логикой перехода между ними наоборот лучше изначально не лениться. Я хочу рассказать о моем опыте организации кода и использования подходов DDD, Портов и Адаптеров для обоих случаев. Есть кратко суть статьи: Джун — пишет код в контроллере. Мидл — пишет кучу абстракций. Сеньор — знает когда нужно писать код в контроллере, а когда нужны абстракции.

Перевод статьи подготовлен специально для студентов курса «Архитектор высоких нагрузок».

---

Введение

Преимущества AWS, такие как высокая доступность, масштабируемость и эластичность, уже доказали свою эффективность для SaaS-провайдеров (Software-as-a-Service). При модернизации SaaS-приложений, AWS помогает плавно перейти на микросервисную архитектуру с предоставлением API-доступа внешним приложениям.

Инструменты управления API, такие как Amazon API Gateway — это естественный выбор для предоставления безопасного и масштабируемого внешнего API. Однако, при переводе своих приложений в облака, SaaS-провайдеры часто сталкиваются с необходимостью быстрого развертывания своих сервисов для нескольких разных клиентов. И, конечно, со специфическими требованиями каждого из них.

API Gateway помогает в создании мультитенантной микросервисной архитектуры. В такой архитектуре для обслуживания разных клиентов используется один экземпляр микросервиса, что позволяет более оптимально использовать ресурсы и оптимизировать затраты. В такой конфигурации для обслуживания своих клиентов от провайдеров требуется поддержка “white-label”-доменов, а также возможность идентификации клиентского домена для привязки специфичной бизнес-логики к конкретному клиенту в бэкенде.

В этой статье рассказывается об эталонной архитектуре, которая позволяет использовать API Gateway как единую точку входа для веб-приложений и микросервисов, основанных на API, с несколькими внешними клиентами, используя для каждого из них разные поддомены.

И снова здравствуйте! В преддверии старта курса «Архитектор ПО» подготовили перевод еще одного интересного материала.

---

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

И снова здравствуйте. Как вы знаете, в марте OTUS запускает абсолютно новый курс «Архитектура и шаблоны проектирования». В преддверии старта курса перевели для вас большой материал про Создание масштабируемой и отказоустойчивой архитектуры с помощью динамических микросервисов. Приятного прочтения!

---

Аннотация

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

И снова здравствуйте. В марте OTUS запускает очередной поток курса «Архитектор ПО». В преддверии старта курса подготовили для вас перевод полезного материала.

---

Последнее время получают распространение событийно-ориентированные архитектуры (event-driven architectures) и, в частности, Event Sourcing (порождение событий). Эта вызвано стремлением к созданию устойчивых и масштабируемых модульных систем. В этом контексте довольно часто используется термин “микросервисы”. На мой взгляд, микросервисы — это всего лишь один из способов реализации “ограниченного контекста” (Bounded Context). Очень важно правильно определить границы модулей и в этом помогает стратегическое проектирование (Strategic Design), описанное Эриком Эвансом в Domain Driven Design. Оно помогает вам идентифицировать / обнаружить модули, границы (“ограниченный контекст”) и описать, как эти контексты связаны друг с другом (карта контекстов, ContextMap).

В ИТ редко встретишь человека, который не слышал о микросервисах. В интернете и на профильных сайтах на эту тему есть масса статей, которые в целом хорошо объясняют отличия между монолитом и, собственно, микросервисами. Неискушенный разработчик Java, прочитав статьи из разряда «Что такое микросервисы для web-приложений и с чем их едят», преисполняется радости и уверенности, что вот теперь-то всё станет замечательно. Ведь главная цель — «попилить» монструозный монолит (конечный артефакт, который, как правило, представляет собой war/ear файл), выполняющий кучу всего, на ряд отдельно живущих сервисов, каждый из которых будет выполнять строго определённую, относящуюся только к нему функцию, и будет делать это хорошо. В дополнение к этому идёт горизонтальная масштабируемость — просто делай scaling соответствующих узлов, и всё будет здорово. Пришло больше пользователей или требуется больше мощностей — просто добавил 5–10 новых инстансов сервисов. Грубо говоря, в целом так это и работает, но, как известно, дьявол кроется в деталях, и то, что изначально казалось довольно простым, при более внимательном рассмотрении может обернуться проблемами, которые первоначально в расчёт никто не брал.

В этом посте своим опытом о том, как дебажить микросервисы для web делятся коллеги из практики Java компании «Рексофт».

Сегодня из пустых пивных банок и старых покрышек мы соберём телеграм-бота для такси. С его помощью можно будет вызывать такси нажатием всего лишь двух кнопок. Вернее так: при первом использовании потребуется нажать три кнопки, а затем всегда — только две. Код написан на Node.js (т.е. ECMAScript, aka JavaScript), без использование каких-либо бот-фреймворков или бот-библиотек — только натуральный продукт — Telegram Bot API. Количество кода указано в названии статьи, выполняется он в Яндекс.Облаке, а точнее в Cloud Functions, а состояния и данные хранятся в Firebase, вернее в Cloud Firestore. Ну а заявки на такси наш скромный бот отправляет в CRM Битрикс24. Как видите — задействованы все! На самого бота можно посмотреть на комиксах ниже, а кликнув по картинке-ссылке под комиксами — открыть и проверить в деле.

Прим. перев.: Эта статья — перевод недавнего анонса из мира контейнеров. В прошлом месяце компания Docker объявила о передаче своей очередной разработки в руки более широкого Open Source-сообщества. Речь шла об инструменте конвертации метаданных CNAB-пакета в формат стандарта OCI (Open Container Initiative) — для удобной возможности распространения содержимого таких пакетов в реестрах для контейнеров (вроде Docker Registry). Но чтобы получше во всём этом разобраться, мы начнём с перевода другой заметки (написанной Jack Wallen для The New Stack) — о том, что вообще такое CNAB.

Что такое CNAB и почему он важен для экосистемы cloud native?

Cloud Native Application Bundle (CNAB) — открытая спецификация, цель которой — упростить упаковку, установку контейнеризированных приложений и управление ими. С помощью таких пакетов пользователи могут определять ресурсы, которые затем разворачиваются в различных runtime-средах, таких как Docker, Azure, Kubernetes, Helm, службы автоматизации (например, используемые в GitOps) и т.д.

Queue (очередь) — структура данных на диске или в оперативной памяти, которая хранит ссылки на сообщения и отдает их копии consumers (потребителям). Queue представляет собой Erlang-процесс с состоянием (где могут кэшироваться и сами сообщения). 1 тысяча очередей может занимать порядка 80Mb.

Binding (привязка) — правило, которое сообщает обменнику в какую из очередей должны попадать сообщения.

Докер под Windows — это постоянные приключения. То ему нужно обновить операционку, иначе последние версии не ставятся, то он забывает, как подключаться к сети. В общем, каждый день от него новости. «Поставил и забыл» — это не про Docker Desktop for Windows. Особенно, когда он используется не совсем так, как рекомендуют его разработчики. А они почему-то не одобряют подключение внешних windows сетевых дисков в качестве локальных. И совсем не одобряют доступ к к таким сетевым папкам, которые расположены ещё и на host машине. Пишут, что это ужас-ужас с точки зрения безопасности, требуют всяких ключей типа:

cap_add:
- SYS_ADMIN
- DAC_READ_SEARCH

для работы команды mount в контейнере и прочая, и прочая.

Привет, я Юрий Буйлов, занимаюсь разработкой в CarPrice, а также внедряю практики DevOps, микросервисы и Kubernetes. Хочу рассказать про Kubernetes в духе пиратства — только не про управление большим красивым кораблем на парусах, а, скорее, про флот маленьких неприглядных рыбацких лодочек, местами ржавых, но очень быстрых, шустрых и опасных.

Будет интересно тем, кто разрабатывает или переводит инфраструктуру на микросервисы, внедряет DevOps поверх Kubernetes и всячески идет в cloud native. Расскажу про наш путь, в конце статьи поделюсь нашими наработками окружения для микросервисов — дам ссылку на шаблон, который будет удобен для разработчиков и тестировщиков.

Эта статья — по видео выступления на конференции @Kubernetes Conference by Mail.ru Cloud Solutions, если не хотите читать, можно посмотреть.

Привет, Хабр!

Это третья часть в серии статей "Учимся разворачивать микросервисы", и сегодня речь пойдет о Helm 3. В прошлой части мы создали Kubernetes конфигурацию для учебного проекта из 2 микросервисов (бекенда и шлюза) и задеплоили все это в Google Kubernetes Engine. В этой статье мы напишем Helm-чарт для нашей системы, создадим для него репозиторий на основе GitHub Pages и задеплоим проект в GKE с помощью Helm.

GraphQL — это язык запросов к API, разработанный Facebook. В этой статье будет рассмотрен пример реализации GraphQL API на JVM, в частности, с использованием языка Kotlin и фреймворка Micronaut; большая часть примеров может быть переиспользована на других Java/Kotlin фреймворках. Затем будет показано как объединить несколько GraphQL сервисов в единый граф данных, чтобы предоставить общий интерфейс доступа ко всем источникам данных. Это реализовано с использованием Apollo Server и Apollo Federation. В итоге будет получена следующая архитектура:

Это вольный пересказ моего Lightning Talk с конференции Joker 2019. С тех пор вышло несколько новых версий Quarkus, доклад приведен в соответствие с текущим положением вещей.

В рамках разработки нашего фреймворка CUBA Platform, мы уделяем много внимания тому, что происходит в индустрии. Хотя фреймворк CUBA выстроен вокруг Spring, нельзя игнорировать то, что происходит вокруг. И, наверняка, все заметили, что в последнее время очень много шума вокруг cloud-native фреймворков. Два новичка — Micronaut и Quarkus достаточно уверенно начинают вступать на территорию Spring Boot. В один прекрасный день было решено сделать небольшое RnD, по результатам которого я расскажу об опыте работы с фреймворком Quarkus на примере хорошо известного приложения – Petclinic.

В Яндекс.Маркете большая микросервисная архитектура. Браузерный запрос главной страницы Маркета рождает десятки вложенных запросов в разные сервисы (бэкенды), которые разрабатываются разными людьми. В такой системе бывает сложно понять, по какой именно причине запрос упал или долго обрабатывался.


Анатолий Островский megatolya объясняет, как его команда решила эту проблему, и делится практиками, специфичными для Маркета, но в целом актуальными для любого большого сервиса. Его доклад основан на собственном опыте развёртывания нового маркетплейса в довольно сжатые сроки. Толя несколько лет руководил командой разработки интерфейсов в Маркете, а сейчас перешёл в направление беспилотных автомобилей.

Приветствую! Это небольшая статья, отвечающая на вопросы: "что такое envoy?", "зачем он нужен?" и "с чего начать?".

Что это

Envoy — это L4-L7 балансировщик написанный на С++, ориентированный на высокую производительность и доступность. С одной стороны, это в некотором роде аналог nginx и haproxy, соизмеримый с ними по производительности. С другой, он больше ориентирован под микросервисную архитектуру и обладает функционалом не хуже балансировщиков на java и go, таких как zuul или traefik.

Таблица сравнения haproxy/nginx/envoy, она не претендует на абсолютную истину, но дает общую картину.

Этим постом я хочу открыть ветку статей посвященную IdentityServer4. Начнем мы с основных понятий.

Самым перспективным на текущий момент протоколом аутентификации является OpenID Connect, а протоколом авторизации (предоставления доступа) является OAuth 2.0. IdentityServer4 реализует эти два протокола. Он оптимизирован для решения типичных проблем безопасности.

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

В .Net Core 3 добавилась отличная возможность передачи контекста корреляции в HTTP-заголовках, поэтому если ваши приложения используют прямые HTTP-вызовы для межсервисного взаимодействия, то вы можете воспользоваться этой коробочной функцональностью. Однако, если архитектура вашего бекенда подразумевает взаимодействие через брокера сообщений (RabbitMQ, Kafka и т.п.), то вам по-прежнему необходимо озаботиться темой передачи корелляционного контекста через эти сообщения самостоятельно.

В этой статье мы возьмём простое веб-апи приложение и организуем логирование, которое будет

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

• иметь единую точку входа с удобным анализом, чтобы инструментом логирования смогла пользоваться даже Поддержка, к которой летят вопросы вроде «у меня тут в приложении выскочила ошибка с таким-то айдишником запроса»