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

В одном из проектов возникла необходимость перевести процессы импорта данных сторонних систем на микросервисную архитектуру. В качестве инструмента выбран Apache NiFi. В качестве первого подопытного выбран импорт ЕГРЮЛ ФНС.

Данные ЕГРЮЛ публикуются в виде XML-файлов, упакованных в ZIP-архивы. Архивы ежедневно выкладывают на ресурс https://ftp.egrul.nalog.ru/ в отдельный каталог для соответствующей даты. Для доступа выдается ключ #PKCS12.

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

Микросервисная и модульная системы — это типы архитектуры IT-решений.

При работе с модулями мы дорабатываем коробочную версию существующего IT-продукта.

Под коробочной версией имеем в виду монолит, готовую систему с ядром, которая поставляется всем заказчикам одинаково, «как есть».

Доработка состоит в создании модулей с недостающим функционалом.

Новые модули получаем путём переиспользования частей монолита (ядра или других модулей).
Бизнес-логика прописывается внутри монолита: для программы (приложения, сайта, портала) есть одна точка входа и одна точка выхода.

При работе с микросервисами мы создаём IT-продукт с нуля, составляя его из «кирпичиков» — атомарных микросервисов, отвечающих за отдельный небольшой процесс (отправить письмо, получить данные по заказу, сменить статус заказа, создать клиента и т. п.).
Набор таких блоков объединяется бизнес-логикой в общую систему (например с помощью BPMS). Несмотря на наличие связей, каждый блок автономен и имеет свои точки входа и выхода.

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

Мы широко используем микросервисную архитектуру, хоть и не считаем ее панацеей, и чуть больше 2 лет назад начали переходить на язык Go. Он сравнительно прост и, на мой взгляд, очень хорошо подходит для создания простых, небольших и быстрых микросервисов. Эта простота имеет и обратную сторону: из-за неё возникает множество способов решить одну и ту же задачу.

Казалось бы, насколько сильно может отличаться один микросервис, который ходит в базу данных, от другого микросервиса, который ходит в соседнюю базу данных? Например, одна команда использует Go 1.9, glide, стандартный database/sql и одну структуру проекта, а в это же время другая команда использует Go 1.13, modules, sqlx и, конечно же, другую структуру проекта.

Когда один микросервис в компании отличается от другого, а он, в свою очередь, отличается от третьего — это замедляет разработку. А медленная разработка — это убытки повод для оптимизации.

Меня зовут Алексей Партилов, я техлид команды web-разработки в компании Lamoda. В этой статье я расскажу, как мы справляемся с разношерстностью около 40 наших микросервисов на Go. Статья будет полезна разработчикам, которые только вливаются в Go и не знают, с чего начать более сложный проект, чем “helloworld”.

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


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

И снова здравствуйте. Несколько дней назад началось обучение в новой группе по курсу «Архитектор ПО», а сегодня мы хотели бы поделиться статьей, которую написал один из студентов курса — Плешаков Антон (руководитель направления разработки в компании «Программная логистика» и 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.