RPC
RPC（Remote Process Call），即遠(yuǎn)程服務(wù)調(diào)用，被廣泛地應(yīng)用在很多企業(yè)應(yīng)用中，是早期主要的服務(wù)治理方案，其流程較為簡(jiǎn)單，客戶(hù)端consumer攜帶參數(shù)發(fā)送RPC請(qǐng)求到服務(wù)提供方provider，provider根據(jù)參數(shù)路由到具體函數(shù)，方法，并將執(zhí)行獲得的結(jié)果返回，至此一次RPC調(diào)用完成。
隨著業(yè)務(wù)的發(fā)展，大數(shù)據(jù)時(shí)代的到來(lái)，服務(wù)提供方的壓力也日益增大，單機(jī)應(yīng)用的處理能力無(wú)論在軟件，硬件上都受到限制，provider也不可能一直無(wú)限擴(kuò)容，即使擴(kuò)容，也存在著很多問(wèn)題，即服務(wù)的路由，和Consumer的負(fù)載均衡問(wèn)題。因此，分布式服務(wù)架構(gòu)應(yīng)運(yùn)而生，RPC發(fā)展到一定階段思考的變革，成為了分布式服務(wù)，云計(jì)算的計(jì)算機(jī)基礎(chǔ)。
SOA
由于簡(jiǎn)單的RPC調(diào)用已經(jīng)不能隨著時(shí)代發(fā)展?jié)M足需求，因此復(fù)雜的業(yè)務(wù)邏輯對(duì)于分布式應(yīng)用架構(gòu)體系的需求愈發(fā)強(qiáng)烈，業(yè)務(wù)希望自己的服務(wù)是分布式部署的，請(qǐng)求是分流的，對(duì)數(shù)據(jù)的操作是能讀寫(xiě)分離的，同時(shí)能屏蔽許多復(fù)雜需要自己編寫(xiě)的底層服務(wù)，借助已有的公共服務(wù)，去快速的構(gòu)建自己的應(yīng)用，降低人力開(kāi)發(fā)維護(hù)的成本和提高應(yīng)用交付的效率，基因此，基于分布式服務(wù)思想的SOA（Service-Oriented Architecture）成了新的受追捧的架構(gòu)。常見(jiàn)的SOA服務(wù)調(diào)用流程圖如下：
服務(wù)治理方案
業(yè)界的互聯(lián)網(wǎng)巨頭公司，都有屬于自己的分布式服務(wù)框架，如阿里巴巴的Dubbo，HSF，騰訊的Tars，京東的JSF，新浪的Motan，都已經(jīng)是業(yè)界非常成熟的解決方案，其中開(kāi)源的Dubbo和Motan受到了廣大開(kāi)發(fā)者的研究對(duì)象。
縱觀這些服務(wù)框架，設(shè)計(jì)的基本思路都如上圖，無(wú)非涉及provider發(fā)布注冊(cè)，consumer訂閱，調(diào)用發(fā)起，負(fù)載均衡，服務(wù)分流和監(jiān)控等模塊，并在此基礎(chǔ)上增加了很多玩法，形成了各具特色的分布式服務(wù)框架設(shè)計(jì)，下面就Dubbo，JSF，Motan的設(shè)計(jì)做下簡(jiǎn)單的介紹。
Dubbo：下圖是Dubbo在服務(wù)治理方面的架構(gòu)設(shè)計(jì)
初始化階段：部署在Container的Provider啟動(dòng)后向服務(wù)中心Registry發(fā)布并注冊(cè)自己的服務(wù)，客戶(hù)端Consumer初始化時(shí)即向Registry訂閱自己想要的服務(wù)，同時(shí)Registry對(duì)Consumer保持著一個(gè)長(zhǎng)連接，當(dāng)訂閱的服務(wù)新增或減少節(jié)點(diǎn)時(shí)，會(huì)及時(shí)通知到客戶(hù)端更新（此過(guò)程是異步進(jìn)行的，不會(huì)影響Consumer的主流程），如此一來(lái)，客戶(hù)端Consumer便有了Provider的所有實(shí)時(shí)信息，便可以發(fā)起服務(wù)調(diào)用了。
invoke階段：客戶(hù)端Consumer從獲得的所有Provider列表中通過(guò)負(fù)載均衡等策略選出最適合調(diào)用的服務(wù)提供者Provider并發(fā)起同步調(diào)用。
Monitor階段：Consumer和Provider通過(guò)異步的方式向監(jiān)控中心上報(bào)自己的需要被監(jiān)控的數(shù)據(jù)。
JSF
下圖是JSF在服務(wù)治理方面的架構(gòu)設(shè)計(jì)
初始化階段：Provider啟動(dòng)后向服務(wù)注冊(cè)中心發(fā)布注冊(cè)自己的服務(wù)
invoke階段：與Dubbo不同的是，JSF的注冊(cè)中心不向Consumer推送Provider實(shí)時(shí)數(shù)據(jù)，而是在發(fā)起調(diào)用時(shí)Consumer向注冊(cè)中心詢(xún)問(wèn)并獲得對(duì)應(yīng)的Provider，然后組織匹配JSF協(xié)議的報(bào)文發(fā)起調(diào)用。
Monitor階段：Provider定期向監(jiān)控中心發(fā)送性能統(tǒng)計(jì)數(shù)據(jù)，同時(shí)Provider還會(huì)上報(bào)事件給事件中心。
Motan
Motan是有名的輕量級(jí)服務(wù)框架，代碼質(zhì)量很高，下圖是Motan在服務(wù)治理方面的架構(gòu)設(shè)計(jì)
Motan的服務(wù)治理設(shè)計(jì)與Dubbo十分的相似，都是Provider發(fā)布注冊(cè)，Consumer訂閱與接受推送，之后發(fā)起調(diào)用。
分布式服務(wù)框架主要模塊名詞釋義
無(wú)論是那種SOA的架構(gòu)設(shè)計(jì)，都離不開(kāi)幾個(gè)模塊的功能，即Provider，Consumer，Registry，Gateway，負(fù)載均衡，服務(wù)分流，監(jiān)控等，通過(guò)上述所講，應(yīng)該對(duì)這些功能模塊有了初步的認(rèn)識(shí)，下面就這些名詞再作下介紹
（1）Provider：服務(wù)提供者，無(wú)論是業(yè)務(wù)服務(wù)，還是一個(gè)系統(tǒng)中公用的SAAS，都屬于Provider
（2）Consumer：即發(fā)起調(diào)用的客戶(hù)端
（3）Registry：服務(wù)注冊(cè)中心，是分布式服務(wù)系統(tǒng)中的一個(gè)重要組成模塊，管理Provider的Manager，在實(shí)際的運(yùn)行環(huán)境中，服務(wù)注冊(cè)中心Registry被動(dòng)通知或Consumer主動(dòng)詢(xún)問(wèn)，在Provider有節(jié)點(diǎn)宕機(jī)或新增節(jié)點(diǎn)時(shí)，客戶(hù)端也可實(shí)時(shí)感知到，從而避免了某個(gè)Provider被無(wú)限調(diào)用或是無(wú)限閑置
（4）Gateway：網(wǎng)關(guān)也是分布式服務(wù)框架中不可或缺的部分，每種系統(tǒng)與框架都有自己的一套協(xié)議，當(dāng)異構(gòu)系統(tǒng)互相調(diào)用時(shí)，網(wǎng)關(guān)的作用即顯現(xiàn)出來(lái)，Gateway接受各種外部HTTP請(qǐng)求，完成相應(yīng)的權(quán)限校驗(yàn)，報(bào)文適配，路由轉(zhuǎn)發(fā)到對(duì)應(yīng)的Provider，再將Provider返回的結(jié)果傳遞給異構(gòu)系統(tǒng)的Consumer，完成異構(gòu)系統(tǒng)的互相調(diào)用
（5）負(fù)載均衡，服務(wù)分流：Consumer從Registry獲得具體的Provider列表后，如何選取合適的Provider，取決與一定的負(fù)載均衡算法，常見(jiàn)的算法有輪詢(xún)法，隨機(jī)法，源地址哈希，加權(quán)輪詢(xún)，加權(quán)隨機(jī)等
（6）監(jiān)控：接收來(lái)自Consumer和Provider異步上報(bào)的性能監(jiān)控?cái)?shù)據(jù)，對(duì)有風(fēng)險(xiǎn)的節(jié)點(diǎn)發(fā)出告警
分布式服務(wù)和微服務(wù)的區(qū)別
分布式架構(gòu)是分布式計(jì)算技術(shù)的應(yīng)用和工具，目前成熟的技術(shù)包括J2EE, CORBA和.NET(DCOM)，這些技術(shù)牽扯的內(nèi)容非常廣，相關(guān)的書(shū)籍也非常多，也沒(méi)有涉及這些技術(shù)的細(xì)節(jié)，只是從各種分布式系統(tǒng)平臺(tái)產(chǎn)生的背景和在軟件開(kāi)發(fā)中應(yīng)用的情況來(lái)探討它們的主要異同。
微服務(wù)架構(gòu)是一項(xiàng)在云中部署應(yīng)用和服務(wù)的新技術(shù)。大部分圍繞微服務(wù)的爭(zhēng)論都集中在容器或其他技術(shù)是否能很好的實(shí)施微服務(wù)，而紅帽說(shuō)API應(yīng)該是重點(diǎn)。
微服務(wù)可以在“自己的程序”中運(yùn)行，并通過(guò)“輕量級(jí)設(shè)備與HTTP型API進(jìn)行溝通”。關(guān)鍵在于該服務(wù)可以在自己的程序中運(yùn)行。通過(guò)這一點(diǎn)我們就可以將服務(wù)公開(kāi)與微服務(wù)架構(gòu)（在現(xiàn)有系統(tǒng)中分布一個(gè)API）區(qū)分開(kāi)來(lái)。在服務(wù)公開(kāi)中，許多服務(wù)都可以被內(nèi)部獨(dú)立進(jìn)程所限制。如果其中任何一個(gè)服務(wù)需要增加某種功能，那么就必須縮小進(jìn)程范圍。在微服務(wù)架構(gòu)中，只需要在特定的某種服務(wù)中增加所需功能，而不影響整體進(jìn)程的架構(gòu)。
從概念理解，分布式服務(wù)架構(gòu)強(qiáng)調(diào)的是服務(wù)化以及服務(wù)的分散化，微服務(wù)則更強(qiáng)調(diào)服務(wù)的專(zhuān)業(yè)化和精細(xì)分工；從實(shí)踐的角度來(lái)看，微服務(wù)架構(gòu)通常是分布式服務(wù)架構(gòu)，反之則未必成立。所以，選擇微服務(wù)通常意味著需要解決分布式架構(gòu)的各種難題。
區(qū)別分布式的方式是根據(jù)不同機(jī)器不同業(yè)務(wù)。
將一個(gè)大的系統(tǒng)劃分為多個(gè)業(yè)務(wù)模塊，業(yè)務(wù)模塊分別部署到不同的機(jī)器上，各個(gè)業(yè)務(wù)模塊之間通過(guò)接口進(jìn)行數(shù)據(jù)交互。區(qū)別分布式的方式是根據(jù)不同機(jī)器不同業(yè)務(wù)。
微服務(wù)更加強(qiáng)調(diào)單一職責(zé)、輕量級(jí)通信(HTTP)、獨(dú)立性并且進(jìn)程隔離。
微服務(wù)與分布式的細(xì)微差別是，微服務(wù)的應(yīng)用不一定是分散在多個(gè)服務(wù)器上，他也可以是同一個(gè)服務(wù)器。
分布式是否屬于微服務(wù)？
不一定，如果一個(gè)很大應(yīng)用，拆分成三個(gè)應(yīng)用，但還是很龐大，雖然分布式了，但不是微服務(wù)。。微服務(wù)核心要素是微小。。
微服務(wù)架構(gòu)是分布式服務(wù)架構(gòu)的子集。
微服務(wù)架構(gòu)通過(guò)更細(xì)粒度的服務(wù)切分，使得整個(gè)系統(tǒng)的迭代速度并行程度更高，但是運(yùn)維的復(fù)雜度和性能會(huì)隨著服務(wù)的粒度更細(xì)而增加。
微服務(wù)重在解耦合，使每個(gè)模塊都獨(dú)立。分布式重在資源共享與加快計(jì)算機(jī)計(jì)算速度。
分布式：分散壓力。
微服務(wù)：分散能力。
