Кроме того, помощь и отзывы о ранних версиях книги поступали и от многих других людей. Особенно хочется поблагодарить (не придерживаясь какого-либо определенного порядка) Кейна Венейблса (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. Сэму доводилось работать с компаниями со всего мира в самых разных предметных областях, зачастую заниматься одновременно и разработкой, и поддержкой ПО. Если спросить Сэма, чем он занимается, то он ответит: «Работаю с людьми, чтобы создавать все более и более классные софтверные системы». Сэм Ньюмен — автор статей, докладов на конференциях, время от времени он участвует в разработке свободных проектов.
От издательства
Ваши замечания, предложения и вопросы отправляйте по адресу электронной почты sivchenko@minsk.piter.com (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На сайте издательства 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), или может быть процессом своей собственной операционной системы. Мы стараемся не заполнять несколькими сервисами одну и ту же машину, хотя определение машины в современном мире весьма размыто! Чуть позже мы разберемся в том, что, несмотря на издержки, которые могут быть вызваны обособленностью, получаемая в результате использования такого сервиса простота существенно облегчает рассуждения о распределенной системе, а самые последние технологии позволяют смягчить множество проблем, связанных с этой формой развертывания.
Обмен данными между самими сервисами ведется через сетевые вызовы, чтобы упрочить обособленность сервисов и избежать рисков, сопряженных с тесными связями.
Этим сервисам необходимо иметь возможность изменяться независимо друг от друга и развертываться, не требуя никаких изменений от потребителей. Нам нужно подумать о том, что именно наши сервисы будут показывать и что им можно будет скрывать. Если объем совместно используемого будет слишком велик, потребляемые сервисы станут завязываться на внутренние представления. Это снизит автономность, поскольку при внесении изменений потребует дополнительного согласования с потребителями.