Мы подготовили перевод статьи Нила Форда, системного архитектора и идейного вдохновителя компании ThoughtWorks, которая занимается разработкой программных средств для автоматизации процессов тестирования и развертывания ПО.

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

Микросервисы как эволюционная архитектура

Микросервисная архитектура стремительно завоевывает мир. В марте издательская компания O'Reilly организовала свою первую конференцию по архитектуре программного обеспечения (O'Reilly Software Architecture Conference). И почти 60% докладов были посвящены тем или иным аспектам использования микросервисов. Почему именно этот архитектурный стиль вдруг стал таким популярным?

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

Эволюционная архитектура

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

Микросервисная архитектура полностью соответствует этой идее благодаря тому, что в ней ограниченные контексты (Bounded Context), логически выделенные в соответствии с Предметно-ориентированным проектированием (Domain Driven Design) Эрика Эванса, реализуются как физически раздельно развертываемые компоненты. Это разделение достигается за счет внедрения практик DevOps, таких как выделение виртуальных машин, тестирование и автоматизированное развертывание. Поскольку каждый сервис отделен от всех остальных сервисов (на структурном уровне), замена одного микросервиса на другой происходит так же легко, как перестановка кубиков Лего.

Особенности эволюционной архитектуры

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

Модульность и связанность

Возможность разделять компоненты в рамках четко определенных границ дает разработчикам преимущества в случае необходимости непрерывного внесения изменений. Если архитектура не проектировалась и система выглядит, как большой комок грязи (Big Ball of Mud architecture), то эволюционные изменения невозможны, так как в такой структуре нет выделенных частей.


[Связь между классами (точки по периметру) в большом комке грязи из неназванного клиентского проекта.]

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

Организация вокруг бизнес-возможностей

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

Эксперименты

Проведение экспериментов — одно из существенных преимуществ, которые эволюционная архитектура дает бизнесу. Возможность легкого внесения в приложения небольших изменений обеспечивает применение таких распространенных практик непрерывного развертывания, как A/B-тестирование, тестирование на ограниченной группе пользователей (Canary release) и других. Микросервисные архитектуры нередко выстраиваются на основе маршрутизации обращений к сервисам, благодаря чему создается возможность использования нескольких версий сервиса в рамках целой экосистемы. Это в свою очередь открывает широкие возможности для экспериментов и изменения существующей функциональности. В конечном счете при разработке бизнес-приложений меньше времени тратится на обсуждение планов и бэклога, а разработка ведется в основном в режиме быстрой проверки гипотез.

Принципы эволюционной архитектуры

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

Функции приспособленности (fitness function)

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


[Радарная диаграмма, используемая для выделения важных функций приспособленности, соответствующих этой программной системе.]

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

Внимание на болевые точки

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

Момент принятия решения

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

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

Заключение

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

Чтобы наполнить такую двухмерную диаграмму жизнью, необходимо ее конкретизировать. Метка ORM на двухмерной диаграмме становится Hibernate v4.2.17, делая представляемый мир трехмерным. Когда у вас будет план по ее внедрению в производство и обновления через полгода до неизбежной версии Hibernate v4.3.0.1, вы будете готовы к четырехмерному миру. Многие архитекторы не понимают, что статическое представление архитектуры имеет короткий срок использования. Вселенная программного обеспечения существует в состоянии потока, она динамичная, а не статична. Архитектура — это не уравнение, а скорее моментальный снимок длящегося процесса.

Практики непрерывной поставки ПО и DevOps показали проблемы, растущие из непонимания усилий, которые нужны для реализации и поддержки архитектуры. Реализация архитектуры — это лишь первый шаг. Архитектура остается абстракцией до тех пор, пока она не приведена в действие. Другими словами, о жизнеспособности любой архитектуры в долгосрочной перспективе можно судить только тогда, когда вы не только реализовали, но и хотя бы один раз модифицировали ее. И может быть, сумели справиться с неожиданностями на этом пути.
Понимание архитектором ПО операционных возможностей чрезвычайно важно для разработки эволюционной архитектуры. Эволюционное развитие архитектуры влияет на особенности ее реализации, и поэтому их необходимо учитывать в процессе доработки. Требования, предъявляемые процессом непрерывной поставки к архитектуре, направлены на то, чтобы улучшить ее визуализацию и упростить внесение изменений. Тем самым непрерывная поставка обеспечивает расширение возможностей эволюционной архитектуры.

19 ноября Нил Форд приезжает в Москву с мастер-классом по созданию эволюционной архитектуры ПО.