卓晖冠科說公司需要建立統一軟件開發框架的(de)理(lǐ)由
一、起因：野蠻生長(cháng)
近十年，中國互聯網發展的(de)速度越來(lái)越快(kuài)，互聯網科技颠覆了(le)越來(lái)越多(duō)的(de)傳統行業，我們的(de)衣食住行随著(zhe)互聯網科技的(de)進步，發生了(le)翻天覆地的(de)變化(huà)。在這(zhè)個(gè)大(dà)潮中，越來(lái)越多(duō)新興的(de)公司如雨(yǔ)後春筍般的(de)冒了(le)出來(lái)，他(tā)們的(de)業務增長(cháng)非常快(kuài)，公司規模也(yě)越來(lái)越大(dà)。這(zhè)得(de)益于中國經濟的(de)高(gāo)速增長(cháng)和(hé)互聯網的(de)快(kuài)速發展。
弊端一：自我繁衍
在公司快(kuài)速的(de)發展過程中，往往會出現這(zhè)樣一個(gè)鏈條。新增一塊業務 —> 招聘一位高(gāo)級技術人(rén)員(yuán) —> 圍繞這(zhè)位同事組建一隻技術團隊 —> 該業務基本由這(zhè)隻團隊負責。然後就形成了(le)一個(gè)閉環。當需要跟其他(tā)業務進行交互時(shí)，經常是技術負責人(rén)之間自行決定。（我曾經經曆過一個(gè)項目，同樣一個(gè)業務接口，同時(shí)提供 RPC，HTTP，MQ 等多(duō)種方式，爲了(le)給不同的(de)項目提供基礎服務）。
弊端二：管控壁壘
随著(zhe)業務規模的(de)快(kuài)速發展，這(zhè)個(gè)團隊很快(kuài)的(de)形成了(le)一個(gè)部門，團隊決策者通(tōng)常會從自身利益考量，希望盡量減少對(duì)外部門的(de)依賴，無論是技術選型，規範建立，組件選取，運行環境都能夠自行掌控。（在這(zhè)裏講一個(gè)笑(xiào)話(huà)，在一家公司怎麽成爲中層領導呢(ne)？很簡單，招聘足夠多(duō)的(de)下(xià)屬就可(kě)以了(le)）。
弊端三：斷崖效應
當這(zhè)樣的(de)技術氛圍一旦形成，單個(gè)員(yuán)工對(duì)單個(gè)項目的(de)影(yǐng)響就會變的(de)非常巨大(dà)。一個(gè)産品經常會因爲一兩個(gè)核心員(yuán)工的(de)離職難以爲繼，最後不得(de)不重新開發新的(de)産品。
弊端四：資源浪費
當每個(gè)團隊都在試圖構建自己完整的(de)研發流程時(shí)。中間的(de)技術研究，産品研發，運維管理(lǐ)就會出現非常多(duō)的(de)資源浪費。
弊端五：難以考核
怎麽衡量一個(gè)川菜廚師和(hé)一個(gè)魯菜廚師誰更優秀？當每個(gè)團隊都采用(yòng)不同技術棧，不同的(de)技術組件，不同的(de)維護方式和(hé)規範時(shí)。已經無法從産出效率來(lái)判斷一個(gè)團隊的(de)績效。KPI 指标也(yě)就非常難以設立。
二、如何破解？
在公司發展初期，爲了(le)快(kuài)速的(de)進行業務拓展，大(dà)都不考慮成本投入，運營維護以及技術沉澱等問題。所有的(de)指标導向都是業務的(de)快(kuài)速發展，盡可(kě)能的(de)搶占市場(chǎng)份額，獲取足夠多(duō)的(de)用(yòng)戶數量。
在公司發展到一定階段後，市場(chǎng)逐漸趨于穩定，先期快(kuài)速擴展的(de)各種問題會逐步暴露出來(lái)。從技術層面來(lái)講，如果可(kě)以形成公司級别的(de)統一開發框架，會在實際的(de)生産過程中帶來(lái)非常大(dà)的(de)收益。
三、統一開發框架的(de)優勢
3.1 避免重複性技術研究——節約人(rén)力成本
讓項目組把精力更多(duō)的(de)投入到業務中。相信這(zhè)是大(dà)多(duō)數技術公司的(de)共識，如果讓項目組把精力投入在業務中？就需要在項目組之下(xià)構建一個(gè)基礎的(de)開發架構平台，把技術的(de)共性問題提煉出來(lái)，交給這(zhè)樣一個(gè)團隊負責處理(lǐ)。避免每個(gè)項目都獨自去解決遇到的(de)各種各樣的(de)技術難題，有效的(de)把精力釋放出來(lái)。
3.2 标準化(huà)技術規範——提升産品項目質量
要千人(rén)一面，而不要千人(rén)千面。采用(yòng)統一的(de)開發框架（平台）後，在技術棧，技術組件，技術實現方案，甚至在代碼規範上就能形成标準化(huà)的(de)技術輸出模式，标準化(huà)帶來(lái)的(de)最大(dà)效果不僅僅開發效率的(de)快(kuài)速提升，還(hái)有産品質量的(de)大(dà)幅提升，這(zhè)是顯而易見的(de)。
3.3 進行技術沉澱——提升公司整體技術能力，避免陷入一個(gè)人(rén)的(de)能力決定一個(gè)項目
技術的(de)進步來(lái)源于不斷的(de)技術積累和(hé)沉澱。每個(gè)工程師都是站在别人(rén)肩膀上完成工作的(de)。以項目爲導向的(de)技術團隊，一般都會以實現業務需求爲最重要的(de)目标，技術隻不過是完成業務的(de)一種工具而已。基于此，業務開發團隊就不可(kě)能把技術積累作爲一項重要的(de)工作。當一位核心員(yuán)工構建了(le)一些基礎的(de)平台工具後，往往随著(zhe)他(tā)的(de)離開把之前的(de)技術積累全部丢棄掉，而更嚴重的(de)情況會導緻整個(gè)項目的(de)持續運行都成了(le)問題。
當存在公司級别的(de)統一開發框架（平台），項目團隊基于該平台進行自身項目的(de)研發，不再需要關注于底層技術實現，隻需要關注業務即可(kě)。當存在核心同事離職時(shí)，平台的(de)研發同事可(kě)以對(duì)新進入項目的(de)同事進行相關培訓，不會導緻青黃(huáng)不接的(de)事情發生。而且，專注于平台的(de)同事爲了(le)更好的(de)滿足項目組的(de)技術需求，對(duì)平台進行不斷的(de)改進，從而達到技術積累和(hé)沉澱的(de)目标。
3.4 可(kě)衡量的(de)研發投入——對(duì)研發團隊的(de)有效管理(lǐ)和(hé)考核
當基于同一開發框架（平台）的(de)标準化(huà)技術規範建立起來(lái)後，對(duì)業務功能的(de)代碼實現就可(kě)以進行相對(duì)有效的(de)評估和(hé)考量，可(kě)以避免因爲技術實現差異而出現的(de)種種問題。這(zhè)對(duì) KPI 的(de)制定和(hé)考核是一個(gè)巨大(dà)的(de)幫助。
四、統一開發框架（平台）的(de)定位和(hé)目标
統一開發框架（平台）定位于技術層面，其主要目的(de)是爲統一公司内相關産品研發和(hé)項目實施使用(yòng)的(de)技術架構和(hé)開發工具，有效提高(gāo)統一技術支持力度，形成持續的(de)技術積累手段，提升技術人(rén)員(yuán)的(de)利用(yòng)率并降低對(duì)人(rén)員(yuán)的(de)依賴性，最終提升軟件的(de)規模化(huà)、流水(shuǐ)線式的(de)生産能力。
五、統一開發框架（平台）的(de)建設思路
5.1 基于 Spring Cloud 技術棧
Spring Cloud 在 2017 年一躍成爲最流行的(de)微服務開發框架，不是采用(yòng)了(le) Spring Cloud 框架就實現了(le)微服務架構，具備了(le)微服務架構的(de)優勢。正确的(de)理(lǐ)解是使用(yòng) Spring Cloud 框架開發微服務架構的(de)系統，使系統具備微服務架構的(de)優勢。下(xià)圖爲選擇 Spring Cloud 作爲技術棧的(de)原因。
5.2 部分(fēn) SpringCloud 構件的(de)增強
Spring Cloud 提供的(de)基礎構建可(kě)能無法完全滿足業務需求，需要在部分(fēn)構件之上做(zuò)二次研發。比如我們在 Zuul 基礎之上研發的(de) API 網關、服務注冊發現中心 EurekaPlus 等。
下(xià)圖爲服務注冊發現中心 EurekaPlus 的(de)截圖，可(kě)以手動控制服務注冊中心的(de)節點狀态，從而支持藍綠(lǜ)部署。
5.3 新基礎組件産品的(de)研發
除了(le) Spring Cloud 的(de)基礎構件外，我們往往需要開發新的(de)基礎組件産品來(lái)滿足項目組的(de)需求。特别是當前微服務架構大(dà)行其道，常常需要基于微服務架構的(de)設計思想來(lái)開發新的(de)組件産品，比如我們開發的(de)分(fēn)布式任務調度框架。采用(yòng)自動抓取，在線編排的(de)模式，完全契合于 Spring Cloud 技術棧。
下(xià)圖爲分(fēn)布式任務調度框架原理(lǐ)。執行器在啓動時(shí)将任務接口注冊到分(fēn)布式數據中心，編排中心從分(fēn)布式數據中心獲取執行器信息進行編排，然後把編排信息保存到數據存儲中，調度中心從數據存儲中獲取信息對(duì)執行器進行遠(yuǎn)程調度。
六、統一開發框架（平台）團隊的(de)運作方式
如何在公司推進統一開發框架（平台）的(de)建設，并不是一件簡單的(de)事情。以我個(gè)人(rén)的(de)經驗，從分(fēn)工和(hé)運作方式上來(lái)講，我主要著(zhe)重把統一開發框架（平台）的(de)工作分(fēn)成三個(gè)部分(fēn)。
開發示例、技術支持和(hé)技術規範。編寫完整的(de)開發示例，對(duì)很多(duō)新接觸統一開發框架的(de)同事來(lái)說，有一份完成業務開發是非常重要，不僅僅可(kě)以指導你如何進行業務代碼的(de)編寫，同時(shí)還(hái)能夠指導你如何編寫出正确、高(gāo)效的(de)代碼。還(hái)需要對(duì)很多(duō)同事進行技術培訓與技術支持支持，都是統一開發框架（平台）團隊應該完成的(de)工作。
服務運維。統一開發框架（平台）提供了(le)很多(duō)公司内部的(de)服務，比如服務注冊發現中心、配置中心、監控中心、鏈路中心、健康監測中心等。這(zhè)些都需要統一開發框架（平台）團隊進行運維。
新組件、新産品的(de)研發。前一章(zhāng)節提到的(de) API 網關、分(fēn)布式任務調度框架、服務注冊中心 Plus 等。都是統一開發框架（平台）團隊的(de)工作範圍。
七、過猶不及
雖然建設公司級的(de)統一開發框架（平台）會在實際的(de)生産過程中帶來(lái)非常大(dà)的(de)收益。但未必适用(yòng)于所有情況，考慮到某些項目産品的(de)特殊性，并不能一概而論。