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

Это завершение переводной статьи о разработке транзакционных приложений с использованием микросервисной архитектуры. Начало.

В первой части статьи мы говорили, что основным препятствием при использовании микросервисной архитектуры является то, что модели предметной области (domain model), транзакции и запросы удивительно устойчивы к разделению по функциональному признаку. Было показано, что решение заключается в реализации бизнес-логики каждого сервиса в виде набора DDD-агрегатов. Каждая транзакция обновляет или создает один единственный агрегат. События используются для поддержания целостности данных между агрегатами (и сервисами).

Во второй части статьи мы увидим, что ключевой задачей при использовании событий является атомарное изменение состояния агрегата и одновременная публикация события. Посмотрим, как решить эту проблему с помощью Event Sourcing — используя событийно-ориентированный подход к проектированию бизнес-логики и системы сохранения состояния. После этого опишем, как микросервисная архитектура затрудняет реализацию запросов к базе данных, и как подход, называемый Command Query Responsibility Segregation (CQRS), помогает реализовывать масштабируемые и производительные запросы.

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

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

Однако микросервисы являются не таким уж простым и универсальным решением. В частности, модели предметной области, транзакции и запросы удивительно устойчивы к разделению по функциональному признаку. В результате разработка транзакционных бизнес-приложений с использованием микросервисной архитектуры является довольно сложной задачей. В этой статье мы рассмотрим способ разработки микросервисов, при котором эти проблемы решаются с помощью паттерна проектирования на основе предметной области (Domain Driven Design), Event Sourcing и CQRS.

К сожалению, у меня нет опыта работы с микросервисами, но около года назад я очень активно интересовался этой темой и изучил все источники информации, какие смог найти. Я просмотрел несколько выступлений на конференциях, прочитал несколько статей очень авторитетных и опытных специалистов вроде Мартина Фаулера, Фреда Джорджа, Эдриана Кокрофта и Криса Ричардсона, чтобы как можно больше узнать о микросервисах. Эта статья — результат моих изысканий.

Среди беспорядка найдите простоту; среди раздора найдите гармонию; в трудности найдите возможность...
(С) Альберт Эйнштейн

Статей о микросервисах, их достоинствах и недостатках в последнее время написано немало. Однако как-то редко кто пишет об имплементации микросервисной архитектуры, и прежде всего, именно об микросервисе, как о кирпичике, из которой и строится потом здание такого приложения. Я попытался восполнить этот пробел, и поделиться своим опытом в разработке http-микросервиса, вылившемся в конечном счёте в небольшую библиотеку под не оставляющим места для сомнений названием Microservice. Код написан на прекрасно подходящем для микросервисов, простом и удобном языке программирования Golang.

Преамбула

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

Все паттерны разработки, как правило, имеют свои плюсы и минусы. Таким образом, преимущества зачастую носят субъективный характер и разработчику следует выбирать подходящие модели в зависимости от условий и контекста.

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

Иллюстрация @alvaro_sanchez

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

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

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

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

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

Автор: Вячеслав Михайлов

Монолитные приложения и их проблемы

Все прекрасно знают, что такое монолитное приложение: все мы делали такие двух- или трехслойные приложения с классической архитектурой:

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

Так или иначе, по мере роста и развития приложения, вы сталкиваетесь с проблемами монолитных архитектур:

• сложность системы постоянно растет;
• поддерживать ее все сложнее и сложнее;
• разобраться в ней трудно — особенно если система переходила из поколения в поколение, логика забывалась, люди уходили и приходили, а комментариев и тестов нет);
• много ошибок;
• мало тестов — монолит не разобрать и не протестировать, поэтому обычно есть только UI-тесты, поддержка которых обычно занимает много времени;
• дорого вносить изменения;
• застревание на технологиях (например, я работал в компании, где с 2003 г. технологии до сих пор не изменились).

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

Друзья, приглашаем всех желающих посетить нашу третью встречу ThinkJava. На этот раз мы полностью посвящаем её теме микросервисов: что это такое, как начать их использовать, с какими проблемами можно столкнуться и как их решить, а также как обеспечить безопасность приложения с микросервисной архитектурой.

Последние несколько лет микросервисы остаются одним из наиболее актуальных подходов к разработке крупных приложений. Осенью прошлого года эксперты компании NIX Solutions изучали все нюансы микросервисной архитектуры на крупнейшей международной отраслевой конференции Spring One 2GX. С тех пор наши разработчики успели опробовать многое из услышанного на практике, поэкспериментировать с микросервисами, наступить на некоторые грабли, научиться избегать ошибок или же без потерь устранять их последствия. А заодно освоили различные инструменты разработки микросервисных приложений.

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

Здравствуйте, Хабр!

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

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

Здравствуйте, дорогие читатели!

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

Много Java, JavaScript, схем, рассуждений и очень много текста

Ранее мы уже рассказывали о дата-центре фотосервиса imgix, описывали детективную историю поиска проблем с SSD-дисками проекта Algolia, а сегодня представляем вашему вниманию обсуждение того, как команда стримингового сервиса SoundCloud перешла на использование микросервисов.

Видео: skillsmatter.com/skillscasts/5235-keynote-an-integrated-services-approach
Длинна: 1 час, сайт требует регистрации (email) перед показом видео. На сайте много интересных видеоматериаллов.

Udi Dahan — автор NServiceBus и очень талантливый оратор и учитель. Я слежу за его выступлениями уже несколько лет — Udi всегда есть что сказать и слушать это познавательно и интересно.

Презентации открывала 2й день конференции посвященной микросервисам, Udi весело и аргументированно осмеял популярную нынче тему микросервисов и предложил отслеживать логическую и физическую реализацию, еще раз подумать “зачем нам этот цирк” и провести паралелли между орг структорой, сервисами и многофункциональными командами. Мне лично было очень интересны моменты не “как писать/разворачивать микросервис?” (как бы тактика), а “зачем?” и “чем этот подход лучше?” и собственно как это может жить в большой организации (как бы стратегия).

От переводчика: с момента выхода популярной статьи Мартина Фаулера «Микросервисы» (перевод на Хабре) прошло уже достаточно времени, чтобы автор смог дополнить свои наблюдения свежим опытом проектирования и разработки микросервисов в различных компаниях, и рассказать о нем в новом посте, чей перевод представляется вашему вниманию.
Многие команды разработчиков нашли архитектурный стиль микросервисов подходом, превосходящим монолитную архитектуру; другие команды выяснили, что для них микросервисы — лишняя обуза, подрывающая производительность разработки. Как и у любого стиля архитектуры, у микросервисов есть свои плюсы и минусы. Для того, чтобы делать осознанный выбор, вы должны понимать эти свойства и уметь рассматривать их на фоне собственных конкретных условий.

Микросервисы дают преимущества…	…ценою издержек
Жесткие границы модулей Strong Module Boundaries Микросервисы усиливают модульную структуру, что особенно важно для больших команд разработчиков.	Распределённость Distribution Распределенные системы тяжелее программировать, поскольку удаленные вызовы медленные и всегда рискуют неудачей-отказом.
Независимый деплоймент Independent Deployment Простые сервисы проще деплоить, и, поскольку они автономны, меньше вероятность отказа системы в случае, если что-то идет не так.	Консистентность в конечном счете Eventual Consistency Поддержка cтрогой консистентности чрезвычайно сложна для распределённых систем, и это означает, что придется иметь дело с консистентностью в конечном счете.
Технологическое разнообразие Technology Diversity С микросервисами вы можете смешивать несколько языков, фреймворков и технологий хранения данных.	Эксплуатационная сложность Operational Complexity Вам потребуется опытная команда эксплуатации для управления множеством сервисов, которые будут регулярно редеплоиться.

В предыдущей публикации я писал о плюсах использования микросервисной архитектуры. Сейчас же хочу описать процесс создания одного полезного микросервиса. Забегая вперед, скажу, что будет еще одна «микросервисная» статья, посвященная печальному результату погони за технологией, а не за смыслом.

Задача

В тестовом заданий от компании Wheely мне предстояло реализовать аутентификацю через код в смс-сообщении. Суть процесса в следующем:

1. Пользователь совершаете какое-либо действие.
2. Для подтверждения этого действия генерируется код.
3. Код отправляется в СМС-сообщении.
4. Пользователь указывает ключ.
5. Ключ проверяется на соответствие.

Результатом должно было стать самостоятельное приложение, которое выполняет задачи, обозначенные в пунктах 2, 3 (только имитация), 5. Пины становятся не актуальны через 2 минуты после генерации. Все остальное на мое усмотрение.

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

Знакомство с микросервисной архитектурой серьезно изменило мой подход к разработке. В этой публикации я расскажу о различных аспектах использования микросервисов. Для иллюстрации некоторых из них буду использовать архитектуру проекта по аренде недвижимости.

Подопытное приложение
Клиент просматривает список доступных квартир и бронирует их, также он может размещать на сервисе свои квартиры.

При классическом подходе для построения чаще всего выбирается фреймворк и внутри него реализуются компоненты. В случае с микросервисами для каждого компонента строится отдельное приложение и подбирается свой набор инструментов. Компоненты чаще всего взаимодействуют через REST API.

Компоненты: C — данные по квартирам (ядро), 1 — бронирование, 2 — оплата, 3 — логирование броней, 4 — размещение квартир, 5 — администрирование контента.

Обратите внимание, что перед созданием микросервисного приложения придется как следует продумать бизнес-логику и разбить приложение на самодостаточные компоненты. А теперь поговорим о том, почему микросервисы это круто.

Здравствуйте, уважаемые хабровчане!

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

Эта непростая книга называется «Создание микросервисов», автор — Сэм Ньюмен.

Цель данной статьи — показать возможный подход для построения микросервисов с использованием Scala, RESTful JSON, Spray и Akka. В качестве базы данных мы будем использовать MongoDB. В результате нашей работы мы упакуем наш проект в Docker-контейнер, а Vagrant и Ansible позволит нам управлять конфигурацией приложения.

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