Мультиоблачные приложения: часть 1

Освоение актерской модели

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

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

Что такое актерская модель?

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

Актеры могут быть LEGO® для создания мультиоблачных приложений, потому что они просты, имеют смысл и могут быть легко объединены для создания более крупных вещей. Эта простота и интуитивность упрощают проектирование и создание сложных приложений с акторами в качестве строительных блоков. Акторы - это небольшие, тестируемые, развертываемые, исполняемые блоки кода, которые:

Реагируйте на сообщения, выполняя бизнес-правила и логику.
Отправляйте сообщения другим экземплярам акторов, когда им нужно сообщить им о (событии) или попросить их сделать (запросить) что-нибудь.
Создавать и контролировать другие экземпляры акторов в некоторых реализациях модели. В модели Cloud Actor эти функции обрабатываются по-другому, с использованием Kubernetes.

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

Использование субъектов, взаимодействующих с помощью передачи сообщений, в качестве основных строительных блоков мультиоблачных приложений упрощает выполнение параллельной обработки в облачной сети и:

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

ОБСУЖДЕНИЕ. Модель акторов, как описано здесь, представляет собой тип модели микросервисов и предназначена для использования в тех частях приложения, которые реализуют бизнес-функции и читают, фильтруют, преобразовывают и записывают постоянные данные. - эффективно распределенная облачная серверная часть функциональности приложения - в отличие от подключенных к сети клиентов, которые составляют интерфейс этих приложений и подключают пользователей к серверной стороне. Сегодня внешние интерфейсы чаще всего реализуются с помощью технологий UI / UX и развертываются в виде мобильных приложений, приложений для настольных компьютеров или веб-браузеров. Как правило, эти приложения поддерживают одного пользователя за раз и не имеют проблем с масштабируемостью. Однако на них очень сильно влияют надежность, задержка и масштабируемость серверов, к которым они подключаются, что является областью модели акторов.

Расширение актерской модели

Поскольку контейнеры и оркестровка контейнеров упрощают многие проблемы параллелизма, аварийного переключения и масштабирования, которые раньше записывались в отдельные субъекты, и поскольку современная потоковая передача сообщений имеет возможности, которых не было в 1970-х годах, модель акторов может быть расширена, чтобы принять преимущество этих возможностей. Для этой расширенной модели акторов мы будем использовать термин Cloud Actor Model. В модели Cloud Actor экземпляры акторов находятся в контейнерах в pods и развертываются посредством развертываний Kubernetes.

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

Технологии C ontainer не требуют для работы облака, Kubernetes прекрасно работает в традиционном локальном центре обработки данных.

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

Брокеры - это связующее звено, которое связывает отдельных участников, организуя обмен сообщениями между ними и выступая в качестве выключателей для смягчения условий каскадных ошибок. Брокеры - единственные действующие лица с отслеживанием состояния, которые управляют возможностями переключения при отказе, масштабирования и самоорганизации модели Cloud Actor. Когда брокер работает, он транслирует свое присутствие всем другим доступным брокерам. Брокеры объединены в облачные кластеры и обмениваются информацией о состоянии друг с другом. Небольшой прокси-сервер брокера работает как дополнительный компонент в каждом модуле акторов, чтобы облегчить регистрацию акторов и передачу сообщений с использованием оптимального брокера. Посредники принимают сообщения, адресованные определенному типу актора тип, и направляют их на физический адрес оптимального экземпляра этого типа актора. почтовый ящик связан с каждым отдельным экземпляром актора для буферизации входящих сообщений для актера, а также для отправки сообщений и взаимодействия с посредниками-посредниками от имени экземпляра актора. В этой статье представлены брокеры и почтовые ящики. В следующем выпуске M ulti-Cloud Apps: Part 2, Using Messaging and Brokers более подробно рассказывается о том, почему и как мы их используем.
Акторы Intelligent Transformer специализируются на проверке, форматировании, фильтрации и преобразовании данных. Поведение актора-преобразователя определяется в основном декларативными правилами, а не императивным кодом. Интеллектуальный трансформатор имеет от 1 до n входных каналов и от 1 до n выходных каналов и может быть соединен вместе с другими трансформаторами для более сложной обработки сообщений. Трансформаторы воздействуют на сообщения, перемещаемые между экземплярами акторов. В грядущем выпуске Multi-Cloud Apps: Part 4, Using Intelligent Transformers рассматриваются интеллектуальные акторы-преобразователи, а также способы и причины их использования.
Акторы обработчика контекста - это интерфейсы приложений для создания, чтения, записи и удаления данных с помощью логических представлений. Они могут работать с отдельными обработчиками ресурсов или с несколькими обработчиками ресурсов. Обработчики контекста представляют логическую модель данных экземплярам субъектов приложения и взаимодействуют через REST API с обработчиками ресурсов для физического сопоставления, хранения и извлечения данных в физической модели данных. Обработчики контекста и связанные с ними обработчики ресурсов выполняют тяжелую работу по управлению распределенными данными (переключение при отказе, масштабирование, репликация, согласованность) для остальных участников приложения.
Акторы Resource Handler - это адаптеры приложений для физической модели данных. Они используются обработчиками контекста для сопоставления ресурсов с постоянным хранилищем, очень похоже на объектно-реляционный сопоставитель (ORM), такой как Hibernate, сопоставляющий объекты с реляционными базами данных. Доступ к обработчикам ресурсов осуществляется через REST API. Ресурсы - это вещи, которые находятся в энергонезависимой системной памяти, например файлы, хранилища ключей и значений и базы данных.
Акторы Event Publisher публикуют сообщения о событиях в распределенных системах очередей потоковой передачи, таких как Kafka. Они отправляют сообщения о событиях по темам в очереди событий. Издатели ничего не знают о своих подписчиках и оставляют технические детали очередей потоковой передачи программному обеспечению очередей.
Субъекты обработчика событий подписываются на очередь сообщений указанной темы. Обработчик по порядку считывает каждое сообщение из очереди и пересылает его соответствующему экземпляру субъекта приложения.
Акторы Transaction Tickler подтверждают завершение распределенной транзакции. При активации они проверяют наличие записи в журнале завершения (в фиксированное время или истекшее время) и выдают событие ошибки, если оно не найдено.
Субъекты Distributed Logger записывают сообщения об ошибках и приложения в соответствующие распределенные журналы. Если тип сообщения об ошибке имеет определенный обработчик ошибок, ошибка также пересылается этому обработчику ошибок. Распределенные журналы также могут быть воспроизведены для восстановления состояния после сетевых разделов или сбоя постоянных ресурсов. Распределенные регистраторы - ключевые компоненты для удовлетворения требований наблюдаемости мультиоблачных приложений.
Субъекты обработчика ошибок организуют соответствующие корректирующие действия для типов сообщений об ошибках, которые требуют этого - например, ошибки обработчика ресурсов, которые могут поставить под угрозу конечную согласованность и требуют разрешения и / или создания отчетов.
Субъекты Cluster Bridge перемещают сообщения между облачными кластерами, реализуют и усиливают межкластерную безопасность и оптимизируют обмен сообщениями между кластерами. Это особенно важно для производительности Kafka.
Акторы веб-обработчика - это веб-серверы, которые принимают синхронные запросы (https: //) и направляют их в соответствующий экземпляр актора приложения. Они ждут соответствующего асинхронного ответного сообщения от экземпляра (ов) субъектов обработки и возвращают его синхронному отправителю запроса или тайм-аут и возвращают ошибку HTTP. Веб-обработчики - это внутренняя граница участников, которые обеспечивают доступ извне облачного приложения. Веб-обработчик может использоваться для предоставления защищенного синхронного обмена сообщениями (включая REST API) для внешних приложений.
Акторы WebSocket Handler - это серверы WebSocket, которые принимают асинхронные сообщения (wss: //) и направляют их в соответствующий экземпляр актора приложения. Если и когда обработчик WebSocket получает ответное сообщение, он сопоставляет его и отправляет исходному запрашивающему. Таймауты обрабатываются отправителем запроса. Обработчики WebSocket - это внутренние грани участников, которые обеспечивают доступ извне облачного приложения. Обработчик WebSocket можно использовать для реализации безопасного полнодуплексного обмена сообщениями во внешние приложения и из них.
Акторы Embedded GUI Client предоставляют клиентские функции GUI для приложений, предназначенных для взаимодействия с серверами Cloud Actor Model. Актор GUI Client предоставляет возможность использовать HTML, CSS и JavaScript для создания графического интерфейса приложения. Библиотеки / фреймворки JavaScript, такие как React или Angular, позволяют компонентам графического интерфейса реализации, которые очень хорошо подключаются к модели Cloud Actor. Клиенты со встроенным графическим пользовательским интерфейсом - это участники внешней границы, которые обращаются к облачному приложению извне. Любое клиентское приложение, использующее сокеты TCP / IP, может быть клиентом приложения Cloud Actor Model.
Strangler Façade реализует основанный на правилах фасад для Strangler Fig Pattern и может перенаправлять устаревшие вызовы API в новые облачные приложения в качестве зрелых приложений. постепенно трансформируются в мультиоблачные приложения.

ОБСУЖДЕНИЕ. Мультиоблачные приложения могут быть и часто реализуются без использования модели субъектов. Это имеет значение? Это важно, и это может иметь большое значение. Мультиоблачные приложения предназначены для использования возможностей автоматического развертывания, масштабирования, надежности и аварийного переключения, доступных в гибридном облаке. В конечном итоге идея состоит в том, что, увеличивая изоляцию между программными компонентами, мы можем доставлять отдельные части системы как быстро и независимо, а с помощью контейнеров и оркестровки контейнеров мы можем обеспечить высокую степень горизонтальной масштабируемости и отказоустойчивости. Старые шаблоны составления приложений, развертываемых модулей и методов доступа к ресурсам не способствуют необходимой масштабируемости и отказоустойчивости. Это требует от нас перехода от относительно монолитных или многоуровневых приложений к развертываемым и контейнерным компонентам без сохранения состояния, таким как модель Cloud Actor.

Терминология Kubernetes

Поскольку модель Cloud Actor была создана для использования возможностей оркестрации контейнеров, доступной через Kubernetes, терминология Kubernetes может упростить описание модели. Мы понимаем, что многие читатели уже знакомы с Kubernetes и могут пропустить этот раздел.

Эти определения предоставлены Linode.

Оркестровка - это автоматическая настройка, координация и управление компьютерными системами, программным обеспечением, промежуточным программным обеспечением и службами. Он использует автоматизированные задачи для выполнения процессов. Для Kubernetes оркестровка контейнеров автоматизирует подготовку, развертывание и доступность контейнеров; Балансировка нагрузки; распределение ресурсов между контейнерами; и мониторинг работоспособности кластера.
Контейнеры похожи на виртуальные машины. Это облегченные изолированные среды выполнения, которые совместно используют ресурсы операционной системы без необходимости запускать полную операционную систему самостоятельно. Контейнеры потребляют мало ресурсов, но содержат полный набор информации, необходимой для выполнения содержащихся в них изображений приложений, таких как файлы, переменные среды и библиотеки.
Контейнеризация - это метод виртуализации для запуска распределенных приложений в контейнерах с использованием микросервисов. Для контейнеризации приложения требуется базовый образ, который можно использовать для создания экземпляра контейнера. Когда образ приложения существует, его можно отправить в централизованный реестр контейнеров, который Kubernetes может использовать для развертывания экземпляров контейнера в модулях кластера.
Модули - это наименьшая единица архитектуры Kubernetes, которую можно рассматривать как своего рода оболочку для контейнера. Каждому модулю предоставляется собственный IP-адрес, с которым он может взаимодействовать с другими модулями в кластере. Обычно Pod содержит только один контейнер, но Pod может содержать несколько контейнеров, если эти контейнеры должны совместно использовать ресурсы. Если в поде несколько контейнеров, эти контейнеры могут связываться друг с другом через localhost.
Службы группируют идентичные модули вместе, чтобы обеспечить единообразные средства доступа к ним. Например, у одного может быть три модуля, которые обслуживают веб-сайт, и все эти модули должны быть доступны через порт 80. Служба может гарантировать, что все модули доступны через этот порт, и может балансировать нагрузку трафика между ними. Стручки. Кроме того, Сервис может позволить приложению быть доступным из Интернета. Каждой службе предоставляется IP-адрес и соответствующая локальная запись DNS. Кроме того, службы существуют на всех узлах. Если у вас есть два модуля-реплики на одном узле и дополнительный модуль-реплика на другом узле, служба может включать все три модуля.
Развертывания позволяют поддерживать в рабочем состоянии определенное количество реплик Pod'ов. Развертывание также может обновлять эти модули, чтобы они соответствовали желаемому состоянию, посредством непрерывных обновлений. Например, если кто-то хочет обновить образ контейнера до более новой версии, он должен создать развертывание, и контроллер будет обновлять образы контейнера один за другим, пока не будет достигнуто желаемое состояние. Это гарантирует отсутствие простоев при обновлении или изменении модулей.

Теорема CAP

ОБСУЖДЕНИЕ: когда мы создаем распределенные приложения, работающие с постоянными данными, мы всегда должны помнить о теореме CAP . Это не совсем такой уж абсолютный ограничитель, как свет света в физическом мире, но мы игнорируем его на свой страх и риск. Работоспособные мультиоблачные архитектуры всегда должны учитывать это при выборе компромиссов.

Экземпляры и адреса актеров

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

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

Экземпляры акторов передают сообщения другим экземплярам акторов через посредников. Задача брокера - сопоставить адреса логических субъектов с физическим адресом экземпляра, который имеет наилучшие шансы на максимизацию пропускной способности и минимизацию задержки. Таким образом поддерживается прозрачность местоположения экземпляров субъектов, что позволяет брокерам управлять задержкой, переключением при отказе и масштабированием. Сообщения, передаваемые экземплярам акторов в пределах одного модуля Kubernetes, проходят не через брокеров, а только через присоединенные почтовые ящики экземпляров акторов.

ОБСУЖДЕНИЕ. Сообщение, передаваемое между экземплярами субъектов через брокеров, должно соответствовать двум обязательным критериям: 1) оно должно быть подписано цифровой подписью и 2) оно должно быть зашифровано (обычно TLS). Любое сообщение, не соответствующее этим критериям, регистрируется как ошибка и отбрасывается брокерами сообщений. В противном случае приложение Cloud Actor Model не сможет определить легитимность сообщений в потенциальной глобальной сетевой среде и будет открыто для злонамеренного вмешательства.

Жизненный цикл актера

Когда Kubernetes активирует модуль, прокси-сервер модуля выполняет следующие действия:

Он сообщает о своем существовании всем доступным брокерам и регистрируется у первого ответившего. Брокеры являются федеративными и обмениваются данными регистрации экземпляров субъектов друг с другом.
Затем он регистрирует все свои типы акторов (те, которые могут реагировать на внешние сообщения) у этого брокера.
Наконец, он запускает периодический цикл, который каждые n миллисекунд отправляет контрольное сообщение брокеру, у которого он зарегистрировался. Если этот брокер не отвечает на n последовательных контрольных сообщений, прокси-сервер брокера повторяет шаги с 1 по 3.

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

ОБСУЖДЕНИЕ. Отношения между типами субъектов и брокерами сообщений являются самоорганизующимися и не требуют предварительной настройки. Когда модули Kubernetes подключаются к сети, типы акторов в них регистрируются у ближайшего брокера. Если под перестает быть доступным, его участники автоматически удаляются из реестра его брокера. Если брокер перестает быть доступным, его типы субъектов будут зарегистрированы у нового брокера. Федеративные брокеры обмениваются изменениями состояния друг с другом и всегда направляют сообщения экземплярам субъектов с наименьшей задержкой (с их точки зрения).

В жизненном цикле актера есть несколько моментов, на которые стоит обратить внимание.

Экземпляры актеров выполняют правила и логику только тогда, когда они реагируют на сообщение.
Экземпляры акторов абсолютно повторно входим и не сохраняют состояние. Они реагируют на одно входное сообщение за раз и не помнят ранее обработанные сообщения. Все данные, необходимые для реакции на входящее сообщение, должны находиться в самом сообщении или в постоянном хранилище данных.
Экземпляр актора может реагировать на разные типы сообщений разными наборами правил и логики (каналов).
Экземпляры актеров имеют от 1 до n каналов входных сообщений. Один канал для каждого типа сообщения, на которое он будет реагировать. Канал инкапсулирует набор правил и логики, которые экземпляр актора будет использовать для обработки сообщения. Каналы также используются для реакции на псевдосинхронные ответы других участников.
Экземпляры актеров имеют от 1 до n каналов вывода сообщений. Один канал для каждого типа актера, на который они могут отправлять сообщения. Это полезно для передачи сообщений нескольким и / или разным типам целевых субъектов на основе правил и логики.
Экземпляры актеров одного типа полностью взаимозаменяемы. Это необходимо для переключения при отказе и масштабирования. Псевдосинхронный ответ на сообщение может даже не обрабатываться тем же экземпляром субъекта, который отправил исходный псевдосинхронный запрос. Фактически, в разгар более крупной деятельности приложения Kubernetes мог принимать или отключать поды. Единственное исключение из этого правила взаимозаменяемости применяется к обработчикам контекста и ресурсов, базовые хранилища данных которых могут нуждаться в репликации для обеспечения избыточности или оперативности и могут быть синхронными в своей собственной обработке. Более подробно это обсуждается в следующих приложениях для нескольких облаков: часть 5 - Работа с распределенными данными .

Асинхронный и псевдосинхронный обмен сообщениями

Мы обсудили тот факт, что экземпляры акторов общаются посредством передачи сообщений, а не посредством вызовов функций, вызовов методов или удаленных вызовов процедур (RPC). По многим причинам - некоторые из которых связаны с влиянием, которое обмен сообщениями может иметь на производительность системы - в модели облачного актора обмен сообщениями в основном асинхронный. Экземпляр актора не ждет ответов, поэтому он не удерживает исполняемые потоки. Это здорово для производительности, но на практике большая часть того, что мы делаем с компьютерами, включает запросы и ответы. Как с этим справляется модель Cloud Actor?

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

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

Актеры и умные трансформеры

В модели Cloud Actor Model преобразователь - это последовательность сообщений, которые становятся доступными с течением времени. Трансформатор можно рассматривать как элементы на конвейерной ленте, которые обрабатываются по одному, а не партиями. Интеллектуальный преобразователь - это субъект, который действует как канал с фильтрами, который соединяет поток сообщений от одного экземпляра субъекта к другому. Фильтры применяют локальные преобразования к каждому сообщению, проходящему через канал.

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

Интеллектуальные трансформаторы - это компоненты многократного использования. Например, преобразователь CustomerRecordValidator со спецификациями правил для проверки и преобразования содержимого записи Customer может использоваться любым субъектом, который должен гарантировать, что запись Customer действительна и правильно отформатирована. Если формат или правила записи Customer меняются, обычно необходимо обновить и повторно развернуть только субъект-преобразователь CustomerRecordValidator, чтобы распространить эти изменения везде, где используется запись Customer.

Использование интеллектуальных трансформаторов дает следующие преимущества:

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

Декларативная (low-code) разработка актеров

Простота участников и их сосредоточенность на обработке сообщений делают их первыми кандидатами на инструменты разработки с низким уровнем кода. Инструменты должны начинаться с приложения с графическим интерфейсом пользователя, чтобы направлять разработчиков через набор спецификаций для каждого специализированного типа акторов. Спецификации могут быть сохранены в формате JSON, чтобы механизм шаблонов Velocity мог комбинировать их с соответствующими шаблонами программ для создания компилируемых модулей исходного кода. Легко использовать любой исходный язык, поддерживаемый JVM, например Java или Kotlin, но это выбор реализации.

У методов с низким кодом есть ряд существенных преимуществ:

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

Тестирование Актеров

Тестирование программного обеспечения может быть сложным, трудным, требующим много времени мероприятием в самых лучших обстоятельствах. Как протестировать сотни (или даже тысячи) исполняемых компонентов (акторов), которые взаимодействуют в нескольких облачных кластерах? У модели Cloud Actor есть ответ - предварительные условия и постусловия, обеспечиваемые Intelligent Transformers.

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

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

Пример мультиоблачного актера

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

Веб-приложения Cloud Actor выглядят и работают как любое другое хорошо реализованное веб-приложение. Актор Web Handler имеет встроенный в него высокоэффективный, легкий, предварительно настроенный веб-сервер с открытым исходным кодом. Хотя веб-обработчик может обслуживать статический контент, в этом примере мы сосредоточены на обработке динамических данных. Вот как это работает:

Запрос HTTP или API на создание нового заказа на продажу получен субъектом веб-обработчика.
Веб-обработчик создает сообщение CreateSalesOrder и отправляет его субъекту SalesOrderService.
Субъект SalesOrderService проверяет сообщение, добавляет все необходимые инструкции в сообщение CreateSalesOrder и отправляет его субъекту SalesOrderContext.
Актер SalesOrderContext форматирует сообщение UpdateInventory и отправляет его субъекту InventoryResource, который затем обновляет базу данных Inventory и возвращает результаты.
После получения положительного ответа от субъекта InventoryResource субъект SalesOrderContext отправляет сообщение CreateSalesOrder субъекту SalesOrderResource, который добавляет заказ в базу данных SalesOrder и возвращает результаты.
После успешного добавления SalesOrder в свои базы данных субъект SalesOrderContext отправляет сообщение SalesOrderEventPublisher, который публикует событие SalesOrderEvent в теме «заказ на продажу».
Актер SalesOrderContext отправляет результаты обработки веб-обработчику, который затем отвечает исходному запросчику, завершая действие Cloud 1.
В этом примере базы данных SalesOrder и Inventory зеркалируются как в облаках 2, так и в 3, которые имеют экземпляры SalesOrderEventHandler. Их SalesOrderEventHandler подписывается на тему «заказ на продажу», и когда приходит событие, они отправляют его как сообщение актору, указанному для его обработки.
Актер SalesOrderEventHandlers проверяет сообщение, добавляет все необходимые инструкции в сообщение CreateSalesOrder и отправляет его субъекту SalesOrderContext.
Актер SalesOrderContext форматирует сообщение UpdateInventory и отправляет его субъекту InventoryResource, который обновляет базу данных Inventory и возвращает результаты.
После получения положительного ответа от субъекта InventoryResource субъект SalesOrderContext отправляет сообщение CreateSalesOrder субъекту SalesOrderResource, который добавляет заказ в базу данных SalesOrder и возвращает результаты.

По завершении этих шагов базы данных SalesOrder и Inventory в облаках 1, 2 и 3 имеют согласованное состояние и могут использоваться для аварийного переключения и / или балансировки нагрузки. Каждая из этих баз данных, являющихся зеркалами с несколькими ведущими, может обновляться локальными приложениями, и изменения будут распространяться на другие копии.

ОБСУЖДЕНИЕ. Модель Cloud Actor может не только реализовать функциональность приложений в облаке. Он также может предоставить строительные блоки, необходимые для управления распределенными, прозрачными для местоположения, зеркалированными хранилищами данных, необходимыми для полного выполнения обещаний облака по предоставлению автоматического масштабирования и аварийного переключения.

Переход к модели облачного актера

Создание новых приложений с помощью Cloud Actor Model может быть на удивление безболезненным занятием - как только вы почувствуете новую глину, из которой лепите. Однако одна из наиболее распространенных и сложных проблем разработки программного обеспечения и управления, с которыми мы все сталкиваемся, - это миграция критически важных приложений со старого архитектурного шаблона на новый - например, переход от монолитной или многоуровневой модели к более облачной модели Cloud Actor. Благодаря своей детализированной, разделенной компонентной модели и ее способности отображать между логическими и физическими моделями данных, модель облачного актора может упростить переход с помощью Фигурный шаблон душителя, как первоначально описывалось Мартин Фаулер . Фаулер писал:

«Семена душистого инжира прорастают в верхних ветвях дерева-хозяина и постепенно продвигаются вниз по дереву, пока не укоренятся в почве. За многие годы они вырастают в фантастические и красивые формы, одновременно задушая и убивая дерево, которое было их хозяином ».

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

Альтернативный путь - постепенно создавать новую систему по краям старой, позволяя ей медленно расти в течение нескольких лет, пока старая система не будет задушена. Это звучит сложно, но все чаще я думаю, что это одна из тех вещей, которые недостаточно испробованы ». - Мартин Фаулер

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

Заключение

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

Модель Cloud Actor - хорошая отправная точка на пути к проектированию, созданию и развертыванию мультиоблачных, надежных, масштабируемых, распределенных приложений, но есть и другие вещи, которые нам нужны в наборе инструментов. Эта статья является первой в серии из 6 частей, Создание приложений для нескольких облаков. Остальные:

Многооблачные приложения: часть 2, обмен сообщениями и брокеры -. Передача сообщений реализует слабую связь, но также может реализовывать динамическую связь . Динамическое связывание с использованием брокеров обеспечивает очень мощный механизм для реализации балансировки нагрузки, аварийного переключения и динамического масштабирования. Брокеры также могут быть важным механизмом для реализации самоорганизующихся систем. Здесь мы обсуждаем, как и почему эта архитектура их использует. Мы также обсуждаем, как современные технологии распределенного обмена сообщениями могут обрабатывать миллионы сообщений в секунду.
Многооблачные приложения: часть 3, Управление сложностью с помощью самоорганизации - Сложность является основным ограничивающим фактором в успешной реализации больших распределенных систем. Это ахиллесова пята крупных микросервисов и реализаций управления API. По мере того как количество вещей (API, сервисов, ресурсов) и связей между ними растет, сложность увеличивается в геометрической прогрессии. Нисходящие иерархические элементы управления, реализованные в большинстве систем, плохо справляются с этой сложностью. Здесь мы обсуждаем, как и почему эта архитектура реализует самоорганизацию.
Многооблачные приложения: часть 4, Использование интеллектуальных преобразователей. Большая часть работы по обработке данных - это очистка, проверка, фильтрация, объединение и преобразование данных. Передача сообщения или потока сообщений предоставляет прекрасную возможность выполнять декларативные правила для проверки и преобразования полезных данных этих сообщений с помощью интеллектуальных преобразователей. Здесь мы обсуждаем, как и почему эта архитектура их использует.
Многооблачные приложения: часть 5, Работа с распределенными данными. Облачные вычисления предоставляют огромные возможности для распределения, доступа и управления данными. Но справиться с задержкой и разделением сети при сохранении надежности, масштабируемости, параллелизма и согласованности - нетривиальная задача. Это требует методов и навыков, которые не всегда понятны. Здесь мы обсудим, как эта архитектура управляет распределением данных в облаке.
Многооблачные приложения: часть 6, объединяем все вместе - здесь мы объединили все концепции, чтобы разработать очень простой заказ на продажу. систему, которую можно было бы увидеть на любом веб-сайте электронной коммерции. Мы воспользуемся моделью Cloud Actor и выполним следующие шаги: 1) определим требования к приложению, 2) спроектируем базу данных, 3) определим внешний API, 4) определим необходимые сообщения и интеллектуальные преобразователи и 5) спроектируем необходимые актеры. Затем мы покажем, как компоненты могут быть развернуты в мультиоблачной среде.

По мере публикации каждой новой части мы будем обновлять ее маркер, чтобы он стал ссылкой на статью.

Приложение A. Требования к многооблачной архитектуре

10 основных целей, которым должна соответствовать любая мультиоблачная архитектура:

Минимизация сложности внедрения и обслуживания приложений, настройки, развертывания, управления и эксплуатации. Сложность увеличивает риск и стоимость любых усилий по внедрению программного обеспечения, особенно тех, которые связаны с выходом организации на новую и незнакомую территорию. Несоблюдение этого требования - камень, на котором чаще всего терпят неудачу облачные реализации. Большинство других требований в этом списке существуют для его поддержки.
Убедитесь, что ни одна служба или ресурсы среды выполнения не могут быть доступны или изменены без надлежащей аутентификации и авторизации. Гарантировать, что все коммуникации (сообщения) между службами имеют цифровую подпись и зашифрованы. Без выполнения этого требования любое нарушение работы любой сети или службы, задействованной в распределенном приложении, может потенциально нарушить все части этого приложения.
Убедитесь, что можно развернуть несколько идентичных служб и ресурсов, а также реализовать автоматическое переключение при отказе от служб и ресурсов к аналогичным службам и ресурсам. Без выполнения этого требования реализация любой эффективной стратегии аварийного переключения становится сложной и дорогостоящей.
Убедитесь, что желаемые параметры производительности для служб и ресурсов можно указывать и отслеживать. Предоставление средств автоматизированной среды выполнения для изменения количества и / или расположения исполняемых служб и ресурсов в соответствии с указанными параметрами. Без выполнения этого требования реализация любой эффективной стратегии масштабирования становится сложной и дорогостоящей.
Гарантировать физическую прозрачность местоположения службы или ресурса для других служб и ресурсов. Без выполнения этого требования реализация любой эффективной стратегии масштабирования или переключения при отказе становится сложной и дорогостоящей.
Доступ и управление сложными распределенными данными и представление интегрированной логической модели этих данных приложениям. Без выполнения этого требования реализация функций приложения и смешивание устаревших и новых данных становится более сложной и дорогой.
Оптимизируйте как синхронный (запрос-ответ), так и асинхронный (событие) обмен сообщениями. Без выполнения этого требования достижение желаемых показателей производительности может быть сложным и дорогостоящим. Как синхронный, так и асинхронный обмен данными необходим для полного набора сценариев использования распределенных данных.
Управляйте сетевыми ограничениями и компромиссами в отношении согласованности, доступности, допустимости разделов и задержки распределенных данных. Без выполнения этого требования реализация любой эффективной стратегии управления надежностью и производительностью становится сложной и дорогой.
Представьте согласованную, графическую, декларативную и среду разработки и управления с минимальным объемом кода, позволяющую использовать современные языки программирования, когда это требуется разработчику. Без выполнения этого требования при реализации функциональных возможностей приложения на продуктивность разработчиков негативно повлияет кривая обучения, необходимая для освоения и применения новых технологий.
Предоставьте разработчикам приложений высокофункциональные, согласованные и полезные API. Без выполнения этого требования при реализации функциональных возможностей приложения на продуктивности разработчиков будет отрицательно сказываться кривая обучения, необходимая для освоения и применения новых технологий.

Приложение B: Принципы проектирования распределенных систем

Из пресс-релиза 14 марта 2006 г., посвященного запуску AWS S3 (Simple Storage Service), автор: Вернер Фогельс

Amazon использовала следующие принципы проектирования распределенных систем для удовлетворения требований Amazon S3:

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

Приложение C: Архитектура - ключ к успеху

В сентябре 1984 года Алан Кей писал: Атомы кажутся совершенно невинными. Тем не менее биология показывает, что из простых материалов могут быть образованы чрезвычайно сложные организации, которые могут интерпретировать себя и динамически изменяться. Некоторые из них даже думают! Поэтому трудно отрицать определенные умственные возможности компьютерного материала, поскольку сильной стороной программного обеспечения также является кинетическое структурирование простых компонентов. Компьютеры «могут делать только то, на что они запрограммированы, но то же самое можно сказать об оплодотворенной яйцеклетке, пытающейся стать младенцем. Тем не менее, трудность открытия архитектуры, которая порождает менталитет, невозможно переоценить. Изучение биологии началось за несколько сотен лет до того, как были выяснены свойства ДНК и механизмы ее экспрессии, что показало, что живая клетка является архитектурой в процессе. Более того, молекулярная биология имеет то преимущество, что она изучает систему, которая уже собрана и работает; для композитора программного обеспечения компьютер похож на бутылку атомов, ожидающих своей формы с помощью архитектуры, которую он должен изобрести, а затем произвести впечатление извне ».