Получение описания нашей системы и характера ее поведения играет важную роль, особенно когда дело касается вопросов масштабирования. Мы уже рассмотрели несколько различных технологий, которые помогут нам обрести понимание непосредственно из нашей системы. Отслеживая состояние работоспособности нижестоящих сервисов наряду с отслеживанием идентификаторов взаимосвязанности, что помогает нам проследить цепочки вызовов, мы можем получить реальные данные в условиях взаимосвязанности сервисов. Используя такие системы обнаружения сервисов, как Consul, мы можем увидеть, где работают микросервисы. HAL позволяет нам увидеть, какие возможности размещены в данный момент в каждой отдельно взятой конечной точке, а страница проверки работоспособности и системы мониторинга позволяют узнать, каково состояние работоспособности как системы в целом, так и отдельных сервисов.
Всю эту информацию можно получить программным способом. Совокупность этих данных позволяет нам сделать понятный человеку реестр эффективнее простой вики-страницы, которая, несомненно, будет устаревать. Вместо этого мы будем применять его для задействования и отображения всей информации, выдаваемой системой. Создавая настраиваемые информационные панели, мы можем обобщить огромный массив информации, доступной для оказания помощи в осмыслении нашей экосистемы.
Во всех смыслах начинать следует с чего-нибудь настолько же простого, как статическая веб-странница или вики, на которой по крупицам собираются данные о живой системе. Но со временем нужно присматриваться к размещению все больших объемов информации. То, что к этой информации можно быстро получить доступ, является ключевым инструментом, позволяющим справиться с трудностями, возникающими из-за эксплуатации этих систем в режиме масштабирования.
Микросервисы как подход к проектированию все еще довольно молоды, поэтому, хотя у нас уже есть вполне определенный опыт, от которого можно отталкиваться, я уверен, что в следующие несколько лет появятся более удачные схемы, позволяющие успешно справляться с их масштабированием. И тем не менее я надеюсь, что в этой главе был намечен ряд шагов, которыми можно будет воспользоваться в вашем путешествии по масштабированию микросервисов и которые станут для вас хорошим подспорьем.
Вдобавок к тому, что здесь было рассмотрено, я рекомендую прочитать замечательную книгу Майкла Нигарда (Michael Nygard) Release It!. В ней он делится с нами подборкой историй о сбоях системы и некоторыми схемами, помогающими успешно справиться со сбоями. Книгу действительно стоит прочитать (более того, я хотел бы заострить внимание на том, что она должна рассматриваться в качестве весьма важного пособия для тех, кто создает масштабируемые системы).
Мы уже усвоили довольно много основ и близки к завершению нашего разговора. В следующей, последней главе мы уделим внимание объединению всего изученного в единое целое и подытожим все, что нам удалось узнать при прочтении книги.
12. Коротко обо всем
В предыдущих главах было рассмотрено множество вопросов: от того, чем являются микросервисы, до способов определения их границ и от технологии интеграции до решения вопросов безопасности и мониторинга. У нас даже нашлось время на выяснение роли, отводимой в этой области архитектору. Осмысливать приходится весьма большой объем материала, и хотя сами микросервисы могут быть совсем небольшими, этого не скажешь о ширине размаха и влиянии, оказываемом их архитектурой. Поэтому в данной главе я постараюсь подвести итоги по ряду ключевых моментов, рассмотренных в книге.
Роль, которую могут играть принципы, мы рассматривали в главе 2. Принципы складываются из утверждений о том, как все должно делаться, и из разъяснения причин, по которым все должно делаться именно таким образом. Они помогают нам выстроить различные решения, которые приходится принимать при создании наших систем. Конечно же, вы должны определить собственные принципы, но я считаю, что есть смысл изложить мое видение того, как выглядят ключевые принципы микросервисных архитектур, обобщенный вид которых представлен на рис. 12.1. Эти принципы призваны помочь нам в создании небольших автономных сервисов, успешно выполняющих совместную работу. Все они по крайней мере единожды уже были рассмотрены в этой книге, поэтому ничего нового вы здесь не найдете, но ценность рисунка определяется тем, что в нем передана только суть.
Вы можете принять за основу сразу все эти принципы или же подстроить их под то, что имеет смысл принять именно в вашей организации. Но обратите внимание на ценность их использования в сочетании друг с другом: целостность может быть гораздо ценнее суммы частей. Итак, если вы решили отвергнуть один из них, убедитесь в том, что понимаете, что теряете.
Для каждого из этих принципов я пытался подобрать подтверждающие примеры из практики, которые были рассмотрены в данной книге. Но, как говорится, на них свет клином не сошелся: чтобы выработать принципы, можно воспользоваться собственным опытом, но те принципы, которые здесь изображены, могут для начала стать хорошим подспорьем.
Рис. 12.1. Принципы микросервисов
Опыт подсказывает, что интерфейсы, структурированные вокруг контекстов, связанных с бизнес-задачами, отличаются большей стабильностью, чем те, которые структурированы вокруг технических концепций. Моделированием областей, в которых работает наша система, мы не только пытаемся создать более стабильные интерфейсы, но и обеспечиваем повышение возможности более свободно отображать изменения в бизнес-процессах. Для определения потенциальных границ областей следует использовать ограниченный контекст.
Микросервисы усложняют системы главным образом из-за необходимости работать с огромным количеством активных компонентов. Применение культуры автоматизации является одним из основных способов справиться с этой проблемой, и в этом плане имеет смысл как можно раньше приложить максимум усилий к созданию инструментария для поддержки микросервисов. Поскольку удостовериться в работоспособности сервисов по сравнению с монолитными системами намного сложнее, важную роль в этом процессе играет автоматизированное тестирование. Также может помочь использование одинакового вызова командной строки для повсеместного единообразного развертывания, который может стать основной частью внедрения непрерывной поставки с целью обеспечения быстрой оценки качества работы в производственном режиме при каждой проверке.
Подумайте о возможности использования определений среды в качестве вспомогательного средства конкретизации отличий одной среды от другой без ущерба для возможности использования единообразного метода развертывания. Также подумайте о создании настраиваемых образов, позволяющих ускорить развертывание и включающих в себя создание полностью автоматизированных неизменяемых серверов, упрощающих понимание устройства ваших систем.
Чтобы максимально увеличить возможность одного сервиса совершенствоваться независимо от всех других сервисов, крайне важно скрыть подробности его реализации. Содействие в этом могут оказать ограниченные контексты, поскольку они помогают сконцентрировать усилия на моделях, предназначенных для совместного использования и при этом обладающих скрытностью. Сервисы также должны скрывать свои базы данных во избежание попадания в одну из наиболее распространенных разновидностей связывания, которая может проявляться в традиционных сервис-ориентированных архитектурах и использовать для объединения данных от нескольких сервисов с целью создания отчетов перекачку данных или перекачку данных о событиях.
При любой возможности отдавайте предпочтение применению технологически нейтральных API-интерфейсов, чтобы получить свободу использования различных технологических стеков. Подумайте о применении технологии передачи репрезентативного состояния REST, оформляющей разделение подробностей внутренней и внешней реализации which. Те же самые идеи можно принять за основу и при использовании удаленных вызовов процедур (RPC).
Для достижения максимальной автономности, допускаемой микросервисами, нужно постоянно выискивать возможности для передачи полномочий по принятию решений и управлению тем командам, которые владеют микросервисом. Этот процесс начинается с внедрения самообслуживания везде, где только можно, позволяя людям развертывать программные средства по мере надобности, делая как можно проще разработку и тестирование и исключая необходимость для отдельных команд выполнять эти действия.
Обеспечение того, что команды владеют своими собственными сервисами, является важным шагом на данном пути, возлагающим на команды ответственность за вносимые изменения и в идеале даже за принятие решения о том, когда именно выпустить такие изменения. Чтобы обеспечить возможность внесения изменений в сервисы, находящиеся во владении других команд, воспользуйтесь семейственным открытым кодом, но при этом помните, что для его реализации нужно будет поработать. Подстраивайте команды под организацию, чтобы гарантировать, что закон Конвея работает на вас и помогает вашей команде приобрести специализацию в создаваемых ею сервисах, сконцентрированных на решении конкретных бизнес-задач. Если требуется какая-либо всеобъемлющая ориентация, попробуйте воспользоваться моделью общего руководства, при которой представители разных команд несут коллективную ответственность за развитие технической концепции системы.
Этот принцип применим и для архитектуры. Избегайте подходов вроде сервисных шин предприятия или оркестровых систем, которые могут привести к централизации бизнес-логики и появлению безмолвных сервисов. Чтобы гарантировать наличие соответствующей логики и данных на границах сервисов, которые помогают достигать нужного сцепления,