一、起因：野蠻生長

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

弊端一：自我繁衍

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

弊端二：管控壁壘

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

弊端三：斷崖效應

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

弊端四：資源浪費

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

弊端五：難以考核

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

二、如何破解？

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

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

三、 統一開發框架的優勢

1. 避免重複性技術研究——節約人力成本

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

2. 標準化技術規範——提升產品專案質量

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

3. 進行技術沉澱——提升公司整體技術能力，避免陷入一個人的能力決定一個專案

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

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

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

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

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

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

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

1. 基於 Spring Cloud 技術棧

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

2. 部分 SpringCloud 構件的增強

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

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

3. 新基礎元件產品的研發

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

下圖為分散式任務排程框架原理。執行器在啟動時將任務介面註冊到分散式資料中心，編排中心從分散式資料中心獲取執行器資訊進行編排，然後把編排資訊儲存到資料儲存中，排程中心從資料儲存中獲取資訊對執行器進行遠端排程。

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

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

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

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

3. 新元件、新產品的研發。前一章節提到的 API 閘道器、分散式任務排程框架、服務註冊中心 Plus 等。都是統一開發框架（平臺）團隊的工作範圍。

七、過猶不及

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