NO IMAGE
1 Star2 Stars3 Stars4 Stars5 Stars 給文章打分!
Loading...

摘要: 阿里巴巴前架構師對於微服務毫無保留的分享,360 度無死角剖析微服務

微服務是近年來備受關注的話題,它的出現讓我們想起了十年前的 SOA(Service-Oriented Architecture,面向服務架構),但它比傳統的 SOA 更容易理解,也更容易實踐,它將“面向服務”的思想做得更加徹底。

尤其是當國外的一些知名技術公司成功實踐了微服務以後,這股熱潮就吹遍了國內的大街小巷,我們也看到很多的專案使用了微服務,但實際上依然有不少朋友對於微服務有著不少疑惑。

因此本篇文章,會介紹與微服務架構相關的一些基礎概念、適用場景以及如何解決在實踐中遇到的問題等內容。

一、與微服務相關的一些基本概念

我以前做過微服務,基本框架是 Spring MVC,微服務之間和微服務與平臺之間的訪問是通過在 Zookeeper 上的 Dubbo 通訊的,請問這算是微服務嗎?

其實微服務架構的範圍是相當廣的,這些我認為只是微服務架構的一部分。稍後我也出一篇文章,將上週去 QCon 分享的微服務架構,給大家再次做一個介紹。

如何更好理解【微服務】這個“微”字。從設計之初,開發,部署,運維,監控,等有什麼地方(基於你的過往歷程)需要關注的?

我認為「微」並非它的體積足夠小,而是它的責任足夠單一,很多人誤解了「微」的真實含義,認為服務拆分得足夠小就是微服務了,其實並非這樣。此外,「微」還有“微不足道”的意思,也就是說,某個服務出現故障,它不會影響整個系統。

聽說微服務是個很大的概念,Dubbo 只是實現了其中一小部分,請問完善的微服務架構是什麼樣的?Spring Cloud 是否算是完善的微服務?

微服務架構的範圍比較大,Dubbo 和 Spring Cloud 都只是解決了微服務的一部分問題,並未完全覆蓋。稍後我也出一篇文章,將上週去 QCon 分享的微服務架構,給大家再次做一個介紹。

如果分散式服務本來拆分的顆粒度就比較細,每一個模組都是獨立的服務,可不可就理解為相當於微服務?

微服務並非細粒度服務的組合,也就是說,粒度要細到什麼程度,這取決於對業務功能的把控能力。此外,微服務是一種架構思想,包括看得見的微服務,還包括看不見的基礎設施和自動化技術作為支撐。

請問微服務的核心繫統是什麼?是微服務的發現和組織嗎?每個微服務很好做,如何把他們組合起來,有沒有現成的系統可以參考?

  1. 我認為微服務的核心是:服務註冊中心(Service Registry)與服務閘道器(Service Gateway),它們配合完成服務註冊與服務發現。
  2. 將服務組合起來也成為“服務編排”,有多重做法,可以在服務閘道器中進行編排,也可以通過中間服務進行編排,我更傾向於後者,這樣確保服務閘道器不包含任何業務,更加輕量級。

微服務比普通架構需要多做那些工作?OpenStack 的架構設計屬於什麼型別?微服務是不是需要更多的執行資源?

  1. 微服務架構比傳統架構更加依賴於對自動化運維的支援。
  2. OpenStack 是一款雲端計算平臺,為雲端計算的 IaaS 層提供瞭解決方案。
  3. 在微服務架構中,需要相關的基礎設施與很多獨立執行的服務,我認為相比較傳統架構而言,所消耗的硬體資源較高一些。但從現在來看,硬體資源的成本已經非常低了。

SOA、WebService、RESTful 這些概念有什麼本質的區別。開發者平常使用的那些 AJAX、HTTP 介面(含 session 狀態的)算得上 RESTful 介面嗎?

  1. RESTful 是一種架構風格,SOA 是一種架構思想,可以認為 RESTful 有助於 SOA 的落地化。
  2. RESTful 一般應用在 HTTP 協議上,在前後端分離架構中,前端通過 AJAX 技術傳送 RESTful HTTP 請求到後端,獲取後端 JSON 資料,並進行介面渲染。同樣,RESTful 也用於微服務架構中,每個服務對外暴露 REST API 作為通訊介面。

從什麼角度能區分出或者劃分微服務和 RPC 分散式之間的區別或者關係?

微服務是一種應用架構模式,而 RPC 是一種遠端呼叫方式,它們是不一樣的概念;而在微服務中會出現服務之間的呼叫,為了確保效能,我們一般採用 RPC 來呼叫。

是否有接觸過“領域驅動的分析與設計方法(DDD)”,你是如何理解“DDD”與“微服務”之間關係的?

DDD 是基於領域物件的設計思想,微服務是基於服務的業務架構,DDD 與微服務可相輔相成。

公司現在用的是 Dubbo 框架,這是微服務框架還是 SOA?記得有些部落格說微服務去中心化,那這個中心是不是就是 Dubbo 裡的註冊中心?

  1. Dubbo 從本質上來講屬於微服務框架,它有服務註冊與發現,也有服務之間不同協議的通訊,以及服務呼叫的監控。而傳統的 SOA 更傾向於使用 ESB 這類匯流排的方式來實現服務的註冊與通訊,可以把 ESB 看成是一箇中心,因此相對微服務而言,傳統 SOA 更加重量級一些。我認為微服務是 SOA 的一種輕量級實現,它的本質還是 SOA。
  2. 所謂去中心化,實際上是確保不因為中心而導致單點故障,如果能解決這個問題,有中心又如何呢?因此,我認為不要一味地去中心化,要合理地去中心化才是正道。

二、什麼場景下選擇微服務?

微服務架構我覺得比較適合新專案,如果用於已有專案那相當於要重構,或者逐步拆分做微服務架構?是不是這樣?還是有什麼更好的方法?

  1. 對於業務流程較為複雜,且業務會變得逐漸複雜的專案,可以考慮使用微服務架構。
  2. 對於已有專案而言,可考慮逐步進行微服務化,也可考慮在新業務中使用微服務架構。

我想利用微服務實現系統的模組化,便於公共模組複用和水平擴充套件,但目前的系統規模其實都很小,這種情況是不是不適合使用微服務?

我認為微服務架構用於業務較複雜或目前業務簡單但將來有可能變得複雜的架構,建議視具體情況來確定合理的架構,不要為了微服務而去微服務。

高併發低延遲的系統能使用微服務嗎?

我認為高併發場景不太適合使用微服務,因為微服務會帶來一些呼叫鏈的開銷,高併發場景需要做到儘可能地的延遲以及更高效的通訊。

微服務與 SOA 到底有什麼區別,各自的應用場景是什麼?到底在什麼樣的情況才適合使用微服務架構?

我認為微服務是 SOA 的輕量級解決方案,微服務的本質還是 SOA,只是更加容易落地而已。

我認為在以下幾種情況下,可考慮使用微服務架構:

  • 應用變得越來越大時
  • 專案存在多種開發語言時
  • 感覺到經典架構模式太重時
  • 修改了一個 bug 需要平滑升級時
  • 想對系統進行細粒度監控時

當然還有其他使用場景,但微服務不是萬靈丹,不能適用於所有場景。而且微服務對運維是有一定的要求的,尤其是自動化運維。即便業務目前比較簡單,但將來會變得複雜,也建議使用微服務架構。

三、如何考量微服務的技術選型?

微服務的開源技術選型能介紹幾種嗎?Spring Cloud 如何解決跨語言的問題呢?

比較知名的微服務開源技術選型莫過於 Spring Cloud,它對 Netflix 提供的相關元件做了一定的封裝,讓開發者更容易上手。當然,我更加希望本書所先介紹的開源技術選型會被更多人接受與應用。

這次你的這本關於輕量級微服務,我有幾個問題,你的這本書裡關於微服務的技術選型是怎麼考量的?書中提到了 Spring Boot,你對於 Spring 的這個技術怎麼看?現在微信小程式比較流行,微服務會成為小程式的技術首選嗎?

  1. 這本書中關於微服務的技術選型問題,我做了大量的思考並實踐,所選擇的方案均為開源,且非常輕量級,目的是幫助大家能夠快速搭建這款輕量級微服務架構。
  2. 雖然這本書講到的微服務開發框架是 Spring Boot,用過的人都知道它有明顯的優勢,當然也有明顯的劣勢,畢竟底層還是基於 Spring,而 Spring 從當初的輕量級似乎變得越來越重,我希望有更好的輕量級框架可以出現,所以當初寫了一款 Smart 框架以及《架構探險》第一本書,目的只是拋磚引玉,希望有更多的朋友都能投身到國內開源行業中,創造更優秀的開源專案。
  3. 我非常看好微信小程式的未來,但微服務是否成為小程式的技術首選,我不太敢下次評論,咱們一起靜觀其變吧。

微服務框架是在 SOA 的基礎上提出的嗎?在技術選型要注意哪些點,用 Spring Cloud 還是 Spring Boot?怎樣做到輕量級,有哪些參考?

  1. 我認為微服務是傳統 SOA 的輕量級解決方案,它讓 SOA 更加容易落地。
  2. 在微服務技術選型方面,我建議竟可能地輕量級,做到“進可攻退可守”,至於 Spring Cloud 還是其他框架,完全取決於我們對技術本身的理解以及對業務的把控能力,技術也業務需要相互結合才能產生價值。
  3. 希望這本書中所設計的輕量級開源方案,會幫助您更快地搭建微服務架構。

四、實施微服務的開發成本有多高?

該在多大規模的專案中使用微服務比較合適?微服務會增加架構複雜度嗎?帶來的收益是否可以抵消?

  1. 我認為對於業務比較清晰的專案均可使用微服務架構,並非需要具備多大規模。
  2. 微服務架構會帶來系統的複雜度(成本),但必然會帶來一些收益,至於成本和收益是否低效,這取決於我們對微服務與業務的理解與把控能力。

實施微服務後,對於開發成本是不是更高了?

我認為實施微服務並未提高開發成本,而是提高運維成本,一個好的微服務架構離不開運維方面的支援。本書下冊將針對運維方面將以描述,敬請期待。

微服務一般都要用到 Docker,這樣對研發人員和運維人員技術就要求更高了,如何快速有效實施微服務架構?

實施微服務必然會提高運維方面的成本,但我認為這是有價值的,尤其是自動化運維技術,也需要培養開發人員的運維思想。

微服務挺多人說玩不起,是不是相對來說實施成本挺高的?

玩不起包括兩層含義:一是認為成本較高;二是擔心有風險(怕玩掛了)。

五、微服務中的事務

如何簡單有效的實現事務?

可使用訊息佇列的方式,實現服務之間的事務控制。服務呼叫完畢,寫入訊息佇列,通過訊息驅動的方式呼叫其他服務。

服務間是不是應該避免相互間呼叫, 由 API Gateway 來組織各個服務?

沒錯,應該避免服務間的呼叫,而使用服務閘道器作為呼叫入口,但我不建議在服務閘道器處組織服務呼叫,而是通過一箇中間服務來編排,或使用訊息驅動方式來完成。

服務與服務之間的事務怎麼做?

在微服務架構中,建議儘量避免服務之間的呼叫,因此服務粒度的切分是至關重要的;服務間的呼叫會產生分散式事務問題,建議採用“最終一致性”方法來確保分散式事務,業界有兩種常用做法:CQRS 和 Event Sourcing。

目前,微服務的事務是大家最關心的,微服務的分散式事務問題如何解決?請問,現在業界有沒有開源的解決微服務事務的專案。

微服務的事務控制比較複雜,我們需要做到儘可能避免服務之間的呼叫,這取決於我們對微服務切分的粒度控制。

微服務分散式事務一般藉助訊息驅動與日誌追蹤的方式來解決,以達成事務的“最終一致性”,業界有 CQRS 與 Event Sourcing 來解決微服務的事務問題,希望對您有幫助。

如何使用事務補償模式解決分散式事務問題?

事務補償機制說簡單點就是,在應用程式中通過程式碼的方式做到資料的還原。一般情況下,我們需藉助訊息佇列與日誌追蹤等方式來實現。

微服務在事務控制方面,容錯方面有什麼較好的實踐方式?

  1. 微服務的事務控制本質上是分散式事務控制,建議使用“最終一致性”來確保。
  2. 在容錯方面,需要有基礎設施平臺的支撐,比如服務閘道器的熔斷機制。

六、微服務的業務該如何拆分?

微服務業務拆分有沒有什麼原則要點?

微服務業務拆分可按整體業務元件來拆分,也可按單一業務功能來切分。建議切分步驟從粗到細,逐步細化,否則開始就過細,導致依賴性太高,增加複雜度。

一個大服務怎麼拆最好,依據是什麼,微服務拆分如何控制合適的粒度?另外現在的微服務的教程好像都是針對 Java 的,比如 Spring Boot,其他語言有沒有成熟的體系?

建議從整個業務流程來分析,首先抽象出公共服務,然後採用大粒度的方式來切分,最後逐步細化切分粒度,微服務切分粒度取決於我們對業務的理解與把控能力。其他開發語言也有類似於 Spring Boot 的微服務開發框架,比如 .NET 的 Nancy。

怎樣來控制微服務的粒度?就是有沒有什麼樣的原則和最佳實踐來判斷一個功能(介面)是應該屬於 A 服務還是應該屬於 B 服務。

微服務的粒度控制取決於我們對業務的理解與把控能力,一切所謂的原則都是不靠譜的。

微服務目前對於各個功能拆分是不是有些太細?

我認為微服務的切分粒度沒有必要太細,適合業務發展並能提高開發效率的架構才是好架構。

微服務拆分如果粒度太細,會不會導致維護成本增加?響應時間增加?事務控制如何實現?

  1. 微服務粒度問題取決於我們對業務的理解與把控能力,無需太細。
  2. 可借用訊息佇列和日誌追蹤進行事務控制,也可使用 CQRS 或 Event Sourcing 解決方案。

如何控制粒度在方法級別的介面的呼叫許可權?

此處所描述的“介面”是否理解為服務的 API 介面呢?API 呼叫的許可權控制可在微服務架構中的服務閘道器(Service Gateway)處加以控制。

單體架構拆分成微服務後,每個服務能獨立佈署,也便於橫向擴充套件,但也面臨如下的問題:

1. 微服務拆分粒度的原則是?2. 微服務的服務治理?

  1. 服務是根據業務功能來拆分的,拆分服務時需降低彼此之間的耦合性,儘可能一個服務只做一件事情,即“單一職責原則”。
  2. 服務治理問題所涉及的問題較多,將在這本書下冊中加以描述,敬請期待,也歡迎進一步探討。

服務拆分之後就會出現,微服務呼叫微服務的情況,導致效率很慢,介面的 QPS 很低,怎麼解決?

我的建議是,儘可能避免服務之間的呼叫,不妨使用訊息佇列的方式來降低服務之間的耦合,當然必要的直接呼叫可使用 RPC 技術,它具備優秀的效能,可確保較高的 QPS。

七、使用微服務遇到的問題

我在公司實現分散式的過程中遇到了 3 個問題,如您有時間請您給些思路:

  1. 分散式事務:當前採用訊息佇列,佇列的消費者使用 Redis 做分散式鎖來實現冪等消費,不知道這種方式存在什麼隱患?或者有沒有更好的方式?
  2. 日誌聚合:目前想要做一個日誌聚合功能,暫時考慮還是使用訊息佇列處理,不知道有什麼業界成熟的方式?
  3. 方法呼叫次數統計,暫時我們想使用 AOP 訊息佇列 strom 的方式來實現方法呼叫與耗時統計,不知道業界成熟的方式是什麼?
  1. 訊息佇列可用於分散式事務控制,這項技術已經在業界被證實是可用的。此外,還有 CQRS 與 Event Sourcing 技術也可以嘗試一下。
  2. 日誌聚合可使用業界流行的 ELK,即 Elasticsearch Logstash Kibana 來實現,L 用於收集日誌,E 用於儲存日誌,K 用於展現日誌。
  3. 方法呼叫次數統計,不建議放在服務內部通過 AOP 來控制,建議在微服務架構的服務閘道器(Service Gateway)加以控制。

我覺得介面呼叫次數統計,也可以結合 flume Mq strom 做實時統計,這樣可以根據日誌資訊獲取呼叫次數額外的東西,如呼叫者所在的地區等。

看具體要求是怎樣的,如果只是簡單記錄 API 呼叫次數,可在服務閘道器處增加此功能,將結果記錄到 MQ 中。

許可權分訪問許可權與資源許可權。想請教下資源許可權在微服務中怎麼做?比如我有個商品服務跟優惠服務,想要控制某個使用者只能查詢商品和建立優惠券,是每個微服務都有獨自的許可權功能,還是有個許可權服務統一下發和調配各個微服務的許可權?或者貴公司在微服務中是怎麼做許可權這塊的?

  1. 訪問許可權建議在服務閘道器處加以控制。
  2. 資源許可權建議抽象出一個單獨的中介軟體加以控制。

微服務下有不同的儲存介質,對於跨資料庫的分頁查詢有什麼好的辦法嗎?

使用微服務架構可以做到:

  1. 一個服務使用一個資料庫(單庫)
  2. 一個服務使用多個資料庫(多庫)

對於“多庫”而言,可在服務內部聚合資料,也可使用資料庫中介軟體來解決此問題。

SOA 與 MSA(微服務架構)區別在於系統一體化與服務元件分散化(“微化”)的區別。服務元件微化可以讓關注點進一步縮小範圍,服務之間的規範或者實現的關聯性進一步降低(https://my.oschina.net/waylau/blog/617857)。但同時引入的一些問題:

  • 服務治理;
  • 服務的版本更新;
  • 服務之間的許可權是如何來做控制的;
  • 服務如何來劃分顆粒度。

請教下,貴公司在實踐過程中,有無遇到過上述問題,是如何解決的?

您說的非常好,這些問題可能都是每一位微服務實踐者所要面對的問題,考驗我們的是,如何選擇合理的技術來解決此類問題。比如,服務治理可通過 Kubernetes、Mesos、Docker Swarm 等技術來實現,服務版本可通過 ZooKeeper、Etcd、Consul 等技術來控制,服務許可權可自行實現許可權中介軟體來解決,服務顆粒度劃分考驗我們的是對業務的深度理解(這才是最為關鍵的)。總之,有具體技術能解決的可能都不是問題,可能是問題的往往是我們對自身業務的理解與把控能力。

1. 微服務對網路、資料庫連線、快取伺服器等資源的影響;2. 微服務是否需要多版本服務共存?

  1. 微服務對網路、資料庫、快取方面較傳統架構而言,沒有過高的要求,但對運維方面要求較高。
  2. 微服務需要考慮服務多版本問題,尤其是服務升級時,需要做到平滑,對整體系統沒有任何影響。

針對微服務的全域性 ID 生成策略。不知道黃老師有沒有什麼好的建議?

  1. 看了很多的分散式 ID 生成策略。提到很多 ID 趨勢遞增的策略,這個有什麼用?
  2. 為什麼要讓 ID 具體有順序功能?如何保證順序?

不知道黃老師在實際專案中用了什麼策略,希望能分享一下。

實際上 ID 生成策略並非是微服務架構所涵蓋的範疇。我認為比較好的 ID 生成策略需要結合您所面臨的實際需求,一般應用場景下,可通過 Redis 來生成並管理 ID,它具備較高的併發能力,且能確保分散式一致性。

有一個關於測試的問題想請教。是不是微服務更偏重敏捷模式呢?對於測試而言更容易開展工作?自動化測試覆蓋率更高?

  1. 我認為微服務與敏捷沒有必然的關係,微服務講究的是將“化整為零”,敏捷倡導的是“小步快跑”,但兩者可以有效地結合起來加以應用。
  2. 較傳統架構而言,微服務的測試複雜度和覆蓋面將更為廣泛,不僅需要對每個服務進行測試,而且需要對整體應用加以驗證。因此,我們需要使用自動化測試技術來提高測試效率。

微服務是否就一定是程序級別的?在同一個程序內實現微服務可行嗎?如果一個服務就一個程序,這樣是不是會耗費大量系統資源?

  1. 微服務講究的是服務可以獨立開發與部署,如果在程序內進行微服務,將帶來很高的複雜度,就像當年的 OSGi 那樣,理念非常好,但實踐起來卻困難重重。
  2. 一個服務一個程序,這樣讓服務的隔離性更加徹底,配合 Docker 容器技術,可以更加高效低利用伺服器硬體與網路資源。

微服務目前有什麼成熟的一整套開源方案嗎?包括測試、版本控制,釋出流程,程式碼錯誤回滾?

業界也有其他優秀的微服務開源方案,例如 Java 領域的 Netflix 與 Spring Cloud。當然,我更希望本書所提到的開源方案,可以被更多人接受並應用。

微服務怎麼解決呼叫鏈過長導致的除錯或異常追蹤過難的問題呢?

呼叫鏈追蹤是微服務落地的一個挑戰,我們一般通過追蹤平臺來解決,推薦使用開源的 Zipkin。

微服務一般是 JSON 格式呼叫,與其他呼叫方式有什麼區別麼?

我認為 JSON 格式只是 REST API 返回值的一種,微服務並非侷限於 REST API 通訊。

樓主推薦使用 Spring Cloud 構建微服務嗎?

Spring Cloud 對微服務架構提供了很好的技術封裝,建議對其充分了解的情況下使用。

微服務都是通過 HTTP 方式對外提供?

微服務對外的介面不一定侷限於 HTTP 或 HTTPS,也可以是 TCP,需要根據具體情況而定。

使用 REST 通訊其實挺麻煩的,還需要封裝一層呼叫方法,不知道有沒有類似的問題?

REST API 是一個種輕量級通訊方式,也有助於跨平臺呼叫,我們的做法往往是提供一個客戶端 SDK,目前已有大量的技術來快速實現 REST SDK,比如 Spring RestTemplate,或 Retrofit。

八、微服務與容器的結合會碰撞出怎樣的問題?

目前很火的容器技術和微服務如何結合?

由於微服務架構是可以做到服務的異構性的,也就是說,我們可根據實際情況,選擇最適合的開發語言來實現服務。容器技術具備隔離性,可將異構開發語言的服務進行統一封裝,並有助於自動化部署,以及持續交付。

Docker 容器技術的出現,為微服務提供了更便利的條件,比如更小的部署單元,每個服務可以通過類似 Node.js 或 Spring Boot 的技術跑在自己的程序中。可能在幾十臺計算機中執行成千上萬個 Docker 容器,這麼多 Docker 容器怎麼來有效管理?出錯瞭如何排查呢?

實際上您提到的是服務治理問題,目前有大量的技術可以做到,比如:Google Kubernetes、Apache Mesos、Docker Swarm 等。

聽說使用 Docker 執行 Java 一點優勢都沒有,微服務架構大量啟動 Docker 叢集,記憶體利用率很低,雖然 Java 執行效率很高。您怎麼看?

Java 應用經 Docker 化後,最明顯的問題是 Docker 映象體積較大,啟動 Docker 容器所佔用的系統資源較高。建議根據實際業務場景,選擇最為合適的開發語言實現對應的微服務,而並非侷限於 Java 應用之上。

如果不使用 Docker,會給微服務帶來哪些不便?

如果沒有 Docker 這類容器技術,可能會降低微服務的部署與交付能力。

Spring Boot 與 Docker 整合, 在大資料使用方面多不多?

Spring Boot 與 Docker 整合,在許多領域都有應用,當然不排除大資料方面。

相關文章

程式語言 最新文章