全链路压测调研
微服务
API Gateway 网关是一个服务器，是系统的唯一入口，为了每个客户端提供一个定制的 API。 API 网关的核心是，所有的客户端和消费端都通 过统一的网关接入微服务， 在网关层处理所有的非业务功能。如它还可以具有其它职责， 如身份证、监控、负载均衡、缓存、请求分片于管理、 静态相应处理。通常，网关提供 RESTFUL/HTTP 的方式访问服务，而服务端通过服务注册中进行服务注册和管理。
微服务的特点：
单一职责： 微服务中每一个服务都对应唯一的业务能力， 做到单一职责
面向服务：面向服务是说每个服务都要对外暴露服务接口 API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现， 只要提供 Rest 的接口即可。
自治： 自治是说服务间互相独立， 互不干扰
团队独立： 每个服务是一个独立的开发团队，人数不能过多。
技术独立： 因为是面向服务，提供 Rest 接口， 使用什么技术没有别人干涉
前后端分离：采用前后端分离开发， 提供统一 Rest 接口，后端不用再为 PC、移动端开发不同接口
数据库分离：每个服务都使用自己的数据源
部署独立：服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换， 降低耦合， 易维护 Docker 部署服务
微服务性能测试与传统性能测试区别
传统性能测试更多的是以事务为核心，更多的是由单个或者多个事务构成业务场景进行压测。
微服务则需要进行全链路压测， 全链路压测指完全引入相关联的系统，尽量真实模拟线上硬件环境， 更多的是以请求为核心，完全模拟真实请 求流量，通过引流等方式进行场景的模拟进行压测， 更多的适用于业务链路较长的交易。
全链路一直是性能测试中的难点，其包含系统越多测试难度就越大，系统架构中每增加一层的监控内容就会给分析带来几何倍的难度。因此， 微服务架构下的性能测试重要性就不言而喻了。
微服务性能测试难点
1.如果在测试环境进行全链路压测， 最大的难点在于无法评估用户从客户端登录到完成交易的整个链路中，系统能最大承载能力是多少。如果 无法承载生成中的流量造成系统宕机，就会有灾难性的后果。所以在测试环境进行全链路要结合历史生成的流量，并合理做出业务增长预估， 如果能满足此流量可以判定微生产环境满足性能要求。当然， 这只是权宜之计， 如果在生产环境做全链路压测不会出现此情况。
2.全链路压测涉及的微服务模块多， 开发组多，各组开发人员又各负责自己的模块，因为版本升级快， 业务层架构变化也快， 很难能了解清楚 最新的架构，如果漏掉一个系统的调用关系，分析就会变得非常困难。
3.软件的版本控制问题， 因为版本升级快，造成测试环境与生成环境代码版本不一致，数据库表结构和索引不一致的情况。这种情况会造成测 试结果不准确， 重复测试。多系统更难控制此情况。
微服务性能测试如何开展
开展全链路压测， 除了传统性能测试的需求调研、环境准备、脚本开发、数据预埋、场景执行、应用监控分析、瓶颈定位、瓶颈修复、回归测 试、结果整理、输出报告等环节外还要加入分析需压测业务场景涉及系统和协调各个压测系统资源两个环节。
1、 梳理核心链路
在压测前我们一定要首先分析清楚需要压测的业务场景，只有分析清楚了业务场景才能梳理出来涉及的相关系统， 分析清楚后也可以更快的找 到性能瓶颈进行系统优化。这个工作一般是由架构师来梳理并确认涉及的相关系统，梳理清楚后就可以反馈给压测负责人进行人员和资源的协 调了。
2、 压测资源协调
在全链路压测过程中， 最难的工作其实不是系统优化、压测环境搭建等技术工作， 最难的是压测资源的协调工作。这里的资源不单单指压测硬 件、软件、环境等资源， 还包括了人力资源等。
3、 构建数据
数据的真实和可用是保证压测结果的关键，尽量使数据多元化， 参数重复性低，可以采用生产数据脱敏的方式。数据的真实性可以保证更真实 的模拟生产数据流量。数据的真实不光指发起的数据， 测试数据库的铺底数据量也要生产一致。
4、 流量监控
搭建流量监控平台， 收集生产各种业务的流量， 统计数据，按比例进行流量回放。
5、 容量评估
首先知道容量目标多少， 比如全部交易量预期目标每天 1 亿笔， 按流量平台监控到的业务占比进行压测， 这样我们可以清楚在哪个节点应该增 加多少机器， 既能保证系统的稳定又能避免浪费。容量评估不是一步完成的， 目标需要结合历史数据和公司现有业务规模。第一步先按现有环 境摸底测试，再逐步增加减少机器， 循环多次， 最后达到精准的容量评估。
什么是全链路监控
随着微服务架构的流行，服务按照不同的维度进行拆分，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上，这些软 件模块，有可能是由不同的团队开发的、可能使用不同的编程语言来实现、有的可能部在了几千台服务器，横跨多个不同的数据中心。因此， 就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。
全链路监控组件就在这样的问题背景下产生了。最出名的是谷歌公开的论文提到的 Google Dapper。想要在这个上下文中理解分布式系统的 行为， 就需要监控那些横跨了不同的应用、不同的服务器之间的关联动作。
有了全链路监控工具，我们可以做些什么：
1.请求链路追踪，故障快速定位： 可以通过调用链结合业务日志快速定位错误信息。
2.可视化： 各个阶段耗时，进行性能分析。
3.依赖优化：各个调用环节的可能性、梳理服务依赖关系以及优化。
4.数据分析，优化链路： 可以得到用户的行为路径， 汇总分析应用在很多业务场景。
全链路监控有哪些以及为什么选择 pinpoint
Zipkin、 cat、 pinpoint、 Skywalking
优点 1： 代码入侵性很低
优点 2： 对被监控来说资源消耗低
优点 3： 自动检测应用拓扑，帮助你搞清楚应用的架构
优点 4： 方便水平扩展以便支持大规模服务器集群
优点 5： 分布式事务跟踪， 跟踪跨分布式应用的消息
PinPoint 架构
