重庆幸运农场中奖金额|重庆幸运农场官网
MyException - 我的異常網
當前位置:我的異常網» 軟件架構設計 » 微服務(SOA)的綴輯與編制及組合的分析與實踐

微服務(SOA)的綴輯與編制及組合的分析與實踐

www.h0f1.com  網友分享于:2018-06-06  瀏覽:0次
微服務(SOA)的編排與編制及組合的分析與實踐
    最近在開發公司產品的核心主業務,因為此業務需要串起多個子應用,子應用都已經獨立部署,而且拆分的獨立應用非常多。比如企業任務子應用,訂單子應用,任務執行總控應用(內含很多個子任務執行子應用),簽章子應用,支付子應用,未來還有核算子應用,報告子應用。
    在這樣一個核心業務中的各相關應用調用中,有可能中斷被介入,也可能部分必須同時完成,也可能應用宕機等情況。筆者之前一直做單體應用,剛從事互聯網業務,才面臨這些問題。如何把這些服務合理的整合在一個業務場景中,這是我一直在思考的一個問題。

    雖然第一個版本已經上線了,但時間倉促,在目前的進一步重構優化中,需要很好的把握多個微服務的調用。雖然網上很多微服務編排的文章,還有多個微服務的分頁式事務,但貌似不解決我的業務問題,還有些文章一知半解,到處復制。最近又看到網上的兩個文章,基本上心里有思路了。

一、(微)服務相關概念與關系
    標題中的編排與編制來自后面附的文章。
    “編制的英文是Orchestration,本意是樂隊指揮。微服務的編制強調的是通過一個可執行的中心流程來協同內部及外部的服務交互。通過中心流程來控制總體的目標,涉及的操作,服務調用順序。”
    “編排的英文是Choreography。微服務的編排強調的是協作,通過消息的交互序列來控制各個部分資源的交互。參與交互的資源都是對等的,沒有集中的控制。”

    提到微服務技術,少不了以下一些概念,先分成幾類:
  • 與外部有關的概念:注冊、發現、監控(可以沒有)
  • 與本身有關的概念:熔斷、限流、降級、超時、重試、冪等(部分可以沒有)
  • 與組合有關的概念:最終一致性、分布式事務、CAP、BASE、補償、分布式鎖


     而分析上面的業務應用功能:我們目前沒有注冊、發現,沒有熔斷、限流、降級。應用之間可能有重試、冪等要求。

     應用之間的關系:有兩種情況。比如中間有環節可以被中斷,比如賬戶錢不夠就中斷到某個狀態。重新再支付再運行。所以這時也沒有自動重試,用戶可以介入。也有的應用之間是強關聯,比如訂單支付成功與賬戶金額變化,這兩者之間一定要最終一致,重試與冪等,中間不可能產生有用戶介入的操作。對用戶來說,要么成功要么失敗,用戶不會知道中間狀態的。
    如果兩個應用之間是弱關系,其中一個應用down機了,既然有用戶介入,是不需要維護一致性的。如果后面的強關聯,是一定要維護一致性的(自動或者人工后臺干預)。

     我們這些業務系統,到底是soa嗎?業務是微服務嗎?貌似情況比較多。

二、設想兩種極端的調用

   串行調用方式:
   如果企業任務應用接受一個外部任務開始,只調用訂單子應用。而訂單其內部調用簽章子應用,簽章內部再調用支付子應用,支付內部再調用執行總任務,執行總任務調用核算子應用...再一層層回溯回來。對外層來說,只調了一個應用,其它都被代理了。也只有一個狀態:訂單的狀態。



  一個明顯的問題是,如果很多內部狀態要顯示給用戶,而且用戶可能進行介入操作。如果第一層要記錄下每個層的狀態,層次稍微深一點就非常復雜了。最深一層的狀態變化,都要向上冒泡到最外層。比如任務調用了訂單,訂單調用了執行。外層的任務很難顯示執行的狀態,只知道訂單提交,訂單成功或者失敗。因為執行完全由訂單應用代理了。
   另外,如果用戶介入到深層次的操作,外部除了顯示內部狀態,還要層層把請求轉發到相關層,復雜度,失敗可能性,失敗的處理都非常困難。
   如同生活中找代理公司辦事,人家可能一層層找人做,你只能看到最終的結果,如果去打聽一層層的進展,將是非常困難的。一般會說,你等著,最后結果會告知的。后面也許還有他不掌握的層層調用,代價很大,怎么可能提供外部詳細的調用狀態呢。如果想辦法找到了某層代理人,要介入,人家也不認識你,人家只認上層調用他的人。

  中心總控方式:
   這在生活中非常常見。比如我們去醫院體驗,有一個體驗表,每個任務都有一個填寫塊,都完成了就總檢。如果有沒完成的,第二天再去,也許有步驟可以跳過。再比如一個建設項目,要很多個部門審批,公司肯定有一個項目進展表,規土局,建委,環保局,一個個進展都記錄下來。



   不可能你去規土局辦事,規土局一門受理了,最后由機關內部流轉到建委、環保局,最后你從規土局口子拿到一串部門辦好的結果。

   組合方式:
   設想在中心總控的方式中提到的公司的項目進行審批,你得到的狀態是一個個部門的受理、辦結。而你得不到部門內部的受理環節、科審、處審、辦結等具體環節。部門之間你可以介入再發起、部門內部你完全無法介入,如果科審失敗就整體失敗返回,重新從受理開始。
    用戶對服務的調用發起,只能從可介入的服務開始,比如各個部門的受理。而內部要么成功要么失敗,中間是不能由用戶介入的,用戶通常也不知道內部的進展環節。


    如果一個部門的處長審核時認為缺少資料不通過,結果會是本部門辦理的整體審核失敗,不會在此環節由企業介入補材料。企業可以下次重新受理,也可以不辦理了。

三、結論

  我的業務要求在給用戶展示出幾個重要環節的狀態給用戶介入,比如錢不夠會停止在訂單,用戶可以再支付。授權時,如果沒收到授權,用戶可以介入再發起。核算中如果再付款,用戶可以再支付。然而有些過程,比如用戶帳戶有錢,那訂單狀態與賬戶扣費及發票都是一起發生的。這幾個又有最終一致性要求,不會給用戶顯示中間的狀態。

   所以合理的設計,強組合在一起的業務,可能由一些應用發起,對調用方只返回結果,內部保證最終一致性,這里沒有中心,是完全去中心化的。而這些強組合的進一步組合出更大的弱業務流程,中間可正常中斷,就需要一個總控,顯示某個強組合的狀態,這個狀態的用戶所介入的操作,將啟動強組合業務。

   用字母表示應用,應用的組合類似于: “-ABC-DE-F-G-HIJL--”。如果一切順利,可以從A調用到L不失敗,如果中間有問題,只能停留在“-”的狀態由用戶介入。"DE"是強組合,成功就到F,不管DE哪一個失敗,停留在D前的狀態。D成功E失敗,D可以不斷重試,直到超時D回退。比如訂單修改了狀態與庫存,再調用扣費,結果沒調成功,反復重試還不成功,訂單狀態就要回退。如果先扣費,再修改狀態與庫存,修改出錯,扣費就退款。反正必須同時成功;反正不用用戶介入。

   這樣,我們要合理劃分業務流程中的各應用之間的關系。數據庫中主業務數據表的狀態有一個總控狀態,只記錄在弱組合中的結果狀態。應用強組合之間進行超時、重試,冪等,回退等,只有整體成功與失敗。


    此圖中,小黑塊是一個個服務,服務會有一定的強組合,就是最終一致性,而整體的業務會串起單一的或者組合的應用。強組合內不存在用戶可介入的分支(如果重試、超時、意外的不一致,由后臺管理介入)。
    我們的業務是整體的由中心控制的編制,與局部無中心化的編排的復雜的結合。

四、感悟

   微服務確實很微。完整的業務往往是一些組合情況。高聚合低耦合的原理無處不在。高聚合的微服務就是要研究編排,一致性,分布鎖等。低聚合的微服務就是要編制,為了靈活可以參考工作流的原理進行統一配置。

附參考文章:
https://blog.csdn.net/jessise_zhan/article/details/80129818

https://blog.csdn.net/wp94302948/article/details/79653945

文章評論

軟件開發程序錯誤異常ExceptionCopyright © 2009-2015 MyException 版權所有
重庆幸运农场中奖金额