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