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

Неделю назад я выступал на митапе по Node.JS, и многим обещал выложить запись выступления. Уже потом я понял, что мне не удалось вместить в регламентированные полчаса некоторые интересные факты. Да и сам я больше люблю читать, а не смотреть и слушать, поэтому решил выложить выступление в формате статьи. Впрочем, видео тоже будет в конце поста в разделе ссылок.

Рассказать я решил про набившую оскомину тему — жизнь в монолите. Об этом на хабре уже есть сотни статей, тысячи копий сломаны в комментах, истина давно погибла в спорах, но… Дело в том, что у нас в OneTwoTrip есть весьма специфический опыт, в отличие от многих людей, которые пишут про некие архитектурные паттерны в вакууме:

• Во-первых, нашему монолиту уже 9 лет.
• Во-вторых, всю жизнь он провёл под хайлоадом (сейчас это 23 млн запросов в час).
• А в NaN-ых, мы пишем наш монолит на Node.JS, который за эти 9 лет изменился до неузнаваемости. Да, мы начинали писать на ноде в 2010, безумству храбрых поём мы песню!

Так что всякой специфики и реального опыта у нас довольно много. Интересно? Поехали!

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

Проект начал свою историю довольно давно, в начале 2000. Первые версии были написаны на Visual Basic 6. С течением времени стало понятно, что разработку на этом языке в будущем будет сложно поддерживать, так как IDE и сам язык развиваются слабо. В конце 2000-х было решено переходить на более перспективный C#. Новая версия писалась параллельно с доработкой старой, постепенно все больше кода было на .NET. Backend на C# изначально ориентировался на сервисную архитектуру, однако при разработке использовались общие библиотеки с логикой, да и запускались сервисы в едином процессе. Получилось приложение, которое мы называли «сервисный монолит».

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

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

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

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

Ниже представлен отрывок из книги «Использование асинхронного обмена сообщениями»

Рады пригласить всех интересующихся java-разработкой на очередной открытый DINS Java EVENING, который пройдет в нашем офисе на Старо-Петергофском, 19.

На встрече мы познакомимся с опытом TextBack и узнаем, как проходит их миграция с Vert.x на Spring. Коллега из Genestack поделится своим опытом построения билд-системы на Gradle в большом проекте с нуля.

Под катом — подробнее о докладах и спикерах, ссылка на регистрацию для участия во встрече.

Привет! Меня зовут Вадим Мадисон, я руковожу разработкой System Platform Авито. О том, как мы в компании переходим с монолитной архитектуры на микросервисную, было сказано не раз. Пора поделиться тем, как мы преобразовали свою инфраструктуру, чтобы извлечь из микросервисов максимум пользы и не дать себе в них потеряться. Как нам здесь помогает PaaS, как мы упростили деплой и свели создание микросервиса к одному клику — читайте дальше. Не всё, о чём я пишу ниже, в Авито реализовано в полной мере, часть — то, как мы развиваем нашу платформу.

(А ещё в конце этой статьи я расскажу о возможности попасть на трехдневный семинар от эксперта по микросервисной архитектуре Криса Ричардсона).

25 апреля мы в Mail.ru Group провели конференцию про облака и вокруг — mailto:CLOUD. Несколько хайлайтов:

• На одной сцене собрались основные российские провайдеры — про специфику нашего облачного рынка и своих сервисов говорили Mail.ru Cloud Solutions, #CloudMTS, SberCloud, Selectel, «Ростелеком — ЦОД» и «Яндекс.Облако»;
• Коллеги из «Битрикс24» рассказали, как они пришли к мультиклауду;
• «Леруа Мерлен», «Открытие», Burger King и Schneider Electric предоставили интересный взгляд со стороны потребителей облаков — какие задачи их бизнес ставит перед IT и какие технологии, в том числе облачные, видятся им наиболее перспективными.

Все видео с конференции mailto:CLOUD можно посмотреть по ссылке, а здесь можно почитать, как прошла дискуссия про микросервисы. Своими — успешными — кейсами избавления от монолитов поделились Александр Деулин, руководитель центра исследования и разработки бизнес-систем «МегаФона», и Сергей Сергеев, директор по информационным технологиям группы «М.Видео-Эльдорадо». Также обсудили близкие вопросы IT-стратегии, процессов и даже HR.

В настоящее время нет недостатка во фреймворках для создания микросервисов на Java и Kotlin. В статье рассматриваются следующие:

Service Mesh — известный архитектурный паттерн для интеграции микросервисов и перехода на облачную инфраструктуру. Сегодня в облачно-контейнерном мире обойтись без него довольно сложно. На рынке уже доступны несколько open-source реализаций service mesh, но их функциональности, надежности и безопасности далеко не всегда достаточно, особенно когда речь идет о требованиях больших финансовых компаний масштаба всей страны. Поэтому мы в Сбертехе решили кастомизировать Service Mesh и хотим рассказать о том, что в Service Mesh круто, что не очень и что мы с этим собираемся сделать.

Доброе утро всем!

Сегодня мы рады предложить вам перевод статьи, кратко рассказывающей о новом технологическом веянии под названием «Service mesh» (сервисная сеть). Наиболее интересным решением в этой сфере (на наш взгляд) является Istio, но предлагаемая статья интересна, в первую очередь, экспресс-сравнением имеющихся технологий такого рода и high-level обзором всей парадигмы. Автор Тобиас Кунце также написал вторую, более практически-ориентированную статью о service mesh — просьба высказаться, стоит ли опубликовать и ее перевод

Перевод статьи подготовлен для студентов курса «DevOps практики и инструменты» в образовательном проекте OTUS.

---

Когда в 2015 году начали появляться первые туториалы с использованием AWS Lambda и API Gateway, было неудивительно, что они в основном были сосредоточены на копировании микросервисной архитектуры. Но тем, кто использовал AWS Lambda в больших масштабах, с течением времени становилось понятно, что существуют значительные ограничения для применения микросервисного подхода к AWS Lambda…

Под капотом hh.ru — большое количество Java-сервисов, запущенных в докер-контейнерах. За время их эксплуатации мы столкнулись с большим количеством нетривиальных проблем. Во многих случаях чтобы докопаться до решения приходилось долго гуглить, читать исходники OpenJDK и даже профилировать сервисы на продакшене. В этой статье я постараюсь передать квинтэссенцию полученного в процессе знания.

• CPU лимиты
• Docker и server class machine
• CPU лимиты (да, опять) и фрагментация памяти
• Обрабатываем Java-OOM
• Оптимизируем потребление памяти
• Ограничиваем потребление памяти: heap, non-heap, direct memory
• Ограничиваем потребление памяти: Native Memory Tracking
• Java и диски
• Как за всем уследить?

Сравниваем особенности микросервисной и монолитной архитектуры, их преимущества и недостатки. Статья подготовлена для Хабра по материалам нашего митапа Hot Backend, который прошел в Самаре 9 февраля 2019 года. Мы рассматриваем факторы выбора архитектуры в зависимости от конкретной задачи.

Привет, я — Оля и я новоиспеченный РО. Работаю владельцем продукта 1,5 года, каждые пару месяцев прилетают новые инстайты, мир переворачивается с ног на голову, а я думаю: «Черт»! Я все делала неправильно! Но теперь-то я точно знаю как правильно! Разумеется, каждый раз я даже не представляю, насколько я ошибаюсь.

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

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

В интернете куча статей о сервис-мешах (service mesh), и вот ещё одна. Ура! Но зачем? Затем, что я хочу изложить своё мнение, что лучше бы сервис-меши появились 10 лет назад, до появления контейнерных платформ, таких как Docker и Kubernetes. Я не утверждаю, что моя точка зрения лучше или хуже других, но поскольку сервис-меши — довольно сложные животные, множественность точек зрения поможет лучше их понять.

Я расскажу о платформе dotCloud, которая была построена на более чем сотне микросервисах и поддерживала тысячи приложений в контейнерах. Я объясню проблемы, с которыми мы столкнулись при её разработке и запуске, и как сервис-меши могли бы помочь (или не могли).

В этой статье мы расскажем про проблемы, которые решает Consumer Driven Contracts, покажем как это применять на примере Pact с Node.js и Spring Boot. И расскажем про ограничения этого подхода.

Проблематика

При тестировании продуктов часто используют сценарные тесты, в которых проверяется интеграция различных компонент системы на специально выделенном окружении. Такие тесты на живых сервисах дают самый достоверный результат (не считая тестов на бою). Но в то же время они — одни из самых дорогих.

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



Об авторе: Ken Pugh обучает компании развивать гибкость, создает высококачественные системы с помощью Acceptance Test-Driven Development, BDD, ускорения DevOps. Кен написал несколько книг по разработке ПО, был лауреатом премии Jolt Award 2006 Prefactoring, один из создателей курса SAFe Agile Software Engineering.

Всем привет! Уже 28 мая мы запускаем первую группу по курсу «Разработчик Golang». И сегодня делимся с вами первой публикацией приуроченной к запуску этого курсу. Поехали.



Ключевые выдержки

• The Economist требовалось больше гибкости для распространения контента на все более разнообразные цифровые каналы. Для достижения этой цели и поддержания высокого уровня производительности и надежности, платформа перешла от монолитной к микросервисной архитектуре.
• Средства, написанные на Go, были ключевым компонентом новой системы, которая позволила The Economist предоставлять масштабируемые, высокопроизводительные сервисы и быстро создавать новые продукты.
• Go, нацеленный на параллелизм и поддержку API, вместе с его конструкцией статического компилируемого языка, облегчал разработку распределенных систем обработки событий которые могли бы масштабироваться. Поддержка тестирования также была плюсом.
• В целом, опыт работы команды The Economist с Go был положительным, и это был один из решающих факторов, которые позволили масштабировать Content Platform.
• Go не всегда будет являться подходящим инструментом, и это нормально. The Economist обладает платформой-полиглотом и использует разные языки там, где это имеет смысл.

.NET Community Райффайзенбанка приглашает на Meetup, который состоится в московском офисе в Нагатино 23 мая.

Сообщество разработчиков Райффайзенбанка активно проводит митапы, готовит вокркшопы, и делает еще много всего, для того, чтобы сотрудники могли делиться опытом и знаниями друг с другом. В программе события два доклада. Поговорим про DDD в микросервисах и узнаем как коллеги из Ozon реализовали сбор метрик в приложениях ASP.NET Core

Цели данной публикации:

• Краткое введение в Consumer Driven Contracts (CDC)
• Настройка CI pipeline на основе CDC

Consumer Driven Contracts

В этой части мы пройдемся по основным моментам CDC. Данная статья не является исчерпывающей на тему контрактного тестирования. Существует достаточное количество материалов на эту тему на том же Хабре.

Для продолжения нам необходимо познакомиться с основными положениями CDC:

• Контактное тестирование находится на уровне Service/Integration Tests над Unit Tests согласно пирамиде автотестирования (Mike Cohn)
• Контрактное тестирование может применяться, когда есть 2 (или более) сервиса, которые взаимодействуют друг с другом
• Сonsumer driven подход означает, что первым шагом в реализации является написание теста на стороне потребителя. Результатом теста является пакт (контракт) в формате json, который описывает взаимодействие между потребителем (например, веб-интерфейс / мобильный интерфейс: сервис, который хочет получить некоторые данные) и поставщиком (например, серверный API: сервис, который предоставляет данные)
• Следующим шагом является проверка договора с провайдером. Это полностью осуществлено фреймворком Pact.