Оригнинальная статья является размышления на тему почему документация в мире микросервисов критично необходима и как ее можно создавать и публиковать используя swagger. Пошаговой инструкцией по настройке она точно не является.
Рубрика «Microservices» - 8
Документирование #Микросервисов
2017-02-23 в 10:57, admin, рубрики: api, docker, documentation, java, Microservices, rest, swagger, Тестирование веб-сервисовМногократное использование кода в микросервисной архитектуре — на примере SPRING BOOT
2017-02-17 в 14:07, admin, рубрики: api, code reuse, IT-стандарты, java, Microservices, spring boot, Блог компании Издательский дом «Питер», высокая производительность, книгиЗдравствуйте! Сегодня предлагаем вам очередной интересный пост на неисчерпаемую тему микросервисов, на этот раз — для корифеев и неофитов языка Java. Читаем и голосуем!
Читать полностью »
Подкинули задачу сделать микросервис, который получает данные от RabbitMQ, обрабатывает, и отправляет данные дальше по этапу в RabbitMQ. После отправки задания, я посмотрел на то что поучилось. Оказалось, что этот набор компонентов можно использовать для быстрого прототипирования pipeline архитектуры
Используемые компоненты:
Для примера буду делать микросервис для выдачи рейтинга игроков. От ядра системы в микросервис приходят следующие сообщения:
- player_registered(id,name);
- player_renamed(id,name);
- player_won(id, points).
Сервис раз в минуту должен отсылать сообщение с содержимым рейтинга.Рейтинг сортируется по набранным очкам за календарную неделю.
Дата снаружи, дата внутри, дата танцуй, дата умри
2016-10-17 в 13:15, admin, рубрики: data structure, Microservices, Анализ и проектирование систем, Блог компании Mail.Ru Group, микросервисы, Профессиональная литература, хранение данных
В статье «Данные снаружи и данные внутри» 2005 года Пэт Хелланд размышляет о данных в сервис-ориентированных архитектурах. В настоящее время СОА принято считать «микросервисной архитектурой», состоящей из «микросервисов». Хелланд показывает, что для инкапсулированных данных и данных, которыми обмениваются сервисы, требуются совершенно разные подходы. Переход от монолитной структуры к микросервисам более глубокий, чем просто рефакторинг кода в удобные, независимо развёртываемые модули:
Читать полностью »
Joker Student Edition: Лучшие видео прошлых конференций
2016-08-19 в 13:52, admin, рубрики: gradle, java, joker, junior, maven, Microservices, students, tools, Блог компании JUG.ru Group, доклады, конференция, прокрастинация, студентыБескрайние просторы интернета часто озаряются вспышками праведного гнева по поводу бессмысленности и бесполезности студентов-айтишников, нашего образования и сетований в стиле «раньше трава была зеленее».
Этот пост получится большим, а все вот почему: мы рассмотрим ТОП-5 докладов с двух наших студенческих конференций (Joker 2015 University Day и JPoint 2016 Student Day), поговорим о том, чего хочет молодежь в 2016 году, а также пройдемся по новому формату Joker 2016 Student Edition (Петербург, 15 октября, Экспофорум).
Читать полностью »
Управление Docker проектом со множеством git репозиториев
2016-07-26 в 4:00, admin, рубрики: docker, docker-compose, Microservices, докер, Программирование, Разработка веб-сайтовКоманда, в которой я работаю, использует микросервисную организацию в проектах.
У каждого микросервиса свой репозиторий. Каждый микросервис это docker контейнер.
Для среды разработки, чтобы запустить все вместе, мы используем docker-compose.
Кроме того, мы используем концепцию разделения процессов сборки приложения и упаковки контейнера, чтобы не тащить исходные коды и утилиты разработки в контейнеры.
Мы столкнулись с двумя проблемами:
- При первоначальном разворачивании среды разработки, приходится обьяснять программисту, либо писать скрипт инициализации, который склонирует и создаст необходимую иерархию папок из нескольких репозиториев.
- docker-compose не может собрать приложение, а потом упаковать в идижд. он умеет только запускать
docker build.
Для решения этих проблем мы сделали управляющий скрипт docker-project, который оказался очень удобным в работе.
Чем мы и хотим поделиться с open-source сообществом.
Финализирована программа коммьюнити-трека конференции DevCon 2016
2016-05-16 в 7:56, admin, рубрики: alm, angular, azure, cloud, devcon, DevCon 2016, IoT, microframework, Microservices, Microsoft Azure, PowerBI, Блог компании Microsoft, Разработка для интернета вещей
Привет!
Рады представить уже участникам и еще-не-участникам-но-планирующим финальную программу коммьюнити-трека. В этом году мы решили немного сменить траекторию, и дать голос сообществу. Траекторию сменили, и в коммьюнити-треке за два дня выступит 25 докладчиков. Это люди, занимающиеся совершенно разными проектами, из совершенно разных компаний, разных стран, но всех их объединяет то, что они будут говорить о реальном опыте и у участников конференции будет возможность поспрашивать тех, кто в полях познакомился с той или иной технологией или решением. Под катом — подробности, о чем будет идти речь в треке. Так как на DevCon будет трансляция, а потом и записи, весь этот уникальный контент будет доступен — не пропустите!
Читать полностью »
Микросервисная архитектура, Spring Cloud и Docker
2016-04-11 в 8:18, admin, рубрики: continuous delivery, continuous integration, docker, docker-compose, eureka, feign, hystrix, java, Microservices, netflix, oauth 2.0, Ribbon, spring cloud, spring framework, zuul, виртуализация, ит-инфраструктура, Программирование, разработка, метки: microservicesПривет. В этой статье я кратко расскажу о деталях реализации микросервисной архитектуры с использованием инструментов, которые предоставляет Spring Cloud на примере простого концепт-пруф приложения.
Код доступен для ознакомления на гитхабе. Образы опубликованы на докерхабе, весь зоопарк стартует одной командой.Читать полностью »
Consul.io Часть 1
2016-03-01 в 2:30, admin, рубрики: architecture, consul, discovery, Microservices, Анализ и проектирование систем, Веб-разработка, ит-инфраструктура, разработка, Серверное администрирование При разработке приложений необходимо уделять особое внимание архитектуре. Если изначально этого не сделать, проблемы масштабирования могут появиться внезапно (а иногда могут не иметь решения). Масштабирование приложения и эффективное использование ресурсов на начальном этапе — это сэкономленные месяцы работы в дальнейшем.
Для предотвращения подобных проблем часто используют распределенную архитектуру, то есть архитектуру с возможностью горизонтального масштабирования всех компонентов. Но к сожалению, при реализации SOA возникают новые проблемы, а именно: связность и сложность конфигурации сервисов.
В данной статье мы расскажем об одном из discovery-сервисов под названием Consul, с помощью которого можно решить вышеизложенные проблемы и сделать архитектуру более прозрачной и понятной.
Читать полностью »
Аутентифицируем запросы в микросервисном приложении с помощью nginx и JWT
2016-02-21 в 15:36, admin, рубрики: lua-nginx-module, Microservices, nginx, ruby on rails, Веб-разработкаСтараясь оставаться в тренде и следуя веяниям моды веб разработки, последнее веб приложение я решил реализовать как набор микросервисов на ruby плюс “толстый” клиент на ember. Одна из первых проблем, вставших перед мной была связана с аутентификацией запросов. Если в классическом, монолитном, приложении все просто, используем куки, сессии, подключаем какой-нибудь devise, то тут все как в первый раз.
Архитектура
За базу я выбрал JWT — Json Web Token. Это открытый стандарт RFC 7519 для представления заявок (claims) между двумя участниками. Он представляет из себя структуру вида: Header.Payload.Signature, где заголовок и payload это запакованые в base64 json хэши. Здесь стоит обратить внимание на payload. Он может содержать в себе все что угодно, в принципе это может быть и просто client_id и какая-то другая информация о пользователе, но это не очень хорошая идея, лучше передавать там только ключ идентификатор, а сами данные хранить где-то в другом месте. В качестве хранилища данных можно использовать что угодно, но мне показалось, что redis будет оптимальным, тем более что он пригодится и для других задач. Еще один важный момент — каким ключем мы будем подписывать наш токен. Самый простой вариант использовать один shared key, но это явно не самый безопасный вариант. Коль скоро мы храним данные сессии в redis, ничто не мешает нам генерировать уникальный ключ для каждого токена и хранить его там же.
Понятно, что генерировать токены будет сервис отвечающий за авторизацию, но кто и как будет их проверять? В принципе можно проверку затолкать в каждый микросервис, но это противоречит идеи их максимального разделения. Каждый сервис должен будет содержать логику обработки и проверки токенов да еще и иметь доступ к redis. Нет, наш цель получить архитектуру в которой все запросы приходящие в конечные сервисы уже авторизованы и несут в себе данные о пользователе (например в каком-нибудь специальном заголовке).
Читать полностью »