• <source id="sqj45"><optgroup id="sqj45"></optgroup></source>
  • <rt id="sqj45"></rt>
    <rt id="sqj45"></rt><rt id="sqj45"></rt>
  • <source id="sqj45"><nav id="sqj45"></nav></source><rt id="sqj45"></rt><rt id="sqj45"></rt><tt id="sqj45"><noscript id="sqj45"></noscript></tt>
    專業 靠譜 的軟件外包伙伴

    您的位置:首頁 > 新聞動態 > 微服務軟件開發架構核心要素分析!

    微服務軟件開發架構核心要素分析!

    2017-08-18 14:09:24

     

    微服務架構中職能團隊的劃分

    傳統單體架構將系統分成具有不同職責的層次,對應的項目管理也傾向于將大的團隊分成不同的職能團隊,主要包括:用戶交互UI團隊、后臺業務邏輯處理團隊與數據存取ORM團隊、DBA團隊等。每個團隊只對自己分層的職責負責,并對使用方提供組件服務質量保證。如果其中一個模塊化組件需要升級、更新,那么這個變更會涉及不同的分層團隊,即使升級和變更的改變很小,也需要進行跨團隊溝通:需求階段需要跨團隊溝通產品功能,設計階段需要跨團隊溝通設計方案,開發階段需要跨團隊溝通具體的接口定義,測試階段需要溝通業務回歸等事宜,甚至上線都需要跨團隊溝通應用的上線順序??梢娫趥鹘y的整體架構下,后期的維護成本很高,出現事故的風險很大。

    根據康威定律,團隊的交流機制應該與架構設計機制相對應。因此,在微服務架構下,職能團隊的劃分方法是我們首先要考慮的一個核心要素。

    微服務時代的團隊溝通方式如圖1-9所示。

    圖片描述

     

    圖1-9

     

    微服務架構按照業務的功能進行劃分,每個單一的業務功能叫作一個服務,每個服務對應一個獨立的職能團隊,團隊里包含用戶交互UI設計師、后臺服務開發人員、DBA、運營和運維人員。

    在傳統的整體架構中,軟件是有生命周期的,經歷需求分析、開發和測試,然后被交付給運維團隊,這時開發團隊將會解散,這是對軟件的一個“放手”。而在微服務架構中,提倡運維人員也是服務項目團隊的一員,倡導誰開發、誰維護,實施終生維護制度。

    在業務服務的內部實現需要升級或者變更時,團隊內的各角色成員進行溝通即可,而不需要進行跨團隊溝通,這大大提高了溝通效率。只有服務之間的接口需要變更時才需要跨部門溝通,如果前期在服務之間的交互上定義了良好的接口,則接口變更的概率并不大,即使接口模式有變更,也可以通過一定的設計模式和規范來解決,可參考1.3.3節。

    微服務的去中心化治理

    筆者曾經在一個互聯網平臺上工作,平臺的決策者倡導建設API網關,所有外部服務和內部服務都由統一的API網關進行管理。在項目初期,中心化的API網關統一了所有API的入口,這看起來很規范,但從技術角度來看限制了API的多樣化。隨著業務的發展,API網關開始暴露問題,每個用戶請求經過機房時只要有服務之間的交互,則都會從API網關進行路由,服務上量以后,由于內部服務之間的交互都會疊加在API網關的調用上,所以在很大程度上放大了API網關的調用TPS,API網關很快就遇到了性能瓶頸。

    這個案例是典型的微服務的反模式,微服務倡導去中心化的治理,不推薦每個微服務都使用相同的標準和技術來開發和使用服務。在微服務架構下可以使用C++開發一個服務,來對接Java開發的另外一個服務,對于異構系統之間的交互標準,通??梢允褂霉ぞ邅硌a償。開發者可以開發共用的工具,并分享給異構系統的開發者使用,來解決異構系統不一致的問題,例如:Thrift遠程調用框架使用中間語言(IDL)來定義接口,中間語言是獨立于任何語言的,并提供了工具來生成中間語言,以及在中間語言與具體語言之間的代碼轉換。

    微服務架構倡導去中心化的服務管理和治理,盡量不設置中心化的管理服務,最差也需要在中心化的管理服務宕機時有替代方案和設計。在筆者工作的支付平臺服務化建設中,第1層SOA服務化采用Dubbo框架進行定制化,如果Dubbo服務化出現了大面積的崩潰,則服務化體系會切換到點對點的hessian遠程調用,這被稱為服務化降級,降級后點對點的hessian遠程調用時沒有中心化節點,整體上符合微服務的原理。

    微服務的交互模式

    本節介紹微服務之間交互的通用設計模式,這些設計模式對微服務之間的交互定義契約,服務的生產者和調用者都需要遵守這些契約,才能保證微服務不出問題。

    1. 讀者容錯模式

    讀者容錯模式(Tolerant Reader)指微服務化中服務提供者和消費者之間如何對接口的改變進行容錯。從字面上來講,消費者需要對提供者提供的功能進行兼容性設計,尤其對服務提供者返回的內容進行兼容,或者解決在服務提供者改變接口或者數據的格式的情況下,如何讓服務消費者正常運行。

    任何一個產品在設計時都無法預見將來可能增加的所有需求,服務的開發者通常通過迭代及時地增加新功能,或者讓服務提供的API自然地演進。不過,服務提供者對外提供的接口的數據格式的改變、增加和刪除,都會導致服務的消費者不能正常工作。

    因此,在服務消費者處理服務提供者返回的消息的過程中,需要對服務返回的消息進行過濾,只提取自己需要的內容,對多余或者未知的內容采取拋棄的策略,而不是硬生生地拋錯處理。

    在實現過程中不推薦使用嚴格的校驗策略,而是推薦使用寬松的校驗策略,即使服務消費者拿到的消息報文發生了改變,程序也只需盡最大努力提取需要的數據,同時忽略不可識別的數據。只有在服務消費者完全不能識別接收到的消息,或者無法通過識別的信息繼續處理流程時,才能拋出異常。

    服務的消費者的容錯模式忽略了新的消息項、可選的消息項、未知的數據值及服務消費者不需要的數據項。

    筆者當前在某個支付公司工作,公司里幾乎每個業務都需要使用枚舉類型,在微服務平臺下,筆者在研發流程規范中定義了一條枚舉值使用規范:

    在服務接口的定義中,參數可以使用枚舉值,在返回值的DTO中禁止使用枚舉值。

    這條規范就是讀者容錯模式在實踐中的一個實例,之所以在參數中允許使用枚舉值,是因為如果服務的提供者升級了接口,增加了枚舉值,若服務的消費者并沒有感知,則服務的消費者得知新的枚舉值就可以傳遞新的枚舉值了;但是如果接口的返回DTO中使用了枚舉值,并且因為某種原因增加了枚舉值,則服務消費者在反序列化枚舉時就會報錯,因此在返回值中我們應該使用字符串等互相認可的類型,來做到雙方的互相兼容,并實現讀者容錯模式。

    2. 消費者驅動契約模式

    消費者驅動契約模式用來定義服務化中服務之間交互接口改變的很好規則。

    服務契約分為:提供者契約、消費者契約及消費者驅動的契約,它從期望與約束的角度描述了服務提供者與服務消費者之間的聯動關系。

    • 提供者契約:是我們最常用的一種服務契約,顧名思義,提供者契約是以提供者為中心的,提供者提供了什么功能和消息格式,各消費者都會無條件地遵守這些約定,不論消費者實際需要多少功能,消費者接受了提供者契約時,都會根據服務提供者的規則來使用服務。

    • 消費者契約:是對某個消費者的需求進行更為精確的描述,在一次具體的服務交互場景下,代表消費者需要提供者提供功能中的哪部分數據。消費者契約可以被用來標識現有的提供者契約,也可以用來發現一個尚未明確的提供者契約。

    • 消費者驅動的契約:代表服務提供者向其所有當前消費者承諾遵守的約束。一旦各消費者把自己的具體期望告知提供者,則提供者無論在什么時間和場景下,都不應該打破契約。

    在現實的服務交互設計中,上面這三種契約是同時存在的,筆者所在的支付平臺里,交易系統在完成一筆支付后,需要到賬務系統為商戶入賬,在這個過程中,服務契約表現如下。

    • 生產者契約:賬務系統提供Dubbo服務化接口,參數為商戶賬戶ID、入賬訂單號和入賬金額。

    • 消費者契約:賬務系統返回DTO,包含商戶賬戶ID、入賬訂單號、入賬金額、入賬時間、賬務流水號、入賬狀態等,而交易系統只需使用其中的入賬訂單號和入賬狀態。

    • 消費者驅動的契約:為了保證資金安全,交易系統作為入賬的發起者向賬務提出要求,需要賬務做冪等和濾重處理,對重復的入賬請求進行攔截;賬務系統在接受這個契約后,即使將來有任何改變,也不能打破這個限制,否則就會造成資金的損失,這在金融系統中是最嚴重的問題。

    服務之間的交互需要使用的三種服務契約如圖1-10所示。

    圖片描述

     

    圖1-10

     

    從圖1-10可以看到,服務提供者契約是服務提供者單方面定下的規則,而一個消費者契約會成為提供者契約的一部分,多個服務消費者可以對服務提供者提出約束,服務提供者需要在將來遵守服務消費者提出的契約,這就是消費者驅動的契約。

    3. 去數據共享模式

    與SOA服務化對比,微服務是去ESB總線、去中心化及分布式的;而SOA還是以ESB為核心實現遺留系統的集成,以及基于Web Service為標準實現的通用的面向服務的架構。在微服務領域,微服務之間的交互通過定義良好的接口來實現,不允許使用共享數據來實現。

    在實踐的過程中,有些方案的設計使用緩存或者數據庫作為兩個微服務之間的紐帶,在業務流程的處理過程中,為了處理簡單,前一個服務將中間結果存入數據庫或者緩存,下一個服務從緩存或者數據庫中拿出數據繼續處理。處理流程如圖1-11所示。

    圖片描述

     

    圖1-11

     

    這種交互流程的缺點如下。

    • 使得微服務之間的交互除了接口契約,還存在數據存儲契約。
    • 上游的數據格式發生變化時,可能導致下游的處理邏輯出現問題。
    • 多個服務共享一個資源服務,對資源服務的運維難以劃清職責和界限。
    • 在做雙機房獨立部署時,需要考慮服務和資源的路由情況,跨機房的服務調用不能使用獨立的資源部署模式,因此難以實現服務自治。

    因此,在設計微服務架構時,一定不要共享緩存和數據庫等資源,也不要使用總線模式,服務之間的通信和交互只能依賴定義良好的接口,通常使用RESTful樣式的API或者透明的RPC調用框架。

    微服務的分解和組合模式

    使用微服務架構劃分服務和團隊是微服務架構實施的重要一步,良好的劃分和拆分使系統達到松耦合和高內聚的效果,然后通過微服務的靈活組裝可以滿足上層的各種各樣的業務處理需求。

    在微服務架構的需求分析和架構設計過程中,通常是用領域的動詞和名詞來劃分微服務的,例如,對于一個電商后臺系統,可以分解為訂單、商品、商品目錄、庫存、購物車、交易、支付、發票、物流等子系統,每個名詞和動詞都可以是一個微服務,將這幾個微服務組合在一起,就實現了電商平臺用戶購買商品的整個業務流。

    這樣拆分以后,系統具有敏捷性、靈活性、可伸縮性等,拆分后有多個高度自治的微服務,那么以什么方式組合微服務呢?

    1. 服務代理模式

    服務代理模式是最簡單的服務組合模式,它根據業務的需求選擇調用后端的某個服務。在返回給使用端之前,代理可以對后端服務的輸出進行加工,也可以直接把后端服務的返回結果返回給使用端。

    服務代理模式的架構如圖1-12所示。

    圖片描述

     

    圖1-12

     

    在筆者工作的微服務化架構平臺下,經常會使用這種模式,典型的案例是做平滑的系統遷移,通常經歷如下4個階段。

    • 在新老系統上雙寫。
    • 遷移雙寫之前的歷史遺留數據。
    • 將讀請求切換到新系統。
    • 下調雙寫邏輯,只寫新系統。

    服務代理模式常常應用到第3步,一般會對讀請求切換設計一個開關,開關打開時查詢新系統,開關關閉時查詢老系統。

    遷移案例中開關的邏輯如圖1-13所示。

    圖片描述

     

    圖1-13

     

    2. 服務聚合模式

    服務聚合模式是最常用的服務組合模式,它根據業務流程處理的需要,以一定的順序調用依賴的多個微服務,對依賴的微服務返回的數據進行組合、加工和轉換,最后以一定的形式返回給使用方。

    這里,每個被依賴的微服務都有自己的緩存和數據庫,聚合服務本身可以有自己的數據存儲,包括緩存和數據庫等,也可以是簡單的聚合,不需要持久化任何數據。

    服務聚合模式的架構如圖1-14所示。

    圖片描述

     

    圖1-14

     

    這里體現了DRY(Don’t Repeat Yourself)原則的設計理念,在設計或者構造應用時,最大限度地重用了現有的實現。假如一塊業務邏輯由三個獨立的邏輯塊組成,每個獨立的邏輯塊可能有多個使用方,則DRY原則推薦將三個獨立的邏輯塊封裝成三個獨立運行的微服務,然后使用本節的服務聚合模式開發聚合服務,將三個獨立的邏輯塊聚合在一起提供給上層組合服務。這樣的設計原則有如下好處。

    • 三個獨立的子服務可以各自獨立開發、敏捷變更和部署。
    • 聚合服務封裝下層的業務處理服務,由三個獨立的子服務完成數據持久化等工作,項目結構清晰明了。
    • 三個獨立的子服務對于其他使用方仍然可以重用。

    考慮到本節開頭的例子,在對微服務進行拆分時,將電商后臺系統大致拆分成訂單、商品、商品目錄、庫存、購物車、交易、支付、發票、物流等微服務,那么電商平臺的前端應用就是后端各個微服務的一個最大的聚合服務,前端應用通過調用商品和商品目錄顯示商品列表,提供給用戶選擇商品的功能,用戶選擇商品后增加商品到購物車,在用戶從購物車結算時,調用交易系統完成交易和支付等。

    電商前臺的聚合模式的案例架構如圖1-15所示。

    圖片描述

     

    圖1-15

     

    另外,聚合服務也可以是一個純后臺服務,通過聚合對使用方輸出組合的服務,例如在上面的電商系統案例中,在用戶選擇結算后,系統調用交易,交易系統會調用庫存系統鎖庫存,然后創建交易訂單,引導用戶去支付,支付成功后扣減庫存,最后通過發票服務開具電子發票。

    電商后臺交易服務的聚合模式架構如圖1-16所示。

    圖片描述

     

    圖1-16

     

    3. 服務串聯模式

    服務串聯模式類似于一個工作流,最前面的服務1負責接收請求和響應使用方,串聯服務后再與服務1交互,隨后服務1與服務2交互,最后,從服務2產生的結果經過服務1和串聯服務逐個處理后返回給使用方,如圖1-17所示。

    圖片描述

     

    圖1-17

     

    服務串聯模式之間的調用通常使用同步的RESTful風格的遠程調用實現,注意,這種模式采用的是同步調用方式,在串聯服務沒有完成并返回之前,所有服務都會阻塞和等待,一個請求會占用一個線程來處理,因此在這種模式下不建議服務的層級太多,如果能用服務聚合模式代替,則優先使用服務聚合模式,而不是使用這種服務串聯模式。

    相對于服務聚合模式,服務串聯模式有一個優點,即串聯鏈路上再增加一個節點時,只要不是在串聯服務的正后面增加,那么串聯服務是無感知的。

    在串聯服務中調用鏈的最后端增加服務無感知的架構如圖1-18所示。

    圖片描述

     

    圖1-18

     

    在上面提及的電商案例中,UI前端應用調用交易,交易調用商品庫存系統鎖定庫存和扣減庫存,使用的就是服務串聯模式。

    服務串聯模式案例的架構如圖1-19所示。

    圖片描述

     

    關于:中科研拓

    深圳市中科研拓科技有限公司專注提供軟件+硬件結合系統解決方案定制開發服務,其中包括:軟件外包、軟件開發、軟件定制、硬件開發、硬件定制、智能硬件開發、物聯網項目等開發外包服務,通過IT技術實現創造客戶和社會的價值,成為優秀的軟件公司,通過客戶需求導向、開放式創新、卓越運營管理等戰略的實施,全面打造公司的核心競爭力。優秀軟件外包公司、軟件開發公司,聯系電話400-0316-532,郵箱sales@zhongkerd.com,網址www.ruige-europe.com


      上一篇   [返回首頁] [打印] [返回上頁]   下一篇
    香蕉97超级碰碰碰免费公开
  • <source id="sqj45"><optgroup id="sqj45"></optgroup></source>
  • <rt id="sqj45"></rt>
    <rt id="sqj45"></rt><rt id="sqj45"></rt>
  • <source id="sqj45"><nav id="sqj45"></nav></source><rt id="sqj45"></rt><rt id="sqj45"></rt><tt id="sqj45"><noscript id="sqj45"></noscript></tt>