前言
微服務對於各位並不陌生，在互聯網浪潮下不是在學習微服務的路上，就是在使用改造的路上，每個人對於微服務都有自己理解，有用k8s 就說自己是微服務，有用一些第三方框架spring cloud, dubbo ，abp, nginx,kong就說是微服務的，還有用一些第三放分布式平台去架設部署也認為它是微服務，反正微服務的架設是各種各樣，沒有定義哪個架構是對的，只要是集大成者，全部用docker, 滿足服務發現，服務治理就是微服務。而對於以上架構選擇不去評判是對是錯。沒有一桿稱砣去評判是否滿足微服務思想架構，所以這種口伐筆誅是沒有意義，那么現在淺談一下對於微服務中微是如何理解，如何架構實現。
而對於微服務，微服務一詞中的前綴"微"是一個隱含體系結構最佳實踐，讓服務在設計階段保持簡單、傻瓜式。雖然傳統上微服務僅應用於架構，但它也開始與日常中所說的服務、webapi等進行替換。
"微"是一個重要的提示詞，它可以消除企業對系統過渡復雜化的架構。如果你去拆解數年業務系統，然而可以將一個大功能分解為許多小的功能模塊服務，從而提供微服務給其它服務終端調用。
而每個微服務都能成為模塊功能或者是API.通過微服務集成，可以輕松實現復雜的集成方案。例如，物聯網的設備多終端交互，流媒體的多終端推流訂閱播放，支付成功多終端消息推送，對於這些都可以分解為獨立的微服務進行調用集成，如果不能滿足業務需要，不能擴展實現的，只能說你只是對於現有的服務演變升級為分布式服務治理，並不是微服務，因為你還停留在以往需要找尋第三框架，工具去實現，這樣還是造成架構臃腫。
而對於業務會有源源不斷的需求需要實現，對於這種需求的情況下不可能重復去實現微服務，而我們要做的是對於現有的微服務進行聚合，形成新的服務以提供給其它服務終端進行調用，而surging 現有的做法是通過在服務代碼中遠程調用微服務數據整合的方式去實現服務聚合，這種方式有一種弊端，需要投入大量的人力去架構維護，並不能滿足大型系統架構需要。那么怎么去解決這個難題呢？首先就需要通過現有的微服務進行流程化服務編排，以便實現新的業務服務，那么我們可以通過這篇文章來淺談一下微服務編排，后面surging 將如何實現。
什么是微服務編排？
微服務編排是指把已經開發好的微服務按照一定的業務流程進行可視化編排的過程，微服務編排引擎會在內部重新聚合為一個新的服務進行發布，而這個服務我們稱為聚合服務
通過微服務編排引擎可以把已經開發好的微服務無需任何代碼就可以進行業務邏輯的重組與重構，可以提升微服務的復用效率實現前台業務或業務系統集成的的敏捷交付，通過微服務編排引擎也能把業務系統、數據、業務邏輯進行解藕，業務邏輯的編排交由專門的微服務編排引擎完成，而微服務只需要專注完成自已內部邏輯即可。
為什么需要微服務編排引擎
試想一下當你在沒有微服務編排引擎，在已經完成微服務拆分的情況下，第三方合作商或者移動端要求你增加邏輯處理服務調用，你該怎樣去實現，重新研發擴展微服務？如果是這樣的話，整個系統的微服務將比較臃腫，而且違反了單一職責，完全作為獨立的業務服務存在。
那么微服務編排引擎可以進行可視化的業務流程編排來降低這些重復沒有技術含量的工作、提升服務調用邏輯的可視化。
微服務編排流程的思路
通過微服務rpc,提供的routepath，參數模型和結果模型，再通過流程編排這些微服務來實現一個新的聚合服務。
編排流程的模型
- 服務節點模型。例如（參數賦值、invoke（遠程調用和本地調用））
- 控制模型。例如（順序、分支、循環、異常拋出、並行）
微服務編排框架提供了很多的服務節點模型基礎化設置，比如編排框架引擎可以支持本地調用、遠程RPC調用、協議轉化其它第三方服務調用等服務節點，從而在使用上更加的方便，有了這些基本的模型，我們就能方便的編排出復雜的聚合服務
基於surging 如何研發微服務編排流程引擎
首先現在只是對於需要實現服務編排流程引擎的構思，那么我們從二個方面着手
- 可視化流程編排：對於服務節點，控制模型的屬性和規則進行可視化設置
- 服務編排引擎的邏輯處理：需要對於業務流程，服務節點邏輯處理調用，配置處理返回結果。
那么針對於微服務之間怎么樣順序，分支調用處理呢？我們可以抽象出需要調用的模型
比如每個服務節點都可以以routepath 作為調用標識，然后可以設計輸入參數和輸出參數， 輸入參數是通過網關調用傳入的json 類型的httpbody ,再通過httpbody 可以轉為字典參數模型。就比如以下操作
可以舉例通過網關傳入以下參數：
{ “name”:"fanly", "age":36, "sex":1 }
那么我們在服務節點如何設置輸入參數呢？ 比如需要傳入的是name,那么我們可以通過以下設置
"inputParameters": { "name": "${input.name}" }
那么我們怎么樣去設置輸出參數呢？比如我們需要獲取服務節點名稱為node1 的結果，那么我們可以通過以下進行設置
"outputParameters": { "result": "${node1.output.entity}" }
通過以上我們就可以這樣定義業務流程的json
{ "name": "workflow_name", "description": "測試", "version": 1, "services": [ { "name": "node1", "routepath": "api/user/getuser", "inputParameters": { "name": "${input.name}", }, "type": "microservice", "metadata":{} }, {} ... ], "outputParameters": { "result": "${node1.output.entity}" } }
而對於以上闡述，如何抽象數據模型來滿足流程化調用，而對於surging 是可以通過routepath調用的，所以配置routepath,輸入，輸出參數完全是可以實現微服務調用，就比如可以通過以下代碼routepath方式進行調用
Dictionary<string, object> model = new Dictionary<string, object>(); model.Add("username","name"); string path = "api/user/getuser"; string serviceKey = "User"; var userProxy = ServiceLocator.GetService<IServiceProxyProvider>().Invoke<object>(model, path, serviceKey); var s = userProxy.Result;
總結
以上是對於低代碼平台微服務編排流程引擎構思，后續會陸續實現，現在surging 能支持服務發現，服務治理，多協議擴展，緩存中間件，消息中間件，掃描引擎，並且還支持多語言版本（現支持java 和.net core 兩個版本）完全可以滿足企業多語言混合異構開發，后面會陸續開源至https://github.com/microsurging ，建立surging 微服務引擎低代碼平台