什么是 DSL ?DSL 是一種工具，其核心價值在于提供了一種手段，可以更加清晰地就系統(tǒng)某部分的意圖進行溝通。本文將通過實現(xiàn)一個狀態(tài)機引擎來看清 DSL 的本質(zhì)，介紹狀態(tài)機的核心模型和 Fluent 接口，并解決狀態(tài)機的性能問題。

最近在一個項目中，因為涉及很多狀態(tài)的流轉(zhuǎn)，我們選擇使用狀態(tài)機引擎來表達狀態(tài)流轉(zhuǎn)。因為狀態(tài)機 DSL(Domain Specific Languages)帶來的表達能力，相比較于 if-else 的代碼，要更優(yōu)雅更容易理解。另一方面，狀態(tài)機很簡單，不像流程引擎那么華而不實。

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

作為 COLA 開源的一部分，我已經(jīng)將該狀態(tài)機(cola-statemachine)開源，你可以訪問獲取：https://github.com/alibaba/COLA

在實現(xiàn)狀態(tài)機的過程中，有幸看到Martin Fowler寫的《Domain Specific Languages》。書中的內(nèi)容讓我對 DSL 有了不一樣的認知。

這也是為什么會有這篇文章的原因，希望你看完這邊文章以后，可以對什么是 DSL、如何使用 DSL、如何使用狀態(tài)機都能有一個不一樣的體會。

DSL

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

下面就讓我提煉一下書中的內(nèi)容，帶大家深入了解下 DSL。

什么是 DSL

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

這種清晰并非只是審美追求。一段代碼越容易看懂，就越容易發(fā)現(xiàn)錯誤，也就越容易對系統(tǒng)進行修改。因此，我們鼓勵變量名要有意義，文檔要寫清楚，代碼結(jié)構(gòu)要寫清晰?；谕瑯拥睦碛?，我們應(yīng)該也鼓勵采用 DSL。

按照定義來說，DSL 是針對某一特定領(lǐng)域，具有受限表達性的一種計算機程序設(shè)計語言。這一定義包含 3 個關(guān)鍵元素：

• 語言性(language nature)：DSL 是一種程序設(shè)計語言，因此它必須具備連貫的表達能力——不管是一個表達式還是多個表達式組合在一起。
• 受限的表達性(limited expressiveness)：通用程序設(shè)計語言提供廣泛的能力：支持各種數(shù)據(jù)、控制，以及抽象結(jié)構(gòu)。這些能力很有用，但也會讓語言難于學(xué)習(xí)和使用。DSL 只支持特定領(lǐng)域所需要特性的最小集。使用 DSL，無法構(gòu)建一個完整的系統(tǒng)，相反，卻可以解決系統(tǒng)某一方面的問題。
• 針對領(lǐng)域(domain focus)：只有在一個明確的小領(lǐng)域下，這種能力有限的語言才會有用。這個領(lǐng)域才使得這種語言值得使用。

比如正則表達式：

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

就是一個典型的 DSL，解決的是字符串匹配這個特定領(lǐng)域的問題。

DSL 的分類

按照類型，DSL 可以分為三類：內(nèi)部 DSL(Internal DSL)、外部 DSL(External DSL)、以及語言工作臺(Language Workbench)。

• Internal DSL 是一種通用語言的特定用法。用內(nèi)部 DSL 寫成的腳本是一段合法的程序，但是它具有特定的風(fēng)格，而且只用到了語言的一部分特性，用于處理整個系統(tǒng)一個小方面的問題。用這種 DSL 寫出的程序有一種自定義語言的風(fēng)格，與其所使用的宿主語言有所區(qū)別。例如我們的狀態(tài)機就是 Internal DSL，它不支持腳本配置，使用的時候還是 Java 語言，但并不妨礙它也是 DSL。

builder.externalTransition() 
   .from(States.STATE1) 
   .to(States.STATE2) 
   .on(Events.EVENT1) 
   .when(checkCondition()) 
   .perform(doAction());

• External DSL 是一種“不同于應(yīng)用系統(tǒng)主要使用語言”的語言。外部 DSL 通常采用自定義語法，不過選擇其他語言的語法也很常見(XML 就是一個常見選 擇)。比如像 Struts 和 Hibernate 這樣的系統(tǒng)所使用的 XML 配置文件。
• Workbench 是一個專用的 IDE，簡單點說，工作臺是 DSL 的產(chǎn)品化和可視化形態(tài)。

三個類別 DSL 從前往后是有一種遞進關(guān)系，Internal DSL 最簡單，實現(xiàn)成本也低，但是不支持“外部配置”。Workbench 不僅實現(xiàn)了配置化，還實現(xiàn)了可視化，但是實現(xiàn)成本也最高。他們的關(guān)系如下圖所示：

??

不同 DSL 該如何選擇

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

• Internal DSL：假如你只是為了增加代碼的可理解性，不需要做外部配置，我建議使用 Internal DSL，簡單、方便、直觀。
• External DSL：如果你需要在 Runtime 的時候進行配置，或者配置完，不想重新部署代碼，可以考慮這種方式。比如，你有一個規(guī)則引擎，希望增加一條規(guī)則的時候，不需要重復(fù)發(fā)布代碼，那么可以考慮 External。
• Workbench：配置也好，DSL Script 也好，這東西對用戶不夠友好。比如在淘寶，各種針對商品的活動和管控規(guī)則非常復(fù)雜，變化也快。我們需要一個給運營提供一個 workbench，讓他們自己設(shè)置各種規(guī)則，并及時生效。這時的 workbench 將會非常有用。

??

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

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

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

Fluent Interfaces

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

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

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

連貫接口(fluent interfaces)是實現(xiàn) Internal DSL 的重要方式，為什么這么說呢?

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

比如 Mockito 的 API：

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

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

如果把這個 Fluent 換成是 Command-Query API，將很難表達出測試框架的領(lǐng)域。

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

這里需要注意的是，連貫接口不僅僅可以提供類似于 method chaining 和 builder 模式的方法級聯(lián)調(diào)用，比如 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)

他更重要的作用是，限定方法調(diào)用的順序。比如，在構(gòu)建狀態(tài)機的時候，我們只有在調(diào)用了 from 方法后，才能調(diào)用 to 方法，Builder 模式?jīng)]有這個功能。

怎么做呢?我們可以使用 Builder 和 Fluent 接口結(jié)合起來的方式來實現(xiàn)，下面的狀態(tài)機實現(xiàn)部分，我會進一步介紹。

狀態(tài)機

好的，關(guān)于 DSL 的知識我就介紹這么多。接下來，讓我們看看應(yīng)該如何實現(xiàn)一個 Internal DSL 的狀態(tài)機引擎。

狀態(tài)機選型

我反對濫用流程引擎，但并不排斥狀態(tài)機，主要有以下兩個原因：

• 首先，狀態(tài)機的實現(xiàn)可以非常的輕量，最簡單的狀態(tài)機用一個 Enum 就能實現(xiàn)，基本是零成本。
• 其次，使用狀態(tài)機的 DSL 來表達狀態(tài)的流轉(zhuǎn)，語義會更加清晰，會增強代碼的可讀性和可維護性。

然而，我們的業(yè)務(wù)場景雖然也不是特別復(fù)雜，但還是超出了 Enum 僅支持線性狀態(tài)流轉(zhuǎn)的范疇。因此不得不先向外看看。

開源狀態(tài)機太復(fù)雜

和流程引擎一樣，開源的狀態(tài)機引擎不可謂不多，我著重看了兩個狀態(tài)機引擎的實現(xiàn)，一個是 Spring Statemachine，一個是 Squirrel statemachine。這是目前在 github 上的 Top 2 的狀態(tài)機實現(xiàn)，他們的優(yōu)點是功能很完備，缺點也是功能很完備。

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

就我們的項目而言(其實大部分項目都是如此)，我實在不需要那么多狀態(tài)機的高級玩法：比如狀態(tài)的嵌套(substate)，狀態(tài)的并行(parallel，fork，join)、子狀態(tài)機等等。

開源狀態(tài)機性能差

除此之外，還有一個我不能容忍的問題是，這些開源的狀態(tài)機都是有狀態(tài)的(Stateful)的，表面上來看，狀態(tài)機理所當(dāng)然是應(yīng)該維持狀態(tài)的。但是深入想一下，這種狀態(tài)性并不是必須的，因為有狀態(tài)，狀態(tài)機的實例就不是線程安全的，而我們的應(yīng)用服務(wù)器是分布式多線程的，所以在每一次狀態(tài)機在接受請求的時候，都不得不重新 build 一個新的狀態(tài)機實例。

以電商交易為例，用戶下單后，我們調(diào)用狀態(tài)機實例將狀態(tài)改為“Order Placed”。當(dāng)用戶支付訂單的時候，可能是另一個線程，也可能是另一臺服務(wù)器，所以我們必須重新創(chuàng)建一個狀態(tài)機實例。因為原來的 instance 不是線程安全的。

??

這種 new instance per request 的做法，耗電不說。倘若狀態(tài)機的構(gòu)建很復(fù)雜，QPS 又很高的話，肯定會遇到性能問題。

鑒于復(fù)雜性和性能(公司電費)的考慮，我們決定自己實現(xiàn)一個狀態(tài)機引擎，設(shè)計的目標很明確，有兩個要求：

簡潔的僅支持狀態(tài)流轉(zhuǎn)的狀態(tài)機，不需要支持嵌套、并行等高級玩法。

狀態(tài)機本身需要是 Stateless(無狀態(tài))的，這樣一個 Singleton Instance 就能服務(wù)所有的狀態(tài)流轉(zhuǎn)請求了。

狀態(tài)機實現(xiàn)

• 狀態(tài)機領(lǐng)域模型

鑒于我們的訴求是實現(xiàn)一個僅支持簡單狀態(tài)流轉(zhuǎn)的狀態(tài)機，該狀態(tài)機的核心概念如下圖所示，主要包括：

1. State：狀態(tài)
2. Event：事件，狀態(tài)由事件觸發(fā)，引起變化
3. Transition：流轉(zhuǎn)，表示從一個狀態(tài)到另一個狀態(tài)
4. External Transition：外部流轉(zhuǎn)，兩個不同狀態(tài)之間的流轉(zhuǎn)
5. Internal Transition：內(nèi)部流轉(zhuǎn)，同一個狀態(tài)之間的流轉(zhuǎn)
6. Condition：條件，表示是否允許到達某個狀態(tài)
7. Action：動作，到達某個狀態(tài)之后，可以做什么
8. StateMachine：狀態(tài)機

??

整個狀態(tài)機的核心語義模型(Semantic Model)也很簡單，就是如下圖所示：

??

Note：這里之所以叫 Semantic Model，用的是《DSL》書里的術(shù)語，你也可以理解為是狀態(tài)機的領(lǐng)域模型。Martin 用 Semantic 這個詞，是想說，外部的 DSL script 代表語法(Syntax)，里面的 model 代表語義(Semantic)，我覺得這個隱喻還是很恰當(dāng)?shù)摹?/p>

OK，狀態(tài)機語義模型的核心代碼如下所示：

//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; 
  
     ... 
 }

• 狀態(tài)機的 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 調(diào)用的順序，如下圖所示，在 externalTransition 的后面你只能調(diào)用 from，在 from 的后面你只能調(diào)用 to，從而保證了狀態(tài)機構(gòu)建的語義正確性和連貫性。

??

• 狀態(tài)機的無狀態(tài)設(shè)計

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

分析一下市面上的開源狀態(tài)機引擎，不難發(fā)現(xiàn)，它們之所以有狀態(tài)，主要是在狀態(tài)機里面維護了兩個狀態(tài)：初始狀態(tài)(initial state)和當(dāng)前狀態(tài)(current state)，如果我們能把這兩個實例變量去掉的話，就可以實現(xiàn)無狀態(tài)，從而實現(xiàn)一個狀態(tài)機只需要有一個 instance 就夠了。

關(guān)鍵是這兩個狀態(tài)可以不要嗎?當(dāng)然可以，唯一的副作用是，我們沒辦法獲取到狀態(tài)機 instance 的 current state。然而，我也不需要知道，因為我們使用狀態(tài)機，僅僅是接受一下 source state，check 一下 condition，execute 一下 action，然后返回 target state 而已。它只是實現(xiàn)了一個狀態(tài)流轉(zhuǎn)的 DSL 表達，僅此而已，全程操作完全可以是無狀態(tài)的。

采用了無狀態(tài)設(shè)計之后，我們就可以使用一個狀態(tài)機 Instance 來響應(yīng)所有的請求了，性能會大大的提升。

??

使用狀態(tài)機

狀態(tài)機的實現(xiàn)很簡單，同樣，他的使用也不難。如下面的代碼所示，它展現(xiàn)了 cola 狀態(tài)機支持的全部三種 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 的狀態(tài)機顯著的提升了代碼的可讀性和可理解性。特別是在相對復(fù)雜的業(yè)務(wù)狀態(tài)流轉(zhuǎn)中，比如下圖就是我們用 cola-statemachine 生成的我們實際項目中的 plantUML 圖。如果沒有狀態(tài)機的支持，像這樣的業(yè)務(wù)代碼將會很難看懂和維護。

??

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