不寫代碼搞定微服務(wù)架構(gòu)改造,我信了你的邪(微服務(wù) 低代碼)
近幾年,微服務(wù)大行其道,甚至正成為IT軟件架構(gòu)的標(biāo)配,但微服務(wù)的改造和落地依然困難重重,令無數(shù)中小型軟件公司和傳統(tǒng)企業(yè)陷入掙扎。11月17日,飛算全自動軟件工程平臺正式發(fā)布。這次發(fā)布的“自動化開發(fā)”平臺是對標(biāo)傳統(tǒng)開發(fā)工具(如Eclipse、IntelliJ IDEA)的新一代全自動開發(fā)平臺,業(yè)務(wù)人員只要基于項目需求繪制系統(tǒng)流程圖,平臺就可以自動生成經(jīng)過實踐驗證的的微服務(wù)打包文件,可直接部署到服務(wù)器上,大大降低了微服務(wù)部署運維的門檻,并節(jié)省了大量時間和人力投入。InfoQ記者提前專訪了飛算云智總裁陳定瑋,深入了解該平臺的技術(shù)細節(jié)、誕生的故事以及其對于微服務(wù)、軟件工程成本的思考。
自2014年Martin Fowler與James Lewis共同提出微服務(wù)的概念以來,它就吸引了大批工程師和企業(yè)的關(guān)注,可以說是當(dāng)前軟件開發(fā)領(lǐng)域最火的技術(shù)熱點之一。
在今年年初的一項云計算應(yīng)用調(diào)研中,O'Reilly 調(diào)查了 1283 家公司,有 52%的公司表示他們正在使用微服務(wù)進行軟件開發(fā),其中超過 28%使用微服務(wù)超過3年,超過 55%使用微服務(wù)的時間為1-3年。O'Reilly 還指出,企業(yè)對微服務(wù)的興趣可能達到或接近頂峰。
相比傳統(tǒng)“大而全”的單體架構(gòu),微服務(wù)架構(gòu)在故障隔離、整體可用性、架構(gòu)持續(xù)演進難度、可重用性、可擴展性和交付速度等方面有突出的優(yōu)勢。
傳統(tǒng)行業(yè)的系統(tǒng)架構(gòu)大多是單體架構(gòu),隨著業(yè)務(wù)規(guī)模不斷擴大、代碼量的膨脹和團隊成員增多,傳統(tǒng)單體式架構(gòu)的弊端會逐漸凸顯:代碼沖突加劇、模塊耦合嚴(yán)重,一次上線涉及人員太多代碼質(zhì)量無法保證、協(xié)作效率低下,每次開發(fā)測試花費時間過長、動不動幾周甚至幾個月……對于這些企業(yè)來說,微服務(wù)架構(gòu)已經(jīng)成為剛需,但真正要進行改造和部署時又往往無從下手。
微服務(wù)部署分幾步?
有些人可能認(rèn)為選好框架、把系統(tǒng)內(nèi)部接口調(diào)用換成RPC或者Rest調(diào)用,就算完成微服務(wù)改造了,其實這只是微服務(wù)的冰山一角。
微服務(wù)改造的第一步是對業(yè)務(wù)進行拆分。服務(wù)拆分是否合理直接關(guān)系到微服務(wù)架構(gòu)的復(fù)雜性、穩(wěn)定性以及可擴展性,也是目前業(yè)內(nèi)關(guān)于微服務(wù)議論最多、吵架最多的問題。不過當(dāng)前業(yè)內(nèi)也并沒有統(tǒng)一的做法或規(guī)范,各家基本是根據(jù)架構(gòu)師經(jīng)驗、業(yè)務(wù)形態(tài)和用戶規(guī)模等因素綜合考慮拆分粒度。
服務(wù)拆分之后需要做微服務(wù)的分層:梳理和抽取核心應(yīng)用、公共應(yīng)用,作為獨立的服務(wù)下沉到核心和公共能力層,形成穩(wěn)定的服務(wù)中心,使前端應(yīng)用能更快速地響應(yīng)多變的市場需求。
微服務(wù)的關(guān)鍵,除了跟服務(wù)設(shè)計本身相關(guān)的業(yè)務(wù)拆分和分層,還涉及微服務(wù)底層基礎(chǔ)系統(tǒng)的構(gòu)建工作。系統(tǒng)需要提供一套基礎(chǔ)的架構(gòu),使得微服務(wù)可以獨立的部署、運行、升級,同時讓所有服務(wù)在功能上表現(xiàn)為一個統(tǒng)一的整體。這些系統(tǒng)性功能也需要有一系列服務(wù)來提供,它們可以視作微服務(wù)系統(tǒng)的“底座”。
一個完整的微服務(wù)系統(tǒng)底座最少要包含以下功能:日志和審計、監(jiān)控和告警、消息總線、注冊發(fā)現(xiàn)、負(fù)載均衡、部署和升級、事件調(diào)度、資源管理。另外還有一些非必須的底座功能:認(rèn)證和鑒權(quán)、統(tǒng)一服務(wù)構(gòu)建和打包、統(tǒng)一服務(wù)測試、微服務(wù)CI/CD流水線、服務(wù)依賴關(guān)系管理、統(tǒng)一問題跟蹤調(diào)試框架、灰度發(fā)布、藍綠部署等。
這個微服務(wù)底座必不可少,但實現(xiàn)起來工作量巨大。雖然業(yè)內(nèi)已有不少可用于微服務(wù)架構(gòu)落地的開源框架,但也并非拿來即用,而是有一定技術(shù)門檻,需要開發(fā)團隊有足夠的技術(shù)積累和實踐經(jīng)驗,否則可能需要走很多彎路。以Java領(lǐng)域的微服務(wù)架構(gòu)落地開源框架SpringCloud為例,光是組件就有數(shù)十個,并非所有開發(fā)人員都能很容易地全盤掌握這些組件的原理和使用。
此外,微服務(wù)架構(gòu)本身也存在一些弊端。服務(wù)拆分之后,雖然單個服務(wù)代碼量變小了,更易于修改和維護,但服務(wù)的個數(shù)變多了,系統(tǒng)總體代碼量可能并不會減少,甚至更為復(fù)雜,對運維挑戰(zhàn)很大。如果需要采用微服務(wù)架構(gòu)的項目不止一個,而是幾十個,難道所有項目都要讓團隊從頭寫一遍代碼?經(jīng)過實際業(yè)務(wù)驗證的微服務(wù)組件能不能復(fù)用到其他項目上?如何保障所有服務(wù)的代碼規(guī)范和質(zhì)量?
上述這些,都是2016年底擺在陳定瑋團隊面前的問題。彼時的陳定瑋正陷于150人研發(fā)團隊的管理工作和永遠也做不完的CodeReview中難以脫身。微服務(wù)的興起是機會也是挑戰(zhàn),他開始思考一個問題:能不能用不需要寫代碼的方式來實現(xiàn)微服務(wù)架構(gòu)的開發(fā),進一步緩解研發(fā)項目管理的壓力?
飛算全自動軟件工程平臺的初心:“干掉自己”
在陳定瑋看來,軟件工程行業(yè)雖然發(fā)展欣欣向榮,但實際上仍過度依賴“人工”,這也導(dǎo)致行業(yè)內(nèi)普遍存在四大痛點:
- 項目成本高:人力成本高、溝通成本高、運維成本高、軟硬件投入成本高;
- 開發(fā)周期長:開發(fā)者需要根據(jù)業(yè)務(wù)發(fā)展規(guī)模預(yù)期,配置相應(yīng)的架構(gòu),不同架構(gòu)的復(fù)雜度和開發(fā)工作量完全不可類比;
- 代碼質(zhì)量低:雖然業(yè)內(nèi)有不少編碼規(guī)范,但真正能遵守的仍是少數(shù),而微服務(wù)架構(gòu)下每個服務(wù)由不同開發(fā)人員開發(fā),代碼可讀性、可維護性、重復(fù)度及可測試性都難以保證;
- 團隊管理難:人才招聘難(符合要求的工程師難招,或者太貴)、人才管理難(大型軟件開發(fā)公司或者國企、大型單位的IT部門人員過多)、技術(shù)資產(chǎn)保全難(員工離職后代碼維護難)、技術(shù)依賴強(技術(shù)選型難、技術(shù)綁架多、技術(shù)趟坑多、技術(shù)沉淀難)。
2016年,陳定瑋團隊從傳統(tǒng)領(lǐng)域轉(zhuǎn)型到互聯(lián)網(wǎng),研發(fā)團隊從四五十人一下暴增到了150人,所有管理問題接踵而來。2016年底,“不堪重負(fù)”的陳定瑋開始反思軟件工程體系管理的問題,并嘗試制定解決方案。他希望將軟件行業(yè)傳統(tǒng)的“人工治理”的作業(yè)方式變成“法治”,告別代碼,用標(biāo)準(zhǔn)化的流程操作和拖拉拽的方式實現(xiàn)開發(fā)。
對于軟件開發(fā)人員來說,這是一個最終可能會“干掉自己”的項目,因此在一開始就引來了技術(shù)團隊的不理解與抵觸。最開始的時候,陳定瑋只能單打獨斗,同時不斷給開發(fā)人員做思想工作。他希望工程師們可以從反復(fù)寫代碼、改代碼的困境中解放出來,擺脫低創(chuàng)新、純執(zhí)行、重復(fù)性極高的代碼編寫工作,去思考、突破更高層次的技術(shù)問題。
雖然經(jīng)歷了無數(shù)質(zhì)疑、不理解、爭吵,但在董事長“沒有預(yù)算限制”的信任與支持之下,陳定瑋還是咬牙扛了過來。平臺最主要的核心技術(shù)是用可視化的流程引擎代替代碼來描述整個業(yè)務(wù)邏輯實現(xiàn),運行時解析流程圖執(zhí)行,其中最大的難點就在于如何將流程圖編譯成微服務(wù)。陳定瑋自己做技術(shù)調(diào)研和優(yōu)化調(diào)整,攻克了這個技術(shù)難關(guān)。在魔鬼般的工作強度下,總算做出了一些可以“看見”的成果使人信服,雖然付出的代價是在項目初期長達一年的時間里完全沒有“生活”可言。
當(dāng)項目進入到第二個里程碑、平臺初具雛形,加入這一項目的開發(fā)人員已經(jīng)從3個人變成了8個人,說多不多,但都是精兵強將。
這個時候的平臺其實還存在不少問題,在陳定瑋看來,“沒有經(jīng)過實際生產(chǎn)環(huán)境實踐驗證的微服務(wù)架構(gòu)都是耍流氓”,為了保障實際上線的效果和可用性,他開始“強迫”自己的團隊在實際項目中使用這個平臺。每來一個項目,就單獨剝離一個團隊使用這個平臺做開發(fā),第二個團隊用傳統(tǒng)的開發(fā)模式去交付,兩個團隊的工作同步進行。后者產(chǎn)出的App先交付給客戶,服務(wù)升級時再將用平臺開發(fā)出來的版本替換掉原來的版本。就這樣通過一個個實際項目將平臺錘煉得越來越好,下一步再給到不懂代碼的業(yè)務(wù)人員試用,并改進界面功能和用戶體驗。
歷經(jīng)四年時間,飛算全自動軟件工程平臺總算順利上線,這個最初看上去遙不可及的想法終于變成一個可以在生產(chǎn)環(huán)境大規(guī)模使用的產(chǎn)品。
在陳定瑋團隊中,大部分項目都已經(jīng)改用這個平臺來開發(fā),為陳定瑋有效緩解了項目和團隊管理的壓力。在公司科技項目數(shù)量越接越多、規(guī)模越接越大的情況下,公司技術(shù)團隊卻由2016年的150人,減少到了50人左右。陳定瑋預(yù)計,“到今年年底的時候,公司技術(shù)團隊二三十人就夠了?!?/p>
PK傳統(tǒng)開發(fā)工具:效率提升數(shù)十倍
飛算全自動軟件工程平臺涵蓋“項目管理”、“自動化開發(fā)”、“自動化測試”、“質(zhì)量管理”和“自動化運維”等五大核心板塊,可以通過平臺管理從需求、研發(fā)、測試、部署、上線到運維的整個軟件生命周期。借助該平臺,從項目經(jīng)理到產(chǎn)品經(jīng)理、部分架構(gòu)師可以直接完成項目的計劃和設(shè)計,不需要對研發(fā)工程師做任務(wù)分解和溝通;只要明確項目需求并設(shè)計好架構(gòu),就可以通過繪制流程圖實現(xiàn)全自動開發(fā);自帶服務(wù)注冊中心、分布式鏈路追蹤、服務(wù)發(fā)現(xiàn)、服務(wù)治理等能力。
飛算全自動軟件工程平臺解決軟件工程從項目啟動到運維的151個問題
目前飛算全自動軟件工程平臺已經(jīng)上線阿里云并對外提供SaaS服務(wù)?!白詣踊_發(fā)”板塊率先發(fā)布,“自動化測試”和“自動化運維”板塊的開發(fā)進度也已經(jīng)完成50%,會在不久的將來上線。
據(jù)陳定瑋介紹,這次發(fā)布的“自動化開發(fā)”板塊對標(biāo)傳統(tǒng)開發(fā)工具(如Eclipse、IntelliJ IDEA),創(chuàng)新點在于用流程圖取代了傳統(tǒng)的代碼編寫,用戶可以可視化地設(shè)計業(yè)務(wù),只專注于業(yè)務(wù)邏輯,對使用者的專業(yè)領(lǐng)域、技術(shù)能力基本沒有限制。
該平臺提供了一系列標(biāo)準(zhǔn)化組件(包括基礎(chǔ)組件、SQL組件、工具組件等)、行業(yè)組件、安全模塊等,這些組件和模塊的開發(fā)代碼只有在經(jīng)過內(nèi)置的代碼質(zhì)量平臺審核通過后才能上線,可以有效規(guī)避傳統(tǒng)編碼方式難以保證代碼質(zhì)量的問題。
自動化開發(fā)平臺界面演示
此外,平臺自動提供內(nèi)建的微服務(wù)能力,基于用戶繪制的流程圖,平臺就能自動生成經(jīng)過實踐驗證的微服務(wù)架構(gòu),用戶下載項目部署包 執(zhí)行服務(wù)包,放到服務(wù)端部署即可。用戶不需要深入研究微服務(wù)框架,也不會陷入各類問題難以定位和解決的窘境。平臺采用經(jīng)過團隊實際項目歷練和驗證的微服務(wù)最佳實踐,在高并發(fā)、大業(yè)務(wù)量場景下的穩(wěn)定性會優(yōu)于用戶自己使用的微服務(wù)框架。陳定瑋指出,“雖然沒辦法跟阿里那么大的業(yè)務(wù)體量相比,但是足以支撐大部分中大型電商的業(yè)務(wù)體量?!?/p>
內(nèi)建微服務(wù)能力也是飛算全自動軟件工程平臺與目前市面上已有的無代碼、低代碼開發(fā)平臺最大的區(qū)別。陳定瑋表示,飛算全自動軟件工程平臺目前在市面上還沒有完全對等的競爭產(chǎn)品,市面上已有的產(chǎn)品均更偏向前端開發(fā),而飛算全自動軟件工程平臺屬于后端微服務(wù)開發(fā)。
表1:傳統(tǒng)開發(fā)產(chǎn)品 VS 飛算全自動軟件工程平臺
為了讓大家能更直觀地了解使用飛算全自動軟件工程平臺開發(fā)的效率與效能,在本周的發(fā)布會上專門設(shè)置了一個非常有趣的PK環(huán)節(jié):基于同一份項目需求,開發(fā)人員手動編寫代碼和業(yè)務(wù)人員使用平臺開發(fā)來比拼看誰開發(fā)的更快。
對于這樣一個并不復(fù)雜的項目需求,一個業(yè)務(wù)人員使用飛算全自動軟件開發(fā)平臺開發(fā)只需要20分鐘就能搞定,而開發(fā)人員用傳統(tǒng)編碼方式開發(fā)需要1-2天時間才能完成,開發(fā)效率提升數(shù)十倍。如果是更復(fù)雜的項目,開發(fā)效率的提升會更加明顯。
未來微服務(wù)開發(fā)的變與不變
微服務(wù)雖好,卻并非銀彈。隨著云原生技術(shù)的推廣和大量微服務(wù)案例的落地,社區(qū)關(guān)于微服務(wù)模式質(zhì)疑的聲音越來越多。陳定瑋也注意到了這一現(xiàn)象,他表示,如果是企業(yè)內(nèi)部使用的簡單系統(tǒng),可能確實不需要用到微服務(wù),但對于有高并發(fā)、高可用、快速開發(fā)要求的場景,微服務(wù)依然是當(dāng)前最好的解決方案,暫時沒有第二種選擇。當(dāng)前很多有數(shù)字化轉(zhuǎn)型需求的傳統(tǒng)企業(yè),都希望能吸引大量C端客戶到自己的平臺上,將公域流量轉(zhuǎn)為私域流量,如果沒有微服務(wù)體系的支撐就很難做到。
飛算全自動軟件工程平臺主要的目標(biāo)用戶群體也是這些真正有痛點的中小型軟件公司和傳統(tǒng)企業(yè),這些公司通常有微服務(wù)改造的剛需,但受制于團隊和技術(shù)能力無法實現(xiàn)。飛算全自動軟件工程平臺就是要幫助這些真正對微服務(wù)有需求卻不知道怎么玩轉(zhuǎn)的企業(yè)或團隊,低成本快速上手。對于領(lǐng)域和行業(yè),平臺并沒有任何限制。陳定瑋強調(diào),“只要是Java能做的,我們的平臺都可以做。除了驅(qū)動、游戲、操作系統(tǒng),基本上目前的應(yīng)用系統(tǒng)都可以通過我們的平臺來實現(xiàn)?!?/p>
技術(shù)層面,飛算全自動軟件工程平臺接下來主要有兩項改進計劃:一是支持標(biāo)準(zhǔn)的前端頁面模板或者完全自定義頁面、通過拖拽的方式實現(xiàn)前端頁面開發(fā),二是完成“自動化測試”和“自動化運維”板塊的開發(fā)。
市場層面,陳定瑋也提出了自己的愿景:三年內(nèi)幫助10000家企業(yè)。在平臺正式上線之前,已經(jīng)有十幾家公司在試用并基于平臺構(gòu)建項目。他還有一個更大的目標(biāo),就是要通過知識經(jīng)驗管理的貢獻,徹底改變軟件工程行業(yè)現(xiàn)有的作業(yè)方式,實現(xiàn)軟件工程的全流程自動化。
至于目標(biāo)能否實現(xiàn),就要接受市場的考驗了。陳定瑋表示,從傳統(tǒng)的編寫代碼做開發(fā),到設(shè)計流程圖做開發(fā),對開發(fā)方式是一次很大的變革,原來用傳統(tǒng)開發(fā)方法做過的東西需要全部推倒重來,這是平臺推廣的一個難點。如何讓企業(yè)和開發(fā)團隊接受新方式、掌握流程圖設(shè)計,更重前期培訓(xùn),接下來飛算全自動軟件工程平臺研發(fā)團隊會專門組建一支培訓(xùn)團隊,輔導(dǎo)用戶更快上手使用。
陳定瑋也提到,飛算全自動軟件工程平臺主要是幫助大家提高開發(fā)和維護效率、降低技術(shù)門檻,但是坦率講,它并不能包辦一切,無法幫助大家完成設(shè)計方面的工作,比如微服務(wù)拆分、數(shù)據(jù)庫表設(shè)計等工作,但會提供培訓(xùn)和專業(yè)開發(fā)人員來協(xié)助用戶做好這些工作。這其實已經(jīng)屬于互聯(lián)網(wǎng)軟件體系設(shè)計思路分享的范疇,也是需要教育的。玩轉(zhuǎn)互聯(lián)網(wǎng)軟件體系的方法與傳統(tǒng)軟件的設(shè)計思維方式并不相同,陳定瑋希望傳達這樣一個理念,也會將這一工作作為未來的重點之一。
延伸閱讀:
關(guān)注我并轉(zhuǎn)發(fā)此篇文章,私信我“領(lǐng)取資料”,即可免費獲得InfoQ價值4999元迷你書,點擊文末「了解更多」,即可移步InfoQ官網(wǎng),獲取最新資訊~