作者：古霜卡比
www.cnblogs.com/skabyy/p/11396571.html
本文將介紹微服務架構和相關的組件，介紹他們是什么以及為什么要使用微服務架構和這些組件，本文側重于簡明地表達微服務架構的全域圖景，因此不會涉及具體如何使用組件等細節，
要理解微服務，首先要先理解不是微服務的那些，通常跟微服務相對的是單體應用，即將所有功能都打包成在一個獨立單元的應用程式，
從單體應用到微服務并不是一蹴而就的，這是一個逐漸演變的程序，本文將以一個網上超市應用為例來說明這一程序，
最初的需求
幾年前，小明和小皮一起創業做網上超市，小明負責程式開發，小皮負責其他事宜，當時互聯網還不發達，網上超市還是藍海，只要功能實作了就能隨便賺錢，
所以他們的需求很簡單，只需要一個網站掛在公網，用戶能夠在這個網站上瀏覽商品、購買商品；另外還需一個管理后臺，可以管理商品、用戶、以及訂單資料，
我們整理一下功能清單：
-
網站
-
用戶注冊、登錄功能
-
商品展示
-
下單
-
管理后臺
-
用戶管理
-
商品管理
-
訂單管理
由于需求簡單，小明左手右手一個慢動作，網站就做好了，管理后臺出于安全考慮，不和網站做在一起，小明右手左手慢動作重播，管理網站也做好了，
總體架構圖如下：
小明揮一揮手，找了家云服務部署上去，網站就上線了，上線后好評如潮，深受各類肥宅喜愛，小明小皮美滋滋地開始躺著收錢，
隨著業務發展…
好景不長，沒過幾天，各類網上超市緊跟著拔地而起，對小明小皮造成了強烈的沖擊，
在競爭的壓力下，小明小皮決定開展一些營銷手段：
-
開展促銷活動，比如元旦全場打折，春節買二送一，情人節狗糧優惠券等等，
-
拓展渠道，新增移動端營銷，除了網站外，還需要開發移動端APP，微信小程式等，
-
精準營銷，利用歷史資料對用戶進行分析，提供個性化服務，
-
……
這些活動都需要程式開發的支持，小明拉了同學小紅加入團隊，小紅負責資料分析以及移動端相關開發，小明負責促銷活動相關功能的開發，
因為開發任務比較緊迫，小明小紅沒有好好規劃整個系統的架構，隨便拍了拍腦袋，決定把促銷管理和資料分析放在管理后臺里，微信和移動端APP另外搭建，通宵了幾天后，新功能和新應用基本完工，
這時架構圖如下：
這一階段存在很多不合理的地方：
-
網站和移動端應用有很多相同業務邏輯的重復代碼，
-
資料有時候通過資料庫共享，有時候通過介面呼叫傳輸，介面呼叫關系雜亂，
-
單個應用為了給其他應用提供介面，漸漸地越改越大，包含了很多本來就不屬于它的邏輯，應用邊界模糊，功能歸屬混亂，
-
管理后臺在一開始的設計中保障級別較低，加入資料分析和促銷管理相關功能后出現性能瓶頸，影響了其他應用，
-
資料庫表結構被多個應用依賴，無法重構和優化，
-
所有應用都在一個資料庫上操作，資料庫出現性能瓶頸，特別是資料分析跑起來的時候，資料庫性能急劇下降，
-
開發、測驗、部署、維護愈發困難，即使只改動一個小功能，也需要整個應用一起發布，
有時候發布會不小心帶上了一些未經測驗的代碼，或者修改了一個功能后，另一個意想不到的地方出錯了，
為了減輕發布可能產生的問題的影響和線上業務停頓的影響，所有應用都要在凌晨三四點執行發布，
發布后為了驗證應用正常運行，還得盯到第二天白天的用戶高峰期……
-
團隊出現推諉扯皮現象，關于一些公用的功能應該建設在哪個應用上的問題常常要爭論很久，最后要么干脆各做各的，或者隨便放個地方但是都不維護，
盡管有著諸多問題，但也不能否認這一階段的成果：快速地根據業務變化建設了系統，
不過緊迫且繁重的任務容易使人陷入區域、短淺的思維方式，從而做出妥協式的決策，在這種架構中，每個人都只關注在自己的一畝三分地，缺乏全域的、長遠的設計，
長此以往，系統建設將會越來越困難，甚至陷入不斷推翻、重建的回圈，
是時候做出改變了
幸好小明和小紅是有追求有理想的好青年，意識到問題后，小明和小紅從瑣碎的業務需求中騰出了一部分精力，開始梳理整體架構，針對問題準備著手改造，
要做改造，首先你需要有足夠的精力和資源，如果你的需求方（業務人員、專案經理、上司等）很強勢地一心追求需求進度，以致于你無法挪出額外的精力和資源的話，那么你可能無法做任何事……
在編程的世界中，最重要的便是抽象能力，微服務改造的程序實際上也是個抽象的程序，小明和小紅整理了網上超市的業務邏輯，抽象出公用的業務能力，做成幾個公共服務：
-
用戶服務
-
商品服務
-
促銷服務
-
訂單服務
-
資料分析服務
各個應用后臺只需從這些服務獲取所需的資料，從而刪去了大量冗余的代碼，就剩個輕薄的控制層和前端，
這一階段的架構如下：
這個階段只是將服務分開了，資料庫依然是共用的，所以一些煙囪式系統的缺點仍然存在：
-
資料庫成為性能瓶頸，并且有單點故障的風險，
-
資料管理趨向混亂，即使一開始有良好的模塊化設計，隨著時間推移，總會有一個服務直接從資料庫取另一個服務的資料的現象，
-
資料庫表結構可能被多個服務依賴，牽一發而動全身，很難調整，
如果一直保持共用資料庫的模式，則整個架構會越來越僵化，失去了微服務架構的意義，
因此小明和小紅一鼓作氣，把資料庫也拆分了，所有持久化層相互隔離，由各個服務自己負責，另外，為了提高系統的實時性，加入了訊息佇列機制，
架構如下：
完全拆分后各個服務可以采用異構的技術，比如資料分析服務可以使用資料倉庫作為持久化層，以便于高效地做一些統計計算；商品服務和促銷服務訪問頻率比較大，因此加入了快取機制等，
還有一種抽象出公共邏輯的方法是把這些公共邏輯做成公共的框架庫，這種方法可以減少服務呼叫的性能損耗，但是這種方法的管理成本非常高昂，很難保證所有應用版本的一致性，
資料庫拆分也有一些問題和挑戰：比如說跨庫級聯的需求，通過服務查詢資料顆粒度的粗細問題等，但是這些問題可以通過合理的設計來解決，總體來說，資料庫拆分是一個利大于弊的，
微服務架構還有一個技術外的好處，它使整個系統的分工更加明確，責任更加清晰，每個人專心負責為其他人提供更好的服務，
在單體應用的時代，公共的業務功能經常沒有明確的歸屬，
最后要么各做各的，每個人都重新實作了一遍；要么是隨機一個人（一般是能力比較強或者比較熱心的人）做到他負責的應用里面，
在后者的情況下，這個人在負責自己應用之外，還要額外負責給別人提供這些公共的功能——而這個功能本來是無人負責的，僅僅因為他能力較強/比較熱心，就莫名地背鍋（這種情況還被美其名曰能者多勞），
結果最后大家都不愿意提供公共的功能，長此以往，團隊里的人漸漸變得各自為政，不再關心全域的架構設計，
從這個角度上看，使用微服務架構同時也需要組織結構做相應的調整，所以說做微服務改造需要管理者的支持，
改造完成后，小明和小紅分清楚各自的鍋，兩人十分滿意，一切就像是麥克斯韋方程組一樣漂亮完美，
然而……
沒有銀彈
春天來了，萬物復蘇，又到了一年一度的購物狂歡節，眼看著日訂單數量蹭蹭地上漲，小皮小明小紅喜笑顏開，可惜好景不長，樂極生悲，突然嘣的一下，系統掛了，推薦：這才是微服務劃分的正確姿勢！
以往單體應用，排查問題通常是看一下日志，研究錯誤資訊和呼叫堆疊，而微服務架構整個應用分散成多個服務，定位故障點非常困難，
小明一臺機器一臺機器地查看日志，一個服務一個服務地手工呼叫，
經過十幾分鐘的查找，小明終于定位到故障點：促銷服務由于接收的請求量太大而停止回應了，其他服務都直接或間接地會呼叫促銷服務，于是也跟著宕機了，
在微服務架構中，一個服務故障可能會產生雪崩效用，導致整個系統故障，其實在節前，小明和小紅是有做過請求量評估的，
按照預計，服務器資源是足以支持節日的請求量的，所以肯定是哪里出了問題，
不過形勢緊急，隨著每一分每一秒流逝的都是白花花的銀子，因此小明也沒時間排查問題，當機立斷在云上新建了幾臺虛擬機，然后一臺一臺地部署新的促銷服務節點，
幾分鐘的操作后，系統總算是勉強恢復正常了，整個故障時間內估計損失了幾十萬的銷售額，三人的心在滴血……
事后，小明簡單寫了個日志分析工具（量太大了，文本編輯器幾乎打不開，打開了肉眼也看不過來），統計了促銷服務的訪問日志，發現在故障期間，商品服務由于代碼問題，在某些場景下會對促銷服務發起大量請求，
這個問題并不復雜，小明手指抖一抖，修復了這個價值幾十萬的Bug，
問題是解決了，但誰也無法保證不會再發生類似的其他問題，
微服務架構雖然邏輯設計上看是完美的，但就像積木搭建的華麗宮殿一樣，經不起風吹草動，微服務架構雖然解決了舊問題，也引入了新的問題：
-
微服務架構整個應用分散成多個服務，定位故障點非常困難，
-
穩定性下降，服務數量變多導致其中一個服務出現故障的概率增大，并且一個服務故障可能導致整個系統掛掉，事實上，在大訪問量的生產場景下，故障總是會出現的，
-
服務數量非常多，部署、管理的作業量很大，
-
開發方面：如何保證各個服務在持續開發的情況下仍然保持協同合作，
-
測驗方面：服務拆分后，幾乎所有功能都會涉及多個服務，原本單個程式的測驗變為服務間呼叫的測驗，測驗變得更加復雜，
小明小紅痛定思痛，決心好好解決這些問題，對故障的處理一般從兩方面入手，一方面盡量減少故障發生的概率，另一方面降低故障造成的影響，
監控 - 發現故障的征兆
在高并發分布式的場景下，故障經常是突然間就雪崩式爆發，所以必須建立完善的監控體系，盡可能發現故障的征兆，
微服務架構中組件繁多，各個組件所需要監控的指標不同，
比如Redis快取一般監控占用記憶體值、網路流量，資料庫監控連接數、磁盤空間，業務服務監控并發數、回應延遲、錯誤率等，
因此如果做一個大而全的監控系統來監控各個組件是不大現實的，而且擴展性會很差，
一般的做法是讓各個組件提供報告自己當前狀態的介面（metrics介面），這個介面輸出的資料格式應該是一致的，
然后部署一個指標采集器組件，定時從這些介面獲取并保持組件狀態，同時提供查詢服務，最后還需要一個UI，從指標采集器查詢各項指標，繪制監控界面或者根據閾值發出告警，
大部分組件都不需要自己動手開發，網路上有開源組件，小明下載了RedisExporter和MySQLExporter，這兩個組件分別提供了Redis快取和MySQL資料庫的指標介面，
微服務則根據各個服務的業務邏輯實作自定義的指標介面，
然后小明采用Prometheus作為指標采集器，Grafana配置監控界面和郵件告警，這樣一套微服務監控系統就搭建起來了：
定位問題 - 鏈路跟蹤
在微服務架構下，一個用戶的請求往往涉及多個內部服務呼叫，
為了方便定位問題，需要能夠記錄每個用戶請求時，微服務內部產生了多少服務呼叫，及其呼叫關系，這個叫做鏈路跟蹤，
我們用一個Istio檔案里的鏈路跟蹤例子來看看效果：
圖片來自Istio檔案
從圖中可以看到，這是一個用戶訪問productpage頁面的請求，在請求程序中，productpage服務順序呼叫了details和reviews服務的介面，而reviews服務在回應程序中又呼叫了ratings的介面，
整個鏈路跟蹤的記錄是一棵樹：
要實作鏈路跟蹤，每次服務呼叫會在HTTP的HEADERS中記錄至少記錄四項資料：
-
traceId：traceId標識一個用戶請求的呼叫鏈路，具有相同traceId的呼叫屬于同一條鏈路，
-
spanId：標識一次服務呼叫的ID，即鏈路跟蹤的節點ID，
-
parentId：父節點的spanId，
-
requestTime & responseTime：請求時間和回應時間，
另外，還需要呼叫日志收集與存盤的組件，以及展示鏈路呼叫的UI組件，
以上只是一個極簡的說明，關于鏈路跟蹤的理論依據可詳見Google的Dapper
了解了理論基礎后，小明選用了Dapper的一個開源實作Zipkin，然后手指一抖，寫了個HTTP請求的攔截器，在每次HTTP請求時生成這些資料注入到HEADERS，同時異步發送呼叫日志到Zipkin的日志收集器中，
這里額外提一下，HTTP請求的攔截器，可以在微服務的代碼中實作，也可以使用一個網路代理組件來實作（不過這樣子每個微服務都需要加一層代理），
鏈路跟蹤只能定位到哪個服務出現問題，不能提供具體的錯誤資訊，查找具體的錯誤資訊的能力則需要由日志分析組件來提供，
分析問題 - 日志分析
日志分析組件應該在微服務興起之前就被廣泛使用了，即使單體應用架構，當訪問數變大、或服務器規模增多時，日志檔案的大小會膨脹到難以用文本編輯器進行訪問，更糟的是它們分散在多臺服務器上面，
排查一個問題，需要登錄到各臺服務器去獲取日志檔案，一個一個地查找（而且打開、查找都很慢）想要的日志資訊，
因此，在應用規模變大時，我們需要一個日志的“搜索引擎”，以便于能準確的找到想要的日志，另外，資料源一側還需要收集日志的組件和展示結果的UI組件：
小明調查了一下，使用了大名鼎鼎地ELK日志分析組件，ELK是Elasticsearch、Logstash和Kibana三個組件的縮寫，
-
Elasticsearch：搜索引擎，同時也是日志的存盤，
-
Logstash：日志采集器，它接收日志輸入，對日志進行一些預處理，然后輸出到Elasticsearch，
-
Kibana：UI組件，通過Elasticsearch的API查找資料并展示給用戶，
最后還有一個小問題是如何將日志發送到Logstash，一種方案是在日志輸出的時候直接呼叫Logstash介面將日志發送過去，推薦：Spring Boot & ES 實戰，值得參考！
這樣一來又（咦，為啥要用“又”）要修改代碼……于是小明選用了另一種方案：日志仍然輸出到檔案，每個服務里再部署個Agent掃描日志檔案然后輸出給Logstash，
網關 - 權限控制，服務治理
拆分成微服務后，出現大量的服務，大量的介面，使得整個呼叫關系亂糟糟的，
經常在開發程序中，寫著寫著，忽然想不起某個資料應該呼叫哪個服務，或者寫歪了，呼叫了不該呼叫的服務，本來一個只讀的功能結果修改了資料……
為了應對這些情況，微服務的呼叫需要一個把關的東西，也就是網關，推薦：牛逼哄哄的 API 網關是什么鬼？
在呼叫者和被呼叫者中間加一層網關，每次呼叫時進行權限校驗，另外，網關也可以作為一個提供服務介面檔案的平臺，
使用網關有一個問題就是要決定在多大粒度上使用：最粗粒度的方案是整個微服務一個網關，微服務外部通過網關訪問微服務，微服務內部則直接呼叫；最細粒度則是所有呼叫，不管是微服務內部呼叫或者來自外部的呼叫，都必須通過網關，
折中的方案是按照業務領域將微服務分成幾個區，區內直接呼叫，區間通過網關呼叫，
由于整個網上超市的服務數量還不算特別多，小明采用的最粗粒度的方案：
服務注冊于發現 - 動態擴容
前面的組件，都是旨在降低故障發生的可能性，然而故障總是會發生的，所以另一個需要研究的是如何降低故障產生的影響，推薦：Spring Cloud Eureka 注冊中心集群搭建，Greenwich 最新版！
關注微信公眾號：Java技術堆疊，在后臺回復：cloud，可以獲取我整理的 N 篇最新Spring Cloud 教程，都是干貨，
最粗暴的（也是最常用的）故障處理策略就是冗余，一般來說，一個服務都會部署多個實體，這樣一來能夠分擔壓力提高性能，二來即使一個實體掛了其他實體還能回應，
冗余的一個問題是使用幾個冗余？這個問題在時間軸上并沒有一個切確的答案，根據服務功能、時間段的不同，需要不同數量的實體，
比如在平日里，可能4個實體已經夠用；而在促銷活動時，流量大增，可能需要40個實體，因此冗余數量并不是一個固定的值，而是根據需要實時調整的，
一般來說新增實體的操作為：
-
部署新實體
-
將新實體注冊到負載均衡或DNS上
操作只有兩步，但如果注冊到負載均衡或DNS的操作為人工操作的話，那事情就不簡單了，想想新增40個實體后，要手工輸入40個IP的感覺……
解決這個問題的方案是服務自動注冊與發現，
首先，需要部署一個服務發現服務，它提供所有已注冊服務的地址資訊的服務，DNS也算是一種服務發現服務，
然后各個應用服務在啟動時自動將自己注冊到服務發現服務上，并且應用服務啟動后會實時（定期）從服務發現服務同步各個應用服務的地址串列到本地，
服務發現服務也會定期檢查應用服務的健康狀態，去掉不健康的實體地址，
這樣新增實體時只需要部署新實體，實體下線時直接關停服務即可，服務發現會自動檢查服務實體的增減，
服務發現還會跟客戶端負載均衡配合使用，由于應用服務已經同步服務地址串列在本地了，所以訪問微服務時，可以自己決定負載策略，
甚至可以在服務注冊時加入一些元資料（服務版本等資訊），客戶端負載則根據這些元資料進行流量控制，實作A/B測驗、藍綠發布等功能，
服務發現有很多組件可以選擇，比如說Zookeeper 、Eureka、Consul、Etcd等，不過小明覺得自己水平不錯，想炫技，于是基于Redis自己寫了一個……
熔斷、服務降級、限流
熔斷
當一個服務因為各種原因停止回應時，呼叫方通常會等待一段時間，然后超時或者收到錯誤回傳，推薦：Hystrix理論+實戰，
如果呼叫鏈路比較長，可能會導致請求堆積，整條鏈路占用大量資源一直在等待下游回應，
所以當多次訪問一個服務失敗時，應熔斷，標記該服務已停止作業，直接回傳錯誤，直至該服務恢復正常后再重新建立連接，
圖片來自《微服務設計》
服務降級
當下游服務停止作業后，如果該服務并非核心業務，則上游服務應該降級，以保證核心業務不中斷，推薦閱讀：服務降級的概念及應用手段，
比如網上超市下單界面有一個推薦商品湊單的功能，當推薦模塊掛了后，下單功能不能一起掛掉，只需要暫時關閉推薦功能即可，
限流
一個服務掛掉后，上游服務或者用戶一般會習慣性地重試訪問，
這導致一旦服務恢復正常，很可能因為瞬間網路流量過大又立刻掛掉，在棺材里重復著仰臥起坐，因此服務需要能夠自我保護——限流，
限流策略有很多，最簡單的比如當單位時間內請求數過多時，丟棄多余的請求，另外，也可以考慮磁區限流，僅拒絕來自產生大量請求的服務的請求，
例如商品服務和訂單服務都需要訪問促銷服務，商品服務由于代碼問題發起了大量請求，促銷服務則只限制來自商品服務的請求，來自訂單服務的請求則正常回應，
測驗
微服務架構下，測驗分為三個層次：
-
端到端測驗：覆寫整個系統，一般在用戶界面機型測驗，
-
服務測驗：針對服務介面進行測驗，
-
單元測驗：針對代碼單元進行測驗，
三種測驗從上到下實施的容易程度遞增，但是測驗效果遞減，端到端測驗最費時費力，但是通過測驗后我們對系統最有信心，單元測驗最容易實施，效率也最高，但是測驗后不能保證整個系統沒有問題，
由于端到端測驗實施難度較大，一般只對核心功能做端到端測驗，
一旦端到端測驗失敗，則需要將其分解到單元測驗：則分析失敗原因，然后撰寫單元測驗來重現這個問題，這樣未來我們便可以更快地捕獲同樣的錯誤，服務測驗的難度在于服務會經常依賴一些其他服務，這個問題可以通過Mock Server解決：
單元測驗大家都很熟悉了，我們一般會撰寫大量的單元測驗（包括回歸測驗）盡量覆寫所有代碼，
微服務框架
指標介面、鏈路跟蹤注入、日志引流、服務注冊發現、路由規則等組件以及熔斷、限流等功能都需要在應用服務上添加一些對接代碼，如果讓每個應用服務自己實作是非常耗時耗力的，
基于DRY的原則，小明開發了一套微服務框架，將與各個組件對接的代碼和另外一些公共代碼抽離到框架中，所有的應用服務都統一使用這套框架進行開發，
使用微服務框架可以實作很多自定義的功能，甚至可以將程式呼叫堆疊資訊注入到鏈路跟蹤，實作代碼級別的鏈路跟蹤，或者輸出執行緒池、連接池的狀態資訊，實時監控服務底層狀態，
使用統一的微服務框架有一個比較嚴重的問題：框架更新成本很高，每次框架升級，都需要所有應用服務配合升級，
當然，一般會使用兼容方案，留出一段并行時間等待所有應用服務升級，
但是如果應用服務非常多時，升級時間可能會非常漫長，并且有一些很穩定幾乎不更新的應用服務，其負責人可能會拒絕升級……
因此，使用統一微服務框架需要完善的版本管理方法和開發管理規范，
另一條路 - Service Mesh
另一種抽象公共代碼的方法是直接將這些代碼抽象到一個反向代理組件，每個服務都額外部署這個代理組件，所有出站入站的流量都通過該組件進行處理和轉發，這個組件被稱為Sidecar，
Sidecar不會產生額外網路成本，Sidecar會和微服務節點部署在同一臺主機上并且共用相同的虛擬網卡，所以sidecar和微服務節點的通信實際上都只是通過記憶體拷貝實作的，
_圖片來自：_Pattern: Service Mesh
Sidecar只負責網路通信，還需要有個組件來統一管理所有sidecar的配置，在Service Mesh中，負責網路通信的部分叫資料平面（data plane），負責配置管理的部分叫控制平面（control plane），資料平面和控制平面構成了Service Mesh的基本架構，
_圖片來自：_Pattern: Service Mesh
Sevice Mesh相比于微服務框架的優點在于它不侵入代碼，升級和維護更方便，它經常被詬病的則是性能問題，即使回環網路不會產生實際的網路請求，但仍然有記憶體拷貝的額外成本，另外有一些集中式的流量處理也會影響性能，
結束、也是開始
微服務不是架構演變的終點，往細走還有Serverless、FaaS等方向，另一方面也有人在唱合久必分分久必合，重新發現單體架構……
不管怎樣，微服務架構的改造暫時告一段落了，小明滿足地摸了摸日益光滑的腦袋，打算這個周末休息一下約小紅喝杯咖啡，
近期熱文推薦：
1.Java 15 正式發布， 14 個新特性，重繪你的認知！！
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.我用 Java 8 寫了一段邏輯，同事直呼看不懂，你試試看，，
4.吊打 Tomcat ，Undertow 性能很炸！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/237859.html
標籤：Java
上一篇：WINHTTP訪問網頁問題求助