一起玩轉微服務(1)——概念

一、什麼是微服務

隨着各行各業公司的快速發展,業務規模的不斷擴大,不可避免的造成原有架構不能夠適應快速的增長和變化。這時,微服務就進入大家的視野,其實在微服務之前,很多的公司已經做過服務化的改造,並且取得了一定的成果,但是對於整體流程的標準化還有一定有差距。那麼,什麼是微服務呢?
準確的說,微服務是一種軟件架構模式,將大型系統或者複雜的應用分割成多個服務的架構,服務之間互相協調、互相配合,為用戶提供最終價值。每個服務都有獨立的生命周期,可以單獨的維護和部署,各個業務模塊之間是松耦合的,比傳統的應用程序更有效地利用計算資源,應用的擴展更加靈活,能夠通過擴展組件來處理功能瓶頸問題。這樣一來,開發人員只需要為額外的組件部署計算資源,而不需要部署一個完整的應用程序的全新迭代。
一個微服務的架構如圖所示,單體應用被拆分成多個微小的服務:

也有人將微服務的開發比喻成搭積木,每個服務都是一個零件,使用這些不同的服務可以搭建出不同的形狀。簡單的說,微服務架構就是把一個大系統按業務功能分解成多個職責單一的小系統,並利用簡單的方法使多個小系統相互協作,組合成一個大系統。
其實這裏蘊含着自古以來的真理,就是分而治之,當一件事情大到不能處理的時候,就使用一定的切分方法,將其變成很多微小的類,然後分門別類的進行處理,以達到最好的效果,最終實現1+1>2的功效。
微服務的優點和缺點(或者說挑戰)一樣明顯。
優點

  • 開發簡單,每個服務完成獨立的功能

  • 技術棧靈活,可以選擇不同的語言完成不同的服務,發揮各種語言的最大優勢

  • 服務獨立無依賴,每個服務都可以單獨部署,一個服務出現問題不會導致整個系統癱瘓

  • 獨立按需擴展,以應對高併發以及大流量

  • 可用性高,當其中一個點出現問題時,能夠及時切換,不影響業務正常運行

  • 複雜應用解耦為小而眾的服務,拆分可以基於一定的原則,將耗時的應用解耦

  • 各服務精而專,也就是我們常說的專人干專事,映射到微服務中就是專服務干專事

  • 服務間通信通過API完成,選擇輕量的API通信

    缺點(挑戰)

  • 多服務運維難度,服務的增加意味着運維的困難,如何有效的管理是一個挑戰

  • 系統部署依賴,當業務複雜是,系統之間的耦合關係高度耦合,如何高效部署是一個挑戰

  • 服務間通信成本,包括網絡延遲,接口不可用性等,保證服務的高可用性是一個挑戰

  • 數據一致性,再各個服務間如何有效的共享數據,確保相應服務的數據需求一致性是一個挑戰

  • 系統集成測試,拆分后,原本需要測試的內容成倍的增加,如何高效的降低測試成本是一個挑戰

  • 重複工作,服務拆分之後,由於信息的不對稱導致的重複性工作,如何有效抽象是一個挑戰

  • 性能監控,原本只需要一個監控的部分,現在需要分開監控,如何快速定位問題是一個挑戰

  • 溝通成本的成倍增加,服務拆分后,各個服務由單獨的人來維護,如何高效的溝通是一個挑戰

二、為什麼微服務

從一般的平台遇到的問題說起,平台的問題包括:

  • 服務配置複雜。基礎服務多,服務的資源配置複雜。傳統方式管理服務複雜。
  • 服務之間調用複雜。檢索服務、用戶中心服務等,服務之間的調用複雜,依賴多。
  • 服務監控難度大。服務比較多,機器部署複雜,服務存活監控、業務是否正常監控尤為重要。
  • 服務化測試問題。服務依賴性比較大,測試一個小的功能,周邊服務也需要啟動。

那麼微服務的架構有什麼優勢,大家為什麼都懷着極高的熱情來應對微服務呢。

1. 區別

首先看一下兩者的區別,單體應用和分佈式應用都有哪些優點和缺點呢,通過下面的表格來做一下分析和對比?

 

 

從上面的表格我們可以看到,分佈式系統雖然有一些優勢,但也存在一些問題。

  • 架構設計變得複雜(尤其是其中的分佈式事務)。
  • 部署單個服務會比較快,但是如果一次部署需要多個服務,部署會變得複雜。
  • 系統的吞吐量會變大,但是響應時間會變長。
  • 運維複雜度會因為服務變多而變得很複雜。
  • 架構複雜導致學習曲線變大。
  • 測試和查錯的複雜度增大。
  • 技術可以很多樣,這會帶來維護和運維的複雜度。
  • 管理分佈式系統中的服務和調度變得困難和複雜。

也就是說,分佈式系統架構的難點在於系統設計,以及管理和運維。

接下來我們就一起來看一下架構的演變過程。

2. 從單體應用說起

下圖是我們非常熟悉的單體應用,或者說是非常傳統的應用架構。
從圖中可以看到,應用通過瀏覽器進行訪問,當訪問到訂單服務的時候,分單服務提供相應的功能,然後去訪問應用的數據層,數據層負責對數據的解析,這是一個極其典型的單體應用結構,這種結構所帶來的問題顯而易見,數據庫存在單點,所有服務都耦合在一個應用中,當其中一個服務出現問題的時候,整個工程都需要重新發布,從而導致整體業務不能提供響應。這種結構在小項目中是沒有什麼問題的,而且操作起來非常靈活,但當業務量爆增的時候,就無法靈活應對了。

 

 

3. 第一步切分

為了應對單體應對無法滿足業務增漲,需要對數據庫進行進一步的切分,以提高擴展性,下圖就是一個切分后的架構圖。

業務之間通過進程間的服務進行相互調用,數據庫之間沒有耦合性,不會存在單點故障。前端只需要調用相應的服務,返回自身需要的數據,然後與用戶進行交互。可以看到,這種方式比傳統的單體應用已經前進了一步,但是數據庫層面仍然存在着問題,根據數據量需要評估是否使用讀寫分離的設計,服務層面也增加了相應的複雜性。前端調用隨着調用接口數量的增加也急需治理。

4. 服務化所帶來的問題

隨着服務的拆分,新的問題應運而生。客戶端如何訪問這些服務?這些服務的調用情況,切分是否合理,安全問題,如果受到攻擊應該如何應對,是否可以使用限流或者降級的方式來及時解決。
應對這些問題,API網關是一個不錯的解決方案。當有新的設備需要調用這些接口時,可以復用原有接口,不需要進行二次開發。接口的維護也會更有條理性,對於訪問次數,安全等問題,都可以在這一層進行解決。

解決了應用前端訪問的問題后,服務之間的相互調用也是一個問題,如果整個系統內部調用關係混亂,就會帶來非常多的不必要的問題。所以約定好服務之間的通信方式是非常有必要的。不管是開源還是公司內部研發,都有非常多的解決方案。最簡單的方式,是通過rpc的調用,傳輸json或者XML,雙方定義好協議格式,通過報文的方式進行數據傳輸。
當多種服務需要互相調用的時候,服務的數量會急劇的增加。服務的治理就成為新的問題。不同的服務的版本問題。如果不能通過一個單獨的註冊地址,像書的目錄一樣來管理整個服務結構,服務的調用就侍显示非常混亂。
一般的分佈式服務,都有一個註冊中心,例如dubbo是基於zookeeper進行的二次開發,自身提供管理控制台,可以對服務進行註冊和查找,Spring Cloud有Eureka,還有etcd,consul等可供選擇。
經過上面的處理,整體上來看應用已經達到了一個非常好的狀態,但是每個應用服務仍然存在着單點問題,當一個服務出現問題的時候,有可能導致連鎖的反應,使用整個系統癱瘓。這時候需要除了監控告警之外的一種容錯機制保障整體服務的可運行性。
通過網關層的反向代理來實現高可用是一個不錯的解決方案,訪問層無需要了解整個體系有多少應用提供,只需要關心服務是否能夠提供服務,並且對必要的接口進行監測,當發現接口無法正常提供服務時,提供相應的告警機制,以微信、短信或者郵件的方式通知相關人及時進行處理。
隨着服務的切分,業務的擴展,數據量的激增也是一個非常大的問題,如果採用傳統的方案來應對,各種關係型數據庫都有瓶頸,把運算量比較大,比較耗資源的運算,跨庫統計查詢的需求。
再下一步隨着數據量的不斷增漲,需要業務和統計分離。
統計一般都是比較耗時的應用,比如計算用戶的留存情況,需要分析一周甚至是更長周期內的用戶數據,如果使用在線的方式分析顯然不太現實,所以,對於大數據量的分析和數據挖掘,需要從業務中抽取數據進行離線分析,然後將分析的結果進行展現。

5. 微服務的可擴展性

針對以上的分析,可以看到,微服務需要具備極強的可擴展性,這些擴展性包含以下幾個方面:
• 性能可擴展:性能無法完全實現線性擴展,但要盡量使用具有併發性和異步性的組件。具備完成通知功能的工作隊列要優於同步連接到數據庫。
• 可用性可擴展:CAP理論表明,分佈式系統無法同時提供一致性、可用性和分區容錯性保證。許多大規模Web應用程序都為了可用性和分區容錯性而犧牲了強一致性,而後者則有賴於最終一致性來保證。
• 維護可擴展:軟件和服務器都需要維護。在使用平台的工具監控和更新應用程序時,要盡可能地自動化。
• 成本可擴展:總成本包括開發、維護和運營支出。在設計一個系統時,要在重用現有組件和完全新開發組件之間進行權衡。現有組件很少能完全滿足需求,但修改現有組件的成本還是可能低於開發一個完全不同的方案。另外,使用符合行業標準的技術使組織更容易聘到專家,而發布獨有的開源方案則可能幫助組織從社區中挖掘人才。

6. 微服務與SOA的區別

面向服務的架構(SOA)是一個組件模型,它將應用程序的不同功能單元(稱為服務)通過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的,它應該獨立於實現服務的硬件平台、操作系統和編程語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。
都是做服務化,那麼微服務與SOA的異同有哪些呢?
相同點:

  • 需要Registry,實現動態的服務註冊發現機制;
  • 需要考慮分佈式下面的事務一致性,CAP原則下,兩段式提交不能保證性能,事務補償機制需要考慮;
  • 同步調用還是異步消息傳遞,如何保證消息可靠性?SOA由ESB來集成所有的消息;
  • 都需要統一的Gateway來匯聚、編排接口,實現統一認證機制,對外提供APP使用的RESTful接口;
  • 同樣的要關注如何再分佈式下定位系統問題,如何做日誌跟蹤,就像我們電信領域做了十幾年的信令跟蹤的功能;

差異點:

  • 是持續集成、持續部署?對於CI、CD(持續集成、持續部署),這本身和敏捷、DevOps是交織在一起的,所以這更傾向於軟件工程的領域而不是微服務技術本身;
  • 使用不同的通訊協議是不是區別?微服務的標杆通訊協議是RESTful,而傳統的SOA一般是SOAP,不過目前來說採用輕量級的RPC框架Dubbo、Thrift、gRPC非常多,在Spring Cloud中也有Feign框架將標準RESTful轉為代碼的API這種仿RPC的行為,這些通訊協議不應該是區分微服務架構和SOA的核心差別;
  • 是流行的基於容器框架還是虛擬機為主?Docker和虛擬機還是物理機都是架構實現的一種方式,不是核心區別;

SOA和微服務的一個主要不同點就是自動化程度上的不同。大部分的SOA實現只達到服務級別的抽象,而微服務走的更遠,它達到了對實現和運行環境的抽象級別。
而在一個規範的微服務中,每個微服務應該被構建成胖jar(fat Jar)其中內置了所有的依賴,然後作為一個單獨的java進程存在。

三、常見的微服務組件

既然談到了微服務架構,就說一下通用的微服務都包括哪些組件:

  • 服務註冊

服務註冊是一個記錄當前可用的微服務實例的網絡信息數據庫,是服務發現機制的主要核心,服務註冊表查詢api、管理api,使用查詢api獲得可用服務的實例,使用管理api實現註冊、註銷。

  • 服務發現

服務調用方從服務註冊中心找到自己需要調用的服務的地址。可以選擇客戶端服務發現,也可以選擇服務端服務發現。

  • 負載均衡

服務提供方一般以多實例的形式提供服務,負載均衡功能能夠讓服務調用方連接到合適的服務節點。並且,節點選擇的工作對服務調用方來說是透明的。可以選擇服務端的負載均衡也可以選擇客戶端的負載均衡。

  • 服務網關

服務網關是服務調用的唯一入口,可以在這個組件是實現用戶鑒權、動態路由、灰度發布、A/B測試、負載限流等功能。根據公司流量規模的大小網關可以是一個,也可以是多個。

  • 配置中心

將本地化的配置信息(properties, XML, yaml等)註冊到配置中心,實現程序包在開發、測試、生產環境的無差別性,方便程序包的遷移。配置部分可以單獨使用高可用的分佈式配置中心,確保一個配置服務出現問題是,其它服務也能夠提供配置服務。

  • API管理

以方便的形式編寫及更新API文檔,並以方便的形式供調用者查看和測試。通常需要加入版本控制的概念,以確保服務的不同版本在升級過程中都能夠提供服務。

  • 集成框架

微服務組件都以職責單一的程序包對外提供服務,集成框架以配置的形式將所有微服務組件集成到統一的界面框架下,讓用戶能夠在統一的界面中使用系統。

  • 分佈式事務

對於重要的業務,需要通過分佈式事務技術(TCC、高可用消息服務、最大努力通知)保證數據的一致性。根據業務的不同適當的需要犧牲一些數據的一致性要求,確保數據的最終一致性。

  • 調用鏈

記錄完成一個業務邏輯時調用到的微服務,並將這種串行或并行的調用關係展示出來。在系統出錯時,可以方便地找到出錯點。同時統計各個服務的調用次數,確保比較熱的服務能夠分配更多的資源。

  • 支撐平台

系統微服務化后,系統變得更加碎片化,系統的部署、運維、監控等都比單體架構更加複雜,那麼,就需要將大部分的工作自動化。現在,可以通過Docker等工具來中和這些微服務架構帶來的弊端。 例如持續集成、藍綠髮布、健康檢查、性能健康等等。可以這麼說,如果沒有合適的支撐平台或工具,就不要使用微服務架構。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※教你寫出一流的銷售文案?

※廣告預算用在刀口上,台北網頁設計公司幫您達到更多曝光效益

※回頭車貨運收費標準

※別再煩惱如何寫文案,掌握八大原則!

※超省錢租車方案

※產品缺大量曝光嗎?你需要的是一流包裝設計!