Статьи

Spring Statemachine 1.0.0.RC1 выпущен

Ноябрь 7, 2017

Мы рады объявить о выпуске первой версии Spring Statemachine 1.0.0.RC1.

Целью этого выпуска является повышение стабильности ядра и, наконец, добавление тестов jepsen для распределенного конечного автомата. Мы также добавили первую версию поддержки тестирования. Разрешенные билеты на github можно найти в выпусках RC1 . Мы относительно близки к выпуску релизной версии, а это означает, что если ничего не всплывет, следующий релиз будет 1.0.0.RELEASE. Если что-то срочно появится, мы сделаем это 1.0.0.RC2до выпуска

Теперь, когда мы здесь, давайте разберемся с этим и посмотрим, какие новые функции у нас есть в этом выпуске.

Помимо обычных исправлений, здесь приведен список основных новых функций:

  • Поддержка тестирования
  • Jepsen тестирует машину распределенного состояния

Поддержка тестирования

Тестирование конечного автомата — задача не из легких, поэтому мы вводим новый spring-statemachine-testмодуль, который упростит процесс создания модульных тестов для Spring Statemachine. Из-за зависимостей он не используется в базовой системе, но для интеграции recipesи Zookeeperинтеграции он уже используется для тестирования этих модулей.

Тестирование простого конечного автомата в тестах будет выглядеть так:

StateMachine<String, String> machine = buildMachine();
StateMachineTestPlan<String, String> plan =
  StateMachineTestPlanBuilder.<String, String>builder()
    .defaultAwaitTime(2)
    .stateMachine(machine)
    .step()
      .expectStates("SI")
      .and()
    .step()
      .sendEvent("E1")
      .expectStateChanged(1)
      .expectStates("S1")
      .and()
    .build();
plan.test();

Если конечный автомат определен как:

StateMachine<String, String> buildMachine()
    throws Exception {
  StateMachineBuilder.Builder<String, String> builder =
    StateMachineBuilder.builder();

  builder.configureConfiguration()
    .withConfiguration()
      .taskExecutor(new SyncTaskExecutor())
      .autoStartup(true);

  builder.configureStates()
    .withStates()
      .initial("SI")
      .state("S1");

  builder.configureTransitions()
    .withExternal()
      .source("SI").target("S1")
      .event("E1");

   return builder.build();
}

Тесты Джепсена

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

Среда тестирования Jepsen от Kyle Kingsbury (также известная как @aphyr ) — это система, которая может использоваться для тестирования распределенных систем и имеет такие функции, как синхронизация событий, отправляемых в узлы, и вызывающая расщепление мозга в сети. Jepsen будет ядром нашей системы, чтобы гарантировать, что наша распределенная поддержка сделает то, что должна. Это первоклассная система для тестирования Spring Distributed Statemachine при поддержке Zookeeper.

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

Здесь мы взглянем на наши тесты jepsen, чтобы показать, что происходит, когда кластер подвергается расщеплению, что приводит к полному разрушению ансамбля zookeeper, и что радует, когда сеть ломается и излечивается.

Образец зоопарка

На приведенном выше графике у нас есть кластер из 5 узлов, совместно использующий одну и ту же конфигурацию конечного автомата, подкрепленный Zookeeperансамблем, в котором каждый узел подключается к своему собственному локальному экземпляру. Сначала Cна все машины отправляется событие (только одно будет обрабатывать изменение распределенного состояния), которое инициирует распределенный переход из состояния S21в S211. Затем сеть обрывается, и график показывает, как каждая машина в конечном итоге переходит в состояние ошибки. Когда сеть и Zookeeperансамбль будут позже вылечены, все машины снова присоединятся к ансамблю и синхронизируют свои состояния. Наконец, событие Kотправляется снова на все машины, чтобы показать, что все машины работают должным образом после устранения проблем в сети.

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

SpringOne 2GX 2015 не за горами!

Забронируйте свое место в SpringOne2GX в Вашингтоне, округ Колумбия, в ближайшее время . Это просто лучшая возможность узнать из первых рук обо всем, что происходит, и предоставить прямую обратную связь.

29
Share: