同樣是筆記摘錄自---極客時間 李運華 《從0開始學架構》。
1、微服務和soa比較
因為兩者互相聯絡、互相區別。首先要區分出來。流行觀點有：a、微服務是soa的一種實現形式；b、微服務是soa去掉esb，就是一種輕量級的soa；c、兩者是看起來相似實質上有本質不同的架構模式。
前面部落格裡面，王磊的筆記有記錄，他的觀點是a。但本文作者理解是：soa是基於解決企業的不同系統如何整合提出來的架構模式，是一種重模式，解決的是已有系統的整合，也確實是重量級的，強調的是相容；微服務是基於網際網路發展，在快速交付、基於web的敏捷環境下發展起來，粒度更小，交付更快，基於http模式來通訊，強調的是去耦和快速交付。
2、微服務拆分原則
微服務常見的焦油坑（業務陷阱）
概括起來就是：
·微服務拆分過細，過分強調 small」 ．
·微服務基礎設施不健全，忽略了automated 」 ．
·微服務並不輕量級，規模大了後，lightweight 不再適應．
其實說穿了，就是微服務數量太多，帶來的複雜度問題。所以要根據技術團隊成員數量和能力來劃分微服務，而不是機械地劃分得越多越好。作者提出「三個火槍手」原則，乙個小組3個人。拆分的方法原則有：
a）根據業務邏輯劃分（最常見：各管一件事）
b）根據擴充套件性劃分（需求變動可能大的和比較穩定的分開）
c）根據可靠性、可用性要求來分（核心業務、非核心業務，參見異地多活設計要求）
d）根據效能要求拆分（把瓶頸拆出來）
一般大的專案和團隊，要根據上述原則綜合評估來劃分。
3、微服務基礎設施
顯然，微服務順應敏捷理念在網際網路領域野蠻生長是有原因的。快速交付的背後是devops等，支撐的不只是理念，還有一系列基礎設施：
基礎設施搭建優先順序：
1. 服務發現、服務路由、服務容錯：這是最基本的微服務基礎設施．
2.介面框架、api閘道器：主要是為了提高開發效率，介面框架是提公升內部服務的開發效率，api
閘道器是為了提公升與外部服務對接的效率．
3. 自動化部署、自動化測試、配置中心：主要是為了提公升測試和運維效率．
4. 服務監控、服務跟蹤、服務安全：主要是為了進一步提公升運維效率．
以上 3 和 4 兩類基礎設施，重要性會隨著微服務節點數量增加而越來越重要，但在微服務節 點數量較少的時候，可用人工的方式支撐，雖然效率不高，但也基本能夠頂住。
現在一般都使用springcloud全家桶。
微服務架構學習
微服務框架當下很火，那到底什麼是微服務呢？為什麼會火呢？我們傳統的應用程式是乙個專案，在乙個程序裡面執行的。這樣就會導致各個業務邏輯模組耦合性高，有時 調整時，牽一髮而動全身。傳統的專案大部分採用單體式開發，如下圖所示 如上圖所示，單體式開發弊端顯而易見。我們改動訂單模組時，倉儲 物流 使用者模組也...
微服務與微服務架構
微服務 微服務強調的是服務的大小，它關注的是某乙個點，是具體解決某乙個問題 提供落地對應服務的乙個服務應用,狹意的看,可以看作eclipse裡面的乙個個微服務工程 或者module。例如 訂單服務 支付服務 微服務架構 馬丁.福勒 martin fowler 微服務架構介紹 微服務架構是 種架構模式...
微服務架構
一 先了解一下什麼是單體應用 就是乙個應用程式包含了所有模組功能，各模組同時部署。當然這種應用模式比較容易部署 測試，但隨著專案的加大，單體模式就會變得越來越臃腫，維護的成本逐漸變高。當乙個模組出錯，整個應用都會出現問題，擴充套件能力也會受到限制。二 什麼是微服務 是將整個應用程式分解為多個模組，各...