В настоящее время я создаю приложение с использованием платформы ReliableActors в Azure ServiceFabric. По мере того, как мы расширяемся, я планирую развертывание синего/зеленого. Я вижу, как это сделать, используя систему без сохранения состояния. Есть ли способ сделать это с помощью актеров с состоянием?
Сине-зеленые развертывания с Azure ServiceFabric
Ответы (1)
Service Fabric — это последовательное обновление, а не замена развертывания, например замена VIP. Службы без сохранения состояния и с сохранением состояния обновляются одинаково, но есть несколько дополнительных нюансов, связанных с состоянием, о которых я упомяну позже.
Под чередованием обновлений я подразумеваю, что обновления приложения выполняются на месте, по одному домену обновления за раз, чтобы не было простоев и внезапных переключений. Последовательное обновление в Service Fabric можно выполнить в безопасном «управляемом» режиме, когда платформа будет выполнять проверки работоспособности, прежде чем переходить к следующему домену обновления, и автоматически выполнять откат, если проверки работоспособности не пройдут.
Хорошо, это все звучит красиво. Но как выполнять сине-зеленые развертывания, когда обновления всегда чередуются?
Здесь на помощь приходят типы и версии приложений. Вместо двух «сред», которые могут содержать два запущенных приложения, Service Fabric использует концепцию версионных типов приложений, из которых можно создавать экземпляры приложений. Вот пример того, как это работает:
Допустим, я хочу создать приложение под названием Foo. Мое приложение Foo определено как тип приложения, назовите его FooType. Это похоже на определение класса в C#. И, как класс в C#, я могу создавать экземпляры своего типа. Каждый экземпляр имеет уникальное имя, аналогично тому, как каждый экземпляр объекта класса имеет уникальное имя переменной. Но в отличие от классов в C#, мой FooType имеет номер версии. Затем я могу «зарегистрировать» тип и версию приложения в своем кластере:
FooType 1.0
После регистрации я могу создать экземпляр этого приложения:
"fabric:/FooApp" of FooType 1.0
Теперь, допустим, я разрабатываю версию 2.0 своего приложения. Поэтому я регистрирую версию 2.0 моего FooType в кластере:
FooType 1.0
FooType 2.0
Теперь у меня зарегистрированы обе версии FooType, и у меня все еще работает экземпляр 1.0:
"fabric:/FooApp" of FooType 1.0
Вот где это становится весело. Я могу сделать несколько интересных вещей:
Я могу взять «fabric:/FooApp» — экземпляр FooType 1.0 — и обновить его до FooType 2.0. Это будет непрерывное обновление работающего приложения.
Или... Я могу оставить "fabric:/FooApp" в покое и создать новый экземпляр моего приложения версии 2.0:
"fabric:/FooApp" of FooType 1.0
"fabric:/FooAppv2Test" of FooType 2.0
Теперь у меня есть два приложения, работающих параллельно в одном кластере. Один экземпляр 1.0, а другой экземпляр 2.0. С некоторой настройкой портов и конечных точек приложений я могу гарантировать, что пользователи по-прежнему переходят к экземпляру 1.0, пока я тестирую экземпляр 2.0.
Отлично, так что все мои тесты проходят на экземпляре 2.0, так что теперь я могу безопасно взять экземпляр 1.0 и обновить его до версии 2.0 FooType. Опять же, это непрерывное обновление этого экземпляра (fabric:/FooApp), а не перенос пользователей на новый экземпляр (fabric:/FooAppv2Test). Позже я пойду и удалю ткань:/FooAppv2Test, потому что это было просто для тестирования.
Одним из преимуществ синего/зеленого является возможность переключения обратно на другое развертывание в случае сбоя нового. Ну, у вас все еще зарегистрированы как 1.0, так и 2.0 FooType. Поэтому, если ваше приложение начало работать некорректно после обновления с 1.0 до 2.0, вы можете просто «обновить» его обратно до 1.0! Фактически, вы можете «обновлять» экземпляр приложения между любым количеством различных версий его типа приложения! И вам не нужно, чтобы экземпляры всех версий вашего приложения работали, как в среде подкачки, у вас просто зарегистрированы разные версии и один экземпляр приложения, который может «обновляться» между версиями.
Я упомянул предостережения относительно сервисов с отслеживанием состояния. В случае с сервисами с отслеживанием состояния важно помнить, что состояние приложения — данные ваших пользователей — содержится в экземпляре приложения (fabric:/FooApp), поэтому, чтобы ваши пользователи могли видеть свои данные, вам нужно держать их в этом экземпляре. Вот почему мы делаем последовательные обновления вместо смены развертывания.
Это только основная идея. Есть и другие способы поиграть с типами, версиями и экземплярами приложений в зависимости от ваших целей и того, как работает ваше приложение, но об этом в другой раз.
person
Vaclav Turecek
schedule
09.03.2016
Было полезно, спасибо Вацлав. На мой взгляд, одно из преимуществ сине-зеленого развертывания заключается в том, что я могу пропустить второй сервис, чтобы убедиться, что он работает, прежде чем выполнять весь обмен, обычно направляя его через балансировщик нагрузки. Есть ли способ сделать аналогичную проверку на SF?
- person blackSphere; 10.03.2016
Конечно, для службы без сохранения состояния вы можете настроить это, создав экземпляр версии 1.0 и версии 2.0, и с помощью некоторой собственной маршрутизации вы можете направить трафик в версию 2.0, постепенно увеличивая его и уменьшая масштаб версии 1.0. Для сервисов с отслеживанием состояния это немного сложнее, потому что само состояние находится внутри экземпляра приложения, поэтому, если вы отправите пользователей в новый экземпляр приложения, их данных там не будет. Такова природа вещей с отслеживанием состояния в целом, и именно поэтому Service Fabric предлагает очень надежные первоклассные последовательные обновления.
- person Vaclav Turecek; 10.03.2016
Я бы также сказал, что последовательное обновление в некотором смысле просачивается, потому что все ваше приложение не обновляется сразу. Он обновляет один фрагмент за раз, и если в какой-то момент проверка работоспособности завершится неудачно (вы можете выполнить пользовательские проверки работоспособности), произойдет откат. Таким образом, вы можете думать об этом как об автоматизированном сквозном развертывании, и мы действительно любим автоматизацию!
- person Vaclav Turecek; 10.03.2016
Привет! Это было полезное объяснение, однако я хотел бы остановиться на том, что обновления приложения выполняются на месте, по одному домену обновления за раз, чтобы не было простоев. Неужели нет времени простоя, как в 0 секунд простоя? потому что, согласно моему тесту, при обновлении домена обновления службы не отвечают до тех пор, пока домен обновления не будет завершен.
- person itaysk; 06.05.2016
Я полагаю, что более точным способом было бы сказать: разрешить обновления без простоев. Вы, безусловно, можете сами вызвать простои любым из способов, например, кластером только с одним доменом обновления, службой с отслеживанием состояния только с одной репликой, кодом службы, который неправильно разрешает адреса службы и т. д. Но помимо этого, да, у вашего приложения не должно быть простоев во время обновления.
- person Vaclav Turecek; 19.05.2016
Как насчет двух версий веб-приложений, работающих в одном кластере? Меня в первую очередь интересуют конфликты портов, поскольку порты будут одинаковыми для обеих версий.
- person Alex Pryiomka; 08.09.2017
