微服務
api gateway 閘道器是乙個伺服器，是系統的唯一入口，為了每個客戶端提供乙個定製的 api。 api 閘道器的核心是，所有的客戶端和消費端都通
過統一的閘道器接入微服務， 在閘道器層處理所有的非業務功能。如它還可以具有其它職責， 如身份證、監控、負載均衡、快取、請求分片於管理、 靜態相應處理。通常，閘道器提供 restful/http 的方式訪問服務，而服務端通過服務註冊中進行服務註冊和管理。
微服務的特點：
單一職責： 微服務中每乙個服務都對應唯一的業務能力， 做到單一職責
面向服務：面向服務是說每個服務都要對外暴露服務介面 api。並不關心服務的技術實現，做到與平台和語言無關，也不限定用什麼技術實現， 只要提供 rest 的介面即可。
自治： 自治是說服務間互相獨立， 互不干擾
團隊獨立： 每個服務是乙個獨立的開發團隊，人數不能過多。
技術獨立： 因為是面向服務，提供 rest 介面， 使用什麼技術沒有別人干涉
前後端分離：採用前後端分離開發， 提供統一 rest 介面，後端不用再為 pc、移動端開發不同介面
資料庫分離：每個服務都使用自己的資料來源
部署獨立：服務間雖然有呼叫，但要做到服務重啟不影響其它服務。有利於持續整合和持續交付。每個服務都是獨立的元件，可復用，可替換， 降低耦合， 易維護 docker 部署服務
微服務效能測試與傳統效能測試區別
傳統效能測試更多的是以事務為核心，更多的是由單個或者多個事務構成業務場景進行壓測。
微服務則需要進行全鏈路壓測， 全鏈路壓測指完全引入相關聯的系統，盡量真實模擬線上硬體環境， 更多的是以請求為核心，完全模擬真實請
求流量，通過引流等方式進行場景的模擬進行壓測， 更多的適用於業務鏈路較長的交易。
全鏈路一直是效能測試中的難點，其包含系統越多測試難度就越大，系統架構中每增加一層的監控內容就會給分析帶來幾何倍的難度。因此， 微服務架構下的效能測試重要性就不言而喻了。
微服務效能測試難點
1.如果在測試環境進行全鏈路壓測， 最大的難點在於無法評估使用者從客戶端登入到完成交易的整個鏈路中，系統能最大承載能力是多少。如果 無法承載生成中的流量造成系統宕機，就會有災難性的後果。所以在測試環境進行全鏈路要結合歷史生成的流量，並合理做出業務增長預估， 如果能滿足此流量可以判定微生產環境滿足效能要求。當然， 這只是權宜之計， 如果在生產環境做全鏈路壓測不會出現此情況。
2.全鏈路壓測涉及的微服務模組多， 開發組多，各組開發人員又各負責自己的模組，因為版本公升級快， 業務層架構變化也快， 很難能了解清楚
最新的架構，如果漏掉乙個系統的呼叫關係，分析就會變得非常困難。
3.軟體的版本控制問題， 因為版本公升級快，造成測試環境與生成環境**版本不一致，資料庫表結構和索引不一致的情況。這種情況會造成測
試結果不準確， 重複測試。多系統更難控制此情況。
微服務效能測試如何開展
開展全鏈路壓測， 除了傳統效能測試的需求調研、環境準備、指令碼開發、資料預埋、場景執行、應用監控分析、瓶頸定位、瓶頸修復、回歸測
試、結果整理、輸出報告等環節外還要加入分析需壓測業務場景涉及系統和協調各個壓測系統資源兩個環節。
1、 梳理核心鏈路
在壓測前我們一定要首先分析清楚需要壓測的業務場景，只有分析清楚了業務場景才能梳理出來涉及的相關系統， 分析清楚後也可以更快的找
到效能瓶頸進行系統優化。這個工作一般是由架構師來梳理並確認涉及的相關系統，梳理清楚後就可以反饋給壓測負責人進行人員和資源的協
調了。2、 壓測資源協調
在全鏈路壓測過程中， 最難的工作其實不是系統優化、壓測環境搭建等技術工作， 最難的是壓測資源的協調工作。這裡的資源不單單指壓測硬
件、軟體、環境等資源， 還包括了人力資源等。
3、 構建資料
資料的真實和可用是保證壓測結果的關鍵，盡量使資料多元化， 引數重複性低，可以採用生產資料脫敏的方式。資料的真實性可以保證更真實
的模擬生產資料流量。資料的真實不光指發起的資料， 測試資料庫的鋪底資料量也要生產一致。
4、 流量監控
搭建流量監控平台， 收集生產各種業務的流量， 統計資料，按比例進行流量回放。
5、 容量評估
首先知道容量目標多少， 比如全部交易量預期目標每天 1 億筆， 按流量平台監控到的業務佔比進行壓測， 這樣我們可以清楚在哪個節點應該增
加多少機器， 既能保證系統的穩定又能避免浪費。容量評估不是一步完成的， 目標需要結合歷史資料和公司現有業務規模。第一步先按現有環
境摸底測試，再逐步增加減少機器， 迴圈多次， 最後達到精準的容量評估。
什麼是全鏈路監控
隨著微服務架構的流行，服務按照不同的維度進行拆分，一次請求往往需要涉及到多個服務。網際網路應用構建在不同的軟體模組集上，這些軟 件模組，有可能是由不同的團隊開發的、可能使用不同的程式語言來實現、有的可能部在了幾千臺伺服器，橫跨多個不同的資料中心。因此， 就需要一些可以幫助理解系統行為、用於分析效能問題的工具，以便發生故障的時候，能夠快速定位和解決問題。
行為， 就需要監控那些橫跨了不同的應用、不同的伺服器之間的關聯動作。
有了全鏈路監控工具，我們可以做些什麼：
1.請求鏈路追蹤，故障快速定位： 可以通過呼叫鏈結合業務日誌快速定位錯誤資訊。
2.視覺化： 各個階段耗時，進行效能分析。
3.依賴優化：各個呼叫環節的可能性、梳理服務依賴關係以及優化。
4.資料分析，優化鏈路： 可以得到使用者的行為路徑， 彙總分析應用在很多業務場景。
全鏈路監控有哪些以及為什麼選擇 pinpoint
zipkin、 cat、 pinpoint、 skywalking
優點 1： **入侵性很低
優點 2： 對被監控來說資源消耗低
優點 3： 自動檢測應用拓撲，幫助你搞清楚應用的架構
優點 4： 方便水平擴充套件以便支援大規模伺服器集群
優點 5： 分布式事務跟蹤， 跟蹤跨分布式應用的訊息
pinpoint 架構
pinpoint 展示
pinpoint 安裝部署
全鏈路壓測
2013年為了雙11提前預演而誕生,該服務已提供在阿里雲pts鉑金版。1.1.1 系統可用性問題 經常由下面一些不確定性因素引起 1.1.2 傳統線上單機與單系統壓測的四種方式 從流量分配的角度，將流量集中到某台機器 這兩種方式要求訪問流量不能太小 1.1.3 單系統壓測的問題單鏈路指乙個業務線。全...
全鏈路壓測
之前有和認識的同行聊過他們全鏈路壓測的一些技術實現方案，自己也看了很多相關的資料，這篇部落格，說說自己對全鏈路壓測的理解，以及整理的一些知識點。阿里全鏈路壓測 有讚全鏈路壓測 京東全鏈路壓測 餓了麼全鏈路壓測 一 什麼是全鏈路壓測 基於實際的生產業務場景 系統環境，模擬海量的使用者請求和資料對整個業...
全鏈路壓測筆記
公司業務發展，難有乙個量化的資料衡量核心鏈路的真實峰值。有助於提公升核心業務的穩定性。找出整個鏈路的瓶頸，優化少量的瓶頸部分提公升整體效能，以期達到用最少的資源達到最佳效果。認識誤區 不能單純認為壓測各個子系統後，整體系統沒有問題，因為涉及到業務訪問鏈路，多個業務可能有共用資源的瓶頸，主鏈路請求量增...