Chinaunix
標(biāo)題: 【好書推薦】實(shí)踐“微服務(wù)”,你“玩得起”嗎?(獲獎(jiǎng)名單已公布) [打印本頁]
作者: demilich 時(shí)間: 2016-10-19 14:54
贊,好活動(dòng)要頂?shù)?...
作者: 王楠w_n 時(shí)間: 2016-10-19 15:39
開個(gè)頭吧,之前看過一篇文章,關(guān)于微服務(wù)的。
作者: 王楠w_n 時(shí)間: 2016-10-19 15:40
難以對(duì)比 SOA 和微服務(wù)的原因在于,它們的定義留有很大的解釋空間。如果您僅擁有這兩個(gè)概念的表面知識(shí),可能會(huì)覺得它們很相似。一些關(guān)鍵方面(比如組件化、解耦和標(biāo)準(zhǔn)化通信協(xié)議)描述了最近幾十年的大部分軟件舉措,所以我們需要進(jìn)行更深入地分析。
考慮以下簡(jiǎn)單定義:
如下圖演示了這些定義。SOA 似乎擁有 企業(yè)范圍,應(yīng)用程序在該范圍內(nèi)彼此通信。SOA 通過應(yīng)用程序之間的標(biāo)準(zhǔn)化接口來公開服務(wù)。微服務(wù)架構(gòu)似乎擁有 應(yīng)用程序范圍,僅關(guān)注一個(gè)應(yīng)用程序內(nèi)的結(jié)構(gòu)和組件。
QQ截圖20161019154014.jpg (26.46 KB, 下載次數(shù): 114)
下載附件
2016-10-19 15:40 上傳
這些 SOA 和微服務(wù)的定義過于簡(jiǎn)單。事實(shí)上,它們之間的關(guān)系要復(fù)雜得多。
作者: action08 時(shí)間: 2016-10-19 21:29
什么叫微服務(wù),
從代碼的角度講,就是一個(gè)(集合)小而美的函數(shù)模塊
作者: sjf0115 時(shí)間: 2016-10-19 21:53
好話題 頂一下啊
作者: Fl_wolf 時(shí)間: 2016-10-20 10:45
占樓!占樓!占樓!
作者: jasonhsp 時(shí)間: 2016-10-20 10:55
權(quán)限問題的確是個(gè)要討論的問題,服務(wù)治理服務(wù)管控等等。我個(gè)人覺得,服務(wù)本身應(yīng)該沒有權(quán)限限制,權(quán)限限制應(yīng)該交給api網(wǎng)關(guān)來做,建議這類話題做期微學(xué)堂吧
作者: pengjs991111 時(shí)間: 2016-10-20 10:57
個(gè)人感覺拆分顆粒度自己可以把控,就像系統(tǒng)拆分一樣。分布式事務(wù)可以使用消息隊(duì)列解決。服務(wù)治理通常就是所說的網(wǎng)關(guān)統(tǒng)一管理處理。也不太了解沒有實(shí)踐
作者: cdfoxman 時(shí)間: 2016-10-20 10:59
請(qǐng)問看了這書后能達(dá)到什么程度,上下冊(cè)是什么關(guān)系,書中有沒有成熟的案例
作者: 王楠w_n 時(shí)間: 2016-10-20 11:00
回復(fù) 10# cdfoxman
上冊(cè)介紹基本java框架,下冊(cè)介紹微服務(wù)。下冊(cè)沒看應(yīng)該有案例
作者: supergirlxu 時(shí)間: 2016-10-20 11:01
SOA 與 MSA(微服務(wù)架構(gòu))區(qū)別在于系統(tǒng)一體化與服務(wù)組件分散化(“微化”)的區(qū)別。服務(wù)組件微化可以讓關(guān)注點(diǎn)進(jìn)一步縮小范圍,服務(wù)之間的規(guī)范或者實(shí)現(xiàn)的關(guān)聯(lián)性進(jìn)一步降低(https://my.oschina.net/waylau/blog/617857
)。但同時(shí)引入的一些問題:
* 服務(wù)治理;
* 服務(wù)的版本更新;
* 服務(wù)之間的權(quán)限是如何來做控制的;
* 服務(wù)如何來劃分顆粒度。
請(qǐng)教下,貴公司在實(shí)踐過程中,有無遇到過上述問題,是如何解決的?
作者: xiaojun63 時(shí)間: 2016-10-20 11:03
微服務(wù),分開來就是微、服務(wù)。體現(xiàn)了粒子程度更小,構(gòu)建業(yè)務(wù)流程更靈活。就好比restful就行的原理一樣
作者: jieforest 時(shí)間: 2016-10-20 17:17
1. 你了解微服務(wù)嗎?SOA和微服務(wù)有何差異?
微服務(wù)架構(gòu)被認(rèn)為是目前最適合開發(fā)高可擴(kuò)展性應(yīng)用的架構(gòu)風(fēng)格,微服務(wù)架構(gòu)致力于解決大型、復(fù)雜的應(yīng)用的各種問題。它是一種基于服務(wù)的架構(gòu),這些服務(wù)可獨(dú)立部署,作為基礎(chǔ)的組件。微服務(wù)架構(gòu)在整個(gè)開發(fā)、測(cè)試等開發(fā)周期中提供了更好的控制,但它在服務(wù)分類方面有一些限制。微服務(wù)架構(gòu)還使用了服務(wù)間的通信協(xié)議(REST、JSON等)。
SOA架構(gòu)可以由多種定義方式,這是因?yàn)镾OA架構(gòu)風(fēng)格一直在不斷地發(fā)展演進(jìn)。它為企業(yè)級(jí)軟件的復(fù)雜組合帶來了秩序——通過把它們表示為服務(wù)的集合。SOA還使用了服務(wù)通信協(xié)議,SOA可以被認(rèn)為是微服務(wù)的超集。
SOA架構(gòu)依賴于共享數(shù)據(jù)模型。此模型在大量數(shù)據(jù)結(jié)構(gòu)和模型和分層之間有復(fù)雜的關(guān)系。SOA的分層組織結(jié)構(gòu)有利于服務(wù)協(xié)調(diào)和消息通信功能。
SOA是基于共享數(shù)據(jù)模型的,因此,可以預(yù)估它在服務(wù)和其它系統(tǒng)組件之間存在數(shù)據(jù)緊耦合的現(xiàn)象。這使得它難以做改變。一些附帶的重測(cè)是必要的,以確保改變不影響現(xiàn)有的任何服務(wù)。
微服務(wù)架構(gòu)存在上下文邊界的概念,這使得它在單個(gè)服務(wù)和數(shù)據(jù)之間存在關(guān)聯(lián)。
SOA架構(gòu)的多層模型以中央的消息通信中間件層為主要特征。而對(duì)于微服務(wù)架構(gòu),在組成應(yīng)用的各種服務(wù)之上就存在一個(gè)非協(xié)調(diào)的API層。
通過一個(gè)中央集線控制器,SOA維護(hù)了服務(wù)執(zhí)行的順序。而微服務(wù)使用了服務(wù)間的通信協(xié)議來維護(hù)服務(wù)執(zhí)行的順序。
SOA架構(gòu)致力于解決在復(fù)雜的企業(yè)系統(tǒng)中的異構(gòu)應(yīng)用,促成跨應(yīng)用和功能的共享服務(wù)。而微服務(wù)架構(gòu)是面向基于Web的、更小的、不太復(fù)雜的應(yīng)用程序的最佳架構(gòu)方式,這些應(yīng)用程序不需要明確的服務(wù)協(xié)調(diào)。
2. 到底在什么樣的情況才適合使用微服務(wù)架構(gòu)?
如果遇到了以下的情況,應(yīng)該采用微服務(wù)架構(gòu):
1)系統(tǒng)越來越龐大,新功能開發(fā)或修改功能變得越來越耗時(shí)
2)系統(tǒng)的復(fù)雜度極高,模塊間緊耦合嚴(yán)重,整體擴(kuò)展性差
3)系統(tǒng)性能不高,通過擴(kuò)展也難以提升性能
4)系統(tǒng)的可維護(hù)性越來越差
3. 服務(wù)與服務(wù)之間的事務(wù)怎么做?接口的調(diào)用權(quán)限如何控制,粒度在方法級(jí)別的?
我通常是這么解決的。在基礎(chǔ)服務(wù)的上層封裝面向事務(wù)處理的服務(wù)(這里我稱為A服務(wù)),A服務(wù)依賴于下層的多個(gè)基礎(chǔ)服務(wù),一個(gè)A服務(wù)就是一個(gè)完整的事務(wù)處理過程,它內(nèi)部是調(diào)用下層的多個(gè)服務(wù)共同完成功能的。如果A服務(wù)執(zhí)行失敗,則做相應(yīng)的回退等處理;如果A服務(wù)執(zhí)行成功,那么繼續(xù)。
微服務(wù)架構(gòu)的服務(wù)之間的調(diào)用,可以通過REST接口,還可以用RPC、消息通信等方式。以REST接口為例,服務(wù)間通過內(nèi)網(wǎng)或?qū)>方式進(jìn)行調(diào)用,以保證速度。對(duì)外則使用API網(wǎng)關(guān)來做訪問控制。
4. 為什么有人說“玩不起”?較比普通架構(gòu)需要多做那些工作?
微服務(wù)架構(gòu)要設(shè)計(jì)好并不容易。我的建議是根據(jù)具體的需求具體分析,通用的原則也不少。
作者: chenyx 時(shí)間: 2016-10-25 08:38
還沒接觸到微服務(wù)呢,搬個(gè)板凳坐等討論
作者: heguangwu 時(shí)間: 2016-10-25 13:45
本帖最后由 heguangwu 于 2016-11-11 10:21 編輯
1、你了解微服務(wù)嗎?SOA和微服務(wù)有何差異?
微服務(wù)實(shí)質(zhì)上就是SOA的一種實(shí)現(xiàn)方式,SOA是一個(gè)失敗的項(xiàng)目,所以微服務(wù)不想和他扯上關(guān)系
微服務(wù)是一種基于服務(wù)(Service)的架構(gòu),這些Service可獨(dú)立測(cè)試、部署、升級(jí)。微服務(wù)架構(gòu)為整個(gè)開發(fā)周期中提供了靈活的控制
2、到底在什么樣的情況才適合使用微服務(wù)架構(gòu)?
業(yè)務(wù)清晰并可以被劃分成一個(gè)個(gè)獨(dú)立的service,service之間不需要復(fù)雜的相互調(diào)用關(guān)系
3、服務(wù)與服務(wù)之間的事務(wù)怎么做?接口的調(diào)用權(quán)限如何控制,粒度在方法級(jí)別的
服務(wù)之間是事務(wù)是指分布式事務(wù)嗎?怎么做取決于這類分布式事務(wù)是否很多,如果很少那就例外,如采用在某一個(gè)服務(wù)來做,如果很多那就可以采用分布式事務(wù)的做法,但通常都比較復(fù)雜,個(gè)人認(rèn)為得不償失,還不如考慮這些服務(wù)不拆分
4、為什么有人說“玩不起”?較比普通架構(gòu)需要多做那些工作?
最主要的性能不好把控,因?yàn)槲⒎⻊?wù)是一個(gè)分布式架構(gòu),運(yùn)維和問題定位會(huì)復(fù)雜很多
作者: forgaoqiang 時(shí)間: 2016-10-25 15:19
本帖最后由 forgaoqiang 于 2016-10-28 23:42 編輯
1、你了解微服務(wù)嗎?SOA和微服務(wù)有何差異?最近國(guó)內(nèi)外技術(shù)論壇博客上微服務(wù)話題非常熱門,個(gè)人也讀過一些文章,對(duì)微服務(wù)也有些理解。
微服務(wù)架構(gòu)屬于應(yīng)用技術(shù)架構(gòu),和B/S架構(gòu)類似。強(qiáng)調(diào)的是把復(fù)雜的“巨型單應(yīng)用”拆分成小的應(yīng)用,數(shù)據(jù)上也從集中存儲(chǔ)拆分為更小的存儲(chǔ)單元。
至于SOA是企業(yè)架構(gòu)的范疇,主要是把業(yè)務(wù)上分解為不同的服務(wù),不同的物理系統(tǒng)提供不同的服務(wù),注重的是系統(tǒng)之間通過服務(wù)進(jìn)行互聯(lián)交互的規(guī)范,對(duì)于如何實(shí)現(xiàn)這些服務(wù)并沒有做規(guī)定。
因此個(gè)人理解是,SOA是更大一些的架構(gòu)規(guī)范,沒有規(guī)定具體實(shí)現(xiàn),而微服務(wù)則是如何實(shí)現(xiàn)具體的業(yè)務(wù),兩者并沒有直接關(guān)系。完全可以使用SOA實(shí)現(xiàn)企業(yè)服務(wù),具體的服務(wù)則通過微服務(wù)的形式進(jìn)行拆解。
2、到底在什么樣的情況才適合使用微服務(wù)架構(gòu)?
①首先,微服務(wù)架構(gòu)的應(yīng)用肯定是用在較大規(guī)模的服務(wù)上,規(guī)模大指的是業(yè)務(wù)發(fā)雜程度高。
②需要經(jīng)常進(jìn)行升級(jí)修改的服務(wù),對(duì)于多年不需要變化的服務(wù)沒有必要進(jìn)行拆分。
③系統(tǒng)越來越龐大,啟動(dòng)速度過慢,無法進(jìn)行維護(hù)。
④不同服務(wù)根據(jù)實(shí)際需求需要采用不同的技術(shù)實(shí)現(xiàn)(甚至是不同語言實(shí)現(xiàn))的時(shí)候。
3、服務(wù)與服務(wù)之間的事務(wù)怎么做?接口的調(diào)用權(quán)限如何控制,粒度在方法級(jí)別的?
為了保證數(shù)據(jù)的一致性,事務(wù)是不可避免要上的,每個(gè)服務(wù)都有一個(gè)用RPC-或者消息驅(qū)動(dòng)API定義清楚的邊界。服務(wù)之間的通信和Java的ESB不同,微服務(wù)應(yīng)用采用簡(jiǎn)單輕量級(jí)協(xié)議,比如REST,而不是WS-,在微服務(wù)內(nèi)部避免使用ESB以及ESB類似功能。微服務(wù)架構(gòu)模式也拒絕使用canonical schema等SOA概念。
每個(gè)服務(wù)都根據(jù)內(nèi)部處理情況返回結(jié)果,服務(wù)仍然需要分層,一旦底層服務(wù)調(diào)用失敗,要有對(duì)應(yīng)的異常處理機(jī)制。至于權(quán)限控制,目前來看不可避免的需要在每次調(diào)用的是有帶上token憑據(jù),微信公共號(hào)開發(fā)就是類似的原理,保證權(quán)限控制,粒度應(yīng)該在每次調(diào)用都需要進(jìn)行檢查。
4、為什么有人說“玩不起”?較比普通架構(gòu)需要多做那些工作?
這個(gè)的確會(huì)增加復(fù)雜度,首先整個(gè)系統(tǒng)是分布式的,而且數(shù)據(jù)存儲(chǔ)也是分離的,即使根據(jù)CAP原理,要保證數(shù)據(jù)的一致性也會(huì)變得更加困難,比如有以下的難題:
①服務(wù)因?yàn)槭欠植际降,業(yè)務(wù)調(diào)試難度增加,溝通成本顯著增加。
②微服務(wù)架構(gòu)模式應(yīng)用的改變會(huì)波及多個(gè)服務(wù),特別是服務(wù)之間有依賴的情況,需要協(xié)調(diào)多服務(wù)變更。
③每個(gè)服務(wù)都有自己的實(shí)例,運(yùn)行狀態(tài),需要分別配置、部署、監(jiān)控,還要實(shí)現(xiàn)服務(wù)的發(fā)現(xiàn)機(jī)制,目前視乎不像SOA那樣有成熟的服務(wù)發(fā)現(xiàn)機(jī)制。
以前看過一篇文章說明比如構(gòu)建一個(gè)滴滴打車或者Uber一樣的應(yīng)用,提出了傳統(tǒng)和微服務(wù)的兩種架構(gòu),感覺不錯(cuò),的確可以參考:
①這個(gè)是傳統(tǒng)的單應(yīng)用架構(gòu),核心是業(yè)務(wù)邏輯

下面是微服務(wù)方式實(shí)現(xiàn)的,每一個(gè)應(yīng)用功能區(qū)都使用微服務(wù)完成,另外,Web應(yīng)用會(huì)被拆分成一系列簡(jiǎn)單的Web應(yīng)用

作者: chenxing2 時(shí)間: 2016-10-25 22:20
1、你了解微服務(wù)嗎?SOA和微服務(wù)有何差異?
SOA:面向服務(wù)的架構(gòu),ESB是其一種實(shí)現(xiàn),就是要將緊耦合的系統(tǒng),劃分為面向業(yè)務(wù)的,粗粒度,松耦合,無狀態(tài)的服務(wù)。服務(wù)發(fā)布出來供其他服務(wù)調(diào)用,一組互相依賴的服務(wù)就構(gòu)成了SOA架構(gòu)下的系統(tǒng)。
微服務(wù):是隨著互聯(lián)網(wǎng)的興起而出現(xiàn)的,互聯(lián)網(wǎng)主要就是快速迭代,對(duì)于SOA這樣重的系統(tǒng),迭代一次是很痛苦的,完全達(dá)不到互聯(lián)網(wǎng)時(shí)代的要求,所以將一些獨(dú)立的服務(wù)抽取出來,做一個(gè)小型的服務(wù)(微服務(wù)),方便快速迭代,即使出問題,也不會(huì)影響不相關(guān)的服務(wù),根據(jù)各自服務(wù)的特性可以選擇最佳的編程語言來實(shí)現(xiàn)。
2、到底在什么樣的情況才適合使用微服務(wù)架構(gòu)?
最最合適的情況是,不依賴其他服務(wù)而又能對(duì)外提供服務(wù),且又不涉及事物問題
3、服務(wù)與服務(wù)之間的事務(wù)怎么做?接口的調(diào)用權(quán)限如何控制,粒度在方法級(jí)別的?
服務(wù)與服務(wù)之間都是獨(dú)立的,不可能跟傳統(tǒng)寫法一樣,在一個(gè)大事物中處理。
傳統(tǒng)做法使用 分布式事物XA 兩階段提交,但性能會(huì)較差些,一般互聯(lián)網(wǎng)公司很少使用這種方式
一般使用最終一致,即通過后續(xù)補(bǔ)償保證數(shù)據(jù)的一致性。
在服務(wù)拆分或設(shè)計(jì)時(shí)就要盡量避免這種情況出現(xiàn)。
服務(wù)的調(diào)用通常不會(huì)暴露到公網(wǎng),都是內(nèi)網(wǎng)調(diào)用,不必限制到方法,通過ssl或ip控制即可
一般接入層涉及訪問控制,通常使用spring security或apache shiro來控制資源的訪問
4、為什么有人說“玩不起”?較比普通架構(gòu)需要多做那些工作?
玩不起是因?yàn)楹笃谖⒎⻊?wù)會(huì)變得復(fù)雜,
要多做的工作:服務(wù)注冊(cè)與發(fā)現(xiàn)、熔斷恢復(fù)、黑白名單、超時(shí)控制、服務(wù)容錯(cuò)、灰度路由、鏈路追蹤、容量規(guī)劃、
實(shí)時(shí)監(jiān)控、流量控制、服務(wù)降級(jí)、冪等保障以及分庫分表、事物等等
作者: cxsvip 時(shí)間: 2016-10-26 08:32
高大上的話題,不了解
作者: Fl_wolf 時(shí)間: 2016-10-27 10:35
微服務(wù)這東西還真不是很懂 0 0。。 我就來支持楠子一下。。 繼續(xù)看其他書去了。。
作者: laputa73 時(shí)間: 2016-10-28 16:16
本帖最后由 laputa73 于 2016-11-04 15:03 編輯
正在關(guān)注這個(gè)問題。
我覺得soa和微服務(wù)思路上沒有本質(zhì)區(qū)別,主要是領(lǐng)域問題,一個(gè)是對(duì)外,關(guān)注共享, 一個(gè)是對(duì)內(nèi),關(guān)注通信。
二者在管理需求上有較大差異。
再就是度的問題,soa開放的接口數(shù)量遠(yuǎn)比微服務(wù)小,量變到質(zhì)變。
微服務(wù)和corba其實(shí)有點(diǎn)象。
作者: sjf0115 時(shí)間: 2016-11-12 20:29
1. 你了解微服務(wù)嗎?SOA和微服務(wù)有何差異?
每個(gè)人對(duì)微服務(wù)都可以有自己的理解,不過大概的標(biāo)準(zhǔn)還是有一些的。
(1)分布式服務(wù)組成的系統(tǒng)
(2)按照業(yè)務(wù)而不是技術(shù)來劃分組織
(3)做有生命的產(chǎn)品而不是項(xiàng)目
(4)Smart endpoints and dumb pipes
(5)自動(dòng)化運(yùn)維
(6)容錯(cuò)
(7)快速演化
看了以上幾個(gè)方面,相信很多人都會(huì)問一個(gè)問題,這是不是就是SOA換了個(gè)概念,掛羊頭賣狗肉。有說法把微服務(wù)叫成Lightway SOA。也有很多傳統(tǒng)專家說微服務(wù)就是SOA。其實(shí)微服務(wù)創(chuàng)始人Martin也沒否認(rèn)SOA和Microservice的關(guān)系。個(gè)人理解,微服務(wù)是SOA的傳承,但一個(gè)最本質(zhì)的區(qū)別在Smart endpoints and dumb pipes,或者說是真正的分布式的、去中心化。Smart endpoints and dumb pipes本質(zhì)就是去ESB,把所有的“思考”邏輯包括路由、消息解析等放在服務(wù)內(nèi)部(Smart endpoints),去掉一個(gè)大一統(tǒng)的ESB,服務(wù)間輕(dumb pipes)通信,是比SOA更徹底的拆分。
2. 到底在什么樣的情況才適合使用微服務(wù)架構(gòu)?
隨著更多的應(yīng)用被部署到云平臺(tái),人們的挫敗感漸增。更新周期被緊緊綁定——即便是應(yīng)用中一個(gè)很小部分的改變,也需要整個(gè)應(yīng)用的重構(gòu)和部署。隨著時(shí)間推移,保持一個(gè)良好的模塊化架構(gòu)也日益困難,牽一發(fā)而動(dòng)全身。一旦要進(jìn)行擴(kuò)展,就必須整體擴(kuò)展,而不能僅僅擴(kuò)展其中到一部分模塊,也就需要更多的資源
這種情況最后進(jìn)化為微服務(wù)架構(gòu):把應(yīng)用作為一組服務(wù)來構(gòu)建。這些服務(wù)能夠獨(dú)立部署和擴(kuò)展,每個(gè)服務(wù)提供一個(gè)堅(jiān)實(shí)的模型邊界,甚至可以用不同的程序語言來寫這些服務(wù)。當(dāng)然他們也能被不同的團(tuán)隊(duì)來管理。
3. 為什么有人說“玩不起”?較比普通架構(gòu)需要多做那些工作?
微服務(wù)應(yīng)用是分布式系統(tǒng),由此會(huì)帶來固有的復(fù)雜性。開發(fā)者需要在RPC或者消息傳遞之間選擇并完成進(jìn)程間通訊機(jī)制。更甚于,他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。當(dāng)然這并不是什么難事,但相對(duì)于單體式應(yīng)用中通過語言層級(jí)的方法或者進(jìn)程調(diào)用,微服務(wù)下這種技術(shù)顯得更復(fù)雜一些。
微服務(wù)架構(gòu)模式應(yīng)用的改變將會(huì)波及多個(gè)服務(wù)。
部署一個(gè)微服務(wù)應(yīng)用也很復(fù)雜。
歡迎光臨 Chinaunix (http://72891.cn/) |
Powered by Discuz! X3.2 |