這章具體介紹微服務。
1.微服務的目的
2.微服務的特點
3.微服務的核心要點
以拆分和服務化為基礎，將海量使用者產生的大規模的訪問流量進行分解，採用分而治之的方法，達成使用者需要的功能指標，並同時滿足使用者對高可用、高效能、可伸縮、可擴充套件和安全性的非功能質量的要求。
1.微服務把每個職責單一的功能放在乙個獨立的服務中。
2.每個服務允許在乙個獨立的程序中。
3.每個服務有多個例項在執行，每個例項可以執行在容器化平台內，達到平滑擴充套件伸縮的效果。
4.每個服務有自己的資料儲存，實際上，每個服務應該有自己獨享的資料庫、快取、訊息佇列等資源。
5.每個服務應該有自己的運營平台，以及獨享的運營人員，這包括技術運維和業務運營人員。每個服務都高度自治，內部的變化對外透明。
6.每個服務都可根據效能需求獨立的進行水平伸縮。
微服務架構中職能團隊的劃分
微服務架構按照業務的功能進行劃分，每個單一的業務功能叫做乙個服務，每個服務對應乙個獨立的職能團隊。
微服務倡導去中心化的治理，不推薦每個微服務都使用相同的標準和技術來開發和使用服務。
微服務的互動模式
在微服務領域，微服務之間的互動通過定義良好的介面來實現，不允許使用共享資料來實現。通常使用restful樣式的api或者透明的rpc呼叫。
微服務的組合
根據業務流程處理的需要，以一定的順序呼叫依賴的多個微服務，對依賴的微服務返回的資料進行組合、加工和轉換，最後以一定的形式返回給使用方。
微服務的容錯模式
1.熔斷
當服務的輸入負載迅速增加時，如果沒有有效的措施對負載進行熔斷，則會使服務迅速被壓垮，服務被壓垮會導致依賴的服務都被壓垮，出現雪崩效應，因此，可通過模擬家庭的電路保險開關，在微服務架構中實現熔斷。
2.限流
針對服務突然上量，我們必須有限流機制，限流機制一般會控制訪問的併發量，例如每秒允許處理的併發數及查詢量、請求量等。
2.1計數器
通過原子變數計算單位時間內的訪問次數，如果超過閾值，則拒絕後續的請求，等到下乙個單位時間再重新計數。
2.3令牌桶
通過乙個執行緒在單位時間內生成固定數量的令牌，然後將令牌放入佇列，每次請求呼叫需要從桶中拿取乙個令牌，拿到令牌後才有資格執行請求呼叫，否則只能等待拿到令牌再執行，或者直接丟棄。
微服務的粒度
按照微服務的初衷，服務要按照業務的功能進行拆分，知道每個服務的功能和職責單一，甚至不可再拆分為止，以至於每個服務都能獨立部署，擴容和縮榮方便，能夠有效地提高利用率。拆的越細，服務的耦合度越小，內聚性越好，越適合敏捷發布和上線。
微服務架構的特點
在單體架構下,會非常依賴於專案一開始對技術的選擇,一旦選擇了個技術棧,之後幾年都會被繫結在這樣個技術棧下,很難應對變化。給我們提供了乙個更細粒度使用技術的可能在不同的服務裡可以使用完全不同的技術棧不同的語言 框架甚至資料庫,真正做到用最適合的技術解決最適合的問題,從而讓我們可以更加敏捷地響應需求和市...
微服務專案的整合和測試
1 掌握微服務專案的整合使用 2 掌握swarrger ui的簡單使用 本專案模擬的是乙個簡單的 管理系統，其專案整體結構如圖所示。由於microservice orderservice 訂單微服務 和microservice userservice 使用者微服務 都涉及了mysql資料庫的連線使用...
微服務架構核心（三） 微服務技術架構體系
微服務架構的名字裡雖然有個 微 但它涉及的整體架構體系可一點也不 微 微服務架構除了業務 的開發以外，還需要很多的支撐服務。每個公司都有自己的微服務架構體系，雖然在細節上有很多不同，但是整體的思路是類似的，下圖展示了乙個比較成熟的微服務架構體系。這個體系按照請求接入，由外到內的順序，將整體架構分為接...