гаджетыНовостиразработчиктехнология

Крис Ричардсон о взаимодействии времени разработки в микросервисах

Подпишитесь на:






Вступление [00:05]

Томас Беттс: Здравствуйте, и спасибо, что присоединились к нам для еще одного выпуска подкаста InfoQ. Я Томас Беттс, соведущий подкаста, ведущий редактор по архитектуре и дизайну в InfoQ и старший главный инженер-программист в Blackbaud. В сегодняшнем выпуске я разговариваю с Крисом Ричардсоном о минимизации связи времени проектирования в микросервисной архитектуре. Крис сделал презентацию на ту же тему на Qcon Plus, и мне очень хотелось поговорить с ним дальше и поделиться его мнениями с нашими слушателями. Мы начнем с того, что Крис определит привязку времени разработки и противопоставит ее связыванию времени выполнения. Затем мы обсудим некоторые проблемы, возникающие из-за привязки во время проектирования, анти-шаблонов и симптомов, которые являются предупреждающими знаками, когда у вас высокая взаимосвязь, а также компромиссы, которые архитекторы должны учитывать в своих проектах. Крис, спасибо, что присоединились ко мне, и добро пожаловать в подкаст InfoQ.

Крис Ричардсон: Ой, как хорошо быть здесь.

Связь во время разработки и связь во время выполнения [00:49]

Томас Беттс: Вы говорили на QCon о привязке времени проектирования в микросервисах. Можете ли вы определить для нас привязку времени проектирования, и, пожалуйста, не стесняйтесь вернуться и подготовить почву для объяснения того, почему это важно, почему мы должны думать об этом.

Крис Ричардсон: Да, и это интересно, потому что вся эта концепция связи, которая связана с модульностью, сокрытием и инкапсуляцией информации, – это концепция стара, как мир. Я имею в виду, я думаю, что это восходит как минимум к 1972 году, когда Парнас написал свою статью о наборе критериев для декомпозиции модулей или что-то в этом роде. Таким образом, в некотором смысле то, о чем мы говорим, – это древняя концепция, применяемая к, можно сказать, более современной программной архитектуре, посредством того, что связь применяется на всех этих различных уровнях стека. Между классами, между модулями и между сервисами. Так что да, основная идея состоит в том, что в микросервисной архитектуре у вас есть набор служб для совместной работы. А сотрудничество подразумевает, что службы должны взаимодействовать друг с другом, и всякий раз, когда есть сотрудничество, существует некоторая взаимосвязь, и есть несколько различных типов взаимосвязи.

Крис Ричардсон: И на самом деле в презентациях я говорил о трех типах, и в этой презентации основное внимание уделялось одному. Но, например, существует связь времени выполнения, и это происходит, когда одна служба, скажем, служба заказов, обрабатывает запрос POST для создания заказа, выполняя запрос PUT для службы поддержки клиентов, ожидая ее ответа перед отправкой ответа на создание. запрос на заказ. Кажется простым, но одна из проблем по определению заключается в том, что служба заказов не может отправить ответ, если служба поддержки клиентов не работает. Итак, у вас есть связь времени выполнения, которая снижает доступность. И в этом примере вы могли бы сказать, а в чем дело? Но в микросервисной архитектуре вы можете получить длинные цепочки вызовов.

Крис Ричардсон: Я помню, как однажды я был в гостях у клиента и встретился с командой, которая представила API, который интегрируется с очень крупным клиентом, и у них было очень жесткое соглашение об уровне обслуживания. И инженер сказал: «О да, мы только что позвонили в службу обнаружения мошенничества». Так что это кажется простым. Затем я поговорю с группой по обнаружению мошенничества, и оказывается, что у них есть семь сервисов, которые реализуют обнаружение мошенничества или общение с помощью REST. Итак, чтобы ответить на этот запрос внешнего клиента, было задействовано восемь сервисов. И вы делаете математику, и это результат доступности всех этих услуг. Если бы у вас на самом деле было 10 услуг, вы бы потеряли девятку из них. И это выросло, потому что ни у кого не было глобального взгляда на непрерывный поток. Таким образом, связь времени выполнения влияет на доступность вашей системы. Так что это своего рода операционная сторона дела.

Крис Ричардсон: И еще один тип связи – это временная связь дизайна. Когда мы говорим о слабой взаимосвязи сервисов, чтобы команды могли быть слабо взаимосвязанными и высокопроизводительными, как бы посредством применения закона Конвея, мы говорим о взаимосвязи времени проектирования. Таким образом, мы хотим свести к минимуму увязку времени проектирования. Итак, простой случай – служба заказов использует API службы поддержки клиентов. В общем случае это может быть REST API или просто подписка на события. А привязка времени проектирования – это действительно степень, в которой изменение одной услуги влияет на ее клиентов. Итак, представьте, что внутреннее устройство службы поддержки клиентов изменилось, что потребовало критического изменения API службы поддержки клиентов. Таким образом, служба заказов должна быть обновлена, чтобы отразить это изменение. И если они принадлежат разным командам, эти две команды должны сотрудничать. Им нужно встретиться, чтобы обсудить эти изменения. И всякий раз, когда у вас есть сотрудничество между командами, которое занимает на порядки больше времени, чем сотрудничество внутри команды. Ведь сотрудничество внутри команды – это просто ежедневный стендап. Быстрое и быстрое принятие решений.

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

Томас Беттс: Ранее я слышал, что вы говорили о трех типах сцепления. Какой третий?

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

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

Крис Ричардсон: Да. Я имею в виду, что все это сильно переплетено. Я имею в виду, что один из способов переформулировать закон Конвея таков: структура организации и архитектура программного обеспечения, которое она создает, на самом деле являются зеркалами друг друга. И если цель состоит в том, чтобы поставлять программное обеспечение быстро, часто и надежно, вам нужны слабосвязанные команды. На самом деле это означает, что они могут выполнять свою работу, вносить изменения без необходимости постоянно координировать свои действия с людьми из других команд. Авторы книги Accelerate обнаружили, что это ключевая характеристика высокопроизводительных команд. Так что, если вы постоянно на собраниях, координируете работу, это симптом тесной связи в организации. А учитывая глобальную нехватку конференц-залов, по крайней мере, в эпоху до COVID, я чувствую, что многие организации очень тесно связаны. Они постоянно координируют и согласовывают, а не просто пишут код и доставляют его в производство. Итак, вы хотите иметь слабосвязанную организацию, и если вы применяете стиль мышления, основанный на законе Конвея, это означает, что вам нужна слабо связанная архитектура, что, в частности, означает слабосвязанную с точки зрения времени проектирования.

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

Крис Ричардсон: Я приведу вам пример этого. Я имею в виду, это было очень давно. Гоша, в далеком 2002, 2003 годах я работал над сервером управления устройствами. Что ж, компания создавала продукт для мобильных устройств, и на самом деле он состоял из клиента, некоторого кода, который запускался на мобильном устройстве, и сервера, который выполнял управление устройством. И я возглавлял команду по управлению устройствами. И очевидно, что клиенту необходимо разговаривать с сервером, поэтому у нас была личная встреча с командой клиентов, на которой мы обсудили API, который мы будем использовать, который был очень тонким API. А потом мы оба ушли и разработали свои части системы. На самом деле они находились в Великобритании, а мы – в Кремниевой долине, поэтому были разделены часовые пояса и пространство. Но поскольку у нас был очень плотный API, очень узкий API, который был хорошо определен, мы могли работать независимо, почти никогда не общаясь.

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

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

Крис Ричардсон: Да. Я думаю, когда мы разработали этот продукт для управления устройствами, этого термина, возможно, и не существовало, но в каком-то смысле он был ориентирован на контракт, верно?

Томас Беттс: Верно. Язык еще не освоился. И это вроде бы обычная закономерность. Мы поступаем правильно, и тогда люди будут использовать термин для описания этого, а затем, в конце концов, этот термин будет неправильно использован и неправильно применен к вещам, которым он не должен был быть.

Образец айсберга – раскрывайте как можно меньше [11:32]

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

Крис Ричардсон: Да. На самом деле у меня нет метафоры для другого паттерна. Да. Итак, мы говорим об айсбергах, верно? Итак, общепринятое мнение относительно айсбергов состоит в том, что часть айсберга, которая находится выше ватерлинии, мала по сравнению с тем, что находится ниже. И я думаю, что это отличная метафора для сервисов в частности, но вы также можете сказать программные модули в более общем плане, где вы хотите минимизировать то, что открыто, просто по той простой причине, что то, что скрыто, может быть легко изменено, а то, что открыто, не может, потому что это потенциально влияет потребители вашего программного модуля или вашего сервиса. И была книга, как его зовут, Остерхаут? На самом деле мне никогда не приходилось произносить его имя вслух, «Философия разработки программного обеспечения», это очень тонкая книга, но превосходная. Он говорит о том, что модули скорее глубокие, чем широкие. И это своего рода еще один способ выражения этого принципа айсберга.

Крис Ричардсон: Пример, который я использовал в своем выступлении, – это API, например, Twilio. И я знаю, что у него на самом деле довольно богатый API, но если вы думаете об отправке SMS-сообщения с помощью Twilio, эта операция имеет всего три параметра. Номер телефона отправителя, номер телефона на номер и сообщение, которое вы хотите отправить. Очень минимальный API, но, по-видимому, за этим стоит чертовски большая сложность, потому что вы можете отправлять текстовые сообщения людям в 150 странах. И я думаю, что это действительно сложно.

Томас Беттс: Я так думаю. Я бы не хотел этого писать. Значит, вам не нужны 150 разных API. Вы можете видеть, что это другая версия, худший сценарий.

Крис Ричардсон: Да. Я имею ввиду, на самом деле это забавно. Я думаю, возвращаясь к первоначальным проектам управления устройствами, над которыми я работал, я думаю, что нам пришлось интегрироваться с каким-то SMS-шлюзом, и это было ужасно и взломано. И на самом деле это повторялось несколько раз за эти годы. В любом случае да, так что, по-видимому, Twilio скрывает огромное количество сложностей за очень узким API, и это фантастика. Или полоса. Я имею в виду, еще раз, API немного сложнее, чем я говорю, но основная идея заключается в том, чтобы взимать плату с этой кредитной карты, и, по-видимому, за этим стоит чертовски много сложностей. И все это было абстрагировано, и у вас просто очень узкий интерфейс, так что [inaudible 00:14:21] проектирование услуг таким образом.

Томас Беттс: Да. Я думаю, что компании, которые сделали это действительно хорошо, Twilio и Stripe, где API – их продукт в значительной степени, они должны сделать это правильно, иначе их продукт не будет успешным. Считаете ли вы это большим вызовом для компаний, потому что, о, я могу просто позвонить Крису, и мы можем поговорить об этом в любое время. Итак, поскольку для такого общения меньше препятствий, это может привести к более тесной связи?

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

Потребляйте как можно меньше [15:12]

Томас Беттс: И обратная сторона этого, если сообщения, которые вы получаете, содержат много информации, и я думаю, что вы говорили о [inaudible 00:15:19] данные, которые вам нужны, и вы сказали, что у вас нет хорошей метафоры, но поговорите об этом немного подробнее.

Крис Ричардсон: Да. Это был перевернутый айсберг, верно?

Томас Беттс: Верно. Верно.

Крис Ричардсон: Вид зеркала с минимальной экспозицией – минимальным потреблением. И можно сказать, что есть два разных аспекта. Сведение к минимуму количества других сервисов, от которых вы зависите, ваших исходящих зависимостей, потому что каждая из этих зависимостей является потенциальной нестабильностью или потенциально может заставить вас измениться в какой-то момент. Итак, вы хотите свести к минимуму количество этих зависимостей, и в некотором смысле можно сказать, что идеальное число равно нулю. А затем произнесите идеал, который напомнит мне об одной мысли, которую я не думаю, что я явно упоминал в разговоре, но, возможно, вы могли бы сказать, что идеальная архитектура – это когда у вас есть шлюз API, который просто направляет службы и эти службы не общаются. Так не работает, но у этих сервисов, поскольку между сервисами нет зависимостей, у них нет причин для изменения. Или хотя бы из-за смены других сервисов.

Томас Беттс: Итак, чтобы сыграть адвоката дьявола, если идеальное количество зависимостей ноль, разве вы не описали только монолит.

Крис Ричардсон: Да. По сути, да.

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

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

Цель: свести к минимуму, а не исключить сцепление [17:26]

Томас Беттс: Если есть все эти проблемы с привязкой ко времени проектирования, как вы думаете, разумно ли попытаться устранить ее, попытаться достичь этого нуля? Или это необоснованная цель? И если это неразумно, то какие компромиссы вы примете во внимание и скажете: «Хорошо, это то, что мы готовы принять, потому что дальнейшее продвижение принесет все это дополнительное бремя»?

Крис Ричардсон: Я думаю, что реально сервисам приходится делиться концепциями. Так оно и есть. Но если вы рассматриваете проектирование и микросервисную архитектуру как один из видов распределения обязанностей и другой способ выразить это, это … У меня был другой разговор, который касался темной материи, темной энергии, в котором говорилось о своего рода силах отталкивания и силах притяжения, которые либо поощрять декомпозицию на сервисы, либо сопротивляться декомпозиции на сервисы. Если вы рассматриваете это как проблему группировки поддоменов, поддоменов служб, как некоторый фрагмент функциональности, соответствующий функциональной области вашего бизнеса, задача создания микросервисной архитектуры состоит в том, чтобы определить службу как группу поддоменов, а затем так как решить эту проблему группировки? И в основном, если у вас есть операция, охватывающая несколько поддоменов, это как бы побуждает вас объединить их в одной службе, потому что, если операция охватывает оба из них, то внутри вашей системы существует эффективная совместная связь.

Крис Ричардсон: Вы хотите собрать их вместе, но есть отталкивающая сила желания иметь своего рода сервисы размера команды, которые можно развертывать, разрабатывать, тестировать и развертывать независимо. Так что все дело в уравновешивании этих противоборствующих сил и в разработке моделей сотрудничества таким образом, чтобы свести к минимуму количество взаимосвязей. И вы могли бы сказать, что избегайте анти-шаблонов, например, один общий анти-шаблон – это когда у вас есть служба данных. Итак, у вас есть служба управления заказами, которая имеет бизнес-логику, и у вас есть служба данных заказов, которая просто обертывает базу данных, вы как бы видите варианты этого, верно? И здесь вы как бы разделили обязанности по управлению заказами между двумя службами, что по сути подразумевает сотрудничество. Итак, все эти данные предоставляются через API службы данных заказов для поддержки службы заказов, но затем становятся доступными для других людей. Так что это в некотором роде похоже на эту услугу открытого доступа.

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

Томас Беттс: Попался. Итак, если я могу повторить это, чтобы увидеть, правильно ли я это понимаю, одна из вещей, которые я вижу в микросервисах, – это то, что базы данных не распределяются между службами. И когда вы описываете службу данных о заказах, это звучит так, как будто вы просто открываете базу данных, чтобы две службы могли ее вызывать, что, похоже, так, почему бы просто не заставить их обе вызывать базу данных? И вы говорите об управлении заказами или обработке заказов, что является названием услуги. У вас нет двух отдельных сервисов, которые не могут существовать независимо. Это граница вашей службы. Это ваш ограниченный контекст.

Крис Ричардсон: Да. Да.

Паттерны и метрики, которые следует искать в качестве индикаторов связи времени разработки [20:54]

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

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

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

Крис Ричардсон: Да. Люди называют это обратным маневром Конвея, когда ваша архитектура слабо связана, а затем работает в обратном направлении и также влияет на организационную структуру.

Томас Беттс: Какие еще варианты поведения или советы, я думаю, вы можете посоветовать людям искать? Похоже, DevOps, вы упомянули, что Accelerate – хорошая книга для чтения, есть ли другие ресурсы, к которым люди могут обратиться, чтобы узнать, как создать свою команду, как настроить свою архитектуру?

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

Томас Беттс: И вы не можете легко иметь одно без другого, или одно ведет к другому.

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

Томас Беттс: Это утка спокойно плывет по воде и под ней безумно гребет ногами.

Крис Ричардсон: Да. Я имею в виду, что это действительно существует, но можно сказать, что это, возможно, из-за доминирования на рынке поставщика программного обеспечения, а не из-за внутренней гибкости организации. В то время как если вы новая компания, в которой у вас нет мускулов устоявшейся компании, я думаю, вы должны преуспеть. Кроме того, я искренне верю, что рано или поздно весь этот технический долг вернется и укусит вас. В конечном итоге вы заплатите цену. Так что да, книга Accelerate действительно хороша. Думаю, к этому относится Руководство DevOps. Потому что мне кажется, что это определение сути DevOps, а также всех принципов и практик, из которых состоит DevOps. Да. А также Джез Хамбл, книга Дэйва Фарли «Непрерывная интеграция». Я считаю, что это фантастическая книга. Так что все это своего рода процесс. Кроме того, с точки зрения организации, книга «Топологии команд» – действительно полезный ресурс.

Томас Беттс: О чем здесь говорится в топологиях команд?

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

Оркестровка против хореографии при реализации паттерна саги [26:02]

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

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

Крис Ричардсон: Это часто называют архитектурой, управляемой событиями. Но я бы назвал это сагой, основанной на хореографии. Таким образом, сервисы объявляют о том, что они сделали, что запускает действия в других сервисах. И это хорошо с точки зрения связывания во время выполнения, потому что они слабо связаны. Нет синхронных звонков. Никто не ждет своевременного ответа от какой-либо другой службы. Таким образом, не имеет значения, не работает ли служба поддержки клиентов, в конечном итоге она вернется к работе, и любые невыполненные события будут обработаны, а кредит будет зарезервирован или отклонен. Итак, это саги, основанные на хореографии.

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

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

Томас Беттс: У меня еще много вопросов, к сожалению, время истекло. Крис, что еще ждет тебя? И как людям лучше всего протянуть руку помощи?

Крис Ричардсон: Над чем я работаю? Я просто занимаюсь микросервисами. Думаю, я уже 15 с лишним лет говорил о таких концепциях, как слабая связь, и Бог знает что, о подобных вещах. Я имею в виду, что некоторые из тех же тем применяются в POJO в дни действий, действительно так. Так что да, люди могут найти меня, ну, очевидно, в Твиттере, @crichardson, а также на microservices.io. А потом мой сайт по обучению и консультированию, chrisrichardson.net. Так что есть несколько разных мест, где вы можете меня найти.

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

Упоминания

О госте

Крис Ричардсон является создателем microservices.io; Автор шаблонов микросервисов и чемпион Java Крис Ричардсон – разработчик и архитектор. Он чемпион Java, рок-звезда JavaOne и автор книги «POJO в действии», в которой описывается, как создавать корпоративные Java-приложения с такими фреймворками, как Spring и Hibernate. Крис также был основателем CloudFoundry.com, ранней версии Java PaaS для Amazon EC2. Сегодня он является признанным идейным лидером в области микросервисов и регулярно выступает на международных конференциях. Крис – создатель Microservices.io, языка шаблонов для микросервисов, и автор книги Microservices Patterns. Он предоставляет консультации по микросервисам и обучает организации, внедряющие микросервисную архитектуру, и работает над своим третьим стартапом Eventuate, платформой приложений для разработки транзакционных микросервисов.

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

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

Back to top button