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

Оригинал статьи:
Microservice Architecture Design in a NodeJS/NestJS Environment | Online Retail System

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

С одной стороны, это может быть и хорошо. Такие шаги стимулируют индустрию. Но всё же лучше понимать, что ты делаешь, иначе проекту можно сделать только хуже. В этой статье я обращаюсь к разработчикам, аналитикам и тестировщикам, которые еще не сталкивались с Kafka по работе. Помогу понять, почему все же в микросервисной среде многие не ходят просто по REST, а используют этот инструмент - что конкретно делает Kafka и когда есть смысл её применять.

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

Привет, хабровчане!

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

А сейчас вот появилось -- решил демонстрации ради запилить Notion из рельсов и шпалок.

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

В это нелегкое время, так сложно найти работу, когда первокурсники МИРЭА уже пишут курсовые с микросервисами на 1к рпс, а выпускники каждый по системе на миллиарды пользователей. Видимо старому Java-коту ничего не остается, кроме как беседовать с вечностью и её сестрой бесконечностью. Если не они, то кто поможет коту найти работу?

Статью можно прочесть в формате pdf.

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

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

Протокол — это набор правил и стандартов, определяющих, как данные передаются и обрабатываются в сети.

Так вот, клиент и сервер взаимодействуют с помощью стандартных протоколов, таких как HTTP, FTP или более низкоуровневых — TCP или UDP. Протокол обычно выбирается под тип услуги, которую оказывают сервера...

В прошлой статье (https://habr.com/ru/articles/819931/) я рассказал про общую структуру проекта, про работу Kafka с CDC для получения данных из базы. Теперь пришло время поговорить про саму реализацию триггеров на Python. Как говорилось в предыдущей статье, мы будем реализовывать только триггеры Before (Instead Of останутся в базе без изменений). Итак, что же нам необходимо предусмотреть при разработке?

Сегодня микросервисы требуют постоянного стремления к автоматизации и оптимизации. В этой статье рассмотрим такой инструмент в Kubernetes, как Horizontal Pod Autoscaler или сокращенно HPA.

Всем привет!

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

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

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

Это моя первая публикация из цикла статей про проектирование и разработку облачной консоли, с помощью которого пользователи могут гибко управлять инфраструктурой.

Идея подсветить данную тему пришла в результате накопленного многолетнего опыта проектирования тех самых облаков и ввиду дефицита информации о подобных системах в публичных источниках.

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

А вы когда-нибудь задумывались, как происходит создание виртуальных машин в среде виртуализации, когда вы нажимаете на кнопку в консоли AWS? Или как реализуется заказ кластеров Kubernetes и дальнейший контроль жизненного цикла этого продукта: от биллинга услуги до управления доступом и ведения системы аудита?

Если я смог вам заинтересовать, то добро пожаловать под кат.

Периодически при тестировании микросервисов приходится сталкиваться с необходимостью изменения времени для проверки работы того или иного функционала. Это может быть функционал, который срабатывает по “тику” cron или применение системного времени как одного из условий обработки/хранения/передачи данных тестируемым микросервисом.  

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

Dropwizard — это комплексный фреймворк, созданный с целью упростить разработку RESTful веб‑сервисов, объединяя в себе множество проверенных временем библиотек и инструментов.

Asp.Net + nginx + kafka + docker + docker-compose + postgersql. Или как из обычного шаблона прийти к такому гибриду.

Всем привет! Меня зовут Андрей Петухов, я техлид команды Testing Experience AvitoTech, занимаюсь разработкой систем тестирования в Авито. В этой статье рассказываю, как мы организовывали у себя процесс тестирования в условиях микросервисной архитектуры. Ниже вы узнаете о том, как применять Testing as a Service (TaaS), зачем нужны шлюзы качества и как все это помогло тестировщикам сосредоточиться.   

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

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

«Скажите, какие основные преимущества микросервисов и почему?». Вероятно, это самых популярный вопрос последних 6–10 лет на любом собеседовании для бэкенд разработчика. Каким-то чудом он даже обогнал: «Назовите три принципа ООП» и «Чем отличается класс от объекта».

На связи Игорь Латкин, управляющий партнер и системный архитектор в KTS. 

Мы на своём опыте разобрались в развертывании stateless- и stateful-сервисов, и теперь хотим поделиться с вами. Мы в KTS не раз создавали подобные инфраструктуры, перепробовали разные решения и выясняли, как построить эффективные процессы.

Сегодня мы поговорим о динамических окружениях (фича-стендах) для stateless- и stateful-сервисов, обсудим особенности и проблемы, которые могут возникнуть и возникали у нас.

В июле 2024 вышла версия Kubernetes 1.31, в которой были окончательно устранены встроенные интеграции облачных провайдеров.

Начиная с версии Kubernetes v1.7, проект Kubernetes преследовал амбициозную цель удаления встроенных интеграций облачных провайдеров. Хотя эти интеграции сыграли важную роль в раннем развитии и росте Kubernetes, их удаление было обусловлено двумя ключевыми факторами: растущей сложностью поддержания собственной поддержки для каждого облачного провайдера в миллионах строк кода Go и желанием сделать Kubernetes по-настоящему независимой от поставщика платформой.

После многих релизов, все интеграции облачных провайдеров были успешно перенесены из основного репозитория Kubernetes во внешние плагины. В дополнение к достижению первоначальных целей, удалось значительно оптимизировать Kubernetes, удалив около 1,5 миллионов строк кода и уменьшив двоичные размеры основных компонентов примерно на 40%.

Эта миграция была сложной и длительной из-за многочисленных затронутых компонентов и критических путей кода, которые полагались на встроенные интеграции для пяти первоначальных поставщиков облачных услуг: Google Cloud, AWS, Azure, OpenStack и vSphere. Для успешного завершения этой миграции пришлось построить четыре новые подсистемы с нуля:

Рассмотрим очередной популярный подход к проектированию систем для управления и координации выполнения бизнес-задач или процессов на основе событий. В общем случае это микс Хореографии и Оркестрации. Рассмотрим их подробнее.