Java微服務和分散式是近幾年越來越熱的詞語，想要理解他們的區別，我們可以從二者的概念入手！

微服務

先說微服務，其實就是把一個大的服務進行拆分，拆分成多個小服務。舉個例子，比如我們都去過火車站買票。那麼火車站最開始的時候可能就是—個很小的地方，裡面提供—個對外服務的視窗，這個時候 火車站就相當於一個己完成的大的服務，對外提供諮詢、買票、退票、改簽等服務。

那麼隨著不斷的發展. 透過火車出行的人越來越多，這個時候如果這個視窗的服務員生病了請假了，那麼所有的人都無法使用火 車服務，有的人沒法買票、有的人沒法退票、有的人沒法改簽。這個時候就需要進行服務的拆分，我們把 這一個視窗拆分成諮詢服務視窗、買票服務視窗、退票服務視窗、改簽服務視窗，這樣拆分過後就好很多， 現在就算退票服務窗口出現了問題沒法退票，但是不會影響買票、諮詢的服務使用。可以極大的提升我們服務的“健壯性”。

分散式

另外再說分散式，還用火車站的例子來說，原來我的服務都在一個地方（比如說同一個機器上），現 在我進行拆分後有諮詢、買票、退票、改簽四個服務，最少4個人，在同一個視窗實在太擁擠了，我就需要分開部署，分成4個視窗。其實火車站也早就是這麼做的，也是分散式微服務的思想。

叢集

最後再說一個叢集的概念。叢集是什麼？就是相同的程式服務做同樣的事情。你看現在買票的服務箱 求量特別大，一個視窗要排起長隊應對不了，那我們就做買票服務叢集，開多個視窗，都是提供買票的服務。改簽就1個視窗，那它就不是叢集，買票有多個服務視窗，這個買票的服務窗a放在一起就是叢集。

分散式架構是分散式計算技術的應用和工具，目前成熟的技術包括J2EE, CORBA和.NET(DCOM)，這些技術牽扯的內容非常廣，相關的書籍也非常多，也沒有涉及這些技術的細節，只是從各種分散式系統平臺產生的背景和在軟體開發中應用的情況來探討

它們的主要異同。

微服務架構是一項在雲中部署應用和服務的新技術。大部分圍繞微服務的爭論都集中在容器或其他技術是否能很好的實施微服務，而紅帽說API應該是重點。（推薦學習：Java影片教程）

微服務可以在“自己的程式”中執行，並透過“輕量級裝置與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程式中執行。透過這一點我們就可以將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務都可以被內部獨立程序所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小程序範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體程序的架構。

從概念理解，分散式服務架構強調的是服務化以及服務的分散化，微服務則更強調服務的專業化和精細分工；從實踐的角度來看，微服務架構通常是分散式服務架構，反之則未必成立。所以，選擇微服務通常意味著需要解決分散式架構的各種難題。

區別分散式的方式是根據不同機器不同業務。

將一個大的系統劃分為多個業務模組，業務模組分別部署到不同的機器上，各個業務模組之間透過介面進行資料互動。區別分散式的方式是根據不同機器不同業務。

微服務更加強調單一職責、輕量級通訊(HTTP)、獨立性並且程序隔離。

微服務與分散式的細微差別是，微服務的應用不一定是分散在多個伺服器上，他也可以是同一個伺服器。

分散式是否屬於微服務？

不一定，如果一個很大應用，拆分成三個應用，但還是很龐大，雖然分散式了，但不是微服務。。微服務核心要素是微小。。

微服務架構是分散式服務架構的子集。

微服務架構透過更細粒度的服務切分，使得整個系統的迭代速度並行程度更高，但是運維的複雜度和效能會隨著服務的粒度更細而增加。

微服務重在解耦合，使每個模組都獨立。分散式重在資源共享與加快計算機計算速度。

你好我是從事多年的java軟體開發工程師，對java微服務和分散式有比較深入的理解，下面我就給你介紹下他們的區別。

第一，你要知道什麼是微服務？書本上的解釋太抽象晦澀難懂，我個人認為微服務就是很小的服務，小到一個服務只對應一個單一的功能，只做一件事。這個服務可以單獨部署執行，服務之間可以透過rpc來相互互動，每個微服務都是由獨立的小團隊開發，測試，部署，上線，負責它的整個生命週期。

第二，你要知道什麼是分散式？分散式服務顧名思義服務是分散部署在不同的機器上的，一個服務可能負責幾個功能，是一種面向SOA架構的，服務之間也是透過rpc來互動或者是webservice來互動的。

我從事JAVA開發多年，對微服務，分散式小有研究，下面說下我的拙見！

分散式誕生背景:

一開始的網站系統功能比較單一，比如只提供影片搜尋，下載等！這樣的網站只需要部署在一臺伺服器上就可以提供全部的功能，這叫做單一系統！

後來，隨著網站的發展，一臺伺服器遭遇攻擊，或者斷電，CPU滿載，訪問量暴增等問題影響，無法繼續正常提供服務，我們透過使用多臺應用伺服器，一臺代理伺服器（nginx），實現一個服務叢集，這叫做集群系統！

然後，老闆說我們網站的功能太單一了，吸引不了更多的使用者，然後我們就加入了會員系統，網購系統，積分系統，還提供當地天氣查詢，廣告系統，直播等等！然後我們發現原本好好的網站什麼亂七八糟的功能都有了，還是在一個系統裡面，假如天氣模組掛了，整個系統就掛了，怎麼辦呢？拆！拆！拆！

我們把廣告，積分，網購，天氣，這些系統拆分到不同的伺服器上，以rpc（remote peocess call）方式呼叫，滿足各大模組的解耦，如果天氣模組掛了，其他的功能正常呼叫！

那麼服務解耦之後，怎麼互相呼叫呢？各種技術層出不窮，基本都是基於tcp/ip協議和http協議的框架，比如hessian，webservice，dubbo，hsf等等！還有最新的微服務，以spring boot為代表！

所以，可以說微服務是分散式架構構想的技術實現，解決分散式的具體技術方案！

spring boot（spring cloud）作為微服務架構中的領頭羊，具體優點有這些:

①，配置檔案集中化，統一化！

②，部署方式簡單化，main方法啟動，就完成部署！

④，RESTFUL風格的服務暴露方式！

⑤，熔斷器，服務追蹤，安全管理，資料匯流排等等！

微服務就像設計模式一樣，實現了功能，服務之間的解耦，保證了服務的穩定！以後微服務還是發展的趨勢，掌握分散式架構和微服務實現是每個伺服器開發工程師必不可缺的技能！

本人架構師，簡單的說，微服務是架構設計方式，分散式是系統部署方式，兩者概念不同，菜鳥經常分不清。

在做架構設計的時候，先做邏輯架構，再做物理架構，當你拿到需求後，估算過最大使用者量和併發量後，計算單個應用伺服器能否滿足需求，如果使用者量只有幾百人的小應用，單體應用就能搞定，即所有應用部署在一個應用伺服器裡，如果是很大使用者量，且某些功能會被頻繁訪問，或者某些功能計算量很大，建議將應用拆解為多個子系統，各自負責各自功能，這就是微服務架構。

邏輯架構設計完後就該做物理架構設計，系統應用部署在超過一臺伺服器或虛擬機器上，且各分開部署的部分彼此透過各種通訊協議互動資訊，就可算作分散式部署，生產環境下的微服務肯定是分散式部署的，分散式部署的應用不一定是微服務架構的，比如叢集部署，它是把相同應用複製到不同伺服器上，但是邏輯功能上還是單體應用。

推薦一個網際網路很火的技術——你還不知道微服務如何zhuangbi？什麼是 Spring Boot ？

解釋一下：Spring Boot 可以構建一切。Spring Boot 設計之初就是為了最少的配置，最快的速度來啟動和執行 Spring 專案。Spring Boot 使用特定的配置來構建生產就緒型的專案。

Spring Boot 的特性：

使用 Spring 專案引導頁面可以在幾秒構建一個專案

方便對外輸出各種形式的服務，如 REST API、WebSocket、Web、Streaming、Tasks

非常簡潔的安全策略整合

支援關係資料庫和非關係資料庫

支援執行期內嵌容器，如 Tomcat、Jetty

強大的開發包，支援熱啟動

自動管理依賴

自帶應用監控

支援各種 IED，如 IntelliJ IDEA、NetBeans

為什麼學 Spring Boot

透過谷歌趨勢來看 Spring Boot 在美國的使用情況發現，中國和美華人民使用 Spring Boot 的整體頻率保持一致，看來國內技術人同步全球的技術頻率越來越快。

Spring Boot 不是為了取代 Spring ，Spring Boot 基於 Spring 開發，是為了讓人們更容易的使用 Spring。

Spring Boot 和微服務架構

網際網路產品需求變化快，使用者群體龐大。在這種情況下，如何構建靈活、易擴充套件的系統，快速應對需求的變化；並且，如何保證系統的可伸縮性、高可用性，成為系統架構面臨的挑戰。

開發一個大型而全的系統已經很難滿足市場對技術的需求，於是從單獨架構發展到分散式架構，又從分散式架構發展到 SOA 架構，服務不斷的被拆分和分解，粒度也越來越小，直到微服務架構的誕生。

Spring Boot 的研發融合了微服務架構的理念，實現了在 Java 領域內微服務架構落地的技術支撐。Spring Boot 在開發、測試、部署、運維等方面都做了大量的最佳化，可以快速響應需求、獨立完成開發部署上線。從目前眾多的技術棧對比來看 Spring Boot 是 Java 領域微服務架構最優落地技術沒有之一。

Spring Boot 的優勢

Spring Boot 集成了大量常用的第三方庫配置（如 Redis、MongoDB、JPA、RabbitMQ、Quartz 等），幾乎可以零配置的開箱即用，使開發者能夠更加專注於業務邏輯。

Spring Boot 開發專案的優勢：

Spring Boot 快速整合各種解決方案提升開發效率。

Spring Boot 使配置變簡單，提供了豐富的 Starters，整合主流開源產品只需簡單配置。

Spring Boot 使部署變簡單，內嵌啟動容器，一個命令即可啟動專案，結合 Jenkins、Docker 自動化運維非常容易實現。

Spring Boot 使監控變簡單，自帶監控元件，使用 Actuator 輕鬆監控服務各項狀態。

Spring Boot 就是儘可能的簡化應用開發的門檻。解放出更多生產力，讓開發人員將精力集中在業務上，而不是各種配置、語法所設定的門檻上。

Spring Boot 所整合的技術棧，幾乎都是各網際網路公司在使用的技術，想進入或者跳槽網際網路公司的技術人可以跟著 Spring Boot 的路線去學習，基本可以瞭解國內外網際網路公司的技術特點。

如果自學能力強可以看書查資料，如果你追求學習效率、想省事，想盡快開始工作實踐；我給你推薦一個 Spring Boot 的入門課程，尤其是你這樣的入門級程式設計師，比你自己去搜索、去折騰要有效的多。

你還不知道微服務？那怎麼加（zhuang）薪（bi）SpringCloud 簡介

前言

前段時間參與了公司的技術選型，一方面瞭解了微服務，另一方面就是了解研究SpringCloud。

主要內容

微服務架構集大成者，雲計算最佳業務實踐。——這句話來自SpringCloud中文網。可見SpringCloud的地位還是蠻高的。

概念

關於概念區分這裡，可能大家都有聽過Spring，也聽過SpringBoot，再加上現在提到的SpringCloud，這名字裡都帶著Spring，是不是有點暈了，莫急莫急，理清思路，我們先看一張圖。

Spring是一個輕量級的Java開發框架，它能使用基本的JavaBean代替EJB。

SpringBoot是由Pivotal團隊提供的全新框架，用來簡化新Spring應用的初始搭建和開發過程。開發人員無需定義樣板化配置。

SpringCloud是一系列框架的有序集合，它把好的東西集合到一起，這就是所謂的集大成者。同時它利用SpringBoot的開發便利性巧妙的簡化了分散式系統基礎設施的開發。

組成

參考英文官網列舉的20個主要專案：

常用專案簡介：

Spring Cloud Config 是配置管理工具包，讓你可以把配置放到遠端伺服器，幾種化管理叢集配置，目前支援本地儲存，Git以及Subversion。

Eureka 雲端服務發現，一個基於 REST 的服務，用於定位服務，以實現雲端中間層服務發現和故障轉移。

Hystrix 熔斷器，容錯管理工具，旨在透過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力。

Zuul 是在雲平臺上提供動態路由,監控,彈性,安全等邊緣服務的框架。Zuul 相當於是裝置和 Netflix 流應用的 Web 網站後端所有請求的前門。

Spring Cloud Bus 事件、訊息匯流排，用於在叢集（例如，配置變化事件）中傳播狀態變化，可與Spring Cloud Config聯合實現熱部署。

Spring Cloud Data Flow 大資料操作工具，作為Spring XD的替代產品，它是一個混合計算模型，結合了流資料與批次資料的處理方式。

優點

SpringCloud很有可能成為未來微服務架構的標準框架。

約定優於配置

開箱即用、快速啟動

適用於各種環境

輕量級的元件

元件支援豐富，功能齊全

選型中立

缺點

文件較少，國內研究並不成熟，相對國外較為火熱，社群活躍度高。

相關技術棧

小結

對於SpringCloud的研究認識算是開闊了學習當中的眼界，與之前瞭解的EJB相比，學習上的宏觀認識知識網又在不斷的完善。對於SpringCloud的學習☞

怎麼學？

Dubbo、Redis、設計模式、Netty、zookeeper、Spring cloud、分散式、高併發等架構技術

Docker簡介

什麼是Docker？

Docker是一個用於開發、遷移、執行的開發平臺。它使你能夠將你的應用程式從基礎架構中分離，從而可以快速交付。使用Docker，你可以以與管理應用程式相同的方式來管理這些基礎架構。使用Docker的方法，進行快速開發，測試，並可以顯著的減少編寫程式碼和執行之間的時間延遲。

就像官網上說的：Build，Ship，and Run Any App, Anywhere

Docker平臺

Docker平臺提供了在容器（鬆散和隔離性的環境中）中進行應用程式的打包和執行的功能。隔離性和安全性允許你在指定的主機上執行多個容器。容器是輕量級的，因為它們不需要管理程式的額外負載，但是需要在主機的核心中執行。你甚至可以在實際上是虛擬機器的主機中執行Docker容器。

Docker提供了工具和平臺來管理容器的生命週期：

使用容器開發應用程式及其支援元件

容器成為分發和測試應用程式的單元

當你準備就緒後，將應用程式部署到生產環境中，作為容器或協調服務。無論你的生產環境是本地資料中心，還是雲提供商或者是兩者的混合，所有的東西都是一樣的。

Docker引擎

Docker 引擎是具有以下元件的客戶端-伺服器應用程式：

一種稱為守護程序的長時間執行的程式

一個Rest API，它指定程式可以用來與守護程序通訊的介面，並指示它應該做什麼

CLI（命令列介面）客戶端

CLI使用Rest API來透過指令碼或者CLI 命令來控制守護程序，許多Docker程式使用底層的API和CLI。

我們可以用Docker做什麼？

快速、一致的交付您的應用程式

Docker透過允許開發人員使用提供應用程式服務的本地容器在標準化的環境中簡化開發生命週期。容器適用於連續整合和持續開發（CI/CD）的工作流程。

Docker可以幫助我們完成如下工作：

開發人員再本地編寫程式碼，並使用Docker容器與同事分享他們的工作

使用Docker將其應用程式推送到測試環境，並執行自動和手動測試

當開發人員發現bug時，他們可以將其修復到開發環境中，並將他們重新部署到測試環境中進行測試和驗證

測試完成後，向客戶解決問題就像將更新的映象推送到生產環境一樣簡單。

實時響應部署和擴充套件

基於容器的Docker平臺允許高度便攜的工作負載。Docker容器可以在開發人員的膝上型電腦上執行，在資料中心的物理機或者虛擬機器上執行，也可以在雲提供商或混合的環境中執行。

Docker的便攜性和輕量級特性使得輕鬆實現動態工作負載，按照業務需求，在近乎實時的範圍內，擴大或拆除應用程式和服務。

在同一硬體上執行更多的負載

Docker重量輕，快速。它為基於虛擬機器管理程式的虛擬機器提供了可行的，具有成本效益的替代方案，因此你可以使用更多的計算能力來實現業務目標。Docker是高密度環境和中小型部署的理想選擇，你需要使用更少的資源來做更多的事情。

怎麼學？

Dubbo、Redis、設計模式、Netty、zookeeper、Spring cloud、分散式、高併發等架構技術

分散式和微服務

首先 ，我認為微服務就是分散式框架的一種。

分散式的思想就是把一個系統的不同模組，部署在不同的伺服器上，以應對高併發的問題。

SOA是一種分散式架構，把業務系統分成多個子系統，提供不同的服務，再透過服務組合、編排實現業務流程；通常在SOA架構中，ESB企業服務匯流排扮演了重要的角色。

微服務是SOA的昇華，如果非要說點兒不同的，那麼微服務更加強調服務的細分和專業，去ESB匯流排、去中心化，部署粒度更細，服務擴充套件更靈活。

微服務不只是技術架構

很多同學一說微服務，就說這是一種技術架構，有的推薦使用Dubbo，有的推薦使用Spring Cloud。

我認為，微服務不單單是一種技術架構，也涉及到了管理、組織架構。

大多數的公司，需求、開發、測試、運維都是獨立的團隊，這實際上是有悖於微服務快速迭代的思想；在微服務的架構下，一個服務應該是由一個團隊全權負責的。

不過組織架構方面的事情，真的不是我們能說了算的。

必須要用微服務？我覺得沒有必要為了微服務，而微服務；有的公司把服務拆分，但是資料庫依然是同一個庫，依然是一個專案直接掉另外一個專案的介面，然後對外就宣稱完成了微服務的改造...

架構設計還是要根據需求背景、團隊開發能力、軟硬體實力綜合來考慮。

好的架構是可以進化的，而不是一步到位建成的。

Java微服務和分散式之前一直說，但是對於其中的內在含義沒有深究，就一般理解的基於 Dubbo + Zookeeper 的分散式架構和基於 Spring Boot + Spring Cloud 微服務架構，基於此，之前認為使用 Dubbo 的就是分散式架構，使用 Spring Cloud 的就是微服務架構，這在傳統意義上可能說的通，但是 Dubbo 和 Spring Cloud 生態體系又能夠完美的融合，國內技術人喜歡拿 Dubbo 和 Spring Cloud 進行對比，是因為兩者都是服務治理非常優秀的開源框架。但它們兩者的出發點是不一樣的，Dubbo 關注於服務治理這塊並且以後也會繼續往這個方向去發展。Spring Cloud 關注的是微服務治理的生態。而在閱讀了部分文章之後，發現微服務是架構設計方式，分散式是系統部署方式。

分散式對應的概念是單體部署。單體(傳統web專案)比較適合小專案，其有一些優點，但它的缺點也非常明顯。特別對於網際網路公司來說：開發效率低，程式碼維護難，部署不靈活，穩定性不高，擴充套件性不夠，無法滿足高併發情況下的業務需求。通俗點說就是對於網際網路專案，屬於一直運營中有客戶一直在使用。單體應用的缺陷就暴露出來了，比如可能會因為一個小問題，需要緊急上線，而導致整個網站需要停止，這樣的情況對客戶、業務都是影響很大的，重新部署、備份對於開發人員來說更是不好維護。分散式服務顧名思義服務是分散部署在不同的機器上的，一個服務可能負責幾個功能，是一種面向SOA架構的，服務之間也是透過 rpc 來互動或者是 webservice 來互動的。再談談分散式架構的缺點：跨程序，跨網路的分散式系統對網路延遲和頻寬的效能影響；高度依賴網路狀態、任何一次遠端呼叫都可能失敗，隨著呼叫棧的增多，其可靠性受到挑戰；引入各種中介軟體，非同步通訊大大增加了功能實現的複雜度；分散式系統必然會有分散式事務的出現，這時對資料的一致性，需要在C（一致性）A（可用性）P（分割槽容錯性）中做出選擇；一個系統拆成了多個服務，每個服務都得配置，部署，監控，日誌處理等運維成本。

而微服務是很小的服務，小到一個服務只對應一個單一的功能，只做一件事。這個服務可以單獨部署執行，服務之間可以透過 RPC 來相互互動，每個微服務都是由獨立的小團隊開發，測試，部署，上線，負責它的整個生命週期。微服務的目的是有效的拆分應用，實現敏捷開發和部署。微服務相比分散式服務來說，它的粒度更小，服務之間耦合度更低，由於每個微服務都由獨立的小團隊負責，因此它敏捷性更高，分散式服務最後都會向微服務架構演化，這是一種趨勢， 不過服務微服務化後帶來的挑戰也是顯而易見的，例如服務粒度小，數量大，後期運維將會很難。

得到的同時也意味著失去，權衡與取捨，始終是架構的魅力。特定業務場景下的特定技術選型，特定發展階段的服務架構演進，適合團隊發展和業務支撐的架構選擇需要資深的熟悉業務和技術的架構師來主導，沒有最好，只有更好，只有在不斷的發展演化中才能找到特定企業和團隊的專案風格和基礎架構。

微服務和分散式的概念：

微服務概念：

所謂概念，我們不引用百科以及書本上的複雜理念作為概念。簡單說：微服務就是一個很小的服務，小到一個服務只是去對應一個單一的功能。也就是說，這個服務可以單獨部署以及執行，服務和服務之間可以透過RPC相互互動。每一個微服務都是由一個小團隊開發-->測試-->部署-->上線負責它一整套的生命週期。

分散式概念：

按照名字理解，就是服務是分佈部署在不同的機器上，一個服務可能負責很多功能。生產的環境下的微服務是肯定要分散式部署的。分散式部署的應用不一定是微服務架構。比如：叢集部署，它就是把相同的應用賦值到了不同的伺服器上，但是邏輯功能還是單獨個體應用。

微服務與分散式的區別：

分散式：不同模組部署在不同的伺服器上，作用就是分散式解決網站高併發帶來的問題。

叢集：相同的服務，多平臺伺服器部署相同應用構成一個叢集。作用在於透過負載均衡裝置共同對外提供服務。

SOA（組裝服務/ESB企業服務匯流排）：業務系統分解成多個元件，並且其中每個元件都提供離散、自治以及可複用的服務能力。透過服務的組合和編排來實現上層的業務流程。作用在於簡化維護，降低整體奉獻，伸縮靈活。

微服務（找到讀服務/微服務閘道器open API）架構設計概念，各個服務之間的隔離。以及分散式依賴整體組合，它的特性是單一的，是分散式概念嚴格執行。SOA到微服務構架的演講過程。作用是各個服務可以獨立的應用，組合服務也是可以系統的應用等。

概念：

叢集是個物理形態，分散式是個工作方式。分散式：一個業務分拆多個子業務，部署在不同的伺服器上叢集：同一個業務，部署在多個伺服器上

1：分散式是指將不同的業務分佈在不同的地方。而叢集指的是將幾臺伺服器集中在一起，實現同一業務。

分散式中的每一個節點，都可以做叢集。而叢集並不一定就是分散式的。

舉例：就比如新浪網，訪問的人多了，他可以做一個群集，前面放一個響應伺服器，後面幾臺伺服器完成同一業務，如果有業務訪問的時候，響應伺服器看哪臺伺服器的負載不是很重，就將給哪一臺去完成。

而分散式，從窄意上理解，也跟叢集差不多，但是它的組織比較鬆散，不像叢集，有一個組織性，一臺伺服器垮了，其它的伺服器可以頂上來。

分散式的每一個節點，都完成不同的業務，一個節點垮了，那這個業務就不可訪問了。

2：簡單說，分散式是以縮短單個任務的執行時間來提升效率的，而叢集則是透過提高單位時間內執行的任務數來提升效率。

例如：如果一個任務由 10 個子任務組成，每個子任務單獨執行需 1 小時，則在一臺伺服器上執行該任務需 10 小時。

採用分散式方案，提供 10 臺伺服器，每臺伺服器只負責處理一個子任務，不考慮子任務間的依賴關係，執行完這個任務只需一個小時。(這種工作模式的一個典型代表就是 Hadoop 的 Map/Reduce 分散式計算模型）

而採用叢集方案，同樣提供 10 臺伺服器，每臺伺服器都能獨立處理這個任務。假設有 10 個任務同時到達，10 個伺服器將同時工作，1 小時後，10 個任務同時完成，這樣，整身來看，還是 1 小時內完成一個任務！

好的設計應該是分散式和叢集的結合，先分散式再叢集，具體實現就是業務拆分成很多子業務，然後針對每個子業務進行叢集部署，這樣每個子業務如果出了問題，整個系統完全不會受影響。

另外，還有一個概念和分散式比較相似，那就是微服務。

微服務是一種架構風格，一個大型複雜軟體應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力。

區別：

1.分散式

將一個大的系統劃分為多個業務模組，業務模組分別部署到不同的機器上，各個業務模組之間透過介面進行資料互動。區別分散式的方式是根據不同機器不同業務。

上面：service A、B、C、D 分別是業務元件，透過API Geteway進行業務訪問。

注：分散式需要做好事務管理。

2.叢集模式

叢集模式是不同伺服器部署同一套服務對外訪問，實現服務的負載均衡。區別叢集的方式是根據部署多臺伺服器業務是否相同。

注：叢集模式需要做好session共享，確保在不同伺服器切換的過程中不會因為沒有獲取到session而中止退出服務。

一般配置Nginx*的負載容器實現：靜態資源快取、Session共享可以附帶實現，Nginx支援5000個併發量。

3.分散式是否屬於微服務？

答案是肯定的。微服務的意思也就是將模組拆分成一個獨立的服務單元透過介面來實現資料的互動。

4.微服務架構

微服務的設計是為了不因為某個模組的升級和BUG影響現有的系統業務。微服務與分散式的細微差別是，微服務的應用不一定是分散在多個伺服器上，他也可以是同一個伺服器。

分散式和微服的架構很相似，只是部署的方式不一樣而已。

分散式：不同模組部署在不同伺服器上作用：分散式解決網站高併發帶來問題叢集：相同的服務多臺伺服器部署相同應用構成一個叢集作用：透過負載均衡裝置共同對外提供服務SOA[組裝服務/ESB企業服務匯流排]業務系統分解為多個元件，讓每個元件都獨立提供離散，自治，可複用的服務能力透過服務的組合和編排來實現上層的業務流程作用：簡化維護,降低整體風險,伸縮靈活微服務[找到服務/微服務閘道器open API]架構設計概念,各服務間隔離（分散式也是隔離）,自治（分散式依賴整體組合）其它特性(單一職責,邊界,非同步通訊,獨立部署)是分散式概念的跟嚴格執行SOA到微服務架構的演進過程作用：各服務可獨立應用，組合服務也可系統應用(巨石應用[monolith]的簡化實現策略-平臺思想)

簡單來說，微服務就是很小的服務，基本上一個服務只有一個單一的功能，只做一件事。這個服務可以單獨部署執行，服務與服務之間的互動是透過rpc來實現的，每個微服務基本都是由獨立的小團隊來管理，負責這個服務的正常執行。

分散式服務則是把服務按模組進行拆分，部署在不同的伺服器上，一個服務可能負責處理幾個功能，是一種面向SOA的架構，服務之間的互動也是透過rpc來互動或者是webservice來實現的。

不難發現，微服務相比分散式服務來說，它的粒度更小，各個服務之間耦合度更低，它敏捷性也更高，按現在的趨勢來看，分散式服務慢慢的會向微服務架構演化。所以對微服務的瞭解也是每個開發人員應該瞭解的。現在市場上也有很多微服務的軟體或平臺，之前因為工作需要接觸過很多快速開發平臺，所以以這個為例子，像天翎的myapps、泛微或蘭陵著一些平臺都是可以作為參考的例子。