為什么我選擇了 SPRING CLOUD 分布式 微服務

常見的架構單體架構
單體架構在小微企業比較常見，一個應用、一個數據庫、一個web容器就可以跑起來。在兩種情況下可能會選擇單體架構：一、在企業發展的初期，為了保證快速上線，采用此種方案較為簡單靈活；二、傳統企業中垂直度較高，訪問壓力較小的業務。在這種模式下對技術要求較低，方便各層次開發人員接手，也能滿足客戶需求。?單體架構的架構圖：

在單體架構中，技術選型非常靈活，優先滿足快速上線的要求，也便于快速跟進市場。?垂直架構
在單體架構發展一段時間后，公司的業務模式得到了認可，交易量也慢慢的大起來。這時候為了應對更大的訪問流量，就會對原有的業務進行拆分，比如說：后臺系統、前端系統、鑒權系統和業務系統等。在這一階段往往會將系統分為不同的層級，每個層級有對應的職責。UI層負責和用戶進行交互、業務邏輯層負責具體的業務功能、數據庫層負責和上層進行數據交換和存儲。比如我們開發的資產盤活和資產驗收就是垂直架構的系統。
垂直架構的架構圖：

在這個階段SSM（SpringMVC、Spring、MyBatis）是項目的關鍵技術，SpringMVC負責邏輯控制、Spring負責業務層管理Bean、MyBatis負責數據庫操作進行封裝，持久化數據。?
服務化架構SOA
如果公司進一步的做大，垂直子系統會變的越來越多，系統和系統之間的調用關系呈指數上升。在這樣的背景下很多公司都會考慮服務SOA化。SOA代表面向服務的架構，將應用程序根據不同的職責劃分為不同的模塊，不同的模塊直接通過特定的協議和接口進行交互。整個系統切分成很多單個組件服務來完成請求，當流量過大時通過水平擴展相應的組件來支撐，所有的組件通過交互來滿足整體的業務需求。優點是可以根據需求通過網絡對應用組件進行分布式部署、組合和使用。服務化架構是一套松耦合的架構，服務的拆分原則是服務內部高內聚，服務之間低耦合。?
服務化架構圖：

SOA的隱性缺陷 當集中式應用轉變成分布式系統后，系統之間的相互可靠調用一直以來都是分布式架構的難題。網絡通信，序列化協議設計等很多技術細節需要確定。一個高性能的框架，能夠構建高可用的分布式系統，系統地考慮各個應用之間的分布式服務發現、服務路由、服務調用以及服務安全等細節。

對比SOA和微服務架構服務化架構已經可以解決大部分企業的需求了，為什么要研究微服務？微服務架構強調：業務系統需要徹底的組件化和服務化，一個組件就是一個產品，可以獨立對外提供服務。不再強調傳統SOA架構里面比較重的ESB企業服務總線。強調每個微服務都有自己獨立的運行空間，包括數據庫資源。源于互聯網的思路，服務強調了采用HTTP Rest API的方式來進行切分粒度會更小微服務架構是 SOA 架構思想的一種擴展，更加強調服務個體的獨立性、拆分粒度更小。微服務架構關鍵詞

有新的應用上線應該怎么辦？
應用是運維管理的基本單位

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

1、應用創建 2、部署 3、啟動 4、回滾 5、擴容縮容 6、停止下線等。

我們需要服務注冊和發現服務中心將所有的可以提供的服務都注冊到它這里來管理，其它各調用者需要的時候去注冊中心獲取，然后再進行調用，避免了服務之間的直接調用，方便后續的水平擴展、故障轉移等。隨著系統的流量不斷增加，需要根據情況來擴展某個服務，只需要增加相應的服務端實例既可。在系統的運行期間服務中心有一個心跳檢測機制，如果某實例在規定的時間內沒有進行通訊則會自動被剔除掉，避免了某個實例掛掉影響服務。從而實現了注冊、負載均衡、故障轉移的功能。

多應用如何相互訪問才能保證安全？
一個好的服務框架要保證用戶每一次分布式調用的穩定與安全。在服務注冊、服務訂閱以及服務調用等每一個環節，都需要進行嚴格的服務鑒權。

我們需要服務網關?網關提供了動態路由，監控，彈性，安全等的邊緣服務。它的具體作用就是服務轉發，接收并轉發所有內外部的客戶端調用。作為資源的統一訪問入口，同時也可以做權限校驗等類似的功能。 不同的服務一般有不同的網絡地址，而外部的客戶端可能需要調用多個服務的接口才能完成一個業務需求。以資產盤活數據統計為例,可能會調用以下幾個服務：用戶微服務? 資產分類微服務? 訂單微服務等如果客戶端直接和微服務進行通信，會存在以下問題：客戶端會多次請求不同服務，增加復雜性。存在跨域請求，處理復雜。每一個服務都需要獨立認證認。代碼難以重構。上述問題，都可以借助網關解決。微服務網管是介于客戶端和服務器端之間的中間層，所有的外部請求都會先經過微服務網關。

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

流量管控

我們需要熔斷器服務雪崩效應：一種因“服務提供者”的不可用導致“服務消費者”的不可用,并將不可用逐漸放大的過程。熔斷器在某個服務連續調用N次不響應的情況下，立即通知調用端調用失敗，避免調用端持續等待而影響了整體服務。間隔一段時間后再次檢查此服務，如果服務恢復將繼續提供服務。 不適用場景
核心無降級業務:拍照驗收時驗收照片是業務核心，這時如果拍照服務無法使用整個資產驗收服務就應該終止。適用場景邊緣業務或者可降級的業務:同樣是拍照，在資產盤活中上架物品對照片的需求沒有非常強烈，這時如果拍照服務出現問題，不應該影響資產上架，就可以利用熔斷器來保證上架流程正常進行。

運維如何高效定位問題？ 隨著服越來越多，對調用鏈的分析會越來越復雜。服務之間的調用關系、某個請求對應的調用鏈、調用之間消費的時間等，對這些信息進行監控就成為一個問題。在實際的使用中我們需要監控服務和服務之間通訊的各項指標，這些數據將是我們改進系統架構的主要依據。因此分布式的業務流程跟蹤就變的非常重要。我們需要鏈路跟蹤
通過鏈路追蹤可以很清楚的了解到一個服務請求經過了哪些服務，每個服務處理花費了多長時間。從而讓我們可以很方便的理清各微服務間的調用關系。

微服務的技術棧

Eureka進行服務注冊發現，連接微服務Hystrix監控服務調用進行熔斷保護Config提供了統一的配置中心服務所有對外的請求和服務都通過Zuul來進行轉發，起到API網關的作用使用Sleuth、Zipkin將所有的請求數據記錄下來，進行后續分析這些功能都是以插拔的形式提供出來，方便我們系統架構演進的過程中，可以合理的選擇需要的組件進行集成，從而在架構衍進的過程中會更加平滑順利。

我們可以獲得什么？

硬件部署架構