Повышаем свою стоимость: Микросервисная архитектура

Разумеется, я не мог обойти стороной мистера "выскочку", "хайпожора", предмет гневных холиваров среди разработчиков. Если говорить об MVW ("Model-View-Whatever"), то в большинстве своем на этих подходах строятся так называемые "монолиты". У них есть свои плюсы и минусы. В противовес им появилась концепция микросервисов, которая избавляется от минусов монолитов, но добавляет своих проблем. И ведь всегда так в индустрии - разработчики из добрых побуждений создают инструменты, подходы или ЯПы, которые решают проблемы других инструментов, подходов или ЯПов, а в итоге у нас становится на один больше проблемных инструментов, подходов или ЯПов.

Монолитная архитектура

Как примерено было устроено MVC веб-приложение лет эдак 15 - 20 назад? Бралась какая-нибудь популярная реляционная СУБДэшечка (MySQL, MSSQL, PostgreSQL), пилилась на ней схема БД на родненьком SQL или ORM (Object-Relational Mapping), затем делались сервисы для работы с данными, эти сервисы инжектились в конструкторы контроллеров (DI - Dependency Injection, одна из форм IoC, буковка "D" в SOLID), контроллеры при их вызове со стороны View работали с данными через интерфейс сервисов, а результатом выполнения запроса возвращали новое View, в которое через шаблонизаторы вставляли новые данные. Все было чётенько, JS тогда особо никому интересен не был, потому с фронтом не заморачивались, в шаблонах делали простенькую верстку со стилями и возвращали вьюшки клиенту, сгенерированные на стороне сервера.

Даже понятий таких не было - backend, frontend и fullstack. Были просто веб-разработчики, которые могли всё веб-приложение построить самостоятельно, никакого разделения, только суровые бородатые мужики, только хардкор!

Почему это считалось нормальным? Да технологий было мало, тот же AJAX в привычном виде только в 2005 году появился, а до него сервера могли только новые странички возвращать при каждом запросе. У JS тоже не все хорошо было (что уж говорить, если его на коленке слепили несколько человек), максимум что на нем делали - запускали снежок перед Новым годом.

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

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

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

И щито в таких случаях делать? Правильно, придумать новые подход и архитектуру.

Микросервисная архитектура

И подумали умные люди: "А какого лешего мы держим все в одном месте? Зачем раздуваем проект до таких лютых масштабов, что сами потом разгрести не можем? Давайте поделим все на мелкие автономные части."

В чем идея? Допустим, вы делаете все тот же пресловутый Интернет-магазин. У него есть регистрация, аутентификация и авторизация пользователей, список товаров, корзина с заказами, оплата. При желании еще можно воткнуть коммуникацию с продавцом и новостной бложик. И админка, разумеется. И за каждую функциональность будет отвечать отдельный микросервис.

В чем преимущества? Каждый микросервис - это отдельный маленький модуль с минимально возможным количеством кода. Что означает простую поддержку, рефакторинг, тестирование. Кроме того, за счет слабой связанности микросервисов, их можно реализовывать на любой любимой технологии. Нравится Python и Flask? Пожалуйста. Динамические языки сидят в печенке и хочется чего-нибудь типизированного? Не вопрос. Хочется упороться и начать юзать указатели на указатели? Отлично, действуйте! Можно даже собирать команды по микросервисам, и пусть каждая их них пилит только свое, не трогая и не осуждая чужое.

В чем проблема? В коммуникации. Представьте себе, что у вас 50 микросервисов. И у многих из них есть небольшие зависимости от других микросервисов. Как им общаться между собой? Кто кого первым вызывать должен? Кто должен запускаться раньше других?

На помощь приходят коммуникаторы, реализованные на разных языках и подходах. Например, самым известным инструментом для общения посредством очередей и сообщений является RabbitMQ (протокол AMQP). А среди коммуникаторов через протокол WAMP лидирует Crossbar.io.

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

Кроме этого, нужно понимать, что клиент не должен знать о всех микросервисах, в которые ему нужно посылать запросы. Для этого необходимо создавать прослойку, так называемый "gateway", в который клиент будет посылать запросы, а тот уже сам разберется, кому их адресовать. Благо, существует тот же GraphQL, который вообще на изи позволит такую штуку провернуть.

А приправить это все нужно DevOps-ингом, ибо такую ораву микросервисов необходимо организовать в единое веб-приложение, а также оперативно доставлять их новые версии в продакшн, не сломав ничего. Тут на помощь приходит контейнеризация посредством Docker и оркестрация (Kubernetes, Docker Swarm).

То есть, получаем, с одной стороны, разделение монолита по ответственностям на микросервисы (привет, Single Responsibility) с легкой разработкой, поддержкой, рефакторингом и тестированием, с другой, усложнение коммуникации, доставки и деплоя.

Итого

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

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

А как получить столь бесценный опыт, если на работе даже близко не подпускают к таким глобальным вопросам? Тут мы плавно перетекаем в следующий блок, который занял второе место в недавнем опросе. Пока я писал прошлые статьи, я понял, что тема "pet-проектов" все равно можно отнести к повышению собственной стоимости, можно было и не выделять её отдельно. Но обо всем по порядку.