Создание микросервисов

Сэм Ньюмен

Создание микросервисов

Предисловие

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

Эта книга полна конкретных примеров использования микросервисов, собранных по всему миру, включая их применение в таких организациях, как Netflix, Amazon, Gilt и REA group, пришедших к мысли, что возросшая автономность этой архитектуры дает их командам огромные преимущества.

Для кого написана эта книга

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

Зачем я написал эту книгу

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

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

Мир микросервисов сегодня

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

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

Структура книги

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

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

Вот краткий обзор всего, что рассматривается в данной книге.

• Глава 1. Микросервисы. Начинается с введения в микросервисы с указанием как их преимуществ, так и некоторых недостатков.

• Глава 2. Архитектор развития. Посвящена трудностям компромиссов в архитектурах и многообразию всего, что нужно осмыслить при использовании микросервисов.

• Глава 3. Как моделировать сервисы. Начинается с определения границ микросервисов с использованием в качестве вспомогательных средств, направляющих мысли в нужное русло, технологий, позаимствованных из проектирования, основанного на областях применения.

• Глава 4. Интеграция. В этой главе начинается погружение в конкретные технологические последствия по мере рассмотрения наиболее подходящих нам разновидностей технологий обеспечения совместной работы сервисов. В ней также более глубоко рассматривается тема пользовательских интерфейсов и интеграции с устаревшими и уже готовыми коммерческими программными средствами (COTS-продуктами).

• Глава 5. Разбиение монолита на части. Многие специалисты рассматривают микросервисы в качестве своеобразного антидота от крупных, слабо поддающихся изменениям монолитных систем. Именно этот вопрос и будет подробно рассмотрен в данной главе.

• Глава 6. Развертывание. Хотя данная книга носит преимущественно теоретический характер, некоторые темы в ней были подняты под влиянием последних изменений в таких технологиях, как развертывание, которое и станет предметом рассмотрения.

• Глава 7. Тестирование. Данная глава посвящена углубленному рассмотрению темы тестирования, к которой следует отнестись с повышенным вниманием, когда речь зайдет о развертывании нескольких отдельных сервисов. Особо будет отмечена роль, которую в содействии обеспечению качества программных средств могут сыграть контракты, основанные на запросах потребителей.

• Глава 8. Мониторинг. Тестирование программного средства перед развертыванием не помогает, если проблемы обнаруживаются во время его работы в производственном режиме, поэтому в данной главе исследуются возможности мониторинга систем, обладающих высокой степенью детализации, и методы, позволяющие справиться со сложностями, присущими распределенным системам.

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

• Глава 10. Закон Конвея и проектирование систем. Основное внимание в данной главе уделяется взаимодействию организационной структуры и архитектуры. Многие организации уже поняли, что если не добиваться в этом вопросе гармонии, то возникнут существенные затруднения. Мы попытаемся добраться до самых глубин этой дилеммы и рассмотрим несколько различных способов увязки проектирования системы со структурой команд.

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

• Глава 12. Коротко обо всем. В заключительной главе предпринимается попытка выделить основные черты, отличающие микросервисы от всего остального. В ней перечислены семь принципов микросервисов, а также подведены итоги по ключевым моментам книги.

Соглашения, принятые в этой книге

В тексте книги действуют следующие типографские соглашения:

Курсив

Служит признаком новых понятий.

Моноширинный шрифт

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

Моноширинный полужирный шрифт

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

Моноширинный курсивный шрифт

Показывает текст, который должен быть заменен предоставляемыми пользователем значениями или значениями, определяемыми контекстом.

Благодарности

Эта книга посвящается Линде Стивенс (Lindy Stephens), без которой книги бы просто не существовало. Она воодушевила меня начать этот путь, поддерживала в течение всего полного стрессовых ситуаций периода написания книги и проявила себя партнером, лучше которого я бы не смог себе даже пожелать. Мне хотелось бы посвятить эту книгу также своему отцу, Говарду Ньюману (Howard Newman), который всегда был рядом со мной. Эта книга посвящается им обоим.

Мне хотелось бы выделить Бена Кристенсена (Ben Christensen), Вивека Субраманьяма (Vivek Subramaniam) и Мартина Фаулера (Martin Fowler) за подробные отзывы в процессе написания книги и оказание помощи в формировании ее облика. Мне также хочется поблагодарить Джеймса Льюиса (James Lewis), с которым мы выпили немало пива, обсуждая идеи, представленные в данной книге. Без их помощи и консультаций эта книга представляла бы жалкую тень самой себя.

Кроме того, помощь и отзывы о ранних версиях книги поступали и от многих других людей. Особенно хочется поблагодарить (не придерживаясь какого-либо определенного порядка) Кейна Венейблса (Kane Venables), Ананда Кришнасвами (Anand Krishnaswamy), Кента Макнила (Kent McNeil), Чарльза Хайнса (Charles Haynes), Криса Форда (Chris Ford), Айди Льюиса (Aidy Lewis), Уилла Темза (Will Thames), Джона Ивса (Jon Eaves), Рольфа Рассела (Rolf Russell), Бадринатха Янакирамана (Badrinath Janakiraman), Даниэля Брайанта (Daniel Bryant), Яна Робинсона (Ian Robinson), Джима Уэббера (Jim Webber), Стюарта Глидоу (Stewart Gleadow), Эвана Ботчера (Evan Bottcher), Эрика Суорда (Eric Sword), Оливию Леонард (Olivia Leonard) и всех остальных коллег из ThoughtWorks и других организаций, которые помогли мне пройти этот длинный путь.

И в заключение я хочу поблагодарить всех специалистов издательства O’Reilly, включая Майка Лукидиса (Mike Loukides), за оказанное мне доверие, моего редактора Брайана Макдональда (Brian MacDonald), Рэйчел Монаган (Rachel Monaghan), Кристен Браун (Kristen Brown), Бетси Валишевски (Betsy Waliszewski) и всех других, кто помог мне в том, о чем я сам и не догадывался.

Об авторе

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

От издательства

Ваши замечания, предложения и вопросы отправляйте по адресу электронной почты [e-mail] (издательство «Питер», компьютерная редакция).

Мы будем рады узнать ваше мнение!

На сайте издательства http://www.piter.com вы найдете подробную информацию о наших книгах.

1. Микросервисы

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

Книга Эрика Эванса (Eric Evans) по предметно ориентированному проектированию Domain-Driven Design (Addison-Wesley) помогла нам осознать важность отображения в коде реального мира и показала более удачные способы моделирования наших систем. Концепция непрерывной поставки показала, как можно более эффективно и рационально внедрять продукты в производство, вселяя в нас идею о том, что завершением каждого рабочего этапа должен считаться выпуск предварительной версии продукта. Понимание порядка работы Всемирной сети привело нас к разработке более эффективных способов организации межмашинного общения. Концепция Алистера Кокберна (Alistair Cockburn) о гексагональной архитектуре увела нас от многоуровневых архитектур, в которых бизнес-логика может быть скрыта. Платформы виртуализации позволяют обеспечивать наши машины и изменять их размеры по своему усмотрению, а автоматизация инфраструктуры дает способ управления этими машинами на должном уровне. Многие крупные и успешные организации, такие как Amazon и Google, поддерживают намерение небольших команд владеть полным жизненным циклом своих сервисов. А совсем недавно компания Netflix поделилась с нами способами создания прочных (antifragile) систем в том масштабе, который трудно было себе даже представить еще 10 лет назад.

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

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

Что же такое микросервисы

Микросервисы — это небольшие, автономные, совместно работающие сервисы. Разберем это определение по частям и рассмотрим, что определяет отличительные черты микросервисов.

Небольшие и нацеленные на то, чтобы хорошо справляться только с одной работой

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

Внутри монолитных систем мы стремимся бороться с этой тенденцией, пытаясь сделать свой код более связанным, зачастую путем создания абстракций или модулей. Придание связности означает стремление сгруппировать родственный код. Эта концепция приобретает особую важность при размышлении о микросервисах. Она усиливается определением, данным Робертом С. Мартином (Robert C. Martin) принципу единственной обязанности — Single Responsibility Principle, которое гласит: «Собирайте вместе все, что изменяется по одной и той же причине, и разделяйте все, что изменяется по разным причинам».

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

Мне часто задают вопрос: а что является критерием понятия «небольшой»? Задание количества строк кода для этого вряд ли подойдет, поскольку одни языки выразительнее других и способны на большее при меньшем количестве строк. Нужно также считаться с тем фактом, что мы могли бы быть втянуты в ряд зависимостей, которые сами по себе содержат множество строк кода. Кроме того, некоторые составляющие вашей области деятельности могут быть сложными по определению и требовать немалого объема кода. Джон Ивс (Jon Eaves) из Австралии на сайте RealEstate.com.au охарактеризовал микросервисы как некий код, который может быть переписан за две недели, что имело вполне определенный смысл в качестве основного правила конкретно в его контексте.

Еще один несколько банальный ответ может прозвучать так: достаточно небольшой и не меньше этого. Выступая на конференциях, я почти всегда задаю вопрос: «У кого есть слишком большая система, которую хотелось бы разбить на части?» Руку поднимают практически все. Похоже, мы прекрасно понимаем, что может считаться слишком большим, и можно будет согласиться с тем, что тот фрагмент кода, который уже нельзя назвать большим, будет, наверное, достаточно небольшим.

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

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

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

Автономные

Наш микросервис является самостоятельным образованием, которое может быть развернуто в качестве обособленного сервиса на платформе, предоставляемой в качестве услуги, — Platform as a Service (PAAS), или может быть процессом своей собственной операционной системы. Мы стараемся не заполнять несколькими сервисами одну и ту же машину, хотя определение машины в современном мире весьма размыто! Чуть позже мы разберемся в том, что, несмотря на издержки, которые могут быть вызваны обособленностью, получаемая в результате использования такого сервиса простота существенно облегчает рассуждения о распределенной системе, а самые последние технологии позволяют смягчить множество проблем, связанных с этой формой развертывания.

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

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

Наши сервисы выставляют напоказ программный интерфейс приложения — Application Programming Interface (API), и работающие на нас сервисы связываются с нами через эти API. Нужно также подумать о технологии, позволяющей не привязывать сами интерфейсы к потребителям. Это может означать выбор API, нейтральных по отношению к тем или иным технологиям, чтобы гарантировать отсутствие ограничений в выборе технологий. На страницах этой книги мы еще не раз вернемся к вопросу о важности качественных, ни к чему не привязанных API.

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

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

Основные преимущества

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

Технологическая разнородность

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

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

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

Рис. 1.1. Микросервисы позволяют упростить использование разнообразных технологий

Разумеется, использование нескольких технологий не обходится без определенных издержек. Некоторые организации предпочитают накладывать на выбор языков ограничения. В Netflix и Twitter, к примеру, в качестве платформы используется преимущественно Java Virtual Machine (JVM), поскольку они очень ценят надежность и производительность этой системы. В этих организациях также разрабатываются библиотеки и инструментальные средства для JVM, существенно упрощающие работу в масштабе платформы, но сильно усложняющие ее для сервисов и клиентов, не работающих на Java-платформе. Но для всех заданий ни в Twitter, ни в Netflix не используется лишь один набор технологий. Еще одним аргументом в противовес опасениям по поводу смешения различных технологий является размер. Если я действительно могу переписать свой микросервис за две недели, то вы также можете снизить риск применения новой технологии.

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

Устойчивость

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

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

Устойчивость в ее лучших проявлениях и методы борьбы с отказами будут рассматриваться в главе 11.

Масштабирование

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

Рис. 1.2. Можно расширять только те микросервисы, которые в этом нуждаются

Именно по этой причине микросервисами воспользовалась компания Gilt, занимающаяся продажей через Интернет модной одежды. Начав в 2007 году с использования монолитного Rails-приложения, к 2009 году компания столкнулась с тем, что используемая система не в состоянии справиться с возлагаемой на нее нагрузкой. Разделив основные части своей системы, Gilt смогла намного успешнее справляться со всплесками трафика, и теперь компания использует 450 микросервисов, каждый из которых запущен на нескольких отдельных машинах.

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

Простота развертывания

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

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

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

Решение организационных вопросов

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

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

Компонуемость