Современные решения, построенные на микросервисной архитектуре, напоминают сложный организм: сотни взаимосвязанных компонентов, распределенные базы данных, облачные сервисы. Без продуманного наблюдения даже мелкая ошибка в одном узле может спровоцировать цепную реакцию — например, падение конверсии из-за «зависшего» платежного шлюза или потерю данных из-за перегруженной очереди сообщений.
Грамотная стратегия мониторинга решает три ключевые проблемы:
В мобильную разработку приходят различными путями. Некоторые рождаются с девайсом в руках, других ведет извилистая дорога вдоль серверов, майнфреймов, дестопных приложений. Но каждый кто в нее попадает ощущает свою незащищенность с тыла, если нет надежного партнера в лице бэкенд ‑разработчика. И, буквально, каждый мобильщик ожидает, что необходимый API будет готов хотя бы за один спринт, до того, как в нем возникнет необходимость. Конечно же, мир IT разработки редко допускает такую роскошь — за нее требуется бороться с ПМ и бизнес‑аналитиком. К тому же не редки ситуации, когда то, что должно быть сделано «на вчера», будет готово «на послезавтра». Те кто имеют достаточно опыта как в наземном, так и подземном мире — берут инициативу с свои руки, и сами предлагают клиент‑серверный интерфейс.
Для мобильного мира C# и Java — падения из рая в ад — это довольно естественный процесс, поскольку присущие им платформы изначально целились на поддержку темных сил бэкенда. То ли дело Swift — познавшему небо — не легко дается жизнь на льдине, вместе с ластоногими.
Получить лучшее из обоих миров, и не потерять темп позволяют некоторые экзотические решения, наподобие Perfect и Vapor. Однако, они в большей степени отвечают на вопрос «Как?» вместо того, чтоб предложить какое‑нибудь удовлетворительное минимальное решение. С другой стороны, как правило, исходные требования мобильной команды довольно умерены и стереотипны от одного приложения к другому. Обычно требуется поддержка и управления такими сущностями как аккаунт пользователя, профиль, продукт и изображения.
В этой статье я расскажу о ключевых вызовах микросервисной архитектуры и способах их преодоления. Мы рассмотрим, как найти баланс между автономностью сервисов и сложностью их взаимодействия, почему даже идеальный код не спасает от «распределенного монолита» и как превратить хаос микросервисов в управляемую систему.
Привет! Меня зовут Игорь Шаталкин, я разработчик-эксперт в CUSTIS. В этой статье продолжим обсуждение монолитов и микросервисов. Я подробно рассмотрю важные моменты работы с микросервисной архитектурой и поделюсь как своим опытом, так и опытом компании CUSTIS: с чем нам приходилось сталкиваться в проектах и какими способами мы решали возникшие проблемы.
Много лет мы обсуждали, как разбить монолит на микросервисы. Микросервисная архитектура стала стандартом для создания сложных систем. Однако что делать, если растущее число сервисов начинает тормозить разработку, усложнять сопровождение и порождать избыточность? Забавно, что спустя столько времени я пишу статью о том, как вернуться к монолиту. Это история о том, как микросервисная архитектура сыграла с нами злую шутку, а монолит оказался спасением. Данный подход, хотя и кажется шагом назад, открыл нам возможность упростить код, снизить эксплуатационные затраты и навести порядок в хаосе микросервисов. В этой статье я поделюсь тем, как я переосмыслила процессы и нашла баланс между гибкостью микросервисов и преимуществами модульного подхода.
Привет, Хабр! На связи команда разработки App.Farm в РСХБ-Интех.
App.Farm — платформа по типу PaaS для стандартизации процесса разработки бизнес-приложений: от хранения исходного кода до запуска сервисов. App.Farm CI — подсистема обеспечивающая хранение кода, артефактов, автоматизацию сборки. В этой статье хотели бы представить вам одну из подсистем нашего продукта — PaaS App.Farm, и это будет финальная часть цикла статей об App.Farm CI. Наш материал посвящён работе с пользователями App.Farm CI — какие темы затронем в этой части:
Сопровождение как задумывали
Сопровождение как получилось
Процесс Feature Requests
Публикация Changelog
Итоги и планы
Продолжаем наращивать базу знаний по System Design! В этот раз освятим использование Pub/Sub, Event-Driven Architecture, Distributed Systems, Leader Election. Посмотрим на их концепции и области применения при проектирование высокодоступных отказоустойчивых систем.
Привет! Меня зовут Олег Стрекаловский, я старший разработчик в команде корзины маркетплейса. Сервис корзины Ozon отвечает за хранение корзин покупателей и за отрисовку соответствующего экрана в приложении и на сайте. Слежение за стабильностью сервиса — важная задача. В этой статье я расскажу о нюансах интерпретации данных, которые предоставляет система мониторинга Prometheus. Если вы тоже часто всматриваетесь в графики, чтобы понять, как чувствует себя сервис, эта статья для вас.
Сейчас, когда мы более-менее представляем, что такое микросервисы, самое время переходить к конкретике. Мы в курсе, что нам предстоит разрабатывать веб-приложения, так что надо узнать, какие средства для этого предлагает .NET.
Потому, что микро-сервисы часто оказываются не «микро», а «нано» сервисами.
Маленькими, изолированными сервисами под конкретную маленькую задачу. Они любят полакомиться чужими событиями. Но они не жадные: поймают одно событие, кинут три. Поодиночке они почти бесполезны. Про них можно слагать анекдоты: «Сколько надо сервисов, чтобы напечатать Hello World?». Поэтому нано-сервисов много, они плодятся как зайчики. Или как маленькие паучки, которые затягивают организацию своей паутинкой.
Систему нано-сервисов трудно спроектировать, легко уронить и невозможно поддерживать.
«Микро» — это не «нано», микро-сервисы устроены иначе. Не скажу, что знаю рецепт хорошего микро-сервиса. Но я постараюсь показать, каким он точно не должен быть.
Когда говорят о микросервисах, чаще всего подразумевают контейнеры, Linux и Kubernetes. Но что, если у вас микросервисное приложение работает на Windows, а контейнеризация по ряду причин — не ваш путь? В этой статье рассказываем, как можно обойтись без Docker и всё же реализовать оркестрацию микросервисов с помощью HashiCorp Nomad, включая работу с IIS, настройку кластера и доработку необходимых плагинов.
В любой сфере деятельности есть знаковые фигуры. Признанные эксперты. Лидеры мнений. Программирование не является исключением. Всем нам знакомы имена Кернигана, Кнута, Торвальдса, Скита. Не последним в этом ряду будет и имя Мартина Фаулера. Он написал книгу «Рефакторинг», которую обязан прочитать любой профессиональный программист. Он предложил термин Dependency Injection. Он участвовал в подготовке каталога действительно полезных паттернов проектирования. Он был одним из авторов Манифеста Гибкой Разработки Программ.
В 2014-м вместе с Джеймсом Льюисом Фаулер написал статью о микросервисах, которая начинается словами: «Термин „микросервисная архитектура‟ уже несколько лет применяется, чтобы описать способ проектирования программ»… Очевидно, теме микросервисов без малого десять лет. Можно ли добавить что-нибудь к тому, что уже было сказано и написано за это время?
Оказывается, можно.
Микрофронтенд на пальцах с module federation 2.0. Как собрать микрофронты из кубиков без магии по шагам.
Контейнеризация становится неотъемлемой частью современного подхода к разработке и развертыванию приложений, однако с увеличением их использования возрастает и необходимость обеспечения безопасности этих изолированных сред.
В статье рассмотрены основные аспекты мониторинга безопасности контейнеров с использованием Docker и системы Wazuh, которая позволяет отслеживать и анализировать события безопасности в реальном времени. Особое внимание уделено интеграции Wazuh с Docker, настройке прослушивателя Docker listener и мониторингу активности контейнеров, что помогает специалистам по безопасности оперативно выявлять угрозы и минимизировать риски.
Языки программирования расходятся во мнении, что такое ошибки или исключения и как их обрабатывать. Возникает вопрос: что использовать, если нужны стандартизированная телеметрия и отчёты об ошибках для написанных на этих языках микросервисов? Ответом может быть OpenTelemetry.
Перевели материал, из которого вы узнаете, как OpenTelemetry обрабатывает ошибки, чем отличаются ошибки в спанах и логи, а также как добавить в спаны OTel метаданные и события.
Игры про автоматизацию затягивают с головой, если хоть раз прочувствовать их прелесть и красоту. Часами смотришь на бесконечные цепочки производств, продумываешь, как всё оптимизировать, а окружающие недоумевают, чем ты вообще занят.
Если вы бывали в этой ситуации, провели сотни часов в Factorio или Satisfactory, но не слышали о других представителях жанра — эта подборка для вас. А для тех, кто никогда не пробовал играть во что-то подобное или всегда избегал Factorio, считая её слишком громоздкой — это отличная возможность найти что-то по душе и открыть для себя новое увлечение.
Мы не только рассмотрим свежие игры в этом жанре, но ещё и проведём аналогии с разработкой ПО: обсудим, какие качества эти игры развивают и как на их примере учиться на ошибках. А также посмотрим на игры с открытым исходным кодом для тех, кто хочет углубиться в их внутреннее устройство.
Если вы только начинаете осваивать профессию, эти игры помогут вам понять преимущества и недостатки различных подходов на более простых аналогиях, а позже перенести этот опыт в реальную разработку. Например, необходимость масштабируемости, удобства хорошо настроенного CI/CD, или компромиссы, которые приходится принимать при использовании микросервисной архитектуры.
На прошлой неделе это случилось снова. Я был на совещании по анализу архитектуры, и коллега-архитектор начал ещё одну оживлённую дискуссию о микросервисах. Спустя считанные минуты взгляд присутствующих остекленел, и мы погрузились в абсурдное обсуждение того, что должно быть средством для достижения цели, но превратилось в саму цель. В тот самый момент я осознал: с меня хватит. Я наконец-то поклялся больше не общаться с архитекторами о микросервисах. Почему? Да потому, что такие обсуждения обычно не приводят ни к чему продуктивному.
Часто ли вы слышите о новом принципе проектирования IT-архитектуры? А об обновлении классических принципов? Попробую вас удивить и привнести что-то новое. 😎
У вас никогда не вызывало недоумения, что связанность и прочность (или связность) — это про примерно одно и то же (и то, и другое — это некая связь), но одно — хорошо, а другое — почему-то плохо? 🙂
Но давайте по порядку.
Всем привет!
В этой серии из нескольких статей мы разберемся, что делать тестировщику на проекте с кафкой (как впервые, так и имея какой-то опыт). Здесь я не буду говорить о брокерах и zookeeper-ах, о том, как развернуть кафку. Но мы разберемся, как её настроить и как с её помощью тестировать ваши микросервисы.
Начнём с «базы» (точнее, теории).
Apache Kafka — распределённый программный брокер сообщений с открытым исходным кодом, разрабатываемый в рамках фонда Apache на языках Java и Scala.
Привет! Меня зовут Игорь Шаталкин, я разработчик-эксперт в CUSTIS. В ИТ только и разговоров о том, что лучше — разделять или монолитствовать. Однако выбор архитектурного подхода зависит от множества факторов: масштабов проекта, бизнес-логики, организационной структуры команды и технических ограничений.
В этой статье я поделюсь практическим опытом CUSTIS, расскажу о ключевых особенностях, преимуществах и недостатках микросервисной и монолитной архитектур. Ведь настоящая задача разработчика — не холиварить об идеальном решении, а грамотно подбирать инструменты под конкретные условия проекта.
А в следующих статьях планирую поделиться практическими кейсами внедрения микросервисов и рекомендациями по переходу от монолита к микросервисам.
