. Декабрьская новость о переходе модулей Spring Cloud Netflix в maintenance mode наверняка заставила многих задуматься о замене их на альтернативы. Александр расскажет об опыте переезда на одну из самых популярных альтернатив — Kubernetes.
Поделимся опытом нашей компании при построении систем на основе микросервисной архитектуры. Расскажем об опыте использования Spring Boot Netflix OSS stack (Eureka, Feign, Ribbon, Hystix, Zuul) и построения Zero Downtime Deployment c использованием Spinnaker (AWS as infrastructure), о том, для чего использовался каждый из элементов Netflix OSS stack, о его преимуществах/недостатках, а также проблемах, с которыми столкнулись в продакшне.
Затем расскажем про причины перехода на Kubernetes, как он помог решить те же проблемы, что и Netflix OSS stack, но с меньшими затратами времени. Проведем аналогии с элементами Netflix OSS (например, Eureka — Kubernetes Service API, Zuul — Kubernetes Ingress API, etc.). Поговорим об опыте построения CI/CD с Zero Downtime Deployment с использованием Kubernetes и Helm (пакетный менеджер для Kubernetes).
Целевая аудитория: специалисты (Senior/Lead/Architect), которые переходят или планируют перейти с Netflix OSS на Kubernetes для построения решений на микросервисной архитектуре.
На дворе 2018 — все любят микросервисы и пилить монолиты.
При этом у монолита с единой базой есть плюс — целостность и согласованность данных о, например, списании денег за услугу и применении услуги можно гарантировать обычной транзакцией на уровне СУБД (PostgreSQL, Oracle и т.п.).
…
— Нашли ошибку в видео? Пишите нам на support@ontico.ru
Не так часто на конференциях рассказывают про архитектуру платежных систем, особенно если они делались без legacy. Нашей платежной системе всего три года, из которых два в продакшне. Мы изначально проектировали надежную и масштабируемую систему, и за прошедшее время накопилось тем для рассказа.
…
Нашли ошибку в видео? Пишите нам на support@ontico.ru
. Ближайшая конференция — DotNext 2020 Piter
15-18 июня, Online
Подробности и билеты: bit.ly/dotnext2020piter
. Apache Kafka — довольно популярная open source платформа для обработки потоков сообщений. Абстракция распределённого лога, лежащая в основе Kafka, даёт возможность использовать её в качестве системы очередей, но при этом даёт некоторые очень полезные преимущества, недоступные даже решениям ESB-уровня.
В этом докладе мы разберём основные принципы, на которых построена Apache Kafka, узнаем, как и в каких случаях её использование позволяет решать задачи просто и эффективно.
Но самое главное, рассмотрим реальное применение Apache Kafka в системе, имеющей микросервисную архитектуру и бэкенды которой реализованы на .NET Core и Scala. Также вспомним про замечательную библиотеку Reactive Extensions и посмотрим, как применение реактивного подхода позволяет сохранить код простым, надёжными и крайне производительным.
Ну и конечно же, не забудем про особенности и нюансы, которых всегда очень много, когда мы делаем микросервисные приложения, да ещё с таким набором технологий. Здесь поговорим о реальном опыте, полученном в большом проекте. Это позволит вам быстро сориентироваться, если потребуется решать похожие задачи.
Все крупные компании проходят через эту стадию. Стадию, когда бизнес не хочет по-старому, а монолит не может по-новому. И разбираться с этим нам — простым разработчикам. Приходите послушать, как мы решали эту проблему в Леруа Мерлен, на какие грабли мы наступили, и что у нас получилось в итоге.
— Нашли ошибку в видео? Пишите нам на support@ontico.ru
Микросервисная архитектура — это не только новая мода, но и хорошее, а иногда даже единственно возможное решение для задач, которые сейчас встречаются в разработке программного обеспечения. На конференциях микросервисы сравнивают с монолитной архитектурой, описывают их плюсы и минусы, делятся успешными и провальными историями. Но, пока в столицах дают рок-концерты, на местах осваивают балалайки. Не всегда понятно, как начать делать систему, основанную на микросервисной архитектуре. Какие проблемы ждут архитектора и разработчиков, какие узкие места могут встретиться и как к этому подготовиться? Имеет ли смысл начинать с монолита или надо сразу разбивать систему на микросервисы? Как определить границы, которые встанут между вашими микросервисами?
Во время разработки можно заложить на будущее множество сложностей, благодаря привычкам, оставшимся после работы над монолитной архитектурой. Во время доклада будут рассмотрены различные сценарии, в результате которых происходит увеличение связанности системы. Все сценарии взяты из реальных проектов и относятся к работе с библиотеками и интеграцией между микросервисами.
Выбор микросервисов окажет большое влияние на тестирование, где специалистов QA ждет ряд новых проблем, связанных со сбором логов и развертыванием окружения для тестирования.
Цель доклада не только в освещении проблемных мест разработки микросервисов, но и в предложении советов и решений, которые помогут исправить или даже избежать сложностей и, следственно, потери времени и ресурсов на их исправление.
Доклад Дмитрия Столярова, технического директора компании «Флант» (https://flant.ru/), на конференции RootConf, проходившей в рамках фестиваля РИТ 2017 (6 июня 2017 г.). Посвящён устройству и основным возможностями Kubernetes и практике использования этой контейнерной системы в небольших проектах…
ita-lab