絕不收兵

微服務和分佈式的概念：

微服務概念：

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

分佈式概念：

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

微服務與分佈式的區別：

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

集群：相同的服務，多平臺服務器部署相同應用構成一個集群。作用在於通過負載均衡設備共同對外提供服務。

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

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

傳智播客

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

分佈式誕生背景:

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

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

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

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

這就是分佈式的來源，就是把服務分佈到不同的機器上，實現功能間，服務間的解耦，所以分佈式更像是一種思想，架構！

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

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

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

①，配置文件集中化，統一化！

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

③，服務治理和發現:容器啟動之後，服務統一註冊和消費，能快速發現失效的服務！

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

⑤，熔斷器，服務追蹤，安全管理，數據總線等等！

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

我是謝逅，如文章有不正確的地方，歡迎不吝指正！

此生唯一

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

全棧技術棧

這個問題已經收藏了一個多月了，一直在考慮如何回答這個問題，總結了很長時間終於有了一些感悟（之前一直都是隻可意會不可言傳的感覺），和大家分享一下，如果有不同的建議，歡迎大家留言指正。

分佈式和微服務

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

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

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

  
  

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

微服務不只是技術架構

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

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

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

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

必須要用微服務？

• 我覺得沒有必要為了微服務，而微服務；有的公司把服務拆分，但是數據庫依然是同一個庫，依然是一個項目直接掉另外一個項目的接口，然後對外就宣稱完成了微服務的改造...
  

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

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

我將持續分享Java開發、架構設計、程序員職業發展等方面的見解，希望能得到你的關注。

會點代碼的大叔

概念：

集群是個物理形態，分佈式是個工作方式。

• 分佈式：一個業務分拆多個子業務，部署在不同的服務器上
• 集群：同一個業務，部署在多個服務器上

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影響現有的系統業務。微服務與分佈式的細微差別是，微服務的應用不一定是分散在多個服務器上，他也可以是同一個服務器。

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

曲翎風

推薦一個互聯網很火的技術——你還不知道微服務如何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做簡單介紹，最後附上整理來的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的學習☞

怎麼學？

關注我：私信回覆“架構資料”獲取往期Java高級架構資料、源碼、筆記、視頻

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是高密度環境和中小型部署的理想選擇，你需要使用更少的資源來做更多的事情。

怎麼學？

關注我：私信回覆“架構資料”獲取往期Java高級架構資料、源碼、筆記、視頻

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

java高級

額，首先說說分佈式吧，分佈式最簡單的理解就是講服務分佈在不同的機器上，也就是將服務拆分，然而服務拆分可以是微服務也可以使集群式，一般來說在項目的實際使用中微服務和分佈式都是伴生的關係，也可以說兩者都最終結果都是一致的，服務拆分

分佈式的概念誕生的更早一些，以前是SOA服務，現在則以微服務為主，所有兩者也可以說是從屬的關係，微服務是分佈式的一種具象化實現

西安石頭石頭

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 來相互交互，每個微服務都是由獨立的小團隊開發，測試，部署，上線，負責它的整個生命週期。微服務的目的是有效的拆分應用，實現敏捷開發和部署。微服務相比分佈式服務來說，它的粒度更小，服務之間耦合度更低，由於每個微服務都由獨立的小團隊負責，因此它敏捷性更高，分佈式服務最後都會向微服務架構演化，這是一種趨勢， 不過服務微服務化後帶來的挑戰也是顯而易見的，例如服務粒度小，數量大，後期運維將會很難。

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

夕陽雨晴

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

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

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

當你搞清楚上面兩個概念後你就不難發現他們之間的區別了，微服務相比分佈式服務來說，它的粒度更小，服務之間耦合度更低，由於每個微服務都由獨立的小團隊負責，因此它敏捷性更高，分佈式服務最後都會向微服務架構演化，這是一種趨勢， 不過服務微服務化後帶來的挑戰也是顯而易見的，例如服務粒度小，數量大，後期運維將會很難，因此需要藉助一些工具來自動化管理這些微服務，當然這不屬於本問題的範疇，我就不詳細說了，好了到這裡我已經全面的給你闡述了微服務和分佈式之間的區別了，希望對你有幫助，如果同行對此有不同看法，請在評論區留言討論，謝謝🙏

一個沒有靈魂的程序員

微服務是架構的一種設計方法；分佈式是應用的一種部署形態。不論架構是否採用服務或者微服務進行設計，都可以按照分佈式進行部署。而現在的設計理念(更多是受亞馬遜的成功所影響)比較倡導按照微服務進行架構設計，這樣更利於分佈式部署。

服務或者微服務之間有區別，但相似性更高。傳統的程序調用，一般採用API的方式或者混合編碼。這種方式造成編譯依賴，互相影響比較大。如果按照服務的方式，通過消息進行調用，信息採用標準的格式進行編解碼。依賴被解開，調用與被調用方可以獨自演進，極大提升效率。同時這種方式可以較簡單的實現異構操作系統間的交互，使得系統間集成變成輕而易舉的事情。

發佈方進行新服務的註冊，調用方則動態查詢服務的存在，然後通過消息的方式進行調用。

分佈式則是一種應用部署的創舉，通過彈性伸縮，消息緩存等，使得我們自己編寫的程序具備大容量請求消息的處理能力，這在之前是不可想象的。比如Tomcat、docker等技術。

再引申一步，現有的公有、私有云興起，就依賴容器～微服務～消息中間件等基礎技術。當然這與亞馬遜的技術創舉分不開。

補充強調一下：微服務是一種架構設計方法，與語言無關。

關鍵字: 服務 科技 分佈式計算