公司爲何須要創建一套統一的開發框架？

1、原由：野蠻生長

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

弊端一：自我繁衍

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

弊端二：管控壁壘

隨着業務規模的快速發展，這個團隊很快的造成了一個部門，團隊決策者一般會從自身利益考量，但願儘可能減小對外部門的依賴，不管是技術選型，規範創建，組件選取，運行環境都可以自行掌控。（在這裏講一個笑話，在一家公司怎麼成爲中層領導呢？很簡單，招聘足夠多的下屬就能夠了）。

弊端三：斷崖效應

當這樣的技術氛圍一旦造成，單個員工對單個項目的影響就會變的很是巨大。一個產品常常會由於一兩個核心員工的離職難覺得繼，最後不得不從新開發新的產品。

弊端四：資源浪費

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

弊端五：難以考覈

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

2、如何破解？

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

在公司發展到必定階段後，市場逐漸趨於穩定，先期快速擴展的各類問題會逐步暴露出來。從技術層面來說，若是能夠造成公司級別的統一開發框架，會在實際的生產過程當中帶來很是大的收益。

3、統一開發框架的優點

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

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

3.2 標準化技術規範——提高產品項目質量

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

3.3 進行技術沉澱——提高公司總體技術能力，避免陷入一我的的能力決定一個項目

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

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

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

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

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

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

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

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 技術棧。

下圖爲分佈式任務調度框架原理。執行器在啓動時將任務接口註冊到分佈式數據中心，編排中心從分佈式數據中心獲取執行器信息進行編排，而後把編排信息保存到數據存儲中，調度中心從數據存儲中獲取信息對執行器進行遠程調度。

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

如何在公司推動統一開發框架（平臺）的建設，並非一件簡單的事情。以我我的的經驗，從分工和運做方式上來說，我主要着重把統一開發框架（平臺）的工做分紅三個部分。

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

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

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

7、過猶不及

雖然建設公司級的統一開發框架（平臺）會在實際的生產過程當中帶來很是大的收益。但未必適用於全部狀況，考慮到某些項目產品的特殊性，並不能一律而論。

做者：梁鑫

來源：宜信技術學院