前言
微服務對于各位并不陌生，在互聯網浪潮下不是在學習微服務的路上，就是在使用改造的路上，每個人對于微服務都有自己理解，有用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 微服務引擎低代碼平臺
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/285365.html
標籤：.NET Core
上一篇：.NetCore 訊息佇列的使用