日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

什么是 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)開源，你可以訪問獲?。篽ttps://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)要寫清晰。基于同樣的理由，我們應該也鼓勵采用 DSL。

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

• 語言性(language nature)：DSL 是一種程序設計語言，因此它必須具備連貫的表達能力——不管是一個表達式還是多個表達式組合在一起。
• 受限的表達性(limited expressiveness)：通用程序設計語言提供廣泛的能力：支持各種數(shù)據(jù)、控制，以及抽象結(jié)構(gòu)。這些能力很有用，但也會讓語言難于學習和使用。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 寫成的腳本是一段合法的程序，但是它具有特定的風格，而且只用到了語言的一部分特性，用于處理整個系統(tǒng)一個小方面的問題。用這種 DSL 寫出的程序有一種自定義語言的風格，與其所使用的宿主語言有所區(qū)別。例如我們的狀態(tài)機就是 Internal DSL，它不支持腳本配置，使用的時候還是 Java 語言，但并不妨礙它也是 DSL。

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

• External DSL 是一種“不同于應用系統(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ā)布代碼，那么可以考慮 External。
• Workbench：配置也好，DSL Script 也好，這東西對用戶不夠友好。比如在淘寶，各種針對商品的活動和管控規(guī)則非常復雜，變化也快。我們需要一個給運營提供一個 workbench，讓他們自己設置各種規(guī)則，并及時生效。這時的 workbench 將會非常有用。

??

??

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

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

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

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 的知識我就介紹這么多。接下來，讓我們看看應該如何實現(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è)務場景雖然也不是特別復雜，但還是超出了 Enum 僅支持線性狀態(tài)流轉(zhuǎn)的范疇。因此不得不先向外看看。

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

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

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

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

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

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

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

??

??

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

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

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

狀態(tài)機本身需要是 Stateless(無狀態(tài))的，這樣一個 Singleton Instance 就能服務所有的狀態(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)，我覺得這個隱喻還是很恰當?shù)摹?/p>

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

//StateMachine 
 public class StateMachineImpl implements StateMachine { 
  
   private String machineId; 
   private final Map> stateMap; 
  
   ... 
 } 
  
   //State 
   public class StateImpl implements State { 
     protected final S stateId; 
     private Map> transitions = new HashMap<>(); 
  
   ... 
 } 
  
   //Transition 
   public class TransitionImpl implements Transition { 
  
     private State source; 
     private State target; 
     private E event; 
     private Condition condition; 
     private Action action; 
  
     ... 
 }

• 狀態(tài)機的 Fluent API

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

class  TransitionBuilderImpl implements ExternalTransitionBuilder, InternalTransitionBuilder, From, On, To {     
   ...     
   @Override     
   public From from(S stateId) {         
     source = StateHelper.getState(stateMap,stateId);         
     return this;     
   } 
  
   @Override     
    public To 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)設計

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

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

關(guān)鍵是這兩個狀態(tài)可以不要嗎?當然可以，唯一的副作用是，我們沒辦法獲取到狀態(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)設計之后，我們就可以使用一個狀態(tài)機 Instance 來響應所有的請求了，性能會大大的提升。

??

??

使用狀態(tài)機

狀態(tài)機的實現(xiàn)很簡單，同樣，他的使用也不難。如下面的代碼所示，它展現(xiàn)了 cola 狀態(tài)機支持的全部三種 transition 方式。

StateMachineBuilder 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)機顯著的提升了代碼的可讀性和可理解性。特別是在相對復雜的業(yè)務狀態(tài)流轉(zhuǎn)中，比如下圖就是我們用 cola-statemachine 生成的我們實際項目中的 plantUML 圖。如果沒有狀態(tài)機的支持，像這樣的業(yè)務代碼將會很難看懂和維護。

??

??

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

分享名稱：給DSL開個腦洞：無狀態(tài)的狀態(tài)機
本文來源：http://www.dlmjj.cn/article/djodpdh.html