1、使用閘道器設計流程路徑
2、基於資料的專用閘道器
某些事情只能在某些情況下才能完成，所以很少有過程總是走同一條路。
圖2.1:xor閘道器。
在我們的簡單示例(圖2.1)中，我們希望深入烹飪的細節。在飢餓的驅使下，我們思考今天要做什麼。我們只知道三種食譜，所以我們選擇一種。我們要麼做義大利面，要麼做牛排，要麼準備沙拉。假設這些選項是排他性的——我們永遠不會一次準備多個選項。決定下一步要做什麼的點稱為閘道器。我們根據可用資料(選擇的配方)進行決定，並且只遵循其中一條路徑，這是乙個基於資料的獨佔閘道器。我們將獨佔閘道器簡稱為xor。
請記住，閘道器不是乙個任務!在到達乙個入口之前，你必須確定事實和需要。我們將在商業決策管理中再次遇到這個問題。
圖2.2:兩個符號含義相同。
bpmn為異或閘道器使用了兩個符號(參見圖2.2)。它們的意思相同。我們總是使用帶有x的版本，因為它看起來不那麼模糊，但是使用適合您的版本。
我們的bpmn約定俗成:如圖2.1所示，我們將關鍵問題放在了閘道器之前。這是我們的慣例，它在我們的專案中證明了它的價值。在閘道器之後，可能的答案是並行的，bpmn規範就是這樣顯示它們的。我們一直使用以下xor閘道器:
1. 為需要決定xor閘道器的任務建模。
2. 然後對xor閘道器建模。創造乙個答案相互排斥的問題。
3. 為每個可能的答案建模乙個傳出路徑(或序列流)，並用答案標記該路徑。
異或閘道器可以有任意多的傳出路徑。我們在左上角開始一些路徑，在左下角開始另一些路徑，但這只是我們的風格約定。
順便說一下，有三個結束事件，程序產生三個結束狀態也不是不尋常的。認識到這種可能性可以幫助您處理更複雜的圖表。稍後，我們將給出使用不同end事件的更多理由。bpmn不是面向塊的過程符號，因此您不需要在稍後合併乙個分割過程路徑——您可以這樣做，但您也不必這樣做。
當然，合併這三條路徑在語義上是有意義的。無論選擇什麼食譜，這頓飯都是在做好之後吃的。我們還可以使用xor閘道器進行合併，這樣做會將三個傳入路徑的令牌引導到乙個傳出路徑。(參見圖2.3)
圖2.3:xor閘道器也可以合併。
表示合併/拆分的兩種方法
圖2.4:表示合併/拆分的兩種方法
盤古bpm
OpenResty api閘道器設計
本文講述openresty api閘道器設計，主要涉及api閘道器介紹 openresty api閘道器 請求路由 路由判斷 路由重寫 服務判斷 限流 授權驗證 統一認證 動態upstream 以及這三部分理論簡單實現的api閘道器和api閘道器admin。1 什麼是api閘道器 在這個微服務這麼火...
閘道器設計日記
2.路由更新和熱過載 1.1 如何實現身份認證？最簡單的場景，使用者輸入使用者名稱密碼登入，閘道器讀庫或者請求使用者服務http介面，驗證成功後，返回使用者乙個token。每次使用者請求資源介面都要帶著這個token。如何校驗這個token呢？把token放在記憶體資料庫 如redis 每次請求從c...
Gateway閘道器設計 一
閘道器gateway，它負責與客戶端建立連線，接收客戶端傳送過來的訊息，並對訊息進行驗證，等。1，閘道器的功能 1.1 與客戶端建立連線 這個應該是閘道器最基本的網功了，乙個服務做為閘道器，所有客戶端來的訊息都必須先到達這裡。客戶端與閘道器採用tcp長連線。1.2 訊息過濾 客戶端可能給伺服器傳送任...