微服務架構剖析

時間 2020-01-01

原文原文鏈接

互聯網早期、公司創立初期通常使用集中式架構(巨石架構)，全部的服務、數據存儲所有署在一臺機器中。一般會對該機器的性能、硬件比較苛刻，選用HP、SUN、IBM這種小型機，但它們的價格比較昂貴。其次是故障時是單點故障，會形成比較大的影響。html

爲了下降單點故障的影響面、減小服務、數據存儲的耦合性，提升開發效率，集中式架構逐漸演化成了分層架構(SOA)。按照業務緯度、功能緯度進行拆分後部署到不一樣的機器中，不一樣的服務、數據存儲對機器的配置要求通常是不一樣的。分層架構的核心在於「分離」，讓各個拆分後的服務、數據存儲是獨立的，邏輯上能夠去合併在一塊兒進行管理。git

解決一個問題的時候又會引入新的問題，分層架構會讓請求路徑變長、系統的穩定性降低、定位問題變的複雜、運維成本增長。爲了下降運維成本、項目快速迭代、項目持續交付，分層架構演化成了微服務架構。按照業務緯度、功能緯度、人員組織緯度進行架構。微服務架構並非銀彈，它的引入也帶來了新的問題。每一種架構都有優勢和缺點，只要能解決公司當前業務中的痛點就是好的架構。面試

什麼是微服務

我的認爲微服務一種人員組織、一套分佈式架構的思想。後端

微服務架構由一系列小型自治服務組成。每項服務都是獨立的，實現了單一的業務能力。如下是微服務的一些特徵：安全

鬆耦合：服務小，獨立且鬆耦合。
小型，專一的團隊：每一個服務都是一個單獨的代碼(項目)，由一個個的小型開發團隊管理。
獨立部署：服務能夠獨立部署，這樣更新該服務不須要重建、從新部署整個應用程序。
故障隔離：服務負責持久保持本身服務的數據或外部狀態，整個服務相關的都有小型團隊負責。
API相互通訊：服務之間使用API相互通訊，影藏每一個服務的內部實現細節。
混合技術棧：服務能夠是使用不一樣的技術棧開發，最終依靠API通訊組合在一塊兒就行。
細粒度擴展：服務能夠獨立擴展，使用不一樣的機器配置。

微服務的組件

API網關服務器

API網關是客戶端的總入口，客戶端請求不直接調用服務。它們先調用API網關，而後網關將調用轉發到後端相應的服務。它有效的阻止了內部的敏感信息暴露給外部的客戶端，爲服務層增長了一道安全防線，把通用性的功能放到API網關層，設定了服務之間通訊的規範。架構

API網關爲使用者提供完整的API託管服務，提供身份認證、權限管理、請求代理轉發、服務/API級別的流量控制(實現動態流控是難點)、服務/API級別的熔斷，保證API安全，下降API開放風險。提供日誌收集(包含APM的log)、API級別的監控、AB Test功能。運維

服務註冊發現分佈式

微服務架構中存在不少獨立自治的服務，並且微服務中是須要一套CICD(Jenkins、K8s)的基礎組件的建設。服務若是預先定義運行在哪臺服務器，會簡單不少，咱們硬編碼就能夠。可是預先定義運行的服務器要實現充分利用服務器資源幾乎是不可能的。還有服務的自動伸縮性、故障後恢復都很困難。ide

爲了更好的將服務自動部署到資源相對比較空閒的服務器中，充分的利用機器的資源，這樣咱們就須要一個能添加IP地址、端口、服務名稱的地方。把這些數據存儲到某處並能夠被其它的服務進行查找，把數據對全部服務進行共享。就是咱們說的服務註冊和發現(高可用的配置中心 + 服務查找proxy)。

調用鏈路追蹤

微服務架構中因爲也符合分層架構，一樣的它存在請求鏈路較長、出現問題後定位複雜的困惑。它的實現能夠是侵入業務方式也能夠是非侵入式(API網關層去作)。

若是咱們能把每一個接口從用戶發起請求開始，到整個調用正常結束/異常中斷鏈路信息(一般是有向無環圖)記錄起來。這樣一個個的接口就能繪製成一個API級別/服務級別/整個系統級別的調用地圖。咱們只須要提供一個接口的URL就能知道它的上下游依賴服務，也能看直觀的從調用鏈路信息中看出究竟是鏈路中哪一個環節出現了問題。

CI/CD

持續集成、持續部署是微服務架構的主要優點之一。大大的縮短了發佈週期，若是沒有一套良好的CI/CD流程，咱們將沒法實現微服務承諾的靈活性、獨立部署、細粒度擴展等特徵。

代碼倉庫會選擇使用gitlab，約束好項目的分支使用規範。能夠固定幾個特有功能的分支進行觸發git hook，好比release、develop、master分支，分別對應不一樣的部署環境。持續集成的代碼構建這塊咱們選用Jenkins進行，能夠對每次構建輸出詳細的報告。Jenkins設置構建成功的鉤子，當構件成功後去通知相關的CI系統。CI系統能夠進行下一步的部署、自動化測試。CD咱們使用的Kubernetes，能夠是基於公有云/私有云進行搭建。

日誌中心

日誌按照請求數據流向分爲：網關日誌(access、error、info等)、業務日誌(請求第三方、db等log)、機器日誌(cpu、memory、進程、鏈接數...)等這些都是容易產生異常的環節。須要把log進行收集聚合到一塊兒去，像調用鏈路追蹤能夠認爲是基於業務日誌產生的一個聚合應用。

日誌聚合到一塊兒使用的存儲能夠選擇Es、阿里雲的SLS、HDFS。針對不一樣的數量級、不一樣的數據類型(結構化、半結構化、非結構化)、不一樣的查詢量級、維護成本選擇不一樣的存儲、組合多個存儲。日誌數據因爲體量很大，通常會保存一段期間內的log。使用計算引擎(spark、flink)把原始log通過篩選、過濾永久存儲有意義的(錯誤的、支付相關的、重要服務的)log。可視化數據通常使用Grafana，支持多種數據源、提供了多樣化的模板、豐富的圖表。

監控報警

監控報警咱們通常會基礎日誌平臺的基礎上去作。除此以外還有業務數據也與監控，業務數據指的是對重要服務的數據進行數據建模，同比、環節策略進行分析數據的趨勢是否波動的超過了閾值。

監控數據的對象有網關日誌、業務日誌/數據、機器，監控指標的閾值能夠經過全鏈路壓測得出參考值。前期儘量是多報警(存在誤報)、不斷調整閾值、對報警進行必定的收斂。監控工具備Zabbix、Open-flcon、Prometheus、第三方雲服務，能夠組合使用或者單一的使用。報警可使用監控工具自帶的，也能夠是自研報警工具。報警的方式有短信、郵件、電話、內部IM。

業務數據的監控須要進行數據建模、分析、得出結論。業務數據從數據角度看都是INFO類型的，並不能像網關日誌、業務日誌同樣直接就會有ERROR、Waring。業務數據的分析、建模會使用到Python中的statsmodels、數據分析用pandas，numpy，scipy、數據可視化使用seaborn、數據擬合使用matplotlib.pylab。