單體應用
微服務是相對於單體應用的，在介紹微服務之前，先簡單介紹一下單體應用：通常是由三個重要部分組成：客戶端界面（由HTML、JavaScript組成）、數據庫（由許多的表組件構成一個通用的、相互關聯的數據管理系統）、服務端應用。服務端應用處理客戶端的HTTP請求、執行邏輯、檢索並更新數據庫中的數據、然後將處理後的數據返回給客戶端。
一個單體應用被構建成一個系統時，業務中所有請求都要在單一的進程中處理完成，當訪問量很高情況下服務器壓力是很大的。當然可以水平擴展，利用負載均衡將實例佈署到多臺服務器中。
單體架構的缺點
- [ ] 開發效率低
- [ ] 代碼維護難
- [ ] 部署不靈活
- [ ] 穩定性不高
- [ ] 擴展性不高
雲時代
在此之前單體應用也是很成功的，但是隨著雲時代的到來，單體應用就顯得有些不妥了，特別是應用程序發佈到雲端的時候，一個功能的變更，需要統一的編譯和發佈。這樣的架構模式很難使得一個模塊的變更不影響到其他模塊，而且在擴展方面也只能進行整體的擴展，不能根據正在運行的部分進行擴展。
微服務架構風格
雲時代單體應用的尷尬導致了微服務架構風格的出現：以服務構建應用。
一個系統由多個服務組成，各服務可以被獨立部署、獨立擴展，每個服務也都提供了清晰的模塊邊界，甚至不同的服務都可以使用不同的編程語言來實現，也可以由不同的團隊進行管理。
微服務介紹
微服務是SOA架構下的最終產物
SOA介紹
SOA架構即面向服務的架構，是一種組件模型，它將應用程序的不同功能單元進行拆分，並通過這些服務之間定義良好的接口和協議聯繫起來；這些不同功能的單元在被拆分後，就被稱為
服務。在這種架構中，最重要的是接口的定義，這種定義是不依賴於實現服務的硬件平臺、操作系統和編程語言的，即中立的。這樣就可以使各服務可以與非本系統的服務以同樣方式進行交互，使得各服務之間松耦合。它的優點就是非常靈活——當組成整個應用程序的每個服務的內部結構和實現逐漸地發生改變時，各服務能夠繼續存在並提供服務。
SOA的特徵：
- 可從企業外部訪問
- 隨時可用
- 粗粒度的服務接口分級
- 鬆散耦合
- 可重用的服務
- 服務接口設計管理
- 標準化的服務接口
- 支持各種消息模式
- 精確定義的服務契約
分佈式定義
> 旨在支持應用程序和服務的開發，可以利用物理架構，由多個自治的處理元素，不共享主內存，但通過網絡發送消息合作。
微服務風格特徵
- 組件化與服務組件化的主要方式是把它拆分成服務，這些組件被鏈接到程序，並通過內存中函數調用來調用，而服務是進程外組件，他們利用某個機制通信，比如WebService請求，或遠程過程調用。把服務當成組件的一個主要原因是，服務可以獨立部署。如果應用程序是由一個單獨進程中的很多庫組成，那麼對任何一個組件的改變都將導致必須重新部署整個應用程序。但是如果把應用程序拆分成很多服務，只需要重新部署那個改變的服務。另一方面，把服務當組件將擁有更清晰的組件接口。
- 圍繞業務功能的組織 當尋找把一個大的應用程序拆分成小的部分時，通常管理都會集中在技術層面，UI團隊、服務端業務邏輯團隊和數據庫團隊。當使用這種標準對團隊進行劃分時，甚至小小的更變都將導致跨團隊項目協作，從而消耗時間和增加溝通成本。微服務的劃分方法不同，它傾向圍繞業務功能的組織來分割服務。這些服務實現商業領域的軟件，包括用戶界面，持久化存儲，任何的外部協作。因此，團隊是跨職能的，包含開發過程所要求的所有技能：用戶體驗、數據庫和項目管理。
- 強化終端及弱化通道微服務的應用致力松耦合和高內聚：採用單獨的業務邏輯，基於互聯網構建系統。Unix本身就是這樣的哲學。第一種做法是接受請求、處理業務邏輯、返回響應。側重簡單的REST風格，而不是複雜的協議。第二種做法是通過輕量級消息總線來發布消息。這種的通信協議非常的單一，像RabbitMQ或者Kafka這樣的實現，需要依賴產生或者消費消息的終端或者服務來處理這類問題。在整體工風格中，組件在進程內執行，進程間的消息通信通常通過調用方法或者回調函數。從內存內部原始的調用變成遠程調用，產生的大量的不可靠通信。因此需要把粗粒度的方法成更加細粒度的通信。
微服務定義總結
- [x] 由一系列微小的服務共同組成
- [x] 運行在自己的進程裡
- [x] 每個服務為獨立業務開發
- [x] 獨立部署
- [x] 分佈式管理
SOA 架構與微服務架構
微服務是由SOA演化而來，但是微服務與SOA架構有著太多不同了，微服務風格與SOA所提倡的一些優勢非常相似，但是區別還是非常大：
- ESB和API網關SOA架構：使用ESB（企業服務總線）來連接各個服務節點。為了集成不同系統，不同協議的服務，ESB做了消息的轉化解釋和路由工作，讓不同的服務互聯互通。微服務架構：微服務將API網關服務當作系統的唯一入口。所有的客戶端和消費端都通過統一的網關接入微服務，在網關層處理所有的非業務功能。通常，網關提供Restful的訪問API。服務端通過API-GateWay註冊和管理服務。
- 架構特點不同：SOA架構特點：系統集成系統的服務化業務的服務化微服務架構特點通過服務實現組件化按業務來劃分服務去中心化基礎設施自動化（devOps）
- 主要區別功能SOA微服務組件大小大塊業務邏輯單獨任務或小塊業務邏輯耦合通常松耦合總是松耦合公司架構任何類型小型、專注於功能交叉團隊管理著重中央管理著重分散管理目標確保應用能夠交互操作執行新功能、快速拓展開發團隊
服務拆分
服務拆分前提
- 首先要有一個持續集成的平臺，使得服務在拆分的過程中，基於功能的一致性，並且持續的拆分，持續的演進，持續的集成，從而保證系統時刻處於可以驗證交付的狀態，而非閉門拆分一段時間。
- 在接入層，API和UI要動靜分離，API由API網關統一的管理，這樣後端無論如何拆分，對於前端來講，可以保證統一的入口，而且可以實現拆分過程中的灰度發佈，路由分發，流量切分，從而保證拆分的平滑進行。而且拆分後的微服務之間，為了高性能，要避免每次調用都進行認證鑑權的，應該在API網關上做統一的認證鑑權，一旦進入網關內，服務之間的調用就是可信的。
- 對於數據庫，需要進行良好的設計，不應該有大量的聯合查詢，而是將數據庫當成一個簡單的key-value查詢，複雜的聯合查詢通過應用層，或者通過Elasticsearch進行。
- 要做應用的無狀態化，只有無狀態的應用，才能橫向擴展，這樣拆分才有意義。
服務拆分的維度與策略
- AKF擴展立方體模型
- x軸：代表無差別的克隆服務和數據，工作可以很均勻的分散在不同的服務實例上。
- y軸：關注應用中職責的劃分。
- z軸：關注服務和數據的優先級劃分。
理論上按照這三個擴展維度，可以將一個單體系統進行無限擴展。
- 業務與數據服務拆分存在兩大維度，即業務與數據。業務體現在各種功能代碼中，通過確定業務的邊界，並使用領域與界限上下文、領域事件等技術手段可以實現拆分。數據的拆分則體現在如何將集中式的中心化數據轉變為各個微服務各自擁有的獨立數據。
服務拆分的方法論
- 如何拆“功能”單一職責，松耦合、高內聚關注點分離按職責按通用性按粒度級別
- 業務和數據的關係先考慮業務功能，再考慮數據無狀態服務
微服務實現的支撐
一個微服務架構應用的實現，至少需要以下功能的支撐：
- 雲端服務發現（用於定位服務，以實現雲端中間層服務發現和故障轉。）
- 統一配置中心（配置管理工具包，集中化管理集群配置）
- 消息總線（用於在集群中傳播狀態變化）
- 各服務之間的通信方式（中立的接口和協議）
- 容錯管理工具（通過熔斷機制控制服務和第三方庫的節點,從而對延遲和故障提供更強大的容錯能力）
- API網關（在雲平臺上提供動態路由,監控,彈性,安全等邊緣服務的框架）
- 分佈式鏈路追蹤（各鏈路狀態信息收集）
- 日誌收集工具（分佈式日誌收集）
基於SpringCloud的微服務實現
SpringCloud簡介
Spring Cloud是一系列框架的有序集合。利用Spring Boot的開發便利性巧妙地簡化了分佈式系統基礎設施的開發（如配置管理，服務發現，斷路器，智能路由，微代理，控制總線，一次性令牌，全局鎖，領導選舉，分佈式會話，集群狀態）。
SpringCloud對微服務實現的支撐
- 雲端服務發現 --> Eureka服務發現是基於微服務架構的關鍵原則之一。Eureka 採用了C-S的設計架構。Eureka Server作為服務註冊功能的服務器，它是服務註冊中心。而系統中的其他微服務，使用 Eureka 的客戶端連接到 Eureka Server，並維持心跳連接。Eureka由兩個組件組成：Eureka服務器和Eureka客戶端。Eureka服務器用作服務註冊服務器。Eureka客戶端是一個JAVA客戶端，用來簡化與服務器的交互、作為輪詢負載均衡器，並提供服務的故障切換支持。
- 統一配置中心 --> Spring Cloud ConfigSpring Cloud Config用來為分佈式系統中的基礎設施和微服務應用提供集中化的外部配置支持，它分為服務端與客戶端兩個部分。其中服務端也稱為分佈式配置中心，它是一個獨立的微服務應用，用來連接配置倉庫併為客戶端提供獲取配置信息、加密/解密信息等訪問接口；而客戶端則是微服務架構中的各個微服務應用或基礎設施，它們通過指定的配置中心來管理應用資源與業務相關的配置內容，並在啟動的時候從配置中心獲取和加載配置信息。Spring Cloud Config實現了對服務端和客戶端中環境變量和屬性配置的抽象映射。
- 消息總線 --> Spring Cloud BusSpring Cloud Bus將分佈式系統的節點與輕量級消息代理鏈接。這可以用於廣播狀態更改（例如配置更改）或其他管理指令。Bus就像一個擴展的Spring Boot應用程序的分佈式執行器，也可以用作應用程序之間的通信渠道。
- 各服務之間的通信方式 --> Feign（RestFul）Feign是一個聲明式WebService客戶端。Spring Cloud集成Ribbon和Eureka以在使用Feign時提供負載平衡的HTTP客戶端。
- 容錯管理工具 --> Hystrix在分佈式環境中，許多服務依賴項中的一些必然會失敗。Hystrix是一個庫，通過添加延遲容忍和容錯邏輯，控制這些分佈式服務之間的交互。Hystrix通過隔離服務之間的訪問點、停止級聯失敗和提供回退選項來實現，以提高系統的整體彈性。
- API網關 --> ZuulZuul相當於是第三方調用（app應用端和PC端）和服務提供方之間的防護門。作為邊緣服務，Zull的作用是對後端服務做必要的聚合和裁剪後暴露給外部不同的設備，旨在實現動態路由，監控，彈性負載和安全性。
- 分佈式鏈路追蹤 --> Spring Cloud SleuthSpring Cloud Sleuth為SpringCloud應用實現了一種分佈式追蹤解決方案，可以跟蹤一個用戶請求的過程(包括數據採集，數據傳輸，數據存儲，數據分析，數據可視化)，捕獲這些跟蹤數據，就能構建微服務的整個調用鏈的視圖，這是調試和監控微服務的關鍵工具。併兼容了Zipkin, HTrace和log-based追蹤。
- 日誌收集工具 --> Graylog（非Spring Cloud）Graylog是強大的日誌管理、分析工具，可以收集監控多種不同應用的日誌。它基於 Elasticsearch, Java和MongoDB。可用於在分佈式系統應用中，收集各節點日誌整理並分析。
覺得寫的還可以的，歡迎點贊+關注+轉發，需要微服務項目資料的，私信”資料“免費獲取，謝謝
