Микросервисы — пожалуйста, не надо | Блог CEO, CIO Виктора Карабедянц

Данная статья изначально была опубликована на Basho. Она является адаптированной версией блестящей речи Sean на встрече Boston Golang в декабре 2015.

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

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

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

Что же все-таки такое «Микросервис»?

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

Повторюсь, это не монолит. На практике это означает, что микросервис имеет дело с ограниченной зоной домена, таким образом, он выполняет только те функции, которые необходимы для определенной цели в вашем стеке. Покажем вам на более конкретном примере: если бы вы были банком с “Login Service” (служба входа), последнее, чтобы вы хотели, это дать ему доступ к записям финансовых операций пользователей. Вы бы предоставили это “Transaction Service”(службе транзакций) (помните, что трудно давать названия).

Кроме этого, когда говорят о микросервисах, люди часто косвенно говорят о сервисах, которым необходимо «общаться» с другими удаленно. Так как они являются отдельными процессами и довольно часто работают в отдаленных друг от друга местах, часто эти сервисы создают так, что они могут «общаться» внутри сети, используя REST или какой-то другой протокол RPC.

Изначально, все кажется довольно таки легким – мы только завернем крошечные части домена в REST API, какого либо типа, и мы получим, что все начнут говорить друг с другом внутри сети. Исходя из моего опыта, существует 5 «истин» данного подхода, в которые люди верят, хотя это не всегда так:

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

Заблуждение №1. Более чистый код.

«Вам не нужно вводить сетевое ограничение, как предлог для написания лучшего кода»

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

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

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

Следующий плюс данного подхода, при условии, что он четко отражает Service Oriented Architecture(сервис-ориентированную архитектуру), построенную на основе микросервисов, заключается в том, что к тому времени, когда вы решите, что пора переходить к микросервисам, вы уже должны проделать огромную часть проектных работ. Более того, вы, вероятно, уже разобрались в своем домене настолько хорошо, что сможете извлечь его. Основательный подход SOA начинается в самом коде и переходит с течением времени в физическую топологию стека.

Заблуждение №2. Легче писать модули

«Распределенные транзакции никогда не бывают легкими»

Хотя вначале может показаться, что всё легко, большинство доменов (особенно в современных компаниях, которым необходимо создавать прототип, делать pivot и, как правило, переопределять сам домен много раз) не поддаются аккуратному разделению на маленькие коробочки. Временами, определенным частям домена необходимо установить связь и получить данные о других частях, чтобы работать правильно. Ситуация усложняется, когда домену нужно передать ответственность за регистрацию данных за своими пределами. Выйдя за территорию своего влияния, и при необходимости вовлечь других в поток запросов на хранение и изменение данных, вы находитесь в зоне распределенных транзакций (иногда известных как Sagas)

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

Заблуждение №3. Это быстрее

«Вы могли бы получить хорошую производительность в монолитах, применив небольшую дополнительную дисциплину»

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

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

Кроме этого, многие из этих историй о получении производительности являются, по сути, рекламой преимуществ нового языка или полностью технологии стека, а не только концепт создания кода для функционирования в микросервисе. Перепись старого Ruby on Rails, или Django, или NodeJS приложения на такие языки, как Scala или Go (два известных выбора архитектуры микросервиса) приведет к значительному улучшению производительности, свойственному выбору самой технологии. Но этим языкам «неважно», что вы выбрали для них название «микро», они работаю лучше только из-за, например, компиляции.

Далее, для большинства приложения в стартапах чистые CPU или производительность памяти почти никогда не являются вашей проблемой. Она в I/O – а дополнительные вызовы сети только увеличивают I/O.

Заблуждение №4 Просто для инженеров

«При работе группы инженеров в изолированных кодовых базах, появляется синдром «Не моя проблема»»

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

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

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

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

Заблуждение №5 Лучше масштабируется

«Вы можете масштабировать микросервиса вширь так же легко, как и монолит»

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

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

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

Когда вам следует использовать микросервисы?

«Когда вы готовы как инженерная организация»

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

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

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

Наравне с пониманием вашего рабочего окружения стоит его мониторинг. Мониторинг – предмет намного важнее, чем просто «Микросервис против Монолита», но это то, что должно быть в основе ваших инженерных стараний. Вам нужно иметь под рукой большое количество данных о разных частях вашей системы, чтобы понимать, почему одна из них недостаточно эффективно работает или даже генерирует ошибки. Если у вас есть хорошая система мониторинга разных частей системы, вы поймете поведение данной системы при горизонтальном масштабировании.

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

Выводы

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

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