由於最近要學習微服務，首選的實踐就是springcloud，但是仔細回顧以往做的項目也逃不出springmvc模式，其中可能有一部分的功能被提取出單獨模塊，也算是歸爲SOA模式 服務模塊劃分，內部通過restful API HTTP調用 ，這些和微服務沒毛錢關係，從宏觀上對微服務架構設計有一個初步的瞭解
1、單體架構
2、單體架構的拆分
3、SOA與微服務
4、微服務的優缺點
5、微服務的消息
6、服務集成
7、服務發現
8、服務註冊
9、數據的去中心化
SOA：是按水平架構劃分爲：前、後端、數據庫、測試等，提soa必須提到的ESB（企業服務總線），簡單 來說 ESB 就是一根管道，用來連接各個服務節點。爲了集 成不同系統，不同協議的服務， 做了消息的轉化解釋和路由工作，讓不同的服務互聯互通；
SOA體系下，服務之間通過企業服務總線（Enterprise Service Bus）通信，許多業務邏輯在中間層（消息的路由、轉換和組織）。微服務架構傾向於降低中心消息總線（類似於ESB）的依賴，將業務邏輯分佈在每個具體的服務終端。微服務：其實和 SOA 架構類似,微服務是在 SOA 上做的昇華，剔除SOA中複雜的ESB企業服務總線採用API網關，強調按垂直架構劃分，按業務能力劃分，每個服務完成一種特定的功能，服務即產品；API網關方式應該是微服務架構中應用最廣泛的設計模式。
API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能個。通常，網關也是提供REST/HTTP的訪問API。服務端通過API-GW註冊和管理服務。SOA將組件以library的方式和應用部署在同一個進程中運行，微服務則是各個服務獨立運行。權限服務A 與支付服務B ，在B 提交支付時 如果需要驗證user權限,只能通過A暴露的接口獲取；不能直接管理表去搞，每個服務都可以單獨一個庫或者跨數據源的庫， 但是需要注意的時 ，可能徒增接口數量，增加工作量
- 儘可能把接口設置成粗粒度，每個服務方法代表一個獨立的功能，而不是某個功能的步驟。否則就會涉及到分佈式事務
SOA架構特點：有序 複用 高效
系統集成：站在系統的角度，解決企業系統間的通信問 題，把原先散亂、無規劃的系統間的網狀結構，梳理成 規整、可治理的系統間星形結構，這一步往往需要引入 一些產品，比如 ESB、以及技術規範、服務管理規範； 這一步解決的核心問題是【有序】
系統的服務化：站在功能的角度，把業務邏輯抽象成 可複用、可組裝的服務，通過服務的編排實現業務的 快速再生，目的：把原先固有的業務功能轉變爲通用 的業務服務，實現業務邏輯的快速複用；這一步解決 的核心問題是【複用】
業務的服務化：站在企業的角度，把企業職能抽象成 可複用、可組裝的服務；把原先職能化的企業架構轉變爲服務化的企業架構，進一步提升企業的對外服務能力；“前面兩步都是從技術層面來解決系統調用、系統功能複用的問題”。第三步，則是以業務驅動把一個業務單元封裝成一項服務。這一步解決的核心問題是【高效】
參考文獻：
http://www.uml.org.cn/zjjs/201708083.asp
https://zhidao.baidu.com/question/1899225333752310100.html
http://blog.sina.com.cn/s/blog_493a84550102wq50.html
————————————————
版權聲明：本文爲CSDN博主「zpoison」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。
原文鏈接：https://blog.csdn.net/zpoison/article/details/80729052