经过层层面试进入了公司，进到公司发现还有很多知识要去学习，接触新名词与技术，这篇博客就是记录一下我进入公司后接触到的一些陌生名词进行记录与理解，并将持续更新。
BU：
是英语 Business
Unit的缩写，翻译为中文就是业务部门的意思。这个BU可大可小，大到一个战略业务部门，比如一大类产品，巨型集团公司的一个大产业（例如中石化的化工板块），小到一个小部门（例如一家公司的某个地区销售部门）
网关：
又称网间连接器、协议转换器。网关在网络层以上实现网络互连，是复杂的网络互连设备，仅用于两个高层协议不同的网络互连。网关既可以用于广域网互连，也可以用于局域网互连。
网关是一种充当转换重任的计算机系统或设备。使用在不同的通信协议、数据格式或语言，甚至体系结构完全不同的两种系统之间，网关是一个翻译器。与网桥只是简单地传达信息不同，网关对收到的信息要重新打包，以适应目的系统的需求。同层–应用层。
API网关：
API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。
全链路压测：
一、什么是全链路压测
基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程。
二、全链路压测解决什么问题
针对业务场景越发复杂化、海量数据冲击下整个业务系统链的可用性、服务能力的瓶颈，让技术更好的服务业务，创造更多的价值。
三、面对的问题点以及解决方案
1、业务模型梳理
首先应该明确的是：全链路压测针对的是现代越来越复杂的业务场景和全链路的系统依赖。所以首先应该将核心业务和非核心业务进行拆分，确认流量高峰针对的是哪些业务场景和模块，针对性的进行扩容准备，而不是为了解决海量流量冲击而所有的系统服务集群扩容几十倍，这样会造成不必要的成本投入。
2、数据模型构建
数据构建和准备，应该考虑这几点问题：
①、数据的真实性和可用性
可以从生产环境完全移植一份当量的数据包，作为压测的基础数据，然后基于基础数据，通过分析历史数据增长趋势，预估当前可能的数据量；
②、数据脱敏
基于生产环境的全链路压测，必须考虑的一点是不能产生脏数据，以免对生产造成影响，影响用户体验等，因此在数据准备时需要进行数据脱敏；
③、数据隔离
同样，为了避免造成脏数据写入，可以考虑通过压测数据隔离处理，落入影子库，mock对象等手段，来防止数据污染；
3、压测工具选型
全链路压测应对的都是海量的用户请求冲击，可以使用分布式压测的手段来进行用户请求模拟，目前有很多的开源工具可以提供分布式压测的方式，比如jmeter、Ngrinder、locust等。
可以基于这些压测工具进行二次开发，由Contorller机器负责请求分发，agent机器进行压测，然后测试结果上传Contorller机器。
考虑到压测量较大的情况下回传测试结果会对agent本身造成一定资源占用，可以考虑异步上传，甚至事务补偿机制。
4、压测环境搭建
全链路压测都是基于生产环境，解决了业务模型和数据以及压测工具选型开发，就要考虑系统扩容和风险规避了，比如压测不能影响实际的生产业务运行，还有资源申请等。
重新搭建一套完全匹配生产环境的压测环境，成本太高，且需求频次较低，投入成本太大。
5、系统容量规划
前面提到了业务拆分和流量预估，在系统容量规划阶段，首先应该对单个接口单个服务进行基准测试，调整配置参数，得到一个基准线，然后进行分布式集群部署，通过nginx负载均衡。
至于扩容，要考虑到服务扩容和DB资源扩容，以及服务扩容带来的递减效应。
至于大流量冲击情况下，可以考虑队列等待、容器锁、长连接回调、事务降级等方式来解决。
6、测试集群部署
能做全链路压测的业务系统，基本都是分布式系统架构，服务集群部署和负载均衡，就是需要实现和考虑的技术点。
需要解决的问题有：
①、服务间通信问题
一般通信方式有两种：同步和异步。
同步调用：
REST（JAX-RS，Spring Boot）
RPC（Thrift, Dubbo）
异步调用：
(Kafka, Notify, MetaQ)
同步调用一致性强，但是要考虑性能和调用失败的事务处理。
异步调用的话，可以降低服务间的耦合，提升性能体验，但是一致性是需要解决的（分布式架构有个CAP理论，感兴趣的可以查询相关资料看看）。
②、负载均衡问题
需要将大流量冲击均匀的分发给集群上的每台机器，目前比较优秀的负载均衡服务器是nginx，但nginx的部署貌似也存在一些问题，我们公司之前就遇到过订单重复问题。
③、容灾问题
需要确保的一点是：当服务中的某台或者某部分服务宕机，可以及时的进行服务转发，而不至于连锁反应下整个系统链路的服务挂掉（可以参考我之前的博客：容灾测试）。
7、数据收集监控
压测数据收集，需要由agent机回送给Contorller机器，但数据量过大会占用一定的资源，可以考虑异步实现测试结果回送。
至于监控，现在有很多优秀的专业监控工具，比如Nmon、Zabbix，全链路监控工具Zipkin、PinPoint以及携程开源的全链路监控工具CAT。
或者可以针对需要，二次开发JVM自带的一些监控工具，做到实时全方位监控。
IO HANG：
字面理解就是Input Output卡住了。简单的说，就是服务器磁盘出现问题，读写过慢，导致线程和进程挂起。大量读写线程/进程挂起导致服务器宕机…
谓的 hang，其实就是说系统假死了。hang 就是停止响应，IO hang，就是指 IO 停止响应，或者是说 IO 响应的慢了。这也就是为什么很多公司反映 APP 卡顿了之类的。
IO hang 一般非常的少见。与 hang 有相关的还有，系统 hang 住了（系统停止响应了），数据库 hang 等一般指的都是磁盘故障了。引起这类问题的原因一般是硬件故障或者软件出现问题。
PM：
项目经理或产品经理，这个要看公司了
RDS：
RDS是关系型数据库服务（Relational Database
Service）的简称，是一种即开即用、稳定可靠、可弹性伸缩的在线数据库服务。
QPS：
每秒查询率（QPS，Queries-per-second）是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准
