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

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

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

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

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

Умение разбираться в основных причинах

Мы рассмотрели способы разбиения крупных сервисов на более мелкие, но в чем первопричина того, что сервисы разрослись до таких больших размеров? Сначала нужно понять, что разрастание сервиса до определенного объема, требу­ющего его разбиения, — это вполне нормальное явление. Нам нужно, чтобы архитектура системы со временем изменялась. Главное — разобраться в том, что она требует разбиения еще до того, как такое разбиение станет обходиться слишком дорого.

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

Часть проблемы заключается в том, чтобы знать, с чего начать, и я надеюсь, что эта глава помогла вам в этом разобраться. Но другой проблемой являются затраты, связанные с разбиением сервисов на части. Нелегкими задачами будут поиск среды для запуска сервиса, раскрутка нового стека сервисов и т. д. Как же со всем этим справиться? Если дело нужное, но сложное, мы должны попытаться все упростить. Снизить затраты, связанные с созданием нового сервиса, может ставка на применение библиотек и облегченных сред сервисов. Упростить предоставление и те­стирование систем может обеспечение людям доступа к самообслуживаемым виртуальным машинам или даже создание платформы в качестве услуги (PaaS). В следующих главах будет рассмотрен ряд способов, позволяющих снизить эти затраты.

Резюме

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