如何快速實(shí)現(xiàn)REST API集成以優(yōu)化業(yè)務(wù)流程
（圖 多個(gè)微服務(wù)API進(jìn)行流程編排）
（圖?編排過程中可對(duì)API的數(shù)據(jù)及格式進(jìn)行轉(zhuǎn)換）
試想一下在沒有微服務(wù)編排平臺(tái)的情況下，我們要完成一個(gè)這樣的業(yè)務(wù)邏輯怎么樣才能實(shí)現(xiàn)?
我們有一個(gè)查詢商品價(jià)格變化的服務(wù)A，有一個(gè)VIP會(huì)員接收商品變化通知的服務(wù)B，有一個(gè)VIP會(huì)員執(zhí)行中訂單價(jià)格變更服務(wù)C。我們需要在商品價(jià)格發(fā)生變化時(shí)立即自動(dòng)通知VIP會(huì)員服務(wù)B和訂單變更服務(wù)C兩個(gè)API服務(wù)，而且要保證送達(dá)(不能出現(xiàn)B成功C失敗或者B失敗C成功的情況)，也就是事務(wù)一致性。
作為開發(fā)工程師第一時(shí)間肯定是編寫代碼：先定時(shí)不斷的輪詢A服務(wù)，當(dāng)有數(shù)據(jù)變化時(shí)編寫代碼調(diào)用B，C兩個(gè)服務(wù)，看起來其實(shí)非常簡(jiǎn)單也就百十來行代碼就可以搞定，其實(shí)不然。細(xì)思其實(shí)很復(fù)雜：
工程師會(huì)面臨頻繁修改這個(gè)業(yè)務(wù)邏輯的問題，要不斷的發(fā)包測(cè)試聯(lián)調(diào)等，可想一旦這種需求和邏輯多起來后，錯(cuò)綜復(fù)雜的API之間的關(guān)系將很難追查“一個(gè)API出現(xiàn)問題時(shí)到底會(huì)影響多少業(yè)務(wù)系統(tǒng)或其他API服務(wù)”。而微服務(wù)編排平臺(tái)就是專門集中化解決這種服務(wù)與服務(wù)之間集成，數(shù)據(jù)格式轉(zhuǎn)換、服務(wù)聚合、協(xié)議轉(zhuǎn)換、分布式事務(wù)控制的平臺(tái)。通過微服務(wù)編排平臺(tái)可以進(jìn)行可視化的API的編排來降低這些重復(fù)沒有技術(shù)含量的工作、提升服務(wù)調(diào)用邏輯的可視化、提供數(shù)據(jù)傳輸過程的監(jiān)控和回朔能力、事后進(jìn)行數(shù)據(jù)審計(jì)的能力，并進(jìn)一步實(shí)現(xiàn)不合規(guī)業(yè)務(wù)數(shù)據(jù)的自動(dòng)預(yù)警能力(例如：價(jià)格突然被調(diào)到0元，此時(shí)在服務(wù)編排平臺(tái)中可以攔截價(jià)格數(shù)據(jù)并立即發(fā)送預(yù)警消息，避免企業(yè)受到損失)。
目前開源的微服務(wù)編排平臺(tái)主要有Netflix Conductor微服務(wù)編排平臺(tái)，但是存在沒有中文界面、不支持可視化編排、UI不夠友好等等問題，如果用作企業(yè)級(jí)的服務(wù)編排平臺(tái)還存在相當(dāng)大的差距。RestCloud作為最早在國內(nèi)做自主研發(fā)的微服務(wù)框架的團(tuán)隊(duì)，自然是看到了這種問題的存在，可以說在國內(nèi)第一時(shí)間就開始研發(fā)這個(gè)微服務(wù)編排平臺(tái)了，目的是研發(fā)一個(gè)完全國產(chǎn)化的簡(jiǎn)單易用的微服務(wù)編排平臺(tái)，通過可視化的拖、拉、拽就可以完成一堆各種協(xié)議API的編排，當(dāng)然其作為商業(yè)化公司是不開源的。
這個(gè)可以說是我們經(jīng)常被問到的問題，因?yàn)楝F(xiàn)在像IBM和Oracle等的ESB產(chǎn)品也支持Restful API的調(diào)用與編排，也可以通過圖形化的方式進(jìn)行拖拽然后進(jìn)行服務(wù)邏輯重組，但是仔細(xì)來看這兩種平臺(tái)有相似性也有很大的差異，我們體現(xiàn)在以下一些方面。1. 首先微服務(wù)編排平臺(tái)本身一定要是基于微服務(wù)架構(gòu)開發(fā)的且前后端分離的系統(tǒng)，可以分布式部署、可以完全融入到企業(yè)已有的微服務(wù)架構(gòu)中，編排的后的微服務(wù)可以立即發(fā)布到網(wǎng)關(guān)或注冊(cè)中心或基于Docker容器進(jìn)行部署。而傳統(tǒng)的ESB不行，傳統(tǒng)的ESB都是基于SOA架構(gòu)為基礎(chǔ)的CS結(jié)構(gòu)或B/S的單體系統(tǒng)基本上與微服務(wù)沒有什么關(guān)系，其內(nèi)部組件高度耦合，微服務(wù)編排平臺(tái)可以做到真正的敏捷集成和快速發(fā)布。2. 微服務(wù)編排平臺(tái)本身的所有能力又可以作為API服務(wù)對(duì)外進(jìn)行能力輸出。而傳統(tǒng)的ESB卻很難做的到，其能力只能有限對(duì)外發(fā)布。3. 微服務(wù)編排平臺(tái)一般追求更高的流程執(zhí)行和調(diào)度性能，所以更注重輕量級(jí)，易用等特點(diǎn)。而傳統(tǒng)的ESB由于架構(gòu)復(fù)雜性能往往存在瓶頸，同時(shí)顯得非常笨重使用起來普遍感覺很難入門。4. 微服務(wù)編排平臺(tái)更注重API服務(wù)的編排，特別是微服務(wù)的API如(Restful，WebService，Dubbo，gRPC等)。而傳統(tǒng)ESB往往會(huì)引入一大堆與微服務(wù)沒有關(guān)系的功能如：FTP、SMTP、MQTT、JDBC、EXCEL、數(shù)據(jù)庫鏈接、大文件傳送等，甚至把ETL的部分功能混雜進(jìn)了ESB中。
5. 微服務(wù)編排平臺(tái)更注重編排后服務(wù)的事務(wù)性控制能力，往往會(huì)提供最終一致性事務(wù)控制能力，斷點(diǎn)續(xù)跑能力、故障轉(zhuǎn)移等功能，同時(shí)講究數(shù)據(jù)在運(yùn)行過程中的可恢復(fù)性。而ESB在這方面顯然是比較弱的。6. 微服務(wù)編排平臺(tái)一般作為企業(yè)所有開發(fā)人員、子公司、第三方開發(fā)商或者最終業(yè)務(wù)人員的統(tǒng)一服務(wù)編排平臺(tái)。而傳統(tǒng)ESB往往是給那些企業(yè)里面的專業(yè)集成人員所使用的，因?yàn)镋SB使用復(fù)雜而且有些是基于C/S架構(gòu)的沒有提供一個(gè)集成門戶給第三方開發(fā)商或子公司的開發(fā)人員去編排。7. 傳統(tǒng)ESB軟件往往功能做的非常復(fù)雜，會(huì)把一些算法、邏輯進(jìn)行混排，所以使用難度不少。而微服務(wù)編排平臺(tái)會(huì)把大部分邏輯放入到API中。8. 同時(shí)傳統(tǒng)ESB還把微服務(wù)架構(gòu)中的API網(wǎng)關(guān)、API接口管理的能力也進(jìn)行了混入，所以看看ESB是不是什么都想做（API網(wǎng)關(guān)，服務(wù)編排、ETL數(shù)據(jù)交換、API文檔管理、文件傳送）。而在微服務(wù)架構(gòu)中一般API網(wǎng)關(guān)是獨(dú)立的模塊。API網(wǎng)關(guān)就是一個(gè)獨(dú)立的模塊只負(fù)責(zé)數(shù)據(jù)的路由和透?jìng)鳎非蟮氖切阅埽欢⒎?wù)編排平臺(tái)則專門負(fù)責(zé)服務(wù)的編排，追求的是快速的編排；而ETL則專門負(fù)責(zé)數(shù)據(jù)的清洗、轉(zhuǎn)換和加載追求的是大批量的數(shù)據(jù)傳送和清洗能力。9. 我們有時(shí)也認(rèn)為微服務(wù)編排平臺(tái)是一個(gè)輕量級(jí)只注重微服務(wù)編排的ESB產(chǎn)品，因?yàn)槲⒎?wù)編排平臺(tái)也與ESB產(chǎn)品一樣具有中心化節(jié)點(diǎn)的架構(gòu)，構(gòu)建的同樣是企業(yè)的服務(wù)總線。10.傳統(tǒng)ESB產(chǎn)品和微服務(wù)編排平臺(tái)側(cè)重點(diǎn)不一樣，如果企業(yè)對(duì)于文件傳送、其他協(xié)議的轉(zhuǎn)換沒有什么特別要求可以直接使用微服務(wù)編排平臺(tái)+API網(wǎng)關(guān)來構(gòu)建企業(yè)服務(wù)總線，只需要把相關(guān)協(xié)議統(tǒng)一到Restful接口規(guī)范即可(把FTP功能發(fā)布為API，郵件發(fā)送發(fā)布為API等)，如果企業(yè)已經(jīng)購買了ESB產(chǎn)品的情況下可以采取共存的方案。
其實(shí)不然。在企業(yè)里面這種中心化架構(gòu)是必然存在的，互聯(lián)網(wǎng)企業(yè)大部分會(huì)認(rèn)為微服務(wù)架構(gòu)要去中心化，而其實(shí)互聯(lián)網(wǎng)企業(yè)也只是在局部業(yè)務(wù)領(lǐng)域?yàn)榱俗非笮阅芏鴮?shí)現(xiàn)了去中心化的架構(gòu)(因?yàn)榻鉀Q性能問題是互聯(lián)網(wǎng)架構(gòu)的核心訴求)。而在企業(yè)里面面臨的主要問題是有很多遺留業(yè)務(wù)系統(tǒng)、業(yè)務(wù)邏輯非常復(fù)雜、業(yè)務(wù)邏輯多變(在企業(yè)里面解決復(fù)雜業(yè)務(wù)問題是核心訴求)，所以不是我們上了微服務(wù)架構(gòu)就不能有中心化平臺(tái)出現(xiàn)了。像Netflix也是互聯(lián)網(wǎng)公司，但是發(fā)現(xiàn)很多業(yè)務(wù)問題解決起來超出可控范圍，所以不得以研發(fā)了Conductor編排平臺(tái)。企業(yè)不能為了微服務(wù)而微服務(wù)，在企業(yè)IT架構(gòu)中不要進(jìn)行過度的架構(gòu)設(shè)計(jì)，只有能解決業(yè)務(wù)問題才是核心。
（圖?中心化編排可把各種中臺(tái)API接口進(jìn)行統(tǒng)一編排）
我們?cè)谧黾軜?gòu)設(shè)計(jì)時(shí)就考慮到平臺(tái)本身必須是一個(gè)基于微服務(wù)架構(gòu)的平臺(tái)，例如可以自動(dòng)接入服務(wù)注冊(cè)與發(fā)現(xiàn)中心、采用無狀態(tài)架構(gòu)設(shè)計(jì)水平擴(kuò)展、支持Docker容器化部署、前后端分離B/S架構(gòu)等基礎(chǔ)原則。
考慮到編排平臺(tái)可能會(huì)有大量的編排流程在同時(shí)運(yùn)行(可能同時(shí)超過幾千個(gè))，而且被編排的API服務(wù)可能存在不穩(wěn)定性等情況出現(xiàn)，所以作為流程調(diào)度器我們重點(diǎn)實(shí)現(xiàn)了故障自動(dòng)轉(zhuǎn)移、繼點(diǎn)續(xù)跑等重要能力。
在API調(diào)用失敗時(shí)，用戶有時(shí)是需要全流程重跑一次，有時(shí)又希望只跑某幾個(gè)重要節(jié)點(diǎn)，這就需要編排平臺(tái)能夠很好的進(jìn)行靈活定義并在合適的節(jié)點(diǎn)進(jìn)行數(shù)據(jù)的恢復(fù)，而且重跑時(shí)也有可能再次失敗，失敗后還要引入手工干預(yù)流程運(yùn)行的能力。
在編排節(jié)點(diǎn)上我們支持常用的API節(jié)點(diǎn)進(jìn)行編排，目前主要支持：Restful、WebService、Dubbo、kafka、腳本、Rabbitmq、微信、釘釘?shù)裙?jié)點(diǎn)的編排，目前主要考慮的是在微服務(wù)的協(xié)議的上的節(jié)點(diǎn)，后繼擴(kuò)展節(jié)點(diǎn)則根據(jù)用戶的訴求進(jìn)行擴(kuò)充即可。
在流程設(shè)計(jì)上我們遵循BPMN2.0規(guī)范，這樣有利于原來就熟悉工作流的人員可以快速的進(jìn)行API服務(wù)的編排與設(shè)計(jì)。
在編排流程的監(jiān)控上我們實(shí)現(xiàn)了完全可視化的流程回放能力、可視化的數(shù)據(jù)追朔能力、API調(diào)用實(shí)時(shí)監(jiān)控能力，同時(shí)可以統(tǒng)計(jì)編排流程的平均性能、運(yùn)行次數(shù)、失敗次數(shù)等等功能。
（圖?分布式的編排流程調(diào)用引擎和執(zhí)行引擎）?通過服務(wù)編排平臺(tái) 企業(yè)可以做什么？其實(shí)通過服務(wù)編排平臺(tái)可以實(shí)現(xiàn)非常復(fù)雜的業(yè)務(wù)需求，按照企業(yè)中臺(tái)架構(gòu)的實(shí)施進(jìn)度，如果企業(yè)的業(yè)務(wù)能力全部以API的形式對(duì)外開放時(shí)，服務(wù)編排平臺(tái)將具有實(shí)現(xiàn)企業(yè)業(yè)務(wù)能力快速重組的功能，即通過拖、拉、拽就可以實(shí)現(xiàn)一個(gè)新的業(yè)務(wù)創(chuàng)新點(diǎn)然后對(duì)外提供服務(wù)。編排平臺(tái)將處于所有中臺(tái)(數(shù)據(jù)中臺(tái)、業(yè)務(wù)中臺(tái)、技術(shù)中臺(tái))之上的一種高級(jí)的能力重組中心，同時(shí)通過編排平臺(tái)還可以實(shí)現(xiàn)企業(yè)私有化業(yè)務(wù)系統(tǒng)與云端SaaS系統(tǒng)、數(shù)據(jù)中心進(jìn)行打通，可以說在API的世界里，編排平臺(tái)就是上帝之手，他可以通過編排組合新的API基因創(chuàng)造新的物種。
（圖 混合云架構(gòu)下的服務(wù)編排場(chǎng)景）
傳統(tǒng)ESB已經(jīng)很難勝任這種混合云架構(gòu)的集成與快速打通，而微服務(wù)編排平臺(tái)將隨著微服務(wù)架構(gòu)以及中臺(tái)和混合云架構(gòu)的流行將成為企業(yè)不可缺少的企業(yè)中間件產(chǎn)品。
本文章轉(zhuǎn)載微信公眾號(hào)@大語言模型
對(duì)比大模型API的內(nèi)容創(chuàng)意新穎性、情感共鳴力、商業(yè)轉(zhuǎn)化潛力
一鍵對(duì)比試用API 限時(shí)免費(fèi)
鍵.png)
