引言

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

1 一個基本的軟件運行結構圖

上圖中，

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

每個任務需要兩個階段才能完成，先經過階段 1 處理，再經過階段 2 處理;

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

階段 2 需要一個函數處理，即函數 C.

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

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

線程、函數集合、任務隊列的綁定關系圖

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

• 同一個任務隊列可以被多個線程調度
• 多個線程可以調度同一個任務隊列
• 不同的函數集合可以部署在同一個線程上
• 同一個函數集合也可以部署在不同線程上

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

3 線程上的函數如何調度?

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

狀態機循環調度任務

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

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

總結

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