Микросервисы и хранимые процедуры

Являются ли хранимые процедуры плохой практикой в ​​микросервисной архитектуре?

Вот мои мысли:

• большинство книг по микросервисам рекомендуют одну базу данных на микросервис. Хранимые процедуры обычно работают с монолитной базой данных.

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

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

Есть мысли по этому поводу?

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

Отказ от ответственности: мне не нравятся хранимые процедуры из POV разработчика, но это никак не связано с микросервисами.

Хранимые процедуры обычно работают с монолитной базой данных.

Я думаю, что вы уступаете логической ошибке.

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

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

большинство книг по микросервисам рекомендуют одну базу данных на микросервис.

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

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

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

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

Sprocs страдают от сильной связи вообще независимо от микросервисов. Я бы посоветовал против sprocs в целом, но не особенно, потому что вы используете микросервисы. Это тот же аргумент, что и раньше: я не думаю, что sprocs - это путь (в общем), но это может быть просто моим предубеждением, и это не связано с микросервисами.

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

Это всегда было моей главной претензией к sprocs: бизнес-логике в базе данных. Даже если это не намерение, оно всегда так или иначе заканчивается таким образом.

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

Для написания программного обеспечения требуется тесная связь с технологией.

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

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

• Network Service Framework для обеспечения реализации протокола HTTP / SSL / SOAP высокого уровня
• Репозиторий / ORM / DAO Framework для обеспечения постоянства.
• Фреймворки манипулирования данными для предоставления инструментов для работы с данными.
• Process / Threading / OS Framework для обеспечения доступа к ресурсам ОС, таким как многозадачность, файловая система, память, вычисления на GPU, карты расширения и т. Д.

И это сделать микро сервис.

Хранимые процедуры

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

Что это, хотя:

• Еще одна технология. Каждая технология, представленная в приложении, уменьшает вероятность того, что любой данный программист сможет прочитать, понять и сделать разумный выбор дизайна для этого сочетания технологий.
• Язык, использующий другую парадигму программирования. Для неспециалистов слишком легко попытаться навязать им свою собственную императивную, функциональную, ОО и т. Д. Перспективу, что часто приводит к не звездным результатам.
• API. Который должен поддерживаться как любой другой класс в базе кода. Это также означает, что база данных предоставляет не универсальный интерфейс. Это затрудняет как замену самого механизма базы данных, так и прозрачное применение общего поведения, такого как кэширование памяти.
• Артефакт Который должен быть версионным, протестированным и развернутым. Это можно сделать, но базы данных - это живые артефакты, требующие другого подхода. Обычно вы не можете просто удалить оригинал и заменить его. Зачастую для того, чтобы перевести систему в нужное состояние, требуется тщательная согласованность изменений во времени.

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

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

Бизнес Логика

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

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

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

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

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

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

Архитектура

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

Это не легко

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

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

Но это тоже имеет цену.

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

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

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

1. Вы добавляете препятствия для замены систем хранения. Если некоторые эксплуатационные или производственные характеристики или ограничения функций требуют переключения механизмов хранения, стоимость будет выше, поскольку вы будете писать и тестировать много нового кода. Запуск более одного механизма хранения (либо на этапе миграции, либо для изоляции действий на основе требований к производительности) может привести к проблемам согласованности, если вы не используете двухфазную фиксацию (2PC), которая сама по себе имеет проблемы с производительностью.
2. У вас есть другой API для поддержки, что означает, что ваши зависимости могут сломаться. Добавление, удаление или изменение типов параметров в процедурах может привести к поломке существующего кода. То же самое происходит с таблицами и запросами, но ваши инструменты могут быть менее полезными для отслеживания того, где что-то может пойти не так. Проблемы с хранимыми процедурами обычно обнаруживаются во время выполнения, очень поздно в процессе разработки / развертывания.
3. Ваши права доступа к базе данных стали более сложными. Процедура запускается как зарегистрированный пользователь или как какая-то другая роль? Вы должны подумать об этом и управлять этим (надеюсь, автоматически).
4. Вы должны быть в состоянии безопасно перейти на новые версии. Часто процедура должна быть отброшена и воссоздана. Еще раз, разрешения могут вызвать некоторые проблемы для вас.
5. Откат неудачной миграции может потребовать дополнительных усилий. Когда производственная среда отделена от разработчиков, все становится еще сложнее.

Вот некоторые варианты использования хранимых процедур, которые, на мой взгляд, часто стоят:

1. Внедрение истории редактирования (журналы аудита). Триггеры обычно используются для этой цели, а триггеры являются хранимыми процедурами. В некоторых базах данных также возможно полностью запретить вставки и обновления для роли приложения: клиенты выполняют процедуры, которые выполняются как разные роли с соответствующими разрешениями и которые обеспечивают все необходимое поведение.
2. Расширение проверочных ограничений. Это может привести вас к бизнес-логике, но в некоторых случаях встроенных в базу данных инструментов ограничения может быть недостаточно для того, что вам нужно. Часто лучший способ выразить чеки - использовать императивный код, и вы рискуете ввести неверные данные, если вы зависите от своего приложения, чтобы сделать это за вас.
3. Инкапсуляция сложных запросов, когда представление неуместно или слишком сложно. Я видел несколько случаев, когда правильное представление требует некоторого чрезвычайно сложного SQL, который может быть гораздо более понятен в хранимой процедуре. Это, вероятно, редко, но это происходит.

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

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

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

большинство книг по микросервисам рекомендуют одну базу данных на микросервис.

Итак, мы можем кодировать хранимые процедуры в этих базах данных.

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

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

Обратите внимание, что «split» уже действует как разъединяющий агент. Скажем, у нас есть две службы: A поддерживается Oracle, а B - MongoDB. Если мы не нарушим золотое правило развязки, то можно будет отбросить Оракул А + с незначительными побочными эффектами на Б.

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

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

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

большинство книг MSA (которые я читал) рекомендует, чтобы микросервисы были ориентированы на бизнес (разработанные с использованием DDD).

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

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

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

Это не имеет никакого отношения к микросервисам.

Хранимые процедуры могут иметь смысл, если ваша служба имеет многоуровневую архитектуру «старого стиля», в которой БД является основой службы, с уровнями доступа к данным и бизнес-логики. Интерфейс между службой и базой данных в такой архитектуре очень специфичен для самых внутренних деталей службы. Обычно для каждого типа поддерживаемой базы данных существуют специфичные для службы адаптеры, а специфика API, предоставляемая адаптером, позволяет использовать хранимые процедуры на нижележащих уровнях.

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

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

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