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

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

Меня зовут Семен Катаев, я работаю в Авито над процессом перехода от монолитной архитектуры к микросервисам. Переход у нас все еще продолжается, но мне уже есть чем с вами поделиться. Это краткий обзор того, с чем придётся столкнуться, если вы задумались над созданием надежного, масштабируемого, распределённого приложения.

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

Меня зовут Аксёнов Вячеслав, я старший бэкенд Java/Kotlin разработчик в крупном энтерпрайзе. Однажды я попал на проект, полный микросервисов, в котором за конфигурацию отвечала такая штука как Spring Cloud. Чтобы разобраться как именно это работает я исследовал и прикрутил этот диковенный элемент к одному своему пет проекту. И в этой статье я пошагово покажу как я это сделал

В один прекрасный момент вы можете переезжать из одного ДЦ в другой и понять, что не знаете свои системы: их поведение может стать неожиданным. В одной системе вы должны были работать гораздо быстрее, но теперь работаете медленно. В другой — не понимаете, куда приходит запрос, а в третьей столкнетесь с проблемами.

Чтобы проще и быстрее понимать взаимосвязи между системами, и легко оптимизировать то, что уже было, вам прекрасно подойдет distributed tracing. Но как его выбрать, внедрить и не собрать все грабли?

Безкоровайный Денис, директор подразделения DevOps/DevSecOps в Proto Group и Панычев Дмитрий, руководитель разработки ряда достаточно запутанных проектов в Vprok.ru Перекресток, на конференции DevOps 2021 на примерах показали, как distributed tracing помог им решить бизнес-задачи. Читайте под катом, как они выбирали решение для distributed tracing и обходили грабли.

В FunBox мы делаем продукты для мобильных операторов: различные порталы, геосервисы, платежи, мобильную рекламу и многое другое.  Один из наших проектов построен на микросервисной архитектуре. Основная функциональность связана с обработкой потоков событий, поэтому мы выбрали событийно-ориентированную архитектуру. Для организации централизованного, масштабируемого и быстрого механизма обмена сообщениями используем Apache Kafka. Это популярная платформа для решения подобных задач, плюс у неё есть интерфейс для организации потоковой обработки событий.

Очень часто при проектировании высоконагруженных систем, основанных на микросервисной архитектуре, обнаруживается что «узким» местом, ограничивающим производительность системы и возможности ее масштабирования, становится передача сообщений и временные затраты на сериализацию-десериализацию сообщений и дополнительные расходы на установку соединения и начальные согласования. Решением может стать использование протокола gRPC с кодированием сообщений с применением Protocol Buffers (protobuf).

В этой статье рассмотрены подходы к реализации gRPC клиента и сервера для бэкэнда на Kotlin, разобран пример создания проекта для взаимодействия микросервисов через протокол gRPC с использованием возможностей Kotlin DSL и корутин.

Вместо введения

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

Микросервисы. С хайпом вокруг них, лучше быть разработчиком, архитектором, тестировщиком, проджект-менеджером, дизайнером. Хорошо быть кем угодно в микросервсиах, но только не аналитиком. Аналитик ведь всегда во всем виноват. Ни разу не слышал, чтобы в “факапе” и срыве сроков обвинили архитектора, ну или там разработку. Нет, господа, вина всегда лежала и будет лежать на плохой документации и нечетко поставленных задачах. Вот вся команда собралась и тычет в тебя пальцами. Дескать, это все он! Опытный архитектор спроектировал, хороший разработчик сделал, внимательный тестировщик протестировал, мотивированный проджект-менеджер обеспечил… а невнимательный аналитик все завалил. А меж тем, материалов по аналитике и как её вести на русском языке очень мало. И как “анализировать” эти самые микросервисы не совсем понятно. Более того, никто вам не скажет, чем “системный аналитик” теперь отличается от “солюшн архитектора”. Вот во всем этом я и захотел разобраться и поделиться. Поэтому, если вы не аналитик - не читайте. Вам не будет интересно. Ведь, нет в вас экзистенциального кризиса и вопросов “Кто я? и зачем я им нужен на проекте”.

О чем статья

В этой статье речь пойдет о БАЗОВЫХ подходах и принципах к такому quality attribute (QA) как Availability. Никаких сложных случаев, ничего слишком сложного, только теория с двумя примерами, скипайте, если искали что-то эдакое.

Вся информация основана на парах книг, статей, и моем опыте. В конце статьи я покажу, какие именно. Также, эта статья - по суть перевод моей же статьи, только написанной на английском.

Что такое Availability?

Перед тем, как рассматривать паттерны и техники для обеспечения availability мы должны определить сам термин.

В этой серии вы узнаете как собрать докер-образ приложения на Vue.js и как опубликовать его в GitHub Packages. Вот так. Вот в общем-то и... не всё... Одним GitHub Action, как это было для Spring Boot приложения, о котором я рассказывал тут, в этот раз обойтись не получится. Нужно ещё проделать некоторые манипуляции, о которых я и расскажу в данной статье.

Сегодня хочу рассказать про фронт-платформу розницы Газпромбанка, в которой мы реализовали омниканальный подход для выставления продуктов в цифровых и традиционных каналах продаж. Это когда клиент начал свой путь в одном канале, продолжил в другом, а закончил в третьем — и не только пострадал при этом ни морально, ни физически, но и вообще не обнаружил проблем при переходе из одного канала в другой.

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

Данная статья — взгляд на то, как Kubernetes способен повысить уровень безопасности, упростив управление ею и ускорив внедрение механизмов безопасности с точки зрения специалиста по ИБ, который большую часть своей карьеры занимался наступательной безопасностью. Сейчас на примере Kubernetes я вижу, что на нем можно организовать так называемую self defense (самозащищающуюся) систему.

Меня зовут Дмитрий Евдокимов, я founder и CTO компании Лантри, а кто-то может меня лучше знать, как автора каналаk8s (in)security. Про безопасность я буду говорить, исходя из моего опыта, как человека, который десять лет атаковал различные системы, реализуя угрозы и риски. Ссылка на мое выступление на конференции DevOps Conf 2021 будет в конце статьи.

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

В этой статье рассматриваются принципы разработки и лучшие практики тестирования ПО для архитектуры микросервисов.

Это история о том, как увеличить скорость выкатки фич, но сохранить качество продукта. О болевых точках, которые замедляют разработку, и новой «болезни» — микросервисе головного мозга, которую диагностировал Михаил Трифонов, техлид фронтов в SberСloud. Он утверждает, что она приводит к росту функциональности ML Space на 683% при увеличении команды разработки всего в 2 раза. Невероятно, но бизнес-аналитика это подтверждает. Так что давайте разбираться по порядку.

Разговоры о программировании без программистов идут постоянно. За последние 14 лет моей работы в IT идёт уже вторая волна любви к low-code решениям. Если вы дольше наблюдаете IT-рынок, то наверняка вспомните ещё пару подъёмов этой темы. Я побуду в роли критика low-code платформ, но, заодно, опишу способ применения low-code платформы, при котором это применение будет эффективно и оправдано.

В этой статье я хочу исследовать возможности технологии Java Native Image, поделиться опытом взаимодействия с ней и со средствами Spring для генерации нативных образов.

Снова привет, Хабр! 

В первой части статьи мы разбирали, что такое изоляция микросервисов, как в этом помогают переключатели функциональности, и как создать простое ASP.NET приложение в с поддержкой feature toggles, которое будет показывать прогноз погоды. В этой части закончим работу над ним — напишем заглушку, сделаем экспериментальную конечную точку, функциональность которой можно включать или выключать, не останавливая работу приложения, и разберёмся с экстренными ситуациями, которые могут возникнуть при разработке приложения.

Дисклеймер: в статье много тяжёлых иллюстраций, берегите мобильный интернет.

Привет, Хабр! Меня зовут Вячеслав Савельев, я отвечаю за разработку ключевых сервисов Учи.ру. Сегодня расскажу, как в процессе постепенного внедрения микросервисов в компании (тут, тут и тут можно прочитать об этом подробнее) мы столкнулись с проблемой конфигурации стейджовых окружений. И вот как мы с ней справились.

Привет! Недавно мы провели небольшой митап для фронтендеров, куда пригласили троих интересных спикеров. Наш коллега Игорь Борзунов рассказал о том, как решать проблемы с плохим качеством изображений. Даниил Водолазкин из X5Tech поведал о неочевидных сложностях работы с GraphQL. И завершил программу Георгий Конюшков из «Леруа Мерлен» с темой «Time to market: микрофронтенды». В этом посте мы свели основные тезисы всех трех докладов.