爲何我會選擇spring cloud，對比以往傳統架構他的優勢是什麼？

公司重構系統的時候我選擇了spring-cloud的微服務模式替代SpringMVC進行代碼改造。在使用的一年半中磕磕絆絆遇到問題解決問題，但瑕不掩瑜，spring-cloud改變了以往的運做方式，不管從運維仍是代碼開發都大大節約了人力成本。

如今跟你們分享下我爲何選擇spring-cloud，對比以往傳統架構他的優勢是什麼。理解不足或描述錯誤的地方還請斧正。

順便說一句，歡迎轉載~請標明出處。

常見的架構

單體架構

單體架構在小微企業比較常見，一個應用、一個數據庫、一個web容器就能夠跑起來。

在兩種狀況下可能會選擇單體架構：

1、在企業發展的初期，爲了保證快速上線，採用此種方案較爲簡單靈活；

2、傳統企業中垂直度較高，訪問壓力較小的業務。在這種模式下對技術要求較低，方便各層次開發人員接手，也能知足客戶需求。

單體架構的架構圖：

在單體架構中，技術選型很是靈活，優先知足快速上線的要求，也便於快速跟進市場。

垂直架構

在單體架構發展一段時間後，公司的業務模式獲得了承認，交易量也慢慢的大起來。這時候爲了應對更大的訪問流量，就會對原有的業務進行拆分，好比說：後臺系統、前端系統、鑑權系統和業務系統等。

在這一階段每每會將系統分爲不一樣的層級，每一個層級有對應的職責。UI層負責和用戶進行交互、業務邏輯層負責具體的業務功能、數據庫層負責和上層進行數據交換和存儲。好比咱們開發的資產盤活和資產驗收就是垂直架構的系統。

垂直架構的架構圖：

在這個階段SSM（SpringMVC、Spring、MyBatis）是項目的關鍵技術，SpringMVC負責邏輯控制、Spring負責業務層管理Bean、MyBatis負責數據庫操做進行封裝，持久化數據。

服務化架構SOA

若是公司進一步的作大，垂直子系統會變的愈來愈多，系統和系統之間的調用關係呈指數上升。在這樣的背景下不少公司都會考慮服務SOA化。

SOA表明面向服務的架構，將應用程序根據不一樣的職責劃分爲不一樣的模塊，不一樣的模塊直接經過特定的協議和接口進行交互。

整個系統切分紅不少單個組件服務來完成請求，當流量過大時經過水平擴展相應的組件來支撐，全部的組件經過交互來知足總體的業務需求。優勢是能夠根據需求經過網絡對應用組件進行分佈式部署、組合和使用。服務化架構是一套鬆耦合的架構，服務的拆分原則是服務內部高內聚，服務之間低耦合。

服務化架構圖：

SOA的隱性缺陷

當集中式應用轉變成分佈式系統後，系統之間的相互可靠調用一直以來都是分佈式架構的難題。

網絡通訊，序列化協議設計等不少技術細節須要肯定。

一個高性能的框架，可以構建高可用的分佈式系統，系統地考慮各個應用之間的分佈式服務發現、服務路由、服務調用以及服務安全等細節。

對比SOA和微服務架構

服務化架構已經能夠解決大部分企業的需求了，爲何要研究微服務？

微服務架構強調：

• 業務系統須要完全的組件化和服務化，一個組件就是一個產品，能夠獨立對外提供服務。
  
• 再也不強調傳統SOA架構裏面比較重的ESB企業服務總線。
  
• 強調每一個微服務都有本身獨立的運行空間，包括數據庫資源。
  
• 源於互聯網的思路，服務強調了採用HTTP Rest API的方式來進行
  
• 切分粒度會更小
  

微服務架構是 SOA 架構思想的一種擴展，更增強調服務個體的獨立性、拆分粒度更小。

微服務架構關鍵詞

有新的應用上線應該怎麼辦？

應用是運維管理的基本單位

完整的應用生命週期管理機制應該包括：

一、應用建立 二、部署 三、啓動 四、回滾 五、擴容縮容 六、中止下線等。

咱們須要服務註冊和發現

服務中心將全部的能夠提供的服務都註冊到它這裏來管理，其它各調用者須要的時候去註冊中心獲取，而後再進行調用，避免了服務之間的直接調用，方便後續的水平擴展、故障轉移等。

隨着系統的流量不斷增長，須要根據狀況來擴展某個服務，只須要增長相應的服務端實例既可。

在系統的運行期間服務中心有一個心跳檢測機制，若是某實例在規定的時間內沒有進行通信則會自動被剔除掉，避免了某個實例掛掉影響服務。從而實現了註冊、負載均衡、故障轉移的功能。

多應用如何相互訪問才能保證安全？

一個好的服務框架要保證用戶每一次分佈式調用的穩定與安全。在服務註冊、服務訂閱以及服務調用等每個環節，都須要進行嚴格的服務鑑權。

咱們須要服務網關

網關提供了動態路由，監控，彈性，安全等的邊緣服務。它的具體做用就是服務轉發，接收並轉發全部內外部的客戶端調用。做爲資源的統一訪問入口，同時也能夠作權限校驗等相似的功能。

不一樣的服務通常有不一樣的網絡地址，而外部的客戶端可能須要調用多個服務的接口才能完成一個業務需求。

以資產盤活數據統計爲例,可能會調用如下幾個服務：

• 用戶微服務 資產分類微服務 訂單微服務等
  
• 若是客戶端直接和微服務進行通訊，會存在如下問題：
  
• 客戶端會屢次請求不一樣服務，增長複雜性。
  
• 存在跨域請求，處理複雜。
  
• 每個服務都須要獨立認證認。
  
• 代碼難以重構。
  

上述問題，均可以藉助網關解決。微服務網管是介於客戶端和服務器端之間的中間層，全部的外部請求都會先通過微服務網關。

應用如何高效管控，服務又如何治理？

服務降級

流量管控

咱們須要熔斷器

服務雪崩效應：一種因「服務提供者」的不可用致使「服務消費者」的不可用,並將不可用逐漸放大的過程。

熔斷器在某個服務連續調用N次不響應的狀況下，當即通知調用端調用失敗，避免調用端持續等待而影響了總體服務。間隔一段時間後再次檢查此服務，若是服務恢復將繼續提供服務。

不適用場景

核心無降級業務:拍照驗收時驗收照片是業務核心，這時若是拍照服務沒法使用整個資產驗收服務就應該終止。

適用場景

邊緣業務或者可降級的業務:一樣是拍照，在資產盤活中上架物品對照片的需求沒有很是強烈，這時若是拍照服務出現問題，不該該影響資產上架，就能夠利用熔斷器來保證上架流程正常進行。

運維如何高效定位問題？

隨着服愈來愈多，對調用鏈的分析會愈來愈複雜。服務之間的調用關係、某個請求對應的調用鏈、調用之間消費的時間等，對這些信息進行監控就成爲一個問題。

在實際的使用中咱們須要監控服務和服務之間通信的各項指標，這些數據將是咱們改進系統架構的主要依據。所以分佈式的業務流程跟蹤就變的很是重要。

咱們須要鏈路跟蹤

經過鏈路追蹤能夠很清楚的瞭解到一個服務請求通過了哪些服務，每一個服務處理花費了多長時間。從而讓咱們能夠很方便的理清各微服務間的調用關係。

微服務的技術棧

Eureka進行服務註冊發現，鏈接微服務

Hystrix監控服務調用進行熔斷保護

Config提供了統一的配置中心服務

全部對外的請求和服務都經過Zuul來進行轉發，起到API網關的做用

使用Sleuth、Zipkin將全部的請求數據記錄下來，進行後續分析

這些功能都是以插拔的形式提供出來，方便咱們系統架構演進的過程當中，能夠合理的選擇須要的組件進行集成，從而在架構衍進的過程當中會更加平滑順利。

咱們能夠得到什麼？

硬件部署架構

做者：落落落落大大方方
連接：https://www.jianshu.com/p/dd374d849f42複製代碼