《分布式服務(wù)框架原理與實(shí)踐》有獎(jiǎng)試讀活動(dòng)，歡迎大家參與~

王楠w_n

獲獎(jiǎng)詳情：http://www.72891.cn/thread-4242737-1-1.html



話題背景：
“微服務(wù)”無疑是本年度最熱的技術(shù)關(guān)鍵詞之一！近些年來，越來越多網(wǎng)站需要同時(shí)提供Web、移動(dòng)App、OpenAPI多種訪問方式，基于分布式服務(wù)的業(yè)務(wù)分治與復(fù)用需求越來越強(qiáng)烈，使用分布式服務(wù)構(gòu)建系統(tǒng)已經(jīng)成為互聯(lián)網(wǎng)開發(fā)的常用手段。但是分布式服務(wù)的關(guān)鍵技術(shù)有哪些？核心原理是什么？最佳實(shí)踐是什么？如何落地微服務(wù)呢?

今天我們不妨通過此次的試讀活動(dòng)來討論下此類問題帶給我們的一些啟示和思路。


圖書簡介：



書名：分布式服務(wù)框架原理與實(shí)踐
作者：李林鋒
出版社：電子工業(yè)出版社
ISBN：978-7-121-27919-5
出版年月：2016-1-1


作者簡介：
李林鋒，現(xiàn)任華為PaaS平臺架構(gòu)師，8年Java NIO通信框架、平臺中間件架構(gòu)設(shè)計(jì)和開發(fā)經(jīng)驗(yàn)，主導(dǎo)設(shè)計(jì)和開發(fā)的華為分布式服務(wù)框架已經(jīng)在全球數(shù)十個(gè)國家成功商用。精通Netty、Mina、RPC框架、企業(yè)ESB總線、分布式服務(wù)框架等技術(shù)，《Netty權(quán)威指南》作者，公司總裁技術(shù)創(chuàng)新獎(jiǎng)獲得者。



內(nèi)容簡介：
本書作者具有豐富的分布式服務(wù)框架、平臺中間件的架構(gòu)設(shè)計(jì)和實(shí)踐經(jīng)驗(yàn)，主導(dǎo)設(shè)計(jì)的華為分布式服務(wù)框架已經(jīng)在全球數(shù)十個(gè)國家成功商用。書中依托工作實(shí)踐，從分布式服務(wù)框架的架構(gòu)設(shè)計(jì)原理到實(shí)踐經(jīng)驗(yàn)總結(jié)，涵蓋了服務(wù)化架構(gòu)演進(jìn)、訂閱發(fā)布、路由策略、集群容錯(cuò)和服務(wù)治理等多個(gè)專題，全方位剖析服務(wù)框架的設(shè)計(jì)原則和原理，結(jié)合大量實(shí)踐案例與讀者分享作者對分布式服務(wù)框架設(shè)計(jì)和運(yùn)維的體會。同時(shí)，對基于Docker部署微服務(wù)以及基于微服務(wù)架構(gòu)開發(fā)、部署和運(yùn)維業(yè)務(wù)系統(tǒng)進(jìn)行了詳細(xì)介紹。


活動(dòng)時(shí)間：2016-01-06——2016-02-03


活動(dòng)話題：（可任選一個(gè)問題作答）
1.什么是微服務(wù)？您對這個(gè)概念之前有過了解嗎/
2.分布式服務(wù)的關(guān)鍵技術(shù)有哪些？
3.讀完閱讀樣章后，針對分布式服務(wù)這個(gè)技術(shù)，您有何要補(bǔ)充的？或談?wù)勀鷮Ψ植际椒��?wù)的理解。


試讀樣章： 分布式服務(wù)框架原理與實(shí)踐試讀樣章.pdf (1.5 MB, 下載次數(shù): 456)

2016-01-06 10:58 上傳

點(diǎn)擊文件名下載附件

活動(dòng)有獎(jiǎng)：
我們會從大家的回復(fù)中抽出5為最佳參與獎(jiǎng)，獎(jiǎng)勵(lì)《分布式服務(wù)框架原理與實(shí)踐》圖書一本。


目前CU論壇有一些相關(guān)的技術(shù)微信群，歡迎感興趣的各位壇友們前去掃碼加群，定期會有驚喜等著你哦！



IT運(yùn)維群現(xiàn)已到300人，掃碼加不見去的小伙伴，加我微信號：na973966431 ，我拖各位進(jìn)群。

demilich

1.什么是微服務(wù)？您對這個(gè)概念之前有過了解嗎？
我對微服務(wù)的理解，其實(shí)就是把原先一個(gè)提供多種服務(wù)的服務(wù)器，先打散成分別實(shí)現(xiàn)微小功能的服務(wù)。再根據(jù)自己需要對外提供的服務(wù)，組合使用這些微服務(wù)。微服務(wù)本身其實(shí)就是個(gè)服務(wù)器，提供API，可以有自己的數(shù)據(jù)庫，根據(jù)對微服務(wù)的需求，可以獨(dú)立進(jìn)行伸縮擴(kuò)展。其實(shí)，我理解和SOA頗有相似之處，但是也略有不同。各個(gè)微服務(wù)之間的耦合度應(yīng)該更加松散，之間消息的交互應(yīng)該是統(tǒng)一的。

微服務(wù)這么做的話，我覺得有以下好處：
- 耦合度低，所以各個(gè)微服務(wù)可以使用不同的開發(fā)語言進(jìn)行。也可以由不同的團(tuán)隊(duì)負(fù)責(zé)，在多團(tuán)隊(duì)并行開發(fā)的時(shí)候，更加合適

當(dāng)然微服務(wù)系統(tǒng)的開發(fā)，對于項(xiàng)目管理，系統(tǒng)集成以及運(yùn)維提出了更高的要求。

2.分布式服務(wù)的關(guān)鍵技術(shù)有哪些？
- RPC/一致性問題/消息傳遞/負(fù)載均衡/集群/命名服務(wù)/配置管理/如何提供統(tǒng)一的鎖 ....

3.讀完閱讀樣章后，針對分布式服務(wù)這個(gè)技術(shù)，您有何要補(bǔ)充的？或談?wù)勀鷮Ψ植际椒��?wù)的理解。
- 對于分布式相關(guān)的書籍，比較好的一個(gè)風(fēng)格是先提出分布式服務(wù)需要解決的問題，每個(gè)問題有哪些解決方案，優(yōu)劣是什么，常見的排列組合又是什么，再輔以例子證明自己的論述 ...

sjf0115

1.什么是微服務(wù)？您對這個(gè)概念之前有過了解嗎?

一個(gè)簡單的應(yīng)用會隨著時(shí)間推移逐漸變大。幾年后，這個(gè)小而簡單的應(yīng)用會變成了一個(gè)巨大的怪物。一旦你的應(yīng)用變成一個(gè)又大又復(fù)雜的怪物，那開發(fā)團(tuán)隊(duì)肯定很痛苦。敏捷開發(fā)和部署舉步維艱，其中最主要問題就是這個(gè)應(yīng)用太復(fù)雜，以至于任何單個(gè)開發(fā)者都不可能搞懂它。因此，修正bug和正確的添加新功能變的非常困難，并且很耗時(shí)。如果代碼難于理解，就不可能被正確的修改。最終會走向巨大的、不可理解的泥潭。許多公司，比如Amazon、eBay和NetFlix，通過采用微處理結(jié)構(gòu)模式解決了上述問題。其思路不是開發(fā)一個(gè)巨大的單體式的應(yīng)用，而是將應(yīng)用分解為小的、互相連接的微服務(wù)。一個(gè)微服務(wù)一般完成某個(gè)特定的功能，比如下單管理、客戶管理等等。每一個(gè)微服務(wù)都是微型六角形應(yīng)用，都有自己的業(yè)務(wù)邏輯和適配器。一些微服務(wù)還會發(fā)布API給其它微服務(wù)和應(yīng)用客戶端使用。

微服務(wù)架構(gòu)將服務(wù)拆分，分別采用相對獨(dú)立的服務(wù)對各方面進(jìn)行管理，彼此之間使用統(tǒng)一的接口來進(jìn)行交流。
使用微服務(wù)作為主要架構(gòu)類型的系統(tǒng)是一個(gè)擁有大量協(xié)調(diào)微服務(wù)的分布式系統(tǒng)，每個(gè)微服務(wù)分管自己的進(jìn)程。由于微服務(wù)之間緊密協(xié)作，每個(gè)微服務(wù)只提供拼圖的一小塊，而系統(tǒng)做為完整的作品存在。協(xié)作時(shí)，各服務(wù)彼此通過一個(gè)不綁定具體平臺的輕量級媒介進(jìn)行溝通。

這種微服務(wù)架構(gòu)模式深刻影響了應(yīng)用和數(shù)據(jù)庫之間的關(guān)系，不像傳統(tǒng)多個(gè)服務(wù)共享一個(gè)數(shù)據(jù)庫，微服務(wù)架構(gòu)每個(gè)服務(wù)都有自己的數(shù)據(jù)庫。

好處

（1）通過分解巨大單體式應(yīng)用為多個(gè)服務(wù)方法解決了復(fù)雜性問題。在功能不變的情況下，應(yīng)用被分解為多個(gè)可管理的分支或服務(wù)。
（2）每個(gè)服務(wù)都可以有專門開發(fā)團(tuán)隊(duì)來開發(fā)。開發(fā)者可以自由選擇開發(fā)技術(shù)，提供API服務(wù)。
（3）每個(gè)微服務(wù)獨(dú)立的部署。開發(fā)者不再需要協(xié)調(diào)其它服務(wù)部署對本服務(wù)的影響。這種改變可以加快部署速度。
（4）每個(gè)服務(wù)獨(dú)立擴(kuò)展。你可以根據(jù)每個(gè)服務(wù)的規(guī)模來部署滿足需求的規(guī)模。

不足
　　
（1）微服務(wù)應(yīng)用是分布式系統(tǒng)，由此會帶來固有的復(fù)雜性。。
（2）分區(qū)的數(shù)據(jù)庫架構(gòu)。商業(yè)交易中同時(shí)給多個(gè)業(yè)務(wù)分主體更新消息很普遍。這種交易對于單體式應(yīng)用來說很容易，因?yàn)橹挥幸粋�(gè)數(shù)據(jù)庫。在微服務(wù)架構(gòu)應(yīng)用中，需要更新不同服務(wù)所使用的不同的數(shù)據(jù)庫。使用分布式交易并不一定是好的選擇，不僅僅是因?yàn)镃AP理論，還因?yàn)榻裉旄邤U(kuò)展性的NoSQL數(shù)據(jù)庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個(gè)最終一致性的方法，從而對開發(fā)者提出了更高的要求和挑戰(zhàn)。

2.分布式服務(wù)的關(guān)鍵技術(shù)有哪些？

RPC,服務(wù)劃分，服務(wù)調(diào)度，服務(wù)化的高性能，服務(wù)治理，服務(wù)監(jiān)控

王楠w_n

歡迎支持，后期會有在微信群里直播分型回復(fù) 3# sjf0115


   

laputa73

正在關(guān)注這個(gè)內(nèi)容。
希望有人系統(tǒng)介紹一下。感覺RPC, 分布式調(diào)用，分布式任務(wù),分布式計(jì)算,消息隊(duì)列都有些關(guān)系。
比如gearman,beanstalk,thrift,avro這些

sjf0115

回復(fù) 4# 王楠w_n

哪個(gè)微信群  ChinaUnix嗎？具體什么時(shí)候？一定要聽一下


   

jieforest

先占個(gè)坑，支持。

把內(nèi)容再修訂一下。


我選第一個(gè)問題進(jìn)行討論吧。
1.什么是微服務(wù)？您對這個(gè)概念之前有過了解嗎?

要說清楚微服務(wù)，首先得理清服務(wù)架構(gòu)的發(fā)展歷程。

最早是單片架構(gòu)。
企業(yè)應(yīng)用軟件的設(shè)計(jì)目標(biāo)是滿足各種業(yè)務(wù)需求，一個(gè)給定的應(yīng)用軟件可能需要提供數(shù)百個(gè)功能，這些功能堆積到單個(gè)應(yīng)用中。比如ERP、CRM等。這對于部署、故障排除、系統(tǒng)伸縮、升級等都是一個(gè)嚴(yán)峻的考驗(yàn)。
SOA的設(shè)計(jì)目標(biāo)是根據(jù)提供相近功能的模塊進(jìn)行聚合和分組，以服務(wù)的方式提供功能。在SOA中，應(yīng)用軟件是以“粗粒度”的方式設(shè)計(jì)服務(wù)或服務(wù)組合。由于服務(wù)的范圍非常廣泛，故可能會產(chǎn)生復(fù)雜的服務(wù)（比如帶數(shù)十個(gè)操作或功能的服務(wù)），也可能帶來復(fù)雜的消息格式和相關(guān)的標(biāo)準(zhǔn)（比如SOAP中的WS* 標(biāo)準(zhǔn)簇）。

接著是SOA架構(gòu)。
大多數(shù)情況下，SOA的服務(wù)是相互獨(dú)立的，但經(jīng)常是這些服務(wù)都部署到同一個(gè)運(yùn)行時(shí)（比如同一個(gè)Tomcat實(shí)例中）。
單片應(yīng)用程序的設(shè)計(jì)，開發(fā)和部署為單個(gè)單元。
單一應(yīng)用程序絕大多數(shù)是復(fù)雜的; 這導(dǎo)致噩夢維護(hù)，升級和增加新的功能。
努力實(shí)踐與單片架構(gòu)敏捷開發(fā)和交付方法。
它要求重新部署整個(gè)應(yīng)用程序，以更新它的一部分。
縮放：有擴(kuò)大規(guī)模作為一個(gè)單一的應(yīng)用程序，并難以與沖突的資源需求規(guī)模（例如一個(gè)服務(wù)需要更多的CPU，而其他需要更多的內(nèi)存）
可靠性：一個(gè)不穩(wěn)定的服務(wù)可以帶動(dòng)整個(gè)申請下來。
努力創(chuàng)新：這真的很難采用新技術(shù)和框架，因?yàn)樗�有的功能都建立在均質(zhì)技術(shù)/框架。

再接著就是如今的微服務(wù)架構(gòu)。
如果說SOA是粗粒度的服務(wù)架構(gòu)，那么微服務(wù)就是細(xì)粒度的服務(wù)架構(gòu)。
微服務(wù)架構(gòu)（MSA）的基礎(chǔ)是有關(guān)開發(fā)一個(gè)單一的應(yīng)用程序作為一套小的，獨(dú)立的服務(wù)，這是在自己的進(jìn)程，開發(fā)和部署獨(dú)立運(yùn)行。
對于微服務(wù)架構(gòu)的定義，它是作為可用服務(wù)分離為一組或多組獨(dú)立服務(wù)的過程。然而，微服務(wù)不僅僅是在整體上分割提供的服務(wù)成獨(dú)立服務(wù)。
關(guān)鍵的想法是，通過觀察整體所提供的功能，可以找出所需的業(yè)務(wù)能力。那么這些業(yè)務(wù)能力可以實(shí)現(xiàn)為完全獨(dú)立的、細(xì)粒度的、自包含（微）服務(wù)。這些服務(wù)可能會以不同的技術(shù)棧進(jìn)行實(shí)現(xiàn)，每個(gè)服務(wù)都是解決一個(gè)非常具體和有限范圍的問題或需求。

微服務(wù)的一些準(zhǔn)則：
1）單一職責(zé)原則
即SRP，Single Responsibility Principle
2）設(shè)計(jì)邊界對齊業(yè)務(wù)需求
3）讓微服務(wù)的設(shè)計(jì)來保證服務(wù)的獨(dú)立開發(fā)和獨(dú)立部署
4）重心在于微服務(wù)的范圍，而不是讓服務(wù)盡可能小
5）微服務(wù)應(yīng)該有很少的操作/功能以及簡單的消息格式
6）從比較寬泛的服務(wù)邊界帶開始，重構(gòu)微服務(wù)

微服務(wù)中的消息通信
在單片應(yīng)用中，不同的處理單元或組件的業(yè)務(wù)功能通常是使用函數(shù)調(diào)用或語言級的方法調(diào)用來實(shí)現(xiàn)的。在SOA架構(gòu)中，則改用更加松耦合的Web服務(wù)級的消息通信來實(shí)現(xiàn)，它主要是基于SOAP協(xié)議實(shí)現(xiàn)——可以是HTTP或JMS等。SOAP協(xié)議的復(fù)雜性阻礙了SOA的流行。對于微服務(wù)架構(gòu)，則需要有一個(gè)簡單的、輕量級的消息通信機(jī)制。

1）同步消息通信——REST、Thrift
在微服務(wù)架構(gòu)中，對于同步消息通信（客戶端希望能及時(shí)得到服務(wù)的響應(yīng)），REST是一致的選擇。REST提供了一個(gè)簡單的基于HTTP的請求-響應(yīng)模型和基于資源的API的消息通信樣式。每一個(gè)功能都由一個(gè)資源和資源上的操作來表示。

2）異步消息通信——AMQP、STOMP、MQTT
對于一些微服務(wù)方案，需要使用異步消息通信技術(shù)（客戶端無需及時(shí)得到響應(yīng)，或者是根本就不需要響應(yīng)）。在這樣的場景下，廣泛使用AMQP、STOMP、MQTT等技術(shù)。

niao5929

好書一定要頂起來。分布式是未來。LINUX讓我們有了統(tǒng)一的軟件層面的節(jié)點(diǎn)。我們姑且將其定義為細(xì)胞節(jié)點(diǎn)。剩下的事就是不斷的增強(qiáng)細(xì)胞節(jié)點(diǎn)的語義功能。制定規(guī)則。讓這些細(xì)胞節(jié)點(diǎn)進(jìn)入自主狀態(tài)。

chenyx

1.什么是微服務(wù)？您對這個(gè)概念之前有過了解嗎/
這個(gè)應(yīng)該是Docker吧，秒級啟動(dòng)新服務(wù)的方式，最近很火的

crazyhadoop

1. 什么是微服務(wù)

微服務(wù)本身并沒有一個(gè)嚴(yán)格的定義，不過從很多人都達(dá)成了這樣一個(gè)共識：微服務(wù)是一種簡單的應(yīng)用，微服務(wù)是指開發(fā)一個(gè)單個(gè) 小型的但有業(yè)務(wù)功能的服務(wù)，每個(gè)服務(wù)都有自己的處理和輕量通訊機(jī)制，可以部署在單個(gè)或多個(gè)服務(wù)器上。微服務(wù)也指一種種松耦合的、有一定的有界上下文的面向服務(wù)架構(gòu)。也就是說，如果每個(gè)服務(wù)都要同時(shí)修改，那么它們就不是微服務(wù)，因?yàn)樗鼈兙o耦合在一起。

2. 分布式服務(wù)有哪些關(guān)鍵技術(shù)

服務(wù)發(fā)現(xiàn)，分布式鎖，資源調(diào)度和資源隔離，高效率的RPC服務(wù)， 強(qiáng)大的運(yùn)維開發(fā)。 另外基礎(chǔ)服務(wù)要好啊，例如存儲，數(shù)據(jù)庫，網(wǎng)絡(luò)，如果沒有這些基本的技術(shù)保障，說啥都沒有用啊。

3. 看了樣張，這是科普原理的書籍，與實(shí)踐差距還很大啊