低程式碼平臺--基於surging開發微服務編排流程引擎構思

fanly11發表於2021-05-21
微服務

前言

 微服務對於各位並不陌生，在網際網路浪潮下不是在學習微服務的路上，就是在使用改造的路上，每個人對於微服務都有自己理解，有用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 微服務引擎低程式碼平臺

 


 

相關文章