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

Данный проект рассматривается как pet-project. Любую критику и советы готов увидеть в комментариях.

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

Репозиторий с исходным кодом: https://github.com/theartofdevel/notes_system

Видео версия: https://www.youtube.com/watch?v=Txi95RQPRP0

Под катом текстовая расшифровка.

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

Не так давно появилась задача получения информации о доменах в whois.

Требование простое, дернуть curl-ом и получить json, и чтобы было бесплатно.

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

Получился простой скрипт на flask завернутый в докер. Для работы с whois использовал библиотеку. Тут стоит отметить что служба whois достаточно архаична и децентрализованна. В связи с этим есть проблема с новыми зонами, особенно из New gTLD. Понемногу в проект добавляются новые зоны, но до конца списка еще далеко. Так же, можно отправлять реквесты на добавления нужных зон.

Репозиторий проекта

Подергать его можно тут

Для того чтобы получить инфу по домену нужно просто дернуть его следующим образом.

На этом все, спасибо за внимание :)

Концепция микро-фронтенда – это микросервисный подход при разработке клиентской части. В настоящее время есть тенденция создавать мощное и функционально насыщенное веб-приложение, расположенное поверх микросервисной архитектуры. Со временем микро-фронтендовая архитектура становится частью приложения, зачастую ее разрабатывает отдельная команда. Эта архитектура растет, ее становится сложно поддерживать. Возникает так называемый «фронтендовый монолит». Для решения этой проблемы была сформулирована концепция микро-фронтендов.

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

Как архитектор-консультант в Red Hat, я имел возможность поработать над множеством проектов для наших клиентов. У каждого из них есть свои особенности, которые, однако, имеют некоторые общие черты. Большинство клиентов хотят знать, как скоординировать запись в несколько систем одновременно. Ответ на этот вопрос обычно включает подробное объяснение двойной записи, распределенных транзакций, современных альтернатив, а также возможных сценариев сбоев и недостатков каждого подхода. Как правило, именно в этот момент заказчик понимает, что разделение монолитного приложения на микросервисы - долгий и сложный путь, обычно требующий компромиссов.

Привет, меня зовут Владимир Кустиков, я — архитектор решений в e-Legion. И сегодня я хотел бы рассказать вам про микросервисы.

Наверное, я где-то неправ. А возможно, что у меня просто подгорело. Но в какой-то момент после запроса рассказать о том, в каких проектах я успешно применял микросервисы, мое терпение лопнуло. Ни в каких, понятно?! И это мой персональный повод для гордости. Если вам вдруг стало интересно, что еще может рассказать этот странный безумец с пылающим взором, то у меня есть хорошая новость — ниже о микросервисах будет адаптированный под хаброформат рассказ с картинками. А если нет — смело закрывайте эту статью.

Этим летом абитуриентам было жарко, МГУ по проходному баллу почти превратился в ПТУ, а кто-то успешно поступил в вооруженные силы РФ, сам того не желая. Отсутствие автоматизации в 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.