公司為什么需要建立一套統一的開發框架？

一、起因：野蠻生長

近十年，中國互聯網發展的速度越來越快，互聯網科技顛覆了越來越多的傳統行業，我們的衣食住行隨著互聯網科技的進步，發生了翻天覆地的變化。在這個大潮中，越來越多新興的公司如雨后春筍般的冒了出來，他們的業務增長非常快，公司規模也越來越大。這得益于中國經濟的高速增長和互聯網的快速發展。

弊端一：自我繁衍

在公司快速的發展過程中，往往會出現這樣一個鏈條。新增一塊業務 —> 招聘一位高級技術人員 —> 圍繞這位同事組建一只技術團隊 —> 該業務基本由這只團隊負責。然后就形成了一個閉環。當需要跟其他業務進行交互時，經常是技術負責人之間自行決定。（我曾經經歷過一個項目，同樣一個業務接口，同時提供 RPC，HTTP，MQ 等多種方式，為了給不同的項目提供基礎服務）。

弊端二：管控壁壘

隨著業務規模的快速發展，這個團隊很快的形成了一個部門，團隊決策者通常會從自身利益考量，希望盡量減少對外部門的依賴，無論是技術選型，規范建立，組件選取，運行環境都能夠自行掌控。（在這里講一個笑話，在一家公司怎么成為中層領導呢？很簡單，招聘足夠多的下屬就可以了）。

弊端三：斷崖效應

當這樣的技術氛圍一旦形成，單個員工對單個項目的影響就會變的非常巨大。一個產品經常會因為一兩個核心員工的離職難以為繼，最后不得不重新開發新的產品。

弊端四：資源浪費

當每個團隊都在試圖構建自己完整的研發流程時。中間的技術研究，產品研發，運維管理就會出現非常多的資源浪費。

弊端五：難以考核

怎么衡量一個川菜廚師和一個魯菜廚師誰更優秀？當每個團隊都采用不同技術棧，不同的技術組件，不同的維護方式和規范時。已經無法從產出效率來判斷一個團隊的績效。KPI 指標也就非常難以設立。

二、如何破解？

在公司發展初期，為了快速的進行業務拓展，大都不考慮成本投入，運營維護以及技術沉淀等問題。所有的指標導向都是業務的快速發展，盡可能的搶占市場份額，獲取足夠多的用戶數量。

在公司發展到一定階段后，市場逐漸趨于穩定，先期快速擴展的各種問題會逐步暴露出來。從技術層面來講，如果可以形成公司級別的統一開發框架，會在實際的生產過程中帶來非常大的收益。

三、統一開發框架的優勢

3.1 避免重復性技術研究——節約人力成本

讓項目組把精力更多的投入到業務中。相信這是大多數技術公司的共識，如果讓項目組把精力投入在業務中？就需要在項目組之下構建一個基礎的開發架構平臺，把技術的共性問題提煉出來，交給這樣一個團隊負責處理。避免每個項目都獨自去解決遇到的各種各樣的技術難題，有效的把精力釋放出來。

3.2 標準化技術規范——提升產品項目質量

要千人一面，而不要千人千面。采用統一的開發框架（平臺）后，在技術棧，技術組件，技術實現方案，甚至在代碼規范上就能形成標準化的技術輸出模式，標準化帶來的最大效果不僅僅開發效率的快速提升，還有產品質量的大幅提升，這是顯而易見的。

3.3 進行技術沉淀——提升公司整體技術能力，避免陷入一個人的能力決定一個項目

技術的進步來源于不斷的技術積累和沉淀。每個工程師都是站在別人肩膀上完成工作的。以項目為導向的技術團隊，一般都會以實現業務需求為最重要的目標，技術只不過是完成業務的一種工具而已。基于此，業務開發團隊就不可能把技術積累作為一項重要的工作。當一位核心員工構建了一些基礎的平臺工具后，往往隨著他的離開把之前的技術積累全部丟棄掉，而更嚴重的情況會導致整個項目的持續運行都成了問題。

當存在公司級別的統一開發框架（平臺），項目團隊基于該平臺進行自身項目的研發，不再需要關注于底層技術實現，只需要關注業務即可。當存在核心同事離職時，平臺的研發同事可以對新進入項目的同事進行相關培訓，不會導致青黃不接的事情發生。而且，專注于平臺的同事為了更好的滿足項目組的技術需求，對平臺進行不斷的改進，從而達到技術積累和沉淀的目標。

3.4 可衡量的研發投入——對研發團隊的有效管理和考核

當基于同一開發框架（平臺）的標準化技術規范建立起來后，對業務功能的代碼實現就可以進行相對有效的評估和考量，可以避免因為技術實現差異而出現的種種問題。這對 KPI 的制定和考核是一個巨大的幫助。

四、統一開發框架（平臺）的定位和目標

統一開發框架（平臺）定位于技術層面，其主要目的是為統一公司內相關產品研發和項目實施使用的技術架構和開發工具，有效提高統一技術支持力度，形成持續的技術積累手段，提升技術人員的利用率并降低對人員的依賴性，最終提升軟件的規模化、流水線式的生產能力。

五、統一開發框架（平臺）的建設思路

5.1 基于 Spring Cloud 技術棧

Spring Cloud 在 2017 年一躍成為最流行的微服務開發框架，不是采用了 Spring Cloud 框架就實現了微服務架構，具備了微服務架構的優勢。正確的理解是使用 Spring Cloud 框架開發微服務架構的系統，使系統具備微服務架構的優勢。下圖為選擇 Spring Cloud 作為技術棧的原因。

5.3 部分 SpringCloud 構件的增強

Spring Cloud 提供的基礎構建可能無法完全滿足業務需求，需要在部分構件之上做二次研發。比如我們在 Zuul 基礎之上研發的 API 網關、服務注冊發現中心 EurekaPlus 等。

下圖為服務注冊發現中心 EurekaPlus 的截圖，可以手動控制服務注冊中心的節點狀態，從而支持藍綠部署。

5.3 新基礎組件產品的研發

除了 Spring Cloud 的基礎構件外，我們往往需要開發新的基礎組件產品來滿足項目組的需求。特別是當前微服務架構大行其道，常常需要基于微服務架構的設計思想來開發新的組件產品，比如我們開發的分布式任務調度框架。采用自動抓取，在線編排的模式，完全契合于 Spring Cloud 技術棧。

下圖為分布式任務調度框架原理。執行器在啟動時將任務接口注冊到分布式數據中心，編排中心從分布式數據中心獲取執行器信息進行編排，然后把編排信息保存到數據存儲中，調度中心從數據存儲中獲取信息對執行器進行遠程調度。

六、統一開發框架（平臺）團隊的運作方式

如何在公司推進統一開發框架（平臺）的建設，并不是一件簡單的事情。以我個人的經驗，從分工和運作方式上來講，我主要著重把統一開發框架（平臺）的工作分成三個部分。

開發示例、技術支持和技術規范。編寫完整的開發示例，對很多新接觸統一開發框架的同事來說，有一份完成業務開發是非常重要，不僅僅可以指導你如何進行業務代碼的編寫，同時還能夠指導你如何編寫出正確、高效的代碼。還需要對很多同事進行技術培訓與技術支持支持，都是統一開發框架（平臺）團隊應該完成的工作。

服務運維。統一開發框架（平臺）提供了很多公司內部的服務，比如服務注冊發現中心、配置中心、監控中心、鏈路中心、健康監測中心等。這些都需要統一開發框架（平臺）團隊進行運維。

新組件、新產品的研發。前一章節提到的 API 網關、分布式任務調度框架、服務注冊中心 Plus 等。都是統一開發框架（平臺）團隊的工作范圍。

七、過猶不及

雖然建設公司級的統一開發框架（平臺）會在實際的生產過程中帶來非常大的收益。但未必適用于所有情況，考慮到某些項目產品的特殊性，并不能一概而論。

作者：梁鑫

來源：宜信技術學院