springCloud微服務使用

一.微服務簡介

1.演變過程：單體架構、SOA、微服務

2.單體架構：一個應用包含了應用之間全部的功能程序，經過打成war包的方式發佈部署。

缺點：複雜性逐漸偏高、技術債務逐漸變慢、阻礙技術的創新擴展、沒法按需求伸縮

3.SOA：面向服務的架構，是一個組件的架構模型，它將應用程序之間不一樣的功能單點經過服務之間的良好接口進行關聯，接口採用中立的方式進行定義，以一種統一的方式進行交互。

特徵：外部訪問、隨時可用、服務接口分級、鬆散耦合、可複用的服務、服務接口設計管理、標準化服務接口、支持消息模式

4.微服務：以開發一組小型應用的方式進行，開發一個徹底獨立的應用系統，獨立運行本身的進程，並採用http資源API輕量的機制進行相互通訊，並圍繞業務功能進行設計。

特徵：獨立運行進程、獨立的構建系統、輕量級通訊、Rest API的方式應用調用

優勢：易於開發、啓動快、局部修改容易、技術不受限制、按需求伸縮、DevOps

帶來的問題：運維、維護要求高、分佈式複雜性、接口調整成本高、

設計原則：單一原則(只關注本身)、服務自理(獨立)、明確接口、輕量通訊

二.服務發現與註冊

1.建立調用關係的微服務

服務提供者：負責提供Rest API的微服務

服務消費者：負責調用微服務的微服務

二、使用實現微服務註冊與發現

三.微服務容錯

實現容錯機制：

                  1.超時機制：經過網絡請求其餘服務時，都必須設置超時。正常狀況下，一個遠程調用通常在必定的毫秒內獲得請求的響應，若是超時了這個時間、依賴的服務不可用、網絡有問題、響應的時間則會變得很長。一般狀況下，一次請求對應着一個線程、進程。若是響應太慢就得不到這個線程的釋放、又對應着系資源的釋放。若是得不到、則會越積累越多，服務資源就會被耗盡，從而致使服務不可用。因此必須給每一個請求都設置【超時機制】，讓資源儘快的獲得【釋放】。

                  2.斷路器：依賴的服務有大量的超時請求的時候，得不到資源的釋放、積累越多、致使系統服務不可用，再去請求已經沒有意義了。只能是無謂的消耗現有資源從而致使【其餘的服務不可用】，例：設置超時機制2秒，若是在某個時間內100個請求在2秒鐘得不到請求的響應，意味着這個服務發生異常。此時其餘依賴的的請求再去請求已經沒有意義了。

                                使用斷路器實現快速失敗，讓資源獲得快速的響應。例它在某個時間2秒內偵查到200個請求的失敗、超時，就會強迫當即快速失敗，再也不請求所依賴的服務，從而防止應用程序不斷的嘗試執行可能會失敗的操做，這樣應用程序就會執行不用等待錯誤回調、或者去浪費cpu的時間去等待很長很長時間的超時。斷路器也能實現程序的錯誤是否已經獲得修復，若是已經修復、應用程序就會再次調用操做。