一、什麼是微服務架構
微服務
微服務架構是一種架構模式或者說是一種架構風格，就是把一個大型的單個應用程序和服務拆分為數十個的支持微服務。一個微服務的策略可以讓工作變得更為簡便，它可擴展單個組件而不是整個的應用程序堆棧，從而滿足服務等級協議。該架構的設計目標是通過將功能分解到各個離散的服務中以實現對解決方案的解耦。微服務設計原則：1、各司其職 2、服務高可用和可擴展性。
它提倡將單一應用程序劃分成一組小的服務，每個服務運行獨立的自己的進程中，服務之間互相協調、互相配合，為用戶提供最終價值。
服務之間採用輕量級的通信機制互相溝通（通常是基於HTTP 的 RESTful API） 。每個服務都圍繞著具體業務進行構建，並且能夠被獨立地部署到生產環境、類生產環境等。
二、為什麼要使用微服務架構
傳統架構是單一架構模式,就是將項目整體打包部署,比如Java語言的項目會打成war包,部署在tomcat或者jetty應用服務器上,如果使用SpringBoot還可以打成jar包。單一架構模式在項目初期的時候開發,測試,部署方便,但是隨著項目逐步開發,項目工程會很大,最終互相之間會有繁瑣的jar包
微服務架構是將整體項目分割成項目關聯的獨立服務,一個服務通常會實現一組獨立的功能,包含自己的邏輯,各個微服務之間關聯通過暴露API來實現,這些獨立的微服務可以部署在不同的服務器,虛擬機或系統中。
微服務有如下優點：
· 微服務是松藕合的，無論是在開發階段或部署階段都是獨立的。
· 能夠快速響應, 局部修改容易, 一個服務出現問題不會影響整個應用。
· 易於和第三方應用系統集成, 支持使用不同的語言開發, 允許你利用融合最新技術。
· 每個微服務都很小，足夠內聚，足夠小，代碼容易理解。團隊能夠更關注自己的工作成果, 聚焦指定的業務功能或業務需求。
· 開發簡單、開發效率提高，一個服務可能就是專一的只幹一件事, 能夠被小團隊單獨開發，這個小團隊可以是 2 到 5 人的開發人員組成。
同樣的，微服務存在如下缺點:
· 微服務架構帶來過多的運維操作, 可能需要團隊具備一定的 DevOps 技巧.
· 分佈式系統可能複雜難以管理。因為分佈部署跟蹤問題難。當服務數量增加，管理複雜性增加。
微服務之必要性，通過微服務架構模式我們可以將不確定的問題拆分為足夠小，足夠清晰的應用，幫助我們梳理問題。微服務應用有助於我們更好的實現分佈式，實現根據不同業務特性彈性伸縮。同時微服務由於其微小，使得我們更容易控制，也更容易進行DevOps敏捷迭代，快速交付。同時結合微服務治理平臺可以對服務進行全鏈路監控，實現業務高可用。微服務不能直接解決慢的問題，但是微服務可以幫你一步步拆解慢的問題，最終解決應用問題。當然微服務很美好，但是微服務同樣會帶來新的問題，這裡略，所以最後總結沒有完美的架構，只有適合的架構。架構也是一個演進迭代的過程。
三、Spring Cloud介紹
Spring Cloud是一系列框架的有序集合。它利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發，如服務發現註冊、配置中心、消息總線、負載均衡、斷路器、數據監控等，都可以用Spring Boot的開發風格做到一鍵啟動和部署。Spring Cloud並沒有重複製造輪子，它只是將各家公司開發的比較成熟、經得起實際考驗的服務框架組合起來，通過Spring Boot風格進行再封裝屏蔽掉了複雜的配置和實現原理，最終給開發者留出了一套簡單易懂、易部署和易維護的分佈式系統開發工具包。
Spring Cloud組成
Spring Cloud的子項目，大致可分成兩類，一類是對現有成熟框架"Spring Boot化"的封裝和抽象，也是數量最多的項目；第二類是開發了一部分分佈式系統的基礎設施的實現，如Spring Cloud Stream扮演的就是Kafka, ActiveMQ這樣的角色。
· Spring Cloud Netflix
是對Netflix開發的一套分佈式服務框架的封裝，包括服務的發現和註冊，負載均衡、斷路器、REST客戶端、請求路由等。
· Spring Cloud Config
配置管理工具，將配置信息中央化保存, 配置Spring Cloud Bus可以實現動
態修改配置文件。實現應用配置的外部化存儲，支持客戶端配置信息刷新、加密/解密配置內容等。
· Spring Cloud Bus
Spring Cloud Bus將分佈式系統的節點與輕量級消息代理鏈接。這可以用於廣播狀態更改（例如配置更改）或其他管理指令。一個關鍵的想法是，總線就像一個分佈式執行器，用於擴展的Spring Boot應用程序，但也可以用作應用程序之間的通信通道。目前唯一的實現是使用AMQP代理作為傳輸，但是相同的基本功能集（還有一些取決於傳輸）在其他傳輸的路線圖上。
· Spring Cloud Stream
Spring Cloud Stream是構建消息驅動的微服務應用程序的框架。Spring Cloud Stream基於Spring Boot建立獨立的生產級Spring應用程序，並使用Spring Integration提供與消息代理的連接。它提供了來自幾家供應商的中間件的意見配置，介紹了持久發佈訂閱語義，消費者組和分區的概念。
· Spring Cloud Security
基於Spring Security的安全工具包，為我們的應用程序添加安全控制，並能配合Netflix使用。Spring Cloud Security提供了一組用於構建安全應用程序和服務的原語，最小化。可以從外部（或集中）高度配置的聲明式模型適用於通常使用中央契約管理服務的大型合作遠程組件系統的實現。在像Cloud Foundry這樣的服務平臺上也很容易使用。基於Spring Boot和Spring安全性OAuth2，我們可以快速創建實現常見模式的系統，如單點登錄，令牌中繼和令牌交換。
· Spring Cloud Zookeeper
該項目通過自動配置並綁定到Spring環境和其他Spring編程模型成語，為Spring Boot應用程序提供Zookeeper集成。通過幾個簡單的註釋，您可以快速啟用和配置應用程序中的常見模式，並使用基於Zookeeper的組件構建大型分佈式系統。提供的模式包括服務發現和配置。智能路由（Zuul）和客戶端負載平衡（Ribbon），斷路器（Hystrix）通過與Spring Cloud Netflix的集成提供。
· Spring Cloud Eureka
Spring Cloud Eureka 是 Spring Cloud Netflix 微服務套件中的一部分，它基於Netflix Eureka 做了二次封裝服務治理組件，包含服務註冊與發現，主要負責完成微服務架構中的服務治理功能。
四、Spring Cloud核心技術
ELK 日誌聚合
ELK 是Elasticsearch、Logstash、Kibana的簡稱，這三者是核心套件，但並非全部。
Elasticsearch是實時全文搜索和分析引擎，提供蒐集、分析、存儲數據三大功能；是一套開放REST和JAVA API等結構提供高效搜索功能，可擴展的分佈式系統。它構建於Apache Lucene搜索引擎庫之上。
Logstash是一個用來蒐集、分析、過濾日誌的工具。它支持幾乎任何類型的日誌，包括系統日誌、錯誤日誌和自定義應用程序日誌。它可以從許多來源接收日誌，這些來源包括 syslog、消息傳遞（例如 RabbitMQ）和JMX，它能夠以多種方式輸出數據，包括電子郵件、websockets和Elasticsearch。
Kibana是一個基於Web的圖形界面，用於搜索、分析和可視化存儲在 Elasticsearch指標中的日誌數據。它利用Elasticsearch的REST接口來檢索數據，不僅允許用戶創建他們自己的數據的定製儀表板視圖，還允許他們以特殊的方式查詢和過濾數據
Spring Boot Admin 服務監控
Spring Boot Admin 用於監控基於 Spring Boot 的應用，它是在 Spring Boot Actuator 的基礎上提供簡潔的可視化 WEB UI。Spring Boot Admin 提供了很多功能，如顯示 name、id 和 version，顯示在線狀態，Loggers 的日誌級別管理，Threads 線程管理，Environment 管理等。
Spring Cloud Sleuth 分佈服務鏈路追蹤
Spring Cloud Sleuth為Spring Cloud實現分佈式跟蹤解決方案。它在整個分佈式系統中能跟蹤一個用戶請求的過程(包括數據採集，數據傳輸，數據存儲，數據分析，數據可視化)，捕獲這些跟蹤數據，就能構建微服務的整個調用鏈的視圖，這是調試和監控微服務的關鍵工具。
Jenkins 自動化部署
Jenkins是基於Java開發的一種持續集成工具，用於監控持續重複的工作。簡單點來講就是配置好Jenkins以後可以一鍵發佈項目，包括從GIT master分支拉取最新的代碼，然後打包，然後上傳到遠程Linux服務器發佈等一系列步驟它都可以幫你一鍵完成。這無疑可以省去很多程序員重複性繁瑣的操作。特別是對於現在的Spring Cloud微服務來說，一個項目由多個小項目組成，每個小項目都獨立部署，使用Jenkins是最好的部署和管理工具了
微服務數據一致性
在分佈式系統架構中有一個CAP理論：任何分佈式系統只可同時滿足一致性（Consistency）、可用性（Availability）、分區容錯性（Partition tolerance）中的兩點，沒法三者兼顧。對於分佈式系統來說，分區容錯性是基本要求，否則就失去了價值。因此，就只能在可用性和一致性之間做出選擇。如果選擇提供一致性需要付出在滿足一致性之前阻塞其他併發訪問的代價。這可能持續一個不確定的時間，尤其是在系統已經表現出高延遲時或者網絡故障導致失去連接時。依據目前的成功經驗，可用性一般是更好的選擇，但是在服務和數據庫之間維護數據一致性是非常根本的需求，微服務架構中選擇滿足最終一致性。
微服務拆分原則和方法
· 單一職責、高內聚低耦合;
· 服務粒度適中;
· 考慮團隊結構:（康威定律：設計系統的組織其產生系統的設計和架構等價於組織間的溝通結構。就是指每個團隊開發設計和測試發佈自己團隊的微服務時，要互不干擾系統效率才能得到提升，）
· 以業務模型切入:（領域模型：對具體某個邊界領域的抽象，反應了領域內用戶業務需求的本質。領域模型只反應業務與任何技術是現實沒有關係的，不僅反應領域間的實體概念還能反應領域間的過程概念）
· 演進式的拆分;
· 避免環形依賴與雙向依賴:（如：商品服務於訂單服務相互依賴）
微服務API網關
API網關是一個服務器，是系統的唯一入口。從面向對象設計的角度看，它與外觀模式類似。API網關封裝了系統內部架構，為每個客戶端提供一個定製的API。它可能還具有其它職責，如身份驗證、監控、負載均衡、緩存、請求分片與管理、靜態響應處理。API網關方式的核心要點是，所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。通常，網關也是提供REST/HTTP的訪問API。
API網關應當具備以下功能：
· 性能：API高可用，負載均衡，容錯機制。
· 安全：權限身份認證、脫敏，流量清洗，後端簽名（保證全鏈路可信調用）,黑名單（非法調用的限制）。
· 日誌：日誌記錄（spainid,traceid）一旦涉及分佈式，全鏈路跟蹤必不可少。
· 緩存：數據緩存。
· 監控：記錄請求響應數據，API耗時分析，性能監控。
· 限流：流量控制，錯峰流控，可以定義多種限流規則。
· 灰度：線上灰度部署，可以減小風險。
· 路由：動態路由規則。
目前，比較流行的網關有：Nginx 、 Kong 、Orange等，還有微服務網關Zuul 、Spring Cloud Gateway等。
微服務交互服務註冊和發現
註冊中心：
接受服務提供者的註冊、存儲服務提供者的服務信息 ，比如ip 端口號 服務名這些信息；
並且與微服務保持心跳，如果心跳不能保持則註銷該實例。
所以註冊中心主要提供服務提供者信息的存儲，另外與服務提供者保持心跳以監控服務提供者的存活。
服務提供者：
向註冊中心提供服務信息，以及一些健康狀態。
服務消費者：
定期向註冊中心發送查詢請求，以獲取服務提供者的信息，獲取信息之後就向服務提供者發起服務調用。
當服務提供者向註冊中心 ，註冊或者註銷時，它可以接收到來自注冊中心的變更通知。通過變更通知，服務消費者可以實時獲得服務提供者的信息。
