前言

小米商城產品站之前由於歷史原因，存在着諸多問題與不便，隨着技術的快速變革，技術部中台化的建設，越來越不適用於現在快速迭代的業務需求，接下來我將以技術的視角講解我們遇到的痛點，以及解決這些痛點的思路，也就是 Phoenix 框架誕生的故事。

為啥要進行設計一個框架，其實是業務發展導向的結果，若是我們不進行設計，那麼我們會遇到如下一些問題：

• 在新的產品需求規劃下，無法承接大型項目，只能進行小修小改；
• 小米網產品站最初，每個端一套代碼邏輯，風格各異；
• 歷史沉澱，一個接口函數 2000 多行，熟悉代碼邏輯的成本越來越大；
• 隔離性差，服務可用性嚴重依賴下游，下游一個接口的抖動都會給我們接口帶來恐慌；
• 技術上整體中台化建設，隨着調用接口越來越多，接口越來越慢；
• 代碼沒有解耦，特別對新同事而言，新項目上線風險高；
• 缺少 Go 基礎組件的維護，無法對下游接口實時監控；

思考

我們從技術上計劃進行重構，那麼我們如何將現有的調度邏輯抽象出一套兼顧穩定性、便捷開發、可維護性且可監控的框架模型是我們首先帶來的問題。

我去調研了開源的一些併發框架，發現傳統的併發調度模型基本上都有依賴關係、超時控制、線程池分配調度、熔斷限流、接口監控等功能。

為啥我們沒有直接使用開源併發框架進行開發呢？

我調研發現業界 LiteFlow 框架是最受歡迎與好評的框架，於是在 Github 上面去了解框架底層實現的細節，隨着深入閲讀源碼，發現這款框架設計的是真的很優秀，但是也過於龐大、複雜，特別是 EL 規則的寫法，相對來説還是有一定的上手成本。

那麼我就在思考，我作為業務開發人員的話，我不想關心這麼複雜的依賴關係，只需要關心自己產品站業務調用到的中台的接口及其依賴接口即可。特別是大型接口捆綁了幾十個下游接口的邏輯，要是理解每個接口的設計細節更是不太可能的，要是依賴關係特別複雜，那麼 EL 規則會寫的非常複雜且維護成本極高。

那麼該如何設計一款輕量、快速、高效、從根本上解決開發人員手動維護依賴關係的併發框架呢？

既然存在依賴關係，那是不是可以通過算法進行自動構建依賴關係呢？

設計

根據產品站的實際場景，我們發現，調用下游接口若干個，且請求接口存在不同的請求協議與不同的中間件。

更重要的是，接口存在着依賴關係，我們梳理接口調用發現，接口依賴正好是有向依賴圖的結構，
那麼我們就可以進行遍歷依賴關係進行編排併發分組。

這樣就解決了依賴的問題，我們可以依次並行執行每個併發組的任務，這樣就可以得到所有接口或依賴的結果。

那麼獲取到結果之後，怎麼進行業務邏輯的編排，怎麼隔離下游接口，其實原理很簡單，既然任務可以進行分層，那麼我們業務調用、業務編排、防腐蝕層也可以進行分層設計。

• Transfer 層的作用是業務邏輯層，用來進行業務編排，將 BO 數據提供給客户端使用；
• Task 任務層是併發執行的核心設計層，在這裏通過併發分組的每個子 Task 在這裏進行編排後執行調用，用來進行超時控制、耗時統計等操作；
• Infrastructure 層作為防腐層設計，用來隔離下游接口的調用，這樣的設計提高了接口的穩定性；

寫在最後

好了，上文就是給大家講解的自動構建併發調用圖的業務框架，也就是 Phoenix Framework。

Phoenix，最初在周志明老師的網站"鳳凰架構"提及，一方面是對周老師的架構設計理解與 Java 相關知識學習的致敬，另一方面，Phoenix 不死鳥，軟件的生命週期也是如此，隨着業務的快速發展誕生、並隨着業務的的收縮而凋亡，生生不息。

最後，我會以系列的方式進行講解這個框架遇到的問題以及解決思路，感謝大家的閲讀，大家要是感興趣的話推薦大家關注，讓我們一起變得更強～

本文首發於：blog.debuginn.com 公眾號：Debug客棧