发布时间：19-07-1720:12
一、引言
本文题为微服务和大数据性能指标参考，但实际上，无论是单体架构还是分布式架构、数据规模如何，在设计和开发各种功能性模块时，都需要提前考虑高性能需求水平并按需设计，对各种性能指标进行合理评估，从而尽量减少代码重构的可能性。
在完成功能模块的开发以后，还需要使用各种压力测试工具进行性能测试，从而判断代码是否能够满足性能要求，并找出性能瓶颈所在。
为了作出更加合理的性能评估值，我们需要先大概的了解一些常用的计算机操作所消耗的时间，从而心中有数的设计出一个符合需求、且易于实现的系统，减小线上系统失败的风险，并能够做到心中有数。
二、常用应用层性能指标参考标准
以下标准是使用PC X86 桌面机器的经验值，并不代表使用线上生产机器的经验值，仅供参考，评审时应该根据机器的不同进行调整。
2.1 通用标准
容量按照峰值的5倍冗余计算。分库分表后的容量一般可存储N年的数据（根据不同机器调整）。第三方查询接口吞吐量为5000/s。单条数据库记录占用大约1KB的空间。
2.2 MySQL
单端口读：1000/s。单端口写：700/s。单表容量：5000万条。
2.3 Redis
单端口读：40000/s。单端口写：40000/s。单端口内存容量：32GB。
2.4 Kafka
单机读：30000/s。单机写：5000/s。2.5 Flume
HDFS Sink：33k(events)/s。Hive Sink：31k(events)/sHBase Sink：11mb/sAsync HBase Sink：0.8mb/sKafka Source：100mb/s
三、性能测试报告
Flume官方Wiki性能测试报告：
3.1 测试环境:
以下测试基于单个agent
hadoop集群配置：20-node Hadoop cluster (1 name node and 19 data nodes).
服务器配置:24 cores – Xeon E5-2640 v2 @ 2.00GHz, 164 GB RAM, 7200 rpm Hard Drive.
3.2 File channel with HDFS Sink (Sequence File):
基于1.4版本的flume测试，source为4个exec，channel为file，sink为hdfs
Flume version:1.4
Source:4 x Exec Source, 100k batchSize
HDFS Sink Batch size:500,000
Event Size:500 byte events.
Channel:File
Measurements were taken to get an idea around the configuration that yields best performance. So took measurements only for all data points in the grid that made sense. For example it was not necessary to take measurements for multiple dataDirs at single sink, as it was evident multiple HDFS sink would better than single sink config.
结论：混合的多sinks要比单sink的效果好。
3.3 HDFS Sink:
相比3.2使用了内存channel ，memory channel，减少了磁盘的IO压力
Flume version: 1.4
Channel: Memory
Event Size:500 byte events.
Some simple observations:
increasing number of dataDirs helps FC perf even on single disk systemsIncreasing number of sinks helps结论：提高sink的数量是有显著效果的。
3.4 Hive Sink:
hive sink ，channel为内存，flume版本为1.5或者1.6
Flume version: 1.5 & 1.6
Channel:Memory
BatchSz:1million
Event Size:500 byte events.
Observation: Feeding JSON data to Hive sink is much slower, potentially due to higher parsing overhead of JSON in part.
结论：发送json数据格式会慢一些，主要是慢在json的解析上
3.5 HBase Sink:
Flume version:1.5
Channel:Memory
Serializer:RegexHbaseEventSerializer
Total Sinks:1
3.6 ASync HBase Sink:
Flume version: 1.5
Channel:Memory
Serializer:SimpleAsyncHbaseEventSerializer
Total Sinks:1
3.7 Kafka Source:
Flume version: 1.6
Channel:Memory
Sink:Null Sink
Event Size:1000 bytes
Total Sinks:1
其他组件报告暂略。
四、常用系统层性能指标参考标准
4.1 寄存器和内存
寄存器、L2、L3、内存、分支预测失败、互斥量加锁和解锁等耗时为纳秒级别。内存随机读取可达30万次/s，顺序读取可达500万次/s。内存每秒可以读取GB级别的数据。读取内存中1MB的数据为250ns，为亚毫秒级。4.2 硬盘I/O
普通的SATA机械硬盘IOPS能达到120次/s。普通的SATA机械硬盘顺序读取数据可达100MB/s。普通的SATA机械硬盘随机读取数据可达2MB/s。普通的SATA机械硬盘旋转半圈需要3ms。普通的SATA机械硬盘寻道需要3ms。普通的SATA机械硬盘在已经寻道后（找到了要读取的磁盘，也找到了要读取的扇区）开始读取数据，读取一次数据真正的耗时为2ms。FusionIO卡（一种高的SSD硬盘套件）可达到百万级别的IOPS。高端机器如IBM、华为等的服务器配上高端的存储设备，可以达到每秒GB级别的数据读取，相当于普通内存的读取速度。固态硬盘访问延迟：0.1~0.2ms，为亚毫秒级别，和内存速度差不多。4.3 网络I/O
常见的千兆网卡的传输速度为1000Mbit/s，即128Mbit/s。千兆网卡读取1MB数据：10ms。4.4 数据库
读写数据库中的一条记录在毫秒级别，短则几毫秒，多则几百毫秒，大于500ms一般认为超时。MySQL在4核心、256GB内存的CPU中性价比最好，继续垂直扩展时由于体系结构的限制，成本开始增加，提升的性能开始减少，性价比开始降低。4.5 IDC
同一机房网络来回：0.5ms。异地机房来回：30~100ms。同一机房的RPC服务调用为几个毫秒，有的为几十毫秒或者几百毫秒，一般设置500ms以上为超时。4.6 网站
网页加载为秒级别。UV：每日一共有多少用户来访，用Cookie Session跟踪。独立IP访问：每日有多少独立IP来访，同一个局域网可看到同一个IP。PV：每日单独用户的所有页面访问量。如果每日UV为50000000，那么每秒的平均在线人数为50000000/24/60/60=578人，还要知道这一秒内每个用户都在做什么，如果每秒内都在做一次查询操作，那么需要有一个能承受578/s吞吐量的机器。某社交媒体平台每秒的写入量上万，每秒的请求量上百万，每天登录的用户上亿，每天产生的数据量上千亿。4.7 组合计算和估算
普通的SATA机械硬盘一次随机读取的时间为：3ms(磁盘旋转)+3ms(寻道)+2ms(存取数据延迟)=8ms。普通的SATA机械硬盘每秒随机读取：1000ms/8ms=125次IOPS。IOPS代表磁盘每秒可随机寻址多少次，随机读取速度取决于数据是如何存放的，如果数据按照块存放，每块4KB，每次读取10块，那么随机读取速度为：10×4KB×125次/s=5MB/s。一次读取内存的时间：1000ms/30万次/s=3ns。CPU速度=10倍×内存速度=100倍×I/O速度。顺序读取普通的SATA机械硬盘1MB的数据：20ms。请记住：2的10次方=1KB，2的20次方=1MB，2的30次方=1GB，2的32次方=4GB。
五、微服务性能监控和优化组件
5.1 Histrix-Dashboard和Turbin
Hystrix的主要优点之一是它收集关于每个HystrixCommand的度量。并通过Dashboard以一种有效的方式显示每个断路器的健康状况。
Hystrix-dashboard是一个可以单独使用的监控界面，不需要注册进eureka服务端，也不需要与其他微服务有通信，所有需要进行监控的微服务都可以通过dashbaord界面进行配置。
数据和图形会根据监控的端点（如：ip:8010/hystrix.stream）的数据变化在不断的实时变化。
使用Turbine增强健康检查：
从单个实例来看，Hystrix数据在系统整体健康方面并不是很有用。Turbine是一个应用程序，它将所有相关/Hystrix.stream端点聚合到一个组合/Turbine.stream中，以便在Hystrix Dashboard中使用。Turbine可以整合集群中的多个微服务，同时监控整个集群的实时健康状态。
界面如下所示：
从上图可以看到，该界面可以对微服务集群中的流量状态进行监控，指标包括：
请求成功数、超时数、线程池拒绝数、失败/异常数、最近10s的错误比例、请求频率、断路器状态、百分位延迟统计（90%、99%、99.5%）等集群下的主机报告，并使用折线展示2分钟内的流量相对变化。
5.2 Rate-limited网关多维度限流：
微服务开发中有时需要对API做限流保护，防止网络攻击，比如做一个短信验证码API，限制客户端的请求速率能在一定程度上抵御短信轰炸攻击，降低损失。也可以防止某些微服务在单位时间内的访问次数过于频繁。
微服务网关是每个请求的必经入口，非常适合做一些API限流、认证之类的操作，本系统采用一个基于zuul微服务网关的API限流库，它可以：
1、 对请求的目标URL进行限流（例如：某个URL每分钟只允许调用多少次）
2、 对客户端的访问IP进行限流（例如：某个IP每分钟只允许请求多少次）
3、 对某些特定用户或者用户组进行限流（例如：非VIP用户限制每分钟只允许调用100次某个API等）
4、 多维度混合的限流。此时，就需要实现一些限流规则的编排机制。与、或、非等关系。
例如：
我们要对user-center这个服务进行限流，限制每个请求源每分钟最多只能请求10次。某个IP的客户端被限流并不影响其他客户端，即API网关对每个客户端限流是相互独立的。
对API限流是基于Zuul过滤器完成的，默认情况下限流数据是记录在内存中的，实际上是用ConcurrentHashMap保存，同时它也提供了多种存储方式，包括Redis、Consul、Spring Data JPA，使用这三种存储方式要添加相关依赖，我们可以再次基于这些存储进行监控系统的二次开发。
5.3 Sleuth、Zipkin服务调用追踪
在微服务架构中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。
Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案。
跟踪原理：
pom中依赖spring-cloud-starter-sleuth包后，每次链路请求都会添加一串追踪信息，格式是[server-name, main-traceId,sub-spanId,boolean]
第一个参数：服务结点名称；
第二个参数：一条链路唯一的ID，叫TraceID
第三个参数：链路中每一环的ID，叫做SpanID
第四个参数：是否将信息输出到Zipkin等服务收集和展示。
Spring Cloud Sleuth可以对服务与服务之间的调用进行追踪：
1、 服务追踪，一条链路上的所有处理给统一的TraceID，通过这个唯一标识就可以找到完整的处理链路。
2、 每一环的微服务结点处理时我们再给一个独立的SpanID，这样请求何时到达结点、合适离开结点都有追踪的依据，就可以判断出每一跳的延时情况。
图形化展示：
日志采集并积累到一定体量后，就会具备可分析的价值。例如一个请求链会经历ABC3个微服务结点，我们通过分析A、B、C服务结点处理时长的变化可以提前发现某个环节的处理能力不足需要扩展结点。Spring Cloud Zipkin已经提供了这样的图形化分析工具，只需要开启一个Zipkin-server结点，打开收集端口，将此接口添加到所有业务服务结点上就可以基本实现这一需求。
实际生产中单通过Zipkin还是不足以满足我们对日志的收集和分析，Sleuth与ELK的配合才可以把日志处理和分析做到另一个高度，本系统会在未来的更新版本中增加Sleuth与ELK的配合调度。
调用链界面展示：
六、大数据性能监控和优化组件
6.1 Cloudera Manager
CDH：全称Cloudera’s Distribution Including Apache Hadoop
hadoop是一个开源项目，所以很多公司在这个基础进行商业化，Cloudera对hadoop做了相应的改变。
Cloudera公司的发行版，我们将该版本称为CDH(Cloudera Distribution Hadoop)。它是目前市场上企业级大数据框架的主流选择。
Apache版本的大数据框架组件和CDH企业级框架的区别：
1、Apache Hadoop 不足之处
版本管理混乱 部署过程繁琐、升级过程复杂 兼容性差 安全性低
2、Hadoop 发行版
Apache Hadoop Cloudera’s Distribution Including Apache Hadoop（CDH） Hortonworks Data Platform (HDP) MapR EMR …
3、CDH能解决哪些问题
1000台服务器的集群，最少要花费多长时间来搭建好Hadoop集群，包括Hive、Hbase、Flume、Kafka、Spark等等 只给你一天时间，完成以上工作？ 对于以上集群进行hadoop版本升级，你会选择什么升级方案，最少要花费多长时间？ 新版本的Hadoop，与Hive、Hbase、Flume、Kafka、Spark等等兼容？
4、CDH简介
Cloudera's Distribution, including Apache Hadoop 是Hadoop众多分支中的一种，由Cloudera维护，基于稳定版本的Apache Hadoop构建 提供了Hadoop的核心 – 可扩展存储 – 分布式计算 基于Web的用户界面
5、CDH的优点
版本划分清晰 版本更新速度快 支持Kerberos安全认证 文档清晰 支持多种安装方式（Cloudera Manager方式）
CDH对其管理下的各种大数据组件服务均有完善的性能监控功能和对应的API，可以在此基础上进行二次开发。
CDH界面展示：
主页以上各个大数据服务组件均有各自独
6.2 自定义数据采集限速拦截器
在大数据采集过程中，可能会遇到数据产生速度过快、采集速度过快，而内存通道溢出的情况，从而丢失数据或产生宕机，为解决类似问题，参考Netty的流量整形原理，自定义数据采集限速拦截器，可以更好的解决秒杀、流量峰值等问题。
自定义限速拦截器原理是，根据指定速率下每秒采集数据量计算正常耗时，计算上次采集事件发生到现在经过的毫秒数，如果小于正常耗时，当前线程进入休眠，直到正常耗时再次开始接收采集事件。
来源：oschina
链接：https://my.oschina.net/u/4305315/blog/4893729