前言#
由於歷史原因，小米商城產品站存在許多問題和不便。隨著技術的快速變革和技術部門中台化的建設，它越來越不適用於現在快速迭代的業務需求。接下來，我將從技術的角度講解我們遇到的痛點以及解決這些痛點的思路，也就是 Phoenix 框架誕生的故事。
為什麼要設計一個框架，實際上是由於業務發展的導向結果。如果我們不進行設計，那麼我們將遇到以下一些問題：
- 在新的產品需求規劃下，無法承接大型項目，只能進行小修小改；
- 小米網產品站最初，每個端一套代碼邏輯，風格各異；
- 歷史積累，一個接口函數 2000 多行，熟悉代碼邏輯的成本越來越大；
- 隔離性差，服務可用性嚴重依賴下游，下游一個接口的抖動都會給我們接口帶來恐慌；
- 技術上整體中台化建設，隨著調用接口越來越多，接口越來越慢；
- 代碼沒有解耦，特別對新同事而言，新項目上線風險高；
- 缺少 Go 基礎組件的維護，無法對下游接口進行實時監控；
思考#
我們從技術上計劃進行重構，那麼我們如何將現有的調度邏輯抽象出一套兼顧穩定性、便捷開發、可維護性且可監控的框架模型是我們首先帶來的問題。
我去調研了開源的一些並發框架，發現傳統的並發調度模型基本上都有依賴關係、超時控制、線程池分配調度、熔斷限流、接口監控等功能。
為什麼我們沒有直接使用開源並發框架進行開發呢？
我調研發現業界 LiteFlow 框架是最受歡迎和好評的框架，於是在 Github 上了解框架底層實現的細節。隨著深入閱讀源碼，我發現這款框架設計得非常優秀，但也過於龐大、複雜，特別是 EL 規則的寫法，相對來說還是有一定的上手成本。
那麼我就在思考，作為業務開發人員，我不想關心這麼複雜的依賴關係，只需要關心自己產品站業務調用到的中台接口及其依賴接口即可。特別是大型接口捆綁了幾十個下游接口的邏輯，要是理解每個接口的設計細節更是不太可能的，要是依賴關係特別複雜，那麼 EL 規則會寫得非常複雜且維護成本極高。
那麼該如何設計一款輕量、快速、高效、從根本上解決開發人員手動維護依賴關係的並發框架呢？
既然存在依賴關係，那是不是可以通過算法進行自動構建依賴關係呢？
設計#
根據產品站的實際場景，我們發現，調用下游接口若干個，且請求接口存在不同的請求協議與不同的中間件。
更重要的是，接口存在著依賴關係，我們梳理接口調用發現，接口依賴正好是有向依賴圖的結構，那麼我們就可以進行遍歷依賴關係進行編排並發分組。
這樣就解決了依賴的問題，我們可以依次並行執行每個並發組的任務，這樣就可以得到所有接口或依賴的結果。
那麼獲取到結果之後，怎麼進行業務邏輯的編排，怎麼隔離下游接口，其實原理很簡單，既然任務可以進行分層，那麼我們業務調用、業務編排、防腐蝕層也可以進行分層設計。
- Transfer 層的作用是業務邏輯層，用來進行業務編排，將 BO 數據提供給客戶端使用；
- Task 任務層是並發執行的核心設計層，在這裡通過並發分組的每個子 Task 在這裡進行編排後執行調用，用來進行超時控制、耗時統計等操作；
- Infrastructure 層作為防腐層設計，用來隔離下游接口的調用，這樣的設計提高了接口的穩定性；
寫在最後#
好了，上文就是給大家講解的自動構建並發調用圖的業務框架，也就是 Phoenix 框架。
Phoenix，最初在周志明老師的網站 "鳳凰架構" 提及，一方面是對周老師的架構設計理解與 Java 相關知識學習的致敬，另一方面，Phoenix 不死鳥，軟件的生命周期也是如此，隨著業務的快速發展誕生，並隨著業務的收縮而凋亡，生生不息。
最後，我會以系列的方式進行講解這個框架遇到的問題以及解決思路，感謝大家的閱讀，如果感興趣的話推薦大家關注公眾號，讓我們一起變得更強～