公司重構系統(tǒng)的時候我選擇了spring-cloud的微服務模式替代SpringMVC進行代碼改造。在使用的一年半中磕磕絆絆遇到問題解決問題颖对，但瑕不掩瑜缤底，spring-cloud改變了以往的運作方式，無論從運維還是代碼開發(fā)都大大節(jié)約了人力成本江解。
現在跟大家分享下我為什么選擇spring-cloud犁河，對比以往傳統(tǒng)架構他的優(yōu)點是什么桨螺。理解不足或描述錯誤的地方還請斧正酿秸。
順便說一句辣苏，歡迎轉載~請標明出處。
常見的架構
單體架構
單體架構在小微企業(yè)比較常見煌张，一個應用唱矛、一個數據庫绎谦、一個web容器就可以跑起來粥脚。
在兩種情況下可能會選擇單體架構：
一刷允、在企業(yè)發(fā)展的初期树灶，為了保證快速上線，采用此種方案較為簡單靈活泊窘；
二烘豹、傳統(tǒng)企業(yè)中垂直度較高携悯，訪問壓力較小的業(yè)務。在這種模式下對技術要求較低龟劲，方便各層次開發(fā)人員接手咸灿，也能滿足客戶需求。?
單體架構的架構圖：?
在單體架構中囊榜，技術選型非常靈活卸勺，優(yōu)先滿足快速上線的要求烫扼，也便于快速跟進市場映企。?
垂直架構
在單體架構發(fā)展一段時間后堰氓，公司的業(yè)務模式得到了認可双絮，交易量也慢慢的大起來。這時候為了應對更大的訪問流量软免，就會對原有的業(yè)務進行拆分膏萧，比如說：后臺系統(tǒng)、前端系統(tǒng)认境、鑒權系統(tǒng)和業(yè)務系統(tǒng)等叉信。
在這一階段往往會將系統(tǒng)分為不同的層級硼身，每個層級有對應的職責佳遂。UI層負責和用戶進行交互撒顿、業(yè)務邏輯層負責具體的業(yè)務功能凤壁、數據庫層負責和上層進行數據交換和存儲拧抖。比如我們開發(fā)的資產盤活和資產驗收就是垂直架構的系統(tǒng)唧席。
垂直架構的架構圖：
在這個階段SSM（SpringMVC淌哟、Spring绞绒、MyBatis）是項目的關鍵技術，SpringMVC負責邏輯控制喻杈、Spring負責業(yè)務層管理Bean筒饰、MyBatis負責數據庫操作進行封裝瓷们，持久化數據谬晕。?
服務化架構SOA
如果公司進一步的做大攒钳，垂直子系統(tǒng)會變的越來越多，系統(tǒng)和系統(tǒng)之間的調用關系呈指數上升文兢。在這樣的背景下很多公司都會考慮服務SOA化姆坚。
SOA代表面向服務的架構兼呵，將應用程序根據不同的職責劃分為不同的模塊萍程，不同的模塊直接通過特定的協(xié)議和接口進行交互。
整個系統(tǒng)切分成很多單個組件服務來完成請求乎赴，當流量過大時通過水平擴展相應的組件來支撐潮尝，所有的組件通過交互來滿足整體的業(yè)務需求勉失。優(yōu)點是可以根據需求通過網絡對應用組件進行分布式部署乱凿、組合和使用徒蟆。服務化架構是一套松耦合的架構段审，服務的拆分原則是服務內部高內聚，服務之間低耦合抑淫。?
服務化架構圖：
SOA的隱性缺陷
當集中式應用轉變成分布式系統(tǒng)后砌烁，系統(tǒng)之間的相互可靠調用一直以來都是分布式架構的難題。
網絡通信埂蕊，序列化協(xié)議設計等很多技術細節(jié)需要確定往弓。
一個高性能的框架，能夠構建高可用的分布式系統(tǒng)蓄氧，系統(tǒng)地考慮各個應用之間的分布式服務發(fā)現函似、服務路由、服務調用以及服務安全等細節(jié)喉童。
對比SOA和微服務架構
服務化架構已經可以解決大部分企業(yè)的需求了撇寞，為什么要研究微服務堂氯？
微服務架構強調：
業(yè)務系統(tǒng)需要徹底的組件化和服務化蔑担，一個組件就是一個產品，可以獨立對外提供服務咽白。
不再強調傳統(tǒng)SOA架構里面比較重的ESB企業(yè)服務總線啤握。
強調每個微服務都有自己獨立的運行空間，包括數據庫資源晶框。
源于互聯(lián)網的思路排抬，服務強調了采用HTTP Rest API的方式來進行
切分粒度會更小
微服務架構是 SOA 架構思想的一種擴展，更加強調服務個體的獨立性授段、拆分粒度更小蹲蒲。
微服務架構關鍵詞
有新的應用上線應該怎么辦？
應用是運維管理的基本單位
完整的應用生命周期管理機制應該包括：
1侵贵、應用創(chuàng)建 2届搁、部署 3、啟動 4窍育、回滾 5卡睦、擴容縮容 6、停止下線等蔫骂。
我們需要服務注冊和發(fā)現
服務中心將所有的可以提供的服務都注冊到它這里來管理么翰，其它各調用者需要的時候去注冊中心獲取，然后再進行調用辽旋，避免了服務之間的直接調用浩嫌，方便后續(xù)的水平擴展檐迟、故障轉移等。
隨著系統(tǒng)的流量不斷增加码耐，需要根據情況來擴展某個服務追迟，只需要增加相應的服務端實例既可。
在系統(tǒng)的運行期間服務中心有一個心跳檢測機制骚腥，如果某實例在規(guī)定的時間內沒有進行通訊則會自動被剔除掉敦间，避免了某個實例掛掉影響服務。從而實現了注冊束铭、負載均衡廓块、故障轉移的功能。
多應用如何相互訪問才能保證安全契沫？
一個好的服務框架要保證用戶每一次分布式調用的穩(wěn)定與安全带猴。在服務注冊、服務訂閱以及服務調用等每一個環(huán)節(jié)懈万，都需要進行嚴格的服務鑒權拴清。
我們需要服務網關?
網關提供了動態(tài)路由，監(jiān)控会通，彈性口予，安全等的邊緣服務。它的具體作用就是服務轉發(fā)涕侈，接收并轉發(fā)所有內外部的客戶端調用沪停。作為資源的統(tǒng)一訪問入口，同時也可以做權限校驗等類似的功能裳涛。
不同的服務一般有不同的網絡地址牙甫，而外部的客戶端可能需要調用多個服務的接口才能完成一個業(yè)務需求。
以資產盤活數據統(tǒng)計為例,可能會調用以下幾個服務：
用戶微服務? 資產分類微服務? 訂單微服務等
如果客戶端直接和微服務進行通信调违，會存在以下問題：
客戶端會多次請求不同服務，增加復雜性泻轰。
存在跨域請求技肩，處理復雜。
每一個服務都需要獨立認證認浮声。
代碼難以重構虚婿。
上述問題，都可以借助網關解決泳挥。微服務網管是介于客戶端和服務器端之間的中間層然痊，所有的外部請求都會先經過微服務網關。
應用如何高效管控屉符，服務又如何治理剧浸？
服務降級
流量管控
我們需要熔斷器
服務雪崩效應：一種因“服務提供者”的不可用導致“服務消費者”的不可用,并將不可用逐漸放大的過程锹引。
熔斷器在某個服務連續(xù)調用N次不響應的情況下，立即通知調用端調用失敗唆香，避免調用端持續(xù)等待而影響了整體服務嫌变。間隔一段時間后再次檢查此服務，如果服務恢復將繼續(xù)提供服務躬它。
不適用場景
核心無降級業(yè)務:拍照驗收時驗收照片是業(yè)務核心腾啥，這時如果拍照服務無法使用整個資產驗收服務就應該終止。
適用場景
邊緣業(yè)務或者可降級的業(yè)務:同樣是拍照冯吓，在資產盤活中上架物品對照片的需求沒有非常強烈倘待，這時如果拍照服務出現問題，不應該影響資產上架组贺，就可以利用熔斷器來保證上架流程正常進行凸舵。
運維如何高效定位問題？
隨著服越來越多锣披，對調用鏈的分析會越來越復雜贞间。服務之間的調用關系、某個請求對應的調用鏈雹仿、調用之間消費的時間等增热，對這些信息進行監(jiān)控就成為一個問題。
在實際的使用中我們需要監(jiān)控服務和服務之間通訊的各項指標胧辽，這些數據將是我們改進系統(tǒng)架構的主要依據峻仇。因此分布式的業(yè)務流程跟蹤就變的非常重要。
我們需要鏈路跟蹤
通過鏈路追蹤可以很清楚的了解到一個服務請求經過了哪些服務邑商，每個服務處理花費了多長時間摄咆。從而讓我們可以很方便的理清各微服務間的調用關系。
微服務的技術棧
Eureka進行服務注冊發(fā)現人断，連接微服務
Hystrix監(jiān)控服務調用進行熔斷保護
Config提供了統(tǒng)一的配置中心服務
所有對外的請求和服務都通過Zuul來進行轉發(fā)吭从，起到API網關的作用
使用Sleuth、Zipkin將所有的請求數據記錄下來恶迈，進行后續(xù)分析
這些功能都是以插拔的形式提供出來涩金，方便我們系統(tǒng)架構演進的過程中，可以合理的選擇需要的組件進行集成暇仲，從而在架構衍進的過程中會更加平滑順利步做。
我們可以獲得什么？
硬件部署架構
