天天看點
傳回

給 DSL 開個腦洞：無狀态的狀态機

最近在一個項目中，因為涉及很多狀态的流轉，我們選擇使用狀态機引擎來表達狀态流轉。因為狀态機 DSL（Domain Specific Languages）帶來的表達能力，相比較于 if-else 的代碼，要更優雅更容易了解。另一方面，狀态機很簡單，不像流程引擎那麼華而不實。

一開始我們選用了一個開源的狀态機引擎，但我覺得不好用，就自己寫了一個能滿足我們要求的簡潔版狀态機，這樣比較 KISS（Keep It Simple and Stupid）。

作為 COLA 開源的一部分，我已經将該狀态機（cola-statemachine）開源，你可以通路擷取：

https://github.com/alibaba/COLA

在實作狀态機的過程中，有幸看到Martin Fowler寫的《Domain Specific Languages》。書中的内容讓我對 DSL 有了不一樣的認知。

這也是為什麼會有這篇文章的原因，希望你看完這邊文章以後，可以對什麼是 DSL、如何使用 DSL、如何使用狀态機都能有一個不一樣的體會。

DSL

在介紹如何實作狀态機之前，不妨讓我們先來看一下什麼是 DSL，在 Martin Fowler 的《Domain Specific Languages》書中。開篇就是以 State Machine 來作為引子介紹 DSL 的。有時間的話，強烈建議你去讀讀這本書。沒時間的話，看看下面的内容也能掌握個大概了。

下面就讓我提煉一下書中的内容，帶大家深入了解下 DSL。

什麼是 DSL

DSL 是一種工具，它的核心價值在于，它提供了一種手段，可以更加清晰地就系統某部分的意圖進行溝通。

這種清晰并非隻是審美追求。一段代碼越容易看懂，就越容易發現錯誤，也就越容易對系統進行修改。是以，我們鼓勵變量名要有意義，文檔要寫清楚，代碼結構要寫清晰。基于同樣的理由，我們應該也鼓勵采用 DSL。

按照定義來說，DSL 是針對某一特定領域，具有受限表達性的一種計算機程式設計語言。這一定義包含 3 個關鍵元素：

  • 語言性（language nature）：DSL 是一種程式設計語言，是以它必須具備連貫的表達能力——不管是一個表達式還是多個表達式組合在一起。
  • 受限的表達性（limited expressiveness）：通用程式設計語言提供廣泛的能力：支援各種資料、控制，以及抽象結構。這些能力很有用，但也會讓語言難于學習和使用。DSL 隻支援特定領域所需要特性的最小集。使用 DSL，無法建構一個完整的系統，相反，卻可以解決系統某一方面的問題。
  • 針對領域（domain focus）：隻有在一個明确的小領域下，這種能力有限的語言才會有用。這個領域才使得這種語言值得使用。

比如正規表達式：

/\d{3}-\d{3}-\d{4}/

就是一個典型的 DSL，解決的是字元串比對這個特定領域的問題。

DSL 的分類

按照類型，DSL 可以分為三類：内部 DSL（Internal DSL）、外部 DSL（External DSL）、以及語言工作台（Language Workbench）。

  • Internal DSL 是一種通用語言的特定用法。用内部 DSL 寫成的腳本是一段合法的程式，但是它具有特定的風格，而且隻用到了語言的一部分特性，用于處理整個系統一個小方面的問題。用這種 DSL 寫出的程式有一種自定義語言的風格，與其所使用的宿主語言有所差別。例如我們的狀态機就是 Internal DSL，它不支援腳本配置，使用的時候還是 Java 語言，但并不妨礙它也是 DSL。 
builder.externalTransition()
  .from(States.STATE1)
  .to(States.STATE2)
  .on(Events.EVENT1)
  .when(checkCondition())
  .perform(doAction());
  • External DSL 是一種“不同于應用系統主要使用語言”的語言。外部 DSL 通常采用自定義文法，不過選擇其他語言的文法也很常見（XML 就是一個常見選 擇）。比如像 Struts 和 Hibernate 這樣的系統所使用的 XML 配置檔案。
  • Workbench 是一個專用的 IDE，簡單點說，工作台是 DSL 的産品化和可視化形态。

三個類别 DSL 從前往後是有一種遞進關系，Internal DSL 最簡單，實作成本也低，但是不支援“外部配置”。Workbench 不僅實作了配置化，還實作了可視化，但是實作成本也最高。他們的關系如下圖所示：

給 DSL 開個腦洞：無狀态的狀态機

不同 DSL 該如何選擇

幾種 DSL 類型各有各的使用場景，選擇的時候，可以這樣去做一個判斷。

  • Internal DSL：假如你隻是為了增加代碼的可了解性，不需要做外部配置，我建議使用 Internal DSL，簡單、友善、直覺。
  • External DSL：如果你需要在 Runtime 的時候進行配置，或者配置完，不想重新部署代碼，可以考慮這種方式。比如，你有一個規則引擎，希望增加一條規則的時候，不需要重複釋出代碼，那麼可以考慮 External。
  • Workbench：配置也好，DSL Script 也好，這東西對使用者不夠友好。比如在淘寶，各種針對商品的活動和管控規則非常複雜，變化也快。我們需要一個給營運提供一個 workbench，讓他們自己設定各種規則，并及時生效。這時的 workbench 将會非常有用。
給 DSL 開個腦洞：無狀态的狀态機

總而言之，在合适的地方用合适的解決方案，不能一招鮮吃遍天。就像最臭名昭著的 DSL —— 流程引擎，就屬于那種嚴重的被濫用和過渡設計的典型，是把簡單的問題複雜化的典型。

最好不要無端增加複雜性。然而，想做簡單也不是一件容易的事，特别是在大公司，我們不僅要寫代碼，還要能沉澱“NB 的技術”，最好是那種可以把老闆說的一愣一愣的技術，就像尼古拉斯在《反脆弱》裡面說的：

在現代生活中，簡單的做法一直難以實作，因為它有違某些努力尋求複雜化以證明其工作合理性的人所秉持的精神。

Fluent Interfaces

在編寫軟體庫的時候，我們有兩種選擇。一種是提供 Command-Query API，另一種是 Fluent Interfaces。比如 Mockito 的 API ：

when(mockedList.get(anyInt())).thenReturn("element")

就是一種典型連貫接口的用法。

連貫接口（fluent interfaces）是實作 Internal DSL 的重要方式，為什麼這麼說呢？

因為 Fluent 的這種連貫性帶來的可讀性和可了解的提升，其本質不僅僅是在提供 API，更是一種領域語言，是一種 Internal DSL。

比如 Mockito 的 API：

when(mockedList.get(anyInt())).thenReturn("element")

就非常适合用 Fluent 的形式，實際上，它也是單元測試這個特定領域的 DSL。

如果把這個 Fluent 換成是 Command-Query API，将很難表達出測試架構的領域。

String element = mockedList.get(anyInt());
boolean isExpected = "element".equals(element);

這裡需要注意的是，連貫接口不僅僅可以提供類似于 method chaining 和 builder 模式的方法級聯調用，比如 OkHttpClient 中的 Builder：

OkHttpClient.Builder builder=new OkHttpClient.Builder();
  OkHttpClient okHttpClient=builder
    .readTimeout(5*1000, TimeUnit.SECONDS)
    .writeTimeout(5*1000, TimeUnit.SECONDS)
    .connectTimeout(5*1000, TimeUnit.SECONDS)

他更重要的作用是，限定方法調用的順序。比如，在建構狀态機的時候，我們隻有在調用了 from 方法後，才能調用 to 方法，Builder 模式沒有這個功能。

怎麼做呢？我們可以使用 Builder 和 Fluent 接口結合起來的方式來實作，下面的狀态機實作部分，我會進一步介紹。

狀态機

好的，關于 DSL 的知識我就介紹這麼多。接下來，讓我們看看應該如何實作一個 Internal DSL 的狀态機引擎。

狀态機選型

我反對濫用流程引擎，但并不排斥狀态機，主要有以下兩個原因：

首先，狀态機的實作可以非常的輕量，最簡單的狀态機用一個 Enum 就能實作，基本是零成本。

其次，使用狀态機的 DSL 來表達狀态的流轉，語義會更加清晰，會增強代碼的可讀性和可維護性。

然而，我們的業務場景雖然也不是特别複雜，但還是超出了 Enum 僅支援線性狀态流轉的範疇。是以不得不先向外看看。

開源狀态機太複雜

和流程引擎一樣，開源的狀态機引擎不可謂不多，我着重看了兩個狀态機引擎的實作，一個是 Spring Statemachine，一個是 Squirrel statemachine。這是目前在 github 上的 Top 2 的狀态機實作，他們的優點是功能很完備，缺點也是功能很完備。

當然，這也不能怪開源軟體的作者，你好不容易開源一個項目，至少要把 UML State Machine 上羅列的功能點都支援掉吧。

就我們的項目而言（其實大部分項目都是如此），我實在不需要那麼多狀态機的進階玩法：比如狀态的嵌套（substate），狀态的并行（parallel，fork，join）、子狀态機等等。

開源狀态機性能差

除此之外，還有一個我不能容忍的問題是，這些開源的狀态機都是有狀态的（Stateful）的，表面上來看，狀态機理所當然是應該維持狀态的。但是深入想一下，這種狀态性并不是必須的，因為有狀态，狀态機的執行個體就不是線程安全的，而我們的應用伺服器是分布式多線程的，是以在每一次狀态機在接受請求的時候，都不得不重新 build 一個新的狀态機執行個體。

以電商交易為例，使用者下單後，我們調用狀态機執行個體将狀态改為“Order Placed”。當使用者支付訂單的時候，可能是另一個線程，也可能是另一台伺服器，是以我們必須重新建立一個狀态機執行個體。因為原來的 instance 不是線程安全的。

給 DSL 開個腦洞：無狀态的狀态機

這種 new instance per request 的做法，耗電不說。倘若狀态機的建構很複雜，QPS 又很高的話，肯定會遇到性能問題。

鑒于複雜性和性能（公司電費）的考慮，我們決定自己實作一個狀态機引擎，設計的目标很明确，有兩個要求：

  1. 簡潔的僅支援狀态流轉的狀态機，不需要支援嵌套、并行等進階玩法。
  2. 狀态機本身需要是 Stateless（無狀态）的，這樣一個 Singleton Instance 就能服務所有的狀态流轉請求了。

狀态機實作

  • 狀态機領域模型

鑒于我們的訴求是實作一個僅支援簡單狀态流轉的狀态機，該狀态機的核心概念如下圖所示，主要包括：

  1. State：狀态
  2. Event：事件，狀态由事件觸發，引起變化
  3. Transition：流轉，表示從一個狀态到另一個狀态
  4. External Transition：外部流轉，兩個不同狀态之間的流轉
  5. Internal Transition：内部流轉，同一個狀态之間的流轉
  6. Condition：條件，表示是否允許到達某個狀态
  7. Action：動作，到達某個狀态之後，可以做什麼
  8. StateMachine：狀态機
給 DSL 開個腦洞：無狀态的狀态機

整個狀态機的核心語義模型（Semantic Model）也很簡單，就是如下圖所示：

給 DSL 開個腦洞：無狀态的狀态機

Note：這裡之是以叫 Semantic Model，用的是《DSL》書裡的術語，你也可以了解為是狀态機的領域模型。Martin 用 Semantic 這個詞，是想說，外部的 DSL script 代表文法（Syntax），裡面的 model 代表語義（Semantic），我覺得這個隐喻還是很恰當的。

OK，狀态機語義模型的核心代碼如下所示：

//StateMachine
public class StateMachineImpl<S,E,C> implements StateMachine<S, E, C> {

  private String machineId;
  private final Map<S, State<S,E,C>> stateMap;

  ...
}

  //State
  public class StateImpl<S,E,C> implements State<S,E,C> {
    protected final S stateId;
    private Map<E, Transition<S, E,C>> transitions = new HashMap<>();

  ...
}

  //Transition
  public class TransitionImpl<S,E,C> implements Transition<S,E,C> {

    private State<S, E, C> source;
    private State<S, E, C> target;
    private E event;
    private Condition<C> condition;
    private Action<S,E,C> action;

    ...
}
  • 狀态機的 Fluent API

實際上，我用來寫 Builder 和 Fluent Interface 的代碼甚至比核心代碼還要多，比如我們的 TransitionBuilder 是這樣寫的

class  TransitionBuilderImpl<S,E,C> implements ExternalTransitionBuilder<S,E,C>, InternalTransitionBuilder<S,E,C>, From<S,E,C>, On<S,E,C>, To<S,E,C> {    
  ...    
  @Override    
  public From<S, E, C> from(S stateId) {        
    source = StateHelper.getState(stateMap,stateId);        
    return this;    
  }

  @Override    
   public To<S, E, C> to(S stateId) {        
     target = StateHelper.getState(stateMap, stateId);        
     return this;    
  }   
  ...
}

通過這種 Fluent Interface 的方式，我們確定了 Fluent 調用的順序，如下圖所示，在 externalTransition 的後面你隻能調用 from，在 from 的後面你隻能調用 to，進而保證了狀态機建構的語義正确性和連貫性。

  • 狀态機的無狀态設計

至此，狀态機的核心模型和 Fluent 接口我已經介紹完了。我們還需要解決一個性能問題，也就是我前面說的，要把狀态機變成無狀态的。

分析一下市面上的開源狀态機引擎，不難發現，它們之是以有狀态，主要是在狀态機裡面維護了兩個狀态：初始狀态（initial state）和目前狀态（current state），如果我們能把這兩個執行個體變量去掉的話，就可以實作無狀态，進而實作一個狀态機隻需要有一個 instance 就夠了。

關鍵是這兩個狀态可以不要嗎？當然可以，唯一的副作用是，我們沒辦法擷取到狀态機 instance 的 current state。然而，我也不需要知道，因為我們使用狀态機，僅僅是接受一下 source state，check 一下 condition，execute 一下 action，然後傳回 target state 而已。它隻是實作了一個狀态流轉的 DSL 表達，僅此而已，全程操作完全可以是無狀态的。

采用了無狀态設計之後，我們就可以使用一個狀态機 Instance 來響應所有的請求了，性能會大大的提升。

給 DSL 開個腦洞：無狀态的狀态機

使用狀态機

狀态機的實作很簡單，同樣，他的使用也不難。如下面的代碼所示，它展現了 cola 狀态機支援的全部三種 transition 方式。

StateMachineBuilder<States, Events, Context> builder = StateMachineBuilderFactory.create();
  //external transition  
  builder.externalTransition()    
    .from(States.STATE1)    
    .to(States.STATE2)    
    .on(Events.EVENT1)    
     .when(checkCondition())    
     .perform(doAction());

   //internal transition  
  builder.internalTransition()    
     .within(States.STATE2)    
    .on(Events.INTERNAL_EVENT)    
    .when(checkCondition())    
    .perform(doAction());

  //external transitions  
  builder.externalTransitions()    
    .fromAmong(States.STATE1, States.STATE2, States.STATE3)    
    .to(States.STATE4)    
    .on(Events.EVENT4)    
    .when(checkCondition())    
     .perform(doAction());
    
  builder.build(machineId);

可以看到，這種 Internal DSL 的狀态機顯著的提升了代碼的可讀性和可了解性。特别是在相對複雜的業務狀态流轉中，比如下圖就是我們用 cola-statemachine 生成的我們實際項目中的 plantUML 圖。如果沒有狀态機的支援，像這樣的業務代碼将會很難看懂和維護。

給 DSL 開個腦洞：無狀态的狀态機

這就是 DSL 的核心價值——更加清晰地表達系統中，某一部分的設計意圖和業務語義。當然 External DSL 所帶來的可配置性和靈活性也很有價值，隻是 cola-statemachine 還沒有支援，原因很簡單，暫時用不上。

xml 資料可視化 安全 java 應用服務中間件 測試技術 api UML 資料格式 spring dsl狀态機 dsl狀态機規則 iot申請狀态 sql執行狀态 架構dsl
上一篇: 【雲栖号案例 | 網際網路】多來點通過混合雲建構異地雙活架構資料中心
下一篇: 招人！想像孫傳亮一樣做個有“安全感”的人嗎？履歷砸過來～

繼續閱讀