表達過去、現在與將來：之將來(3)

前情提要

本文的第一章：表達過去、現在與將來：之將來(1)

本文的第二章：表達過去、現在與將來：之將來(2)

我們已經看到了單個coroutine可以有多麼強大。但是把所有的業務邏輯全部塞進一個coroutine是不可行的。從複雜度管理的角度，我們必須分而治之。而且「未來」也不可能是單線程的，我們必須描述同時進行的多個事情。

多任務

第一步是先要讓scheduler支持同時跑多個任務。操作系統是一個thread的scheduler一樣，它支持了執行比CPU數更多的線程。但是操作系統因為是一個底層的而且支持搶佔式調度的scheduler，所以相當之複雜。我們這裡要實現的只是一個非常簡單的合作式的scheduler。

lua version: https://tio.run/

我們把scheduler寫成通用的，我們要把tasks用一個lua table保存起來跑

lua version: https://tio.run/

再把sleep future和多任務結合起來，我們就有了這麼一個完整點的實現

lua vesion: https://tio.run/

es2017 await/async 內部有 ready_tasks。resolve 會把 task 放到這個隊列裏了。所以我們可以說 es2017 有一個內建的多任務 scheduler。

Decomposition（分解）

scheduler已經擴展為支持多個同時運行的任務了。下一步就是把一個業務流程分拆成多個子任務，從而能更好地管理複雜度。暫且不論task的粒度問題，有三種分拆長流程的方式：

這裡每一個框框都是一個coroutine。Orchestration（編排）是最簡單的形式：

lua version: https://tio.run/

Orchestration的好處是簡單。跟蹤A的調用鏈，我們可以瞭解一切。Orchestration的壞處是耦合。如果step2或者step3「不關你鳥事」，那麼要調用它們還要等它們返回是很煩的事情。在這種情況下Choreography會有幫助。

lua version: https://tio.run/

這種形式的 choreography 其實也沒有真正避免耦合。A還是知道B的存在的，B也是知道C的存在的。為瞭解耦這幾方，我們需要在它們之間插入一個存儲服務，例如消息隊列或者資料庫。

lua version: https://tio.run/

「A_subscribers」並不是一個很嚴謹的表達方式。消息隊列實際扮演的角色比這個要更複雜。我們在後面的章節會呈現一個更精確的表達。

Coordination（協調）

前面分解的目的僅僅是把一個線性的流程切分成更小的塊。看起來就是一個框接著一個框。和Decomposition不同，Coordination處理了框框之間有重疊的情況。籠統而言，可以分成兩種類型:

Fork/Join

Fork/join 其實仍然是 orchestration。假設A的老闆給A分配了一個任務，A把任務分拆成亮部分，然後分別交給了B和C去做。B和C同時去做任務，然後A在他們都完成了之後把結果收集回來，再報上去。在這個例子裏，B和C是負責的（responsible），A是擔責的（accountable）。orchestration的標誌性特徵就是有明確的責權（ownership），在最上面的傢伙需要擔下面所有的責任。

es2017 version: https://tio.run/