近幾年，微服務(wù)大行其道，甚至正成為IT軟件架構(gòu)的標(biāo)配，但微服務(wù)的改造和落地依然困難重重，令無(wú)數(shù)中小型軟件公司和傳統(tǒng)企業(yè)陷入掙扎。11月17日，飛算全自動(dòng)軟件工程平臺(tái)正式發(fā)布。這次發(fā)布的“自動(dòng)化開發(fā)”平臺(tái)是對(duì)標(biāo)傳統(tǒng)開發(fā)工具（如Eclipse、IntelliJ IDEA）的新一代全自動(dòng)開發(fā)平臺(tái)，業(yè)務(wù)人員只要基于項(xiàng)目需求繪制系統(tǒng)流程圖，平臺(tái)就可以自動(dòng)生成經(jīng)過實(shí)踐驗(yàn)證的的微服務(wù)打包文件，可直接部署到服務(wù)器上，大大降低了微服務(wù)部署運(yùn)維的門檻，并節(jié)省了大量時(shí)間和人力投入。InfoQ記者提前專訪了飛算云智總裁陳定瑋，深入了解該平臺(tái)的技術(shù)細(xì)節(jié)、誕生的故事以及其對(duì)于微服務(wù)、軟件工程成本的思考。

自2014年Martin Fowler與James Lewis共同提出微服務(wù)的概念以來(lái)，它就吸引了大批工程師和企業(yè)的關(guān)注，可以說(shuō)是當(dāng)前軟件開發(fā)領(lǐng)域最火的技術(shù)熱點(diǎn)之一。

在今年年初的一項(xiàng)云計(jì)算應(yīng)用調(diào)研中，O'Reilly 調(diào)查了 1283 家公司，有 52％的公司表示他們正在使用微服務(wù)進(jìn)行軟件開發(fā)，其中超過 28％使用微服務(wù)超過3年，超過 55％使用微服務(wù)的時(shí)間為1-3年。O'Reilly 還指出，企業(yè)對(duì)微服務(wù)的興趣可能達(dá)到或接近頂峰。

相比傳統(tǒng)“大而全”的單體架構(gòu)，微服務(wù)架構(gòu)在故障隔離、整體可用性、架構(gòu)持續(xù)演進(jìn)難度、可重用性、可擴(kuò)展性和交付速度等方面有突出的優(yōu)勢(shì)。

傳統(tǒng)行業(yè)的系統(tǒng)架構(gòu)大多是單體架構(gòu)，隨著業(yè)務(wù)規(guī)模不斷擴(kuò)大、代碼量的膨脹和團(tuán)隊(duì)成員增多，傳統(tǒng)單體式架構(gòu)的弊端會(huì)逐漸凸顯：代碼沖突加劇、模塊耦合嚴(yán)重，一次上線涉及人員太多代碼質(zhì)量無(wú)法保證、協(xié)作效率低下，每次開發(fā)測(cè)試花費(fèi)時(shí)間過長(zhǎng)、動(dòng)不動(dòng)幾周甚至幾個(gè)月……對(duì)于這些企業(yè)來(lái)說(shuō)，微服務(wù)架構(gòu)已經(jīng)成為剛需，但真正要進(jìn)行改造和部署時(shí)又往往無(wú)從下手。

微服務(wù)部署分幾步？

有些人可能認(rèn)為選好框架、把系統(tǒng)內(nèi)部接口調(diào)用換成RPC或者Rest調(diào)用，就算完成微服務(wù)改造了，其實(shí)這只是微服務(wù)的冰山一角。

微服務(wù)改造的第一步是對(duì)業(yè)務(wù)進(jìn)行拆分。服務(wù)拆分是否合理直接關(guān)系到微服務(wù)架構(gòu)的復(fù)雜性、穩(wěn)定性以及可擴(kuò)展性，也是目前業(yè)內(nèi)關(guān)于微服務(wù)議論最多、吵架最多的問題。不過當(dāng)前業(yè)內(nèi)也并沒有統(tǒng)一的做法或規(guī)范，各家基本是根據(jù)架構(gòu)師經(jīng)驗(yàn)、業(yè)務(wù)形態(tài)和用戶規(guī)模等因素綜合考慮拆分粒度。

服務(wù)拆分之后需要做微服務(wù)的分層：梳理和抽取核心應(yīng)用、公共應(yīng)用，作為獨(dú)立的服務(wù)下沉到核心和公共能力層，形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速地響應(yīng)多變的市場(chǎng)需求。

微服務(wù)的關(guān)鍵，除了跟服務(wù)設(shè)計(jì)本身相關(guān)的業(yè)務(wù)拆分和分層，還涉及微服務(wù)底層基礎(chǔ)系統(tǒng)的構(gòu)建工作。系統(tǒng)需要提供一套基礎(chǔ)的架構(gòu)，使得微服務(wù)可以獨(dú)立的部署、運(yùn)行、升級(jí)，同時(shí)讓所有服務(wù)在功能上表現(xiàn)為一個(gè)統(tǒng)一的整體。這些系統(tǒng)性功能也需要有一系列服務(wù)來(lái)提供，它們可以視作微服務(wù)系統(tǒng)的“底座”。

一個(gè)完整的微服務(wù)系統(tǒng)底座最少要包含以下功能：日志和審計(jì)、監(jiān)控和告警、消息總線、注冊(cè)發(fā)現(xiàn)、負(fù)載均衡、部署和升級(jí)、事件調(diào)度、資源管理。另外還有一些非必須的底座功能：認(rèn)證和鑒權(quán)、統(tǒng)一服務(wù)構(gòu)建和打包、統(tǒng)一服務(wù)測(cè)試、微服務(wù)CI/CD流水線、服務(wù)依賴關(guān)系管理、統(tǒng)一問題跟蹤調(diào)試框架、灰度發(fā)布、藍(lán)綠部署等。

這個(gè)微服務(wù)底座必不可少，但實(shí)現(xiàn)起來(lái)工作量巨大。雖然業(yè)內(nèi)已有不少可用于微服務(wù)架構(gòu)落地的開源框架，但也并非拿來(lái)即用，而是有一定技術(shù)門檻，需要開發(fā)團(tuán)隊(duì)有足夠的技術(shù)積累和實(shí)踐經(jīng)驗(yàn)，否則可能需要走很多彎路。以Java領(lǐng)域的微服務(wù)架構(gòu)落地開源框架SpringCloud為例，光是組件就有數(shù)十個(gè)，并非所有開發(fā)人員都能很容易地全盤掌握這些組件的原理和使用。

此外，微服務(wù)架構(gòu)本身也存在一些弊端。服務(wù)拆分之后，雖然單個(gè)服務(wù)代碼量變小了，更易于修改和維護(hù)，但服務(wù)的個(gè)數(shù)變多了，系統(tǒng)總體代碼量可能并不會(huì)減少，甚至更為復(fù)雜，對(duì)運(yùn)維挑戰(zhàn)很大。如果需要采用微服務(wù)架構(gòu)的項(xiàng)目不止一個(gè)，而是幾十個(gè)，難道所有項(xiàng)目都要讓團(tuán)隊(duì)從頭寫一遍代碼？經(jīng)過實(shí)際業(yè)務(wù)驗(yàn)證的微服務(wù)組件能不能復(fù)用到其他項(xiàng)目上？如何保障所有服務(wù)的代碼規(guī)范和質(zhì)量？

上述這些，都是2016年底擺在陳定瑋團(tuán)隊(duì)面前的問題。彼時(shí)的陳定瑋正陷于150人研發(fā)團(tuán)隊(duì)的管理工作和永遠(yuǎn)也做不完的CodeReview中難以脫身。微服務(wù)的興起是機(jī)會(huì)也是挑戰(zhàn)，他開始思考一個(gè)問題：能不能用不需要寫代碼的方式來(lái)實(shí)現(xiàn)微服務(wù)架構(gòu)的開發(fā)，進(jìn)一步緩解研發(fā)項(xiàng)目管理的壓力？

飛算全自動(dòng)軟件工程平臺(tái)的初心：“干掉自己”

在陳定瑋看來(lái)，軟件工程行業(yè)雖然發(fā)展欣欣向榮，但實(shí)際上仍過度依賴“人工”，這也導(dǎo)致行業(yè)內(nèi)普遍存在四大痛點(diǎn)：

1. 項(xiàng)目成本高：人力成本高、溝通成本高、運(yùn)維成本高、軟硬件投入成本高；
2. 開發(fā)周期長(zhǎng)：開發(fā)者需要根據(jù)業(yè)務(wù)發(fā)展規(guī)模預(yù)期，配置相應(yīng)的架構(gòu)，不同架構(gòu)的復(fù)雜度和開發(fā)工作量完全不可類比；
3. 代碼質(zhì)量低：雖然業(yè)內(nèi)有不少編碼規(guī)范，但真正能遵守的仍是少數(shù)，而微服務(wù)架構(gòu)下每個(gè)服務(wù)由不同開發(fā)人員開發(fā)，代碼可讀性、可維護(hù)性、重復(fù)度及可測(cè)試性都難以保證；
4. 團(tuán)隊(duì)管理難：人才招聘難（符合要求的工程師難招，或者太貴）、人才管理難（大型軟件開發(fā)公司或者國(guó)企、大型單位的IT部門人員過多）、技術(shù)資產(chǎn)保全難（員工離職后代碼維護(hù)難）、技術(shù)依賴強(qiáng)（技術(shù)選型難、技術(shù)綁架多、技術(shù)趟坑多、技術(shù)沉淀難）。

2016年，陳定瑋團(tuán)隊(duì)從傳統(tǒng)領(lǐng)域轉(zhuǎn)型到互聯(lián)網(wǎng)，研發(fā)團(tuán)隊(duì)從四五十人一下暴增到了150人，所有管理問題接踵而來(lái)。2016年底，“不堪重負(fù)”的陳定瑋開始反思軟件工程體系管理的問題，并嘗試制定解決方案。他希望將軟件行業(yè)傳統(tǒng)的“人工治理”的作業(yè)方式變成“法治”，告別代碼，用標(biāo)準(zhǔn)化的流程操作和拖拉拽的方式實(shí)現(xiàn)開發(fā)。

對(duì)于軟件開發(fā)人員來(lái)說(shuō)，這是一個(gè)最終可能會(huì)“干掉自己”的項(xiàng)目，因此在一開始就引來(lái)了技術(shù)團(tuán)隊(duì)的不理解與抵觸。最開始的時(shí)候，陳定瑋只能單打獨(dú)斗，同時(shí)不斷給開發(fā)人員做思想工作。他希望工程師們可以從反復(fù)寫代碼、改代碼的困境中解放出來(lái)，擺脫低創(chuàng)新、純執(zhí)行、重復(fù)性極高的代碼編寫工作，去思考、突破更高層次的技術(shù)問題。

雖然經(jīng)歷了無(wú)數(shù)質(zhì)疑、不理解、爭(zhēng)吵，但在董事長(zhǎng)“沒有預(yù)算限制”的信任與支持之下，陳定瑋還是咬牙扛了過來(lái)。平臺(tái)最主要的核心技術(shù)是用可視化的流程引擎代替代碼來(lái)描述整個(gè)業(yè)務(wù)邏輯實(shí)現(xiàn)，運(yùn)行時(shí)解析流程圖執(zhí)行，其中最大的難點(diǎn)就在于如何將流程圖編譯成微服務(wù)。陳定瑋自己做技術(shù)調(diào)研和優(yōu)化調(diào)整，攻克了這個(gè)技術(shù)難關(guān)。在魔鬼般的工作強(qiáng)度下，總算做出了一些可以“看見”的成果使人信服，雖然付出的代價(jià)是在項(xiàng)目初期長(zhǎng)達(dá)一年的時(shí)間里完全沒有“生活”可言。

當(dāng)項(xiàng)目進(jìn)入到第二個(gè)里程碑、平臺(tái)初具雛形，加入這一項(xiàng)目的開發(fā)人員已經(jīng)從3個(gè)人變成了8個(gè)人，說(shuō)多不多，但都是精兵強(qiáng)將。

這個(gè)時(shí)候的平臺(tái)其實(shí)還存在不少問題，在陳定瑋看來(lái)，“沒有經(jīng)過實(shí)際生產(chǎn)環(huán)境實(shí)踐驗(yàn)證的微服務(wù)架構(gòu)都是耍流氓”，為了保障實(shí)際上線的效果和可用性，他開始“強(qiáng)迫”自己的團(tuán)隊(duì)在實(shí)際項(xiàng)目中使用這個(gè)平臺(tái)。每來(lái)一個(gè)項(xiàng)目，就單獨(dú)剝離一個(gè)團(tuán)隊(duì)使用這個(gè)平臺(tái)做開發(fā)，第二個(gè)團(tuán)隊(duì)用傳統(tǒng)的開發(fā)模式去交付，兩個(gè)團(tuán)隊(duì)的工作同步進(jìn)行。后者產(chǎn)出的App先交付給客戶，服務(wù)升級(jí)時(shí)再將用平臺(tái)開發(fā)出來(lái)的版本替換掉原來(lái)的版本。就這樣通過一個(gè)個(gè)實(shí)際項(xiàng)目將平臺(tái)錘煉得越來(lái)越好，下一步再給到不懂代碼的業(yè)務(wù)人員試用，并改進(jìn)界面功能和用戶體驗(yàn)。

歷經(jīng)四年時(shí)間，飛算全自動(dòng)軟件工程平臺(tái)總算順利上線，這個(gè)最初看上去遙不可及的想法終于變成一個(gè)可以在生產(chǎn)環(huán)境大規(guī)模使用的產(chǎn)品。

在陳定瑋團(tuán)隊(duì)中，大部分項(xiàng)目都已經(jīng)改用這個(gè)平臺(tái)來(lái)開發(fā)，為陳定瑋有效緩解了項(xiàng)目和團(tuán)隊(duì)管理的壓力。在公司科技項(xiàng)目數(shù)量越接越多、規(guī)模越接越大的情況下，公司技術(shù)團(tuán)隊(duì)卻由2016年的150人，減少到了50人左右。陳定瑋預(yù)計(jì)，“到今年年底的時(shí)候，公司技術(shù)團(tuán)隊(duì)二三十人就夠了。”

PK傳統(tǒng)開發(fā)工具：效率提升數(shù)十倍

飛算全自動(dòng)軟件工程平臺(tái)涵蓋“項(xiàng)目管理”、“自動(dòng)化開發(fā)”、“自動(dòng)化測(cè)試”、“質(zhì)量管理”和“自動(dòng)化運(yùn)維”等五大核心板塊，可以通過平臺(tái)管理從需求、研發(fā)、測(cè)試、部署、上線到運(yùn)維的整個(gè)軟件生命周期。借助該平臺(tái)，從項(xiàng)目經(jīng)理到產(chǎn)品經(jīng)理、部分架構(gòu)師可以直接完成項(xiàng)目的計(jì)劃和設(shè)計(jì)，不需要對(duì)研發(fā)工程師做任務(wù)分解和溝通；只要明確項(xiàng)目需求并設(shè)計(jì)好架構(gòu)，就可以通過繪制流程圖實(shí)現(xiàn)全自動(dòng)開發(fā)；自帶服務(wù)注冊(cè)中心、分布式鏈路追蹤、服務(wù)發(fā)現(xiàn)、服務(wù)治理等能力。

飛算全自動(dòng)軟件工程平臺(tái)解決軟件工程從項(xiàng)目啟動(dòng)到運(yùn)維的151個(gè)問題

目前飛算全自動(dòng)軟件工程平臺(tái)已經(jīng)上線阿里云并對(duì)外提供SaaS服務(wù)?！白詣?dòng)化開發(fā)”板塊率先發(fā)布，“自動(dòng)化測(cè)試”和“自動(dòng)化運(yùn)維”板塊的開發(fā)進(jìn)度也已經(jīng)完成50%，會(huì)在不久的將來(lái)上線。

據(jù)陳定瑋介紹，這次發(fā)布的“自動(dòng)化開發(fā)”板塊對(duì)標(biāo)傳統(tǒng)開發(fā)工具（如Eclipse、IntelliJ IDEA），創(chuàng)新點(diǎn)在于用流程圖取代了傳統(tǒng)的代碼編寫，用戶可以可視化地設(shè)計(jì)業(yè)務(wù)，只專注于業(yè)務(wù)邏輯，對(duì)使用者的專業(yè)領(lǐng)域、技術(shù)能力基本沒有限制。

該平臺(tái)提供了一系列標(biāo)準(zhǔn)化組件（包括基礎(chǔ)組件、SQL組件、工具組件等）、行業(yè)組件、安全模塊等，這些組件和模塊的開發(fā)代碼只有在經(jīng)過內(nèi)置的代碼質(zhì)量平臺(tái)審核通過后才能上線，可以有效規(guī)避傳統(tǒng)編碼方式難以保證代碼質(zhì)量的問題。

自動(dòng)化開發(fā)平臺(tái)界面演示

此外，平臺(tái)自動(dòng)提供內(nèi)建的微服務(wù)能力，基于用戶繪制的流程圖，平臺(tái)就能自動(dòng)生成經(jīng)過實(shí)踐驗(yàn)證的微服務(wù)架構(gòu)，用戶下載項(xiàng)目部署包 執(zhí)行服務(wù)包，放到服務(wù)端部署即可。用戶不需要深入研究微服務(wù)框架，也不會(huì)陷入各類問題難以定位和解決的窘境。平臺(tái)采用經(jīng)過團(tuán)隊(duì)實(shí)際項(xiàng)目歷練和驗(yàn)證的微服務(wù)最佳實(shí)踐，在高并發(fā)、大業(yè)務(wù)量場(chǎng)景下的穩(wěn)定性會(huì)優(yōu)于用戶自己使用的微服務(wù)框架。陳定瑋指出，“雖然沒辦法跟阿里那么大的業(yè)務(wù)體量相比，但是足以支撐大部分中大型電商的業(yè)務(wù)體量?！?/p>

內(nèi)建微服務(wù)能力也是飛算全自動(dòng)軟件工程平臺(tái)與目前市面上已有的無(wú)代碼、低代碼開發(fā)平臺(tái)最大的區(qū)別。陳定瑋表示，飛算全自動(dòng)軟件工程平臺(tái)目前在市面上還沒有完全對(duì)等的競(jìng)爭(zhēng)產(chǎn)品，市面上已有的產(chǎn)品均更偏向前端開發(fā)，而飛算全自動(dòng)軟件工程平臺(tái)屬于后端微服務(wù)開發(fā)。

表1：傳統(tǒng)開發(fā)產(chǎn)品 VS 飛算全自動(dòng)軟件工程平臺(tái)

為了讓大家能更直觀地了解使用飛算全自動(dòng)軟件工程平臺(tái)開發(fā)的效率與效能，在本周的發(fā)布會(huì)上專門設(shè)置了一個(gè)非常有趣的PK環(huán)節(jié)：基于同一份項(xiàng)目需求，開發(fā)人員手動(dòng)編寫代碼和業(yè)務(wù)人員使用平臺(tái)開發(fā)來(lái)比拼看誰(shuí)開發(fā)的更快。

對(duì)于這樣一個(gè)并不復(fù)雜的項(xiàng)目需求，一個(gè)業(yè)務(wù)人員使用飛算全自動(dòng)軟件開發(fā)平臺(tái)開發(fā)只需要20分鐘就能搞定，而開發(fā)人員用傳統(tǒng)編碼方式開發(fā)需要1-2天時(shí)間才能完成，開發(fā)效率提升數(shù)十倍。如果是更復(fù)雜的項(xiàng)目，開發(fā)效率的提升會(huì)更加明顯。

未來(lái)微服務(wù)開發(fā)的變與不變

微服務(wù)雖好，卻并非銀彈。隨著云原生技術(shù)的推廣和大量微服務(wù)案例的落地，社區(qū)關(guān)于微服務(wù)模式質(zhì)疑的聲音越來(lái)越多。陳定瑋也注意到了這一現(xiàn)象，他表示，如果是企業(yè)內(nèi)部使用的簡(jiǎn)單系統(tǒng)，可能確實(shí)不需要用到微服務(wù)，但對(duì)于有高并發(fā)、高可用、快速開發(fā)要求的場(chǎng)景，微服務(wù)依然是當(dāng)前最好的解決方案，暫時(shí)沒有第二種選擇。當(dāng)前很多有數(shù)字化轉(zhuǎn)型需求的傳統(tǒng)企業(yè)，都希望能吸引大量C端客戶到自己的平臺(tái)上，將公域流量轉(zhuǎn)為私域流量，如果沒有微服務(wù)體系的支撐就很難做到。

飛算全自動(dòng)軟件工程平臺(tái)主要的目標(biāo)用戶群體也是這些真正有痛點(diǎn)的中小型軟件公司和傳統(tǒng)企業(yè)，這些公司通常有微服務(wù)改造的剛需，但受制于團(tuán)隊(duì)和技術(shù)能力無(wú)法實(shí)現(xiàn)。飛算全自動(dòng)軟件工程平臺(tái)就是要幫助這些真正對(duì)微服務(wù)有需求卻不知道怎么玩轉(zhuǎn)的企業(yè)或團(tuán)隊(duì)，低成本快速上手。對(duì)于領(lǐng)域和行業(yè)，平臺(tái)并沒有任何限制。陳定瑋強(qiáng)調(diào)，“只要是Java能做的，我們的平臺(tái)都可以做。除了驅(qū)動(dòng)、游戲、操作系統(tǒng)，基本上目前的應(yīng)用系統(tǒng)都可以通過我們的平臺(tái)來(lái)實(shí)現(xiàn)?！?/p>

技術(shù)層面，飛算全自動(dòng)軟件工程平臺(tái)接下來(lái)主要有兩項(xiàng)改進(jìn)計(jì)劃：一是支持標(biāo)準(zhǔn)的前端頁(yè)面模板或者完全自定義頁(yè)面、通過拖拽的方式實(shí)現(xiàn)前端頁(yè)面開發(fā)，二是完成“自動(dòng)化測(cè)試”和“自動(dòng)化運(yùn)維”板塊的開發(fā)。

市場(chǎng)層面，陳定瑋也提出了自己的愿景：三年內(nèi)幫助10000家企業(yè)。在平臺(tái)正式上線之前，已經(jīng)有十幾家公司在試用并基于平臺(tái)構(gòu)建項(xiàng)目。他還有一個(gè)更大的目標(biāo)，就是要通過知識(shí)經(jīng)驗(yàn)管理的貢獻(xiàn)，徹底改變軟件工程行業(yè)現(xiàn)有的作業(yè)方式，實(shí)現(xiàn)軟件工程的全流程自動(dòng)化。

至于目標(biāo)能否實(shí)現(xiàn)，就要接受市場(chǎng)的考驗(yàn)了。陳定瑋表示，從傳統(tǒng)的編寫代碼做開發(fā)，到設(shè)計(jì)流程圖做開發(fā)，對(duì)開發(fā)方式是一次很大的變革，原來(lái)用傳統(tǒng)開發(fā)方法做過的東西需要全部推倒重來(lái)，這是平臺(tái)推廣的一個(gè)難點(diǎn)。如何讓企業(yè)和開發(fā)團(tuán)隊(duì)接受新方式、掌握流程圖設(shè)計(jì)，更重前期培訓(xùn)，接下來(lái)飛算全自動(dòng)軟件工程平臺(tái)研發(fā)團(tuán)隊(duì)會(huì)專門組建一支培訓(xùn)團(tuán)隊(duì)，輔導(dǎo)用戶更快上手使用。

陳定瑋也提到，飛算全自動(dòng)軟件工程平臺(tái)主要是幫助大家提高開發(fā)和維護(hù)效率、降低技術(shù)門檻，但是坦率講，它并不能包辦一切，無(wú)法幫助大家完成設(shè)計(jì)方面的工作，比如微服務(wù)拆分、數(shù)據(jù)庫(kù)表設(shè)計(jì)等工作，但會(huì)提供培訓(xùn)和專業(yè)開發(fā)人員來(lái)協(xié)助用戶做好這些工作。這其實(shí)已經(jīng)屬于互聯(lián)網(wǎng)軟件體系設(shè)計(jì)思路分享的范疇，也是需要教育的。玩轉(zhuǎn)互聯(lián)網(wǎng)軟件體系的方法與傳統(tǒng)軟件的設(shè)計(jì)思維方式并不相同，陳定瑋希望傳達(dá)這樣一個(gè)理念，也會(huì)將這一工作作為未來(lái)的重點(diǎn)之一。

延伸閱讀：

Postman公司微服務(wù)最新實(shí)踐

Java 并不是構(gòu)建微服務(wù)平臺(tái)的最佳選擇

你家的數(shù)據(jù)庫(kù)“云原生”了嗎？

關(guān)注我并轉(zhuǎn)發(fā)此篇文章，私信我“領(lǐng)取資料”，即可免費(fèi)獲得InfoQ價(jià)值4999元迷你書，點(diǎn)擊文末「了解更多」，即可移步InfoQ官網(wǎng)，獲取最新資訊～