引言

說到現(xiàn)代大型軟件架構(gòu)，很容易想到的就是分布式、緩存數(shù)據(jù)庫、負載均衡、資源虛擬化、微服務(wù)、組件等等。然而，如果你總是和我夸夸其談分布式、并行等各種花里胡哨的框架，卻不告訴我代碼怎么寫，那么你一定在耍流氓。作為一個基層的軟件開發(fā)人員，更關(guān)心的是 main 函數(shù)該怎么寫、大量功能函數(shù)怎么分配到不同的線程上，而這才是最底層的軟件架構(gòu)，也是最重要的。今天，我給大家介紹一種靈活的可編程軟件框架，可以說，這個框架能夠滿足絕大數(shù)場景下的軟件功能、性能及靈活性需求。

1 一個基本的軟件運行結(jié)構(gòu)圖

上圖中，

main 函數(shù)在主線程中，子線程 1 和子線程 2 都用來處理任務(wù)，任務(wù)存放在任務(wù)隊列中;

每個任務(wù)需要兩個階段才能完成，先經(jīng)過階段 1 處理，再經(jīng)過階段 2 處理;

階段 1 需要兩個函數(shù)處理，分別是函數(shù) A 和函數(shù) B;

階段 2 需要一個函數(shù)處理，即函數(shù) C.

2 函數(shù)和隊列如何部署到不同的線程上?

說到底，每個線程上運行的都是一些基本的功能函數(shù)，我們可以把實現(xiàn)某個功能的函數(shù)劃分到一個函數(shù)集合里。這個例子中，子線程 1 上運行的是函數(shù)集合 1，子線程 2 上運行的是函數(shù)集合 3.

線程、函數(shù)集合、任務(wù)隊列的綁定關(guān)系圖

當線程上的函數(shù)從任務(wù)隊列取任務(wù)進行處理的時候，我們要明確以下幾點：

• 同一個任務(wù)隊列可以被多個線程調(diào)度
• 多個線程可以調(diào)度同一個任務(wù)隊列
• 不同的函數(shù)集合可以部署在同一個線程上
• 同一個函數(shù)集合也可以部署在不同線程上

線程、函數(shù)集合、任務(wù)隊列的具體綁定關(guān)系，我們可以靈活地寫在配置文件中，比如 json、yaml 等。在進程起來之后，通過加載配置文件的方式實現(xiàn)資源的部署。為什么一個線程上可以掛多個任務(wù)隊列呢?因為任務(wù)隊列可以有不同的類型呀，比如說系統(tǒng)任務(wù)，用戶業(yè)務(wù)等。

3 線程上的函數(shù)如何調(diào)度?

在業(yè)務(wù)線程實際運行的過程中，我們只會看到一個個函數(shù)，那如何控制函數(shù)的執(zhí)行順序呢?最簡單的一種方案就是狀態(tài)機。線程每執(zhí)行一個循環(huán)，從初始狀態(tài)開始，經(jīng)過中間狀態(tài)，到最終狀態(tài)結(jié)束。任務(wù)到達每一種狀態(tài)時，就會進行相應(yīng)的動作處理(即對應(yīng)了一個有序的函數(shù)集合)，根據(jù)任務(wù)處理的結(jié)果，選擇需要跳轉(zhuǎn)的下一個狀態(tài)，直到遇到最終狀態(tài)，當前任務(wù)處理結(jié)束。接著，從任務(wù)隊列上取下一個任務(wù)，循環(huán)調(diào)度。

狀態(tài)機循環(huán)調(diào)度任務(wù)

4 線程起來之后，哪些函數(shù)集合會真正運行起來?

前文講到，在部署框架中指定了每個線程上需要運行哪些函數(shù)集合。但是，當線程實際起來之后，我們卻是根據(jù)狀態(tài)機進行調(diào)度，狀態(tài)機也指定了每個狀態(tài)需要執(zhí)行哪些動作(也就是函數(shù)集合)，那我們到底是執(zhí)行部署框架中定義的函數(shù)集合還是執(zhí)行狀態(tài)機中對應(yīng)的函數(shù)集合呢?答案當然是狀態(tài)機中對應(yīng)的函數(shù)集合呀。

總結(jié)

這篇文章中，我嘗試總結(jié)了一種基于多線程并行技術(shù)下的可靈活編排的軟件架構(gòu)。這個架構(gòu)核心的地方有兩點：一是資源部署(即隊列、函數(shù)、線程的綁定關(guān)系);二是基于狀態(tài)機原理進行調(diào)度，每個狀態(tài)處理之后如何選擇下個狀態(tài)，直接關(guān)系到軟件性能。朋友們，在摩爾定律失效、軟件性能要求越來越高的需求下，你們有更好的軟件架構(gòu)，能實現(xiàn) CPU 多核、多線程資源的最大化利用及高效的調(diào)度框架嗎?