參考：
https://blog.csdn.net/zpoison/article/details/80729052
https://blog.csdn.net/qq_35119422/article/details/81560833
https://blog.csdn.net/zhonglunsheng/article/details/83153451
SOA架構和微服務架構的區別
1.SOA架構和微服務架構的區別
首先SOA和微服務架構是一個層面的東西，而對於ESB和微服務網關是一個層面的東西，一個談到是架構風格和方法，一個談的是實現工具或組件。
1.SOA（Service Oriented Architecture）“面向服務的架構”:他是一種設計方法，其中包含多個服務， 服務之間通過相互依賴最終提供一系列的功能。一個服務通常以獨立的形式存在與操作系統進程中。各個服務之間通過網絡調用。
2.微服務架構:其實和 SOA 架構類似,微服務是在 SOA 上做的升華，微服務架構強調的一個重點是“業務需要徹底的組件化和服務化”，原有的單個業務系統會拆分為多個可以獨立開發、設計、運行的小應用。這些小應用之間通過服務完成交互和集成。
微服務架構 = 80%的SOA服務架構思想 + 100%的組件化架構思想 + 80%的領域建模思想
2.ESB和微服務API網關。
1.ESB（企業服務總線），簡單 來說 ESB 就是一根管道，用來連接各個服務節點。為了集成不同系統，不同協議的服務，ESB 做了消息的轉化解釋和路由工作，讓不同的服務互聯互通；
2.API網關:API網關是一個服務器，是系統的唯一入口。從面向對象設計的角度看，它與外觀模式類似。API網關封裝了系統內部架構，為每個客戶端提供一個定制的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理。API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。通常，網關也是提供REST/HTTP的訪問API。服務端通過API-GW注冊和管理服務。
3.SOA架構特點：
系統集成：站在系統的角度，解決企業系統間的通信問題，把原先散亂、無規划的系統間的網狀結構，梳理成規整、可治理的系統間星形結構，這一步往往需要引入 一些產品，比如 ESB、以及技術規范、服務管理規范； 這一步解決的核心問題是【有序】
系統的服務化：站在功能的角度，把業務邏輯抽象成 可復用、可組裝的服務，通過服務的編排實現業務的 快速再生，目的：把原先固有的業務功能轉變為通用 的業務服務，實現業務邏輯的快速復用；這一步解決 的核心問題是【復用】
業務的服務化：站在企業的角度，把企業職能抽象成 可復用、可組裝的服務；把原先職能化的企業架構轉變為服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能復用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是【高效】
4.微服務架構特點：
1.通過服務實現組件化
- 開發者不再需要協調其它服務部署對本服務的影響。
2.按業務能力來划分服務和開發團隊
- 開發者可以自由選擇開發技術，提供 API 服務
3.去中心化
- 每個微服務有自己私有的數據庫持久化業務數據
- 每個微服務只能訪問自己的數據庫，而不能訪問其它服務的數據庫
- 某些業務場景下，需要在一個事務中更新多個數據庫。這種情況也不能直接訪問其它微服務的數據庫，而是通過對於微服務進行操作。
- 數據的去中心化，進一步降低了微服務之間的耦合度，不同服務可以采用不同的數據庫技術（SQL、NoSQL等）。在復雜的業務場景下，如果包含多個微服務，通常在客戶端或者中間層（網關）處理。
4.基礎設施自動化（devops、自動化部署）
- Java EE部署架構，通過展現層打包WARs，業務層划分到JARs最后部署為EAR一個大包，而微服務則打開了這個黑盒子，把應用拆分成為一個一個的單個服務，應用Docker技術，不依賴任何服務器和數據模型，是一個全棧應用，可以通過自動化方式獨立部署，每個服務運行在自己的進程中，通過輕量的通訊機制聯系，經常是基於HTTP資源API，這些服務基於業務能力構建，能實現集中化管理（因為服務太多啦，不集中管理就無法DevOps啦）。
5.主要區別：
功能
SOA
微服務
組件大小
大塊業務邏輯
單獨任務或小塊業務邏輯
耦合
通常松耦合
總是松耦合
公司架構
任何類型
小型、專注於功能交叉團隊
管理
着重中央管理
着重分散管理
目標
確保應用能夠交互操作
執行新功能、快速拓展開發團隊
6.Dubbo服務的最佳實踐
分包
- 服務接口、請求服務模型、異常信息都放在api里面，符合重用發布等價原則，共同重用原則
- api里面放入spring 的引用配置。 也可以放在模塊的包目錄下。
粒度
- 盡可能把接口設置成粗粒度，每個服務方法代表一個獨立的功能，而不是某個功能的步驟。否則就會涉及到分布式事務
- 服務接口建議以業務場景為單位划分。並對相近業務做抽象，防止接口暴增
- 不建議使用過於抽象的通用接口 T T<泛型>，接口沒有明確的語義，帶來后期的維護
版本
- 每個接口都應該定義版本，為后續的兼容性提供前瞻性的考慮 version （maven -snapshot）
- 建議使用兩位版本號，因為第三位版本號表示的兼容性升級，只有不兼容時才需要變更服務版本
- 當接口做到不兼容升級的時候，先升級一半或者一台提供者為新版本，再將消費全部升級新版本，然后再將剩下的一半提供者升級新版本
預發布環境
推薦用法
- 在provider端盡可能配置consumer端的屬性
- 比如timeout、retires、線程池大小、LoadBalance
配置管理員信息
- application上面配置的owner 、 owner建議配置2個人以上。因為owner都能夠在監控中心看到
配置dubbo緩存文件
- 注冊中心的列表
- 服務提供者列表
參考文獻：
http://www.uml.org.cn/zjjs/201708083.asp
https://zhidao.baidu.com/question/1899225333752310100.html
http://blog.sina.com.cn/s/blog_493a84550102wq50.html
一分鍾弄懂什么是分布式和微服務
簡單的說，微服務是架構設計方式，分布式是系統部署方式，兩者概念不同
微服務是啥？
這里不引用書本上的復雜概論了，簡單來說微服務就是很小的服務，小到一個服務只對應一個單一的功能，只做一件事。這個服務可以單獨部署運行，服務之間可以通過RPC來相互交互，每個微服務都是由獨立的小團隊開發，測試，部署，上線，負責它的整個生命周期。
微服務架構又是啥？
在做架構設計的時候，先做邏輯架構，再做物理架構，當你拿到需求后，估算過最大用戶量和並發量后，計算單個應用服務器能否滿足需求，如果用戶量只有幾百人的小應用，單體應用就能搞定，即所有應用部署在一個應用服務器里，如果是很大用戶量，且某些功能會被頻繁訪問，或者某些功能計算量很大，建議將應用拆解為多個子系統，各自負責各自功能，這就是微服務架構。
那么分布式又是啥？
分布式服務顧名思義服務是分散部署在不同的機器上的，一個服務可能負責幾個功能，是一種面向SOA架構的，服務之間也是通過rpc來交互或者是webservice來交互的。邏輯架構設計完后就該做物理架構設計，系統應用部署在超過一台服務器或虛擬機上，且各分開部署的部分彼此通過各種通訊協議交互信息，就可算作分布式部署，生產環境下的微服務肯定是分布式部署的，分布式部署的應用不一定是微服務架構的，比如集群部署，它是把相同應用復制到不同服務器上，但是邏輯功能上還是單體應用。
微服務相比分布式服務來說，它的粒度更小，服務之間耦合度更低，由於每個微服務都由獨立的小團隊負責，因此它敏捷性更高，分布式服務最后都會向微服務架構演化，這是一種趨勢， 不過服務微服務化后帶來的挑戰也是顯而易見的，例如服務粒度小，數量大，后期運維將會很難
微服務與SOA區別
SOA（面向服務的架構）：面向服務的架構（SOA）是一個組件模型，它將應用程序的不同功能單元（稱為服務）通過這些服務之間定義良好的接口和契約聯系起來。接口是采用中立的方式進行定義的，它應該獨立於實現服務的硬件平台、操作系統和編程語言。這使得構建在各種各樣的系統中的服務可以以一種統一和通用的方式進行交互。
微服務：微服務架構是一種將單個應用程序作為一套小型服務開發的方法，每種應用程序都在自己的進程中運行，並與輕量級機制（通常是HTTP資源API）進行通信。這些服務是圍繞業務功能構建的，可以通過全自動部署機制獨立部署。這些服務的集中管理最少，可以用不同的編程語言編寫，並使用不同的數據存儲技術。
SOA和微服務的主要區別：
- 微服務剔除SOA中復雜的ESB企業服務總線，所有的業務智能邏輯在服務內部處理，使用Http（Rest API）進行輕量化通訊
- SOA強調按水平架構划分為：前、后端、數據庫、測試等，微服務強調按垂直架構划分，按業務能力划分，每個服務完成一種特定的功能，服務即產品
- SOA將組件以library的方式和應用部署在同一個進程中運行，微服務則是各個服務獨立運行。
- 傳統應用傾向於使用統一的技術平台來解決所有問題，微服務可以針對不同業務特征選擇不同技術平台，去中心統一化，發揮各種技術平台的特長。
- SOA架構強調的是異構系統之間的通信和解耦合；（一種粗粒度、松耦合的服務架構）
- 微服務架構強調的是系統按業務邊界做細粒度的拆分和部署。
微服務的具體特點：
（1） 獨立部署，靈活擴展
傳統的單體架構是以整個系統為單位進行部署，而微服務則是以每一個獨立組件（如用戶服務、商品服務等）為單位進行部署。
（2） 資源的有效隔離
微服務設計原則之一，就是每一個微服務擁有獨立的數據源，假如微服務A想要讀寫微服務B的數據庫，只能調用微服務B對外暴露的接口來完成。這樣有效的避免了服務之間爭用數據庫和緩存資源所帶來的問題。
同時，由於每一個微服務實例在Docker容器上運行，實現了服務器資源（內存、CPU資源等）的有效隔離。
（3） 團隊組織架構的調整
微服務設計的思想也改變了原有的企業研發團隊組織架構。傳統的研發組織架構是水平架構，前端、后端、DBA、測試分別有自己對應的團隊，屬於水平團隊組織架構。而微服務的設計思想對團隊的划分有着一定的影響，使得團隊組織架構的划分更傾向於垂直架構，比如用戶業務是一個團隊來負責，支付業務是一個團隊來負責。但實際上在企業中並不會把團隊組織架構拆分得這么絕對，垂直架構只是一種理想的架構。
微服務架構的不足之處：
（1） 微服務把原有的項目拆分成多個獨立工程，增加了開發、測試、運維、監控等的復雜度。
（2） 微服務架構需要保證不同服務之間的數據一致性，引入了分布式事務和異步補償機制，為設計和開發帶來一定挑戰。
所以微服務適用於復雜的大系統，小應用盲目的拆分只會增加其維護和開發成本...
鏈接：https://www.zhihu.com/question/37808426/answer/90979979
來源：知乎
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
其次，從實現方式上，兩者都是中立性，語言無關，協議跨平台，相比SOA，微服務框架將能夠帶來更大的敏捷性，並為你構建應用提供 更輕量級、更高效率的開發。而SOA更適合大型企業中的業務過程編排、應用集成。另外還有 微服務甚至是去ESB、去中心化、分布式的，而SOA還是以ESB為核心，大量的WS標准實現。
再次，從服務粒度上，既然是微，必然微服務更倡導 服務的細粒度，重用組合，甚至是每個操作（或方法）都是獨立開發的服務，足夠小到不能再進行拆分。而SOA沒有這么極致的要求，只需要接口契約的規范化，內部實現可以更粗粒度，微服務更多為了 可擴充性、負載均衡以及提高吞吐量而去分解應用，但同時也引發了打破數據模型以及維護一致性的問題。
最后，從部署方式上，這個是最大的不同，對比Monolithic（有人翻譯為單體）的Java EE部署架構，通過展現層打包WARs，業務層划分到JARs最后部署為EAR一個大包，而微服務則打開了這個黑盒子， 把應用拆分成為一個一個的單個服務，應用Docker技術，不依賴任何服務器和數據模型，是一個 全棧應用，可以通過自動化方式獨立部署， 每個服務運行在自己的進程中，通過輕量的通訊機制聯系，經常是基於HTTP資源API，這些服務基於業務能力構建，能實現集中化管理（因為服務太多啦，不集中管理就無法DevOps啦）。