Книга Сэма Ньюмена «Создание микросервисов»

book_sozdanie_mikroservisovВ последнее время я решил прокачать свои знания в той области, которую называют DevOps (от слов development и operations) — области, объединяющей в себе разработку, тестирование и развертывание программного обеспечения. Недавно я уже писал обзор очень интересной книги на эту тему — Непрерывное развертывание ПО. В продолжение этой темы мне попалась довольно свежая книга Сэма Ньюмена «Создание микросервисов», вышедшая в этом году.

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

Когда кто-то впервые встречается с термином «микросервис», возникает логичный вопрос: «Что считать микросервисом?» На самом деле этот вопрос не такой простой, как и любой вопрос терминологии. В книге автор приводит несколько определений микросервиса. Общее определение микросервиса дается следующее:

Микросервисы — это небольшие, автономные, совместно работающие сервисы.

Но какие сервисы считать «небольшими»? Отвечая на этот вопрос, автор приводит ответ Джона Ивса, который называет микросервисом такой сервис, который можно переписать за две недели. Остальные определения термина «небольшой» более абстрактные.

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

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

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

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

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

При выборе архитектуры важно определиться с тем, как микросервисы будут между собой взаимодействовать: синхронно или асинхронно, как они будут управляться (по так называемому оркестровому принципу, когда есть один сервис, управляющий всеми остальными, или по хореографическому принципу, когда микросервисам будет ставиться задача, а они ее будут решать более-менее независимо). Также придется выбрать инструмент, с помощью которого будут осуществляться удаленные вызовы и передача данных — использовать RPC или REST, JSON или XML. Возникнет вопрос о том, как управлять версиями развертываемых микросервисов, как выделить интерфейс, видимый стороннему пользователю микросервиса, а какой интерфейс оставить для внутреннего использования. Этим вопросам посвящена четвертая глава.

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

Шестая глава посвящена развертыванию микросервисов, и тут автор коротко пересказывает уже упомянутую выше книгу Непрерывное развертывание ПО со ссылкой на нее. Здесь тоже говорится о построении конвейера развертывания, когда приложение проходит несколько стадий тестирования (чему будет посвящена следующая, седьмая глава), о хранении артефактов (собранных версий приложения), настроек и т.п. В отличие от книги Хамбла и Фарли, в «Создании микросервисов» упоминаются такие инструменты как Docker и Vagrant.

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

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

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

И последняя глава кратко подводит итог всей книге.

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

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

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

PS. Вы можете подписаться на новости сайта через RSS, Группу Вконтакте или Канал в Telegram.

Пожалуйста, оцените запись

УжасноПлохоТак себеХорошоОтлично (Количество голосов: 3, средняя оценка: 3,67)
Загрузка...

Leave a comment

Subscribe without commenting