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

Этим летом абитуриентам было жарко, МГУ по проходному баллу почти превратился в ПТУ, а кто-то успешно поступил в вооруженные силы РФ, сам того не желая. Отсутствие автоматизации в 2021 году, способной обработать распределение абитуриентов по учебным заведениям, а так же необходимость написать продолжение предыдущей статьи, описывающей основы теории о Распределенной Авторизации (РА) побудило решить эту детскую задачу автоматизации. Посмотрим, сколько же рпс нам в этом раз отсыпет антилопа.

Давайте представим, что мы уже написали наше Spring Boot приложение, и оно успешно работает на протяжении некоторого времени. И теперь мы понимаем, что для того, чтобы справиться с возросшей нагрузкой и повысить доступность, нам необходимо запустить несколько новых инстансов сервиса. Но мы не подумали об этом заранее, на этапе разработки.

Так что же может помешать нам просто взять и запустить еще несколько инстансов?

Никому не нравится стоять в очереди на кассе, особенно для покупки всего одного или парочки товаров. В условиях пандемии мы вовсе не хотим рисковать и находиться долгое время вблизи незнакомых людей. Год назад мы в Х5 Group решили помочь нашим покупателям и создали приложение для самостоятельных покупок «Экспресс-Скан». Оно принадлежит к системам класса Scan & GO и позволяет покупателю добавлять товары из магазина в виртуальную корзину приложения через сканирование штрих-кода товара с помощью камеры смартфона. Главный плюс -  оплачивать товары можно прямо в приложении, не подходя к кассе и не ожидая в очереди.

Мы уже писали об архитектуре системы, а сегодня решили рассказать о работе команды поддержки. «Экспресс-Скан» - быстро развивающийся проект, где команда поддержки внедрилась почти на самом начальном этапе его становления. Тогда было доступно лишь добавление товара в приложении без возможности оплаты, а тестирование в реальных магазинах и вовсе начиналось в тяжелых условиях пандемии. Поддержка была привлечена не только к сопровождению приложения, но и к совместному изучению ключевых сервисов системы.

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

Микросервисная архитектура в настоящее время очень популярна. Много кто ее использует, хотя и не всегда на все 100%. Но для успешного применения такого подхода, каждый из микросервисов должен:

Использование микросервисной архитектуры для построения корпоративных приложений взамен традиционной монолитной — популярный тренд в веб-разработке.

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

Мой выбор — Tornado. Поработав с Tornado в паре коммерческих проектов, я в целом остался доволен результатами. Однако, как бы ни было хорошо, всегда хочется чего-то большего.

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

Прим. перев.: автор этой статьи — engineering manager из Испании, работающий в цифровой торговой площадке Adevinta, представленной в 16 странах, — делится своими наблюдениями о частых проблемах, которые он встречал у создателей микросервисов. Об этих вызовах стоит знать заранее, чтобы не столкнуться с ними тогда, когда их решение может оказаться слишком затратным.

Когда пост Мартина Фаулера о микросервисах вышел в 2014 году, команды, в которых я работал, уже занимались SOA-приложениями. Эта статья и последующий хайп коснулись почти каждой команды разработчиков в мире. Стек Open Source-софта от Netflix был самым крутым в то время, поскольку позволял инженерам по всему миру перенимать опыт Netflix в распределенных системах. Если мы взглянем на работу разработчиков программного обеспечения сегодня, более шести лет спустя, большая её часть касается архитектуры микросервисов.

Привет, Хабр. Меня зовут Рустам. Я работаю в Ozon: админю Kubernetes и пишу на Go.

У нас очень много сервисов на Go — их количество исчисляется тысячами. Запускаются они внутри кластеров Kubernetes. А я плотно работаю с Kubernetes и заметил, что при запуске кода внутри Kubernetes для резолва одного адреса делается до десяти DNS-запросов. Это, конечно, влияет на производительность.

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

Ещё лет 5 назад на собеседованиях с backend-разработчиками был популярен вопрос: как переименовать колонку в высоконагруженной таблице (возможны вариации: как сделать любой другой alter table)?

Вопрос всё ещё часто звучит на собесах. И актуальность его выросла, так как за последние 5 лет стало намного больше масштабных проектов с высокой нагрузкой.

Приветствую всех читателей Хабра.

Немного разбросал текущие дела и пришло время для написания следующего поста в моем запланированном цикле статей:

Прим. перев.: системный архитектор Avery Pennarun, создавший VPN-решение Tailscale на базе WireGuard, размышляет об отличиях монолитов с модулями от микросервисов. Он рассказывает об эволюции подхода к модульности вообще и о том, почему изоляция до сих пор далека от совершенства, а также делится своим мнением о том, когда проводить границы между сервисами рационально.

В последнее время меня часто спрашивают, в каких случаях переход на микросервисы — хорошая затея. В статье «Systems design explains the world» я размышляю о таких типичных проблемах, как эффект второй системы, дилемма инноваторов и других. Может ли проектирование систем дать ответ на вопрос о микросервисах? Да, хотя ответы могут вам не понравиться.

Приветствую!

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

В этой статье я расскажу про то, как можно организовать отказоустойчивое взаимодействие с внешними сервисами. Тема актуальная, очень часто из-за недоступности какого-то одного компонента может пострадать вся система.

О чем статья:

•  Синхронное и асинхронное взаимодействие; 

•  Зависимость доступности от использования синхронного взаимодействия;

•  Способы избавления от синхронного взаимодействия;

•  Избавление от синхронного взаимодействия с внешними сервисами в PHP.

Рассказываем, как мы внедряли как мы интегрировали «Экспресс-скан» Х5.

Наши европейские коллеги еще во время весенних эпидемиологических ограничений сделали ставку на развитие систем класса Scan&Go — достаточно быстро обеспечили безопасность клиентов и добились хороших результатов с точки зрения продаж. В апреле мы внимательно проанализировали их опыт и решили, что стоит запустить собственный проект такого типа и развернуть его в магазинах сетей под управлением X5 Group.

Чтобы выполнить эту задачу, мы доработали архитектуру уже имевшегося у нас пилотного проекта и создали целую группу универсальных сервисов. Теперь к ним можно подключить информационные системы каждого из восемнадцати тысяч наших магазинов, чтобы предоставлять клиентам информацию об уникальном ассортименте, текущих ценах, акциях и стоимости уцененных товаров в той или иной локации. Наше решение также позволило обеспечить поддержку процесса самостоятельной покупки «на лету» — от сканирования штрихового кода и проведения оплаты, до отражения результатов в локальных системах магазинов, наших центральных системах и системах фискализации продаж.

Рассказываем, как мы подошли к этому проекту и что смогли осуществить.

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

Скоро будет удалено несколько API. Это беты, которые еще можно использовать в текущих версиях Kubernetes, но они уже deprecated. Им на смену придут обновленные стабильные версии API ("GA", General availability).

В Kubernetes 1.22 (релиз ожидается в августе 2021 года) будет удалено несколько deprecated API. На странице релиза Kubernetes 1.22 можно посмотреть его график.

Приветствуем тебя, читатель Хабра. Возможно, тема непрерывной поставки и интеграции микросервисов покажется немного избитой, ведь сегодня любой идальго путем нехитрых манипуляций при помощи обучающих видео может натравить Jenkins/TeamCity/GitLab (нужное подчеркнуть) на свой репозиторий и начать называть себя испанским доном. Вся соль, на наш взгляд, в тех шагах сборки, которые он для себя определит и какой смысл в них вложит. Не менее чем сама сборка важен процесс автоматизации контроля качества. В этой статье мы расскажем вам о том, что в этом вопросе сделали для себя мы, команда разработчиков всех розничных фронтов банка «Открытие».

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

Рассмотрим конкретный пример.

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

Привет, Хабр! В Netcracker мы уже давно используем микрофронтендную архитектуру, и с 2017 года начали разрабатывать собственный платформенный инструмент построения микрофронтендов.

Недавно на митапе мы показывали, как делать сложные приложения, разрабатываемые разными командами в разных релизных циклах и даже технологиях. В режиме live coding соединили Angular, React и Vue в одном SPA. Было много вопросов про Webpack Module federation. Поскольку мы уже переходим на этот фреймворк, здесь мы поделимся наработками, как сделать Angular host application + React/Angular/Vue microfrontends с возможностью независимого версионирования зависимостей.

Всем привет! Меня зовут Виктория, в Typeable я занимаюсь вопросами архитектуры приложений и не могла пройти мимо вечного вопроса: быть или не быть? Точнее переводить нам наши решения на микросервисы или нет. И с целью это понять я провела небольшое исследование возможных причин и анти-причин, выводы по которому и привожу здесь.

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

Сам подход оформился на стыке технологий из конкурентной необходимости мгновенно вывести бизнес на новый уровень, и поэтому решения развивались лавинообразно и быстро обзаводились надстройками, паттернами и CI/CD обвеской. Для бизнеса причины не теряют актуальности и интерес к микросервисам также не угасает последние десять лет. При этом сделать решение на микросервисах для ИТ команды – задача творческая, интеллектуальная, позволяющая опробовать современные подходы и уложить на лопатки драконов консерватизма предыдущих решений. То есть, вполне благородный вызов. 

Но вот стоит ли поддаваться этой магии — большой вопрос. 

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

Впрочем, давайте разбираться.

Меня зовут Паша Мягков, я frontend tech lead в команде монетизации Учи.ру. Несколько месяцев назад рост команды и задач привел нас к тому, что привычные рабочие процессы перестали отвечать нашим потребностям. Болезнь роста затронула прозрачность разработки, планирование и workflow. В этой статье я расскажу, как в рамках одной быстро выросшей команды нам удалось наладить процессы.

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