KafKa入门

Posted on 周三 19 四月 2017 in [技术架构] • Tagged with [TechnologyArchitecture]Leave a comment

kafka背景

Kafka最初是由LinkedIn开发,并于2011年成为Apache的一个开源项目,随后在2012变为Apache的一个顶级项目。kafka是由Scala和Java语言编写的的。Kafka是一个基于发布-订阅,具有容错的消息系统。具有高性能,可扩展,分布式等特性。

kafka介绍

在大数据领域中,我们会使用了大量的数据。 关于大数据,我们有两个主要挑战。第一个挑战是如何收集大量的数据,第二个挑战是分析收集到的数据。为了克服这些挑战,你需要一个消息系统。Kafka的设计目标就是称为一个分布式,高吞吐量的消息系统。Kafka也可以作为一个传统的消息中间件的替代品。 与其他消息系统相比,Kafka具有更好的吞吐量,内置分区,复制和固有的容错能力,这使得它非常适合大规模消息处理应用程序。

什么是消息系统?

消息系统负责将数据从一个应用程序传输到另一个应用程序,因此应用程序可以专注于数据,但不用关心消息如何共享。 分布式消息传递基于可靠消息队列的概念。 消息在客户端应用程序和消息传递系统之间异步排队。 有两种类型的消息模式可用:一种是点对点,另一种是发布-订阅(pub-sub)消息系统。 大多数消息模式遵循pub-sub。

点对点消息系统

在点对点消息系统中,消息被保留在队列中。 一个或多个消费者可以消费队列中的消息,但是特定消息最多只能由一个消费者消费。 一旦消费者读取队列中的消息,它就从该队列中消失。 该系统的典型示例是订单处理系统,其中每个订单将由一个订单处理器处理,但多个订单处理器也可以同时工作。 下图描述了结构。

01

发布-订阅消息系统

在发布-订阅系统中,消息被保留在一个主题中。与点对点系统不同,消费者可以订阅一个或多个主题并使用该主题中的所有消息。在发布-订阅系统中,消息生产者称为发布者,消息使用者称为订阅者。 一个现实生活的例子是Dish电视,它发布不同的渠道,如运动,电影,音乐等,任何人都可以订阅自己的频道集,并在这些订阅的频道可用时获得它们。
02

kafka是什么?

Apache Kafka是一个分布式发布 - 订阅消息系统和一个强大的队列,可以处理大量的数据,并使您能够将消息从一个端点传递到另一个端点。 Kafka适合离线和在线消息消费。 Kafka消息保留在磁盘上,并在群集内复制以防止数据丢失。 Kafka构建在ZooKeeper同步服务之上。 它与Apache Storm和Spark非常好地集成,用于实时流式数据分析。

优点

以下是Kafka的几个优点:

可靠性 - Kafka 是一个分布式,消息分区的,拥有消息复制和容错的系统。 扩展性 - Kafka消息系统可以实现在线扩展 可用性 - Kafka 使用 “分布式的commit log”,这也意味着消息会尽可能快的持久化到磁盘。 高性能 - Kafka 针对消息发送和消费都有很高的吞吐量。 即使保存了TB级别的数据性能也不会下降。

Kafka 非常快并保证零宕机和零消息丢失。

用例

kafka通常用于下面的使用场景:

  • 监控 Kafka通常用于监控数据的操作。 这涉及聚合来自分布式应用程序的统计信息,以产生集中化的操作数据。
  • 日志聚合方案 kafka可以用来收集跨组织的多个服务的日志,并将这些日志转为统一的格式供消费者使用。
  • 流式处理 流行的实时计算框架,如Storm和Spark流式读取topic中的数据进行处理,然后将处理的结果写入新的,用户或应用需要使用的topic中。Kafka强大的持久性功能在流式处理上下文中也是非常有用的。

need for Kafka

Kafka是一个统一的平台,用于处理所有实时数据Feed。 Kafka支持低延迟消息传递,并在出现机器故障时提供对容错的保证。它具有处理大量不同消费者的能力。 Kafka非常快,执行2百万w/s。 Kafka将所有数据保存到磁盘,这实质上意味着所有写入都会进入操作系统(RAM)的页面缓存。 这使得将数据从页面缓存传输到网络套接字非常有效。

Kafka基础概念

在深入了解Kafka之前,你应该先了解一些基本的术语。像topics,brokers,producers,consumers。下图说明了主要的术语并且表格对这些术语进行了详细的解释。 03
在上图中一个topic被配置为拥有3个分区,分区1包含两个偏移因子0和1。分区2包含4个偏移因子0, 1, 2 和 3。分区3包含1个偏移因子0。 分区副本的id和该副本所在的broker的id一致。

假设,如果一个topic配置的副本因子为3,则kafka会针对该topic的每个分区创建3个独立的副本并将这些副本尽量均匀分散到集群的每个节点上 …

Continue reading

性能测试之监控指标

Posted on 周一 17 四月 2017 in [性能测试] • Tagged with [PerformanceTest]Leave a comment

测试场景

测试场景类型有性能测试、负载测试、压力测试、稳定性测试。

性能测试,是指以性能预期目标为前提,对系统不断施加压力,验证系统在资源可接受范围内,是否能达到性能预期。运用场景:此类型的测试目前最常见。每个项目的性能点,都需要做性能测试。

负载测试,狭义的负载测试,是指对系统不断地增加压力或增加一定压力下的持续时间,直到系统的某项或多项性能指标达到安全临界值,例如某种资源已经达到饱和状态等。运用场景:此类型的测试目前运用得比较少。一般情况下,是以服务器资源安全临界值为界限的测试。如果要模拟某个应用在指定服务器上最大且安全的负载量,则属于负载测试。

压力测试,是指超过安全负载的情况下,对系统不断施加压力,是通过确定一个系统的瓶颈或不能接收用户请求的性能点,来获得系统能提供的最大服务级别的测试。运用场景:此类型的测试目前运用得比较少。但对于大型的共享中心或者核心的应用也会用到。

稳定性测试,是指被测试系统在特定硬件、软件、网络环境条件下,给系统加载一定业务压力,使系统运行一段较长时间,以此检测系统是否稳定,一般稳定性测试时间为n*12小时。运用场景:此类型的测试目前也最常见,针对需要长时间稳定运行的性能点,需要执行稳定性测试。往往在一个项目的性能测试过程中,会划分出优先级较高的性能点,做稳定性测试。

性能指标

  • PV: PageView, 页面浏览量或点击量,用户每次刷新即被计算一次;用户的一次刷新,给服务器造成了一次请求。

  • UV: UniqueVisitor, 访问你网站的一台计算机客户端为一个访客,0:00 - 24:00 内相同的客户端仅记一次。

  • TPS: Transaction Per Second 每秒系统处理的交易或事物的数量,衡量系统处理能力的重要指标。

  • RT: 响应时间,从客户端发送一个请求开始,到客户端接收到从服务器返回的响应结果结束所经历的时间,包括请求发送时间,网络传输时间和服务器处理时间三部分。

  • VU: Virtual User, 模拟真实业务逻辑步骤的虚拟用户,虚拟用户模拟的操作步骤被记录在虚拟用户脚本中,通常使用并发实现。

  • TPS波动: 系统性能依赖于特定的硬件、软件代码、应用服务、网络资源等,所以在性能场景执行期间,TPS可能会表现为稳定,或者波动,抑或遵循一定的上升或下降趋势。用TPS波动系数来记录这个指标值。

  • CPU: CPU资源是指性能测试场景运行的这个时间段内,应用服务系统的CPU资源占用率。CPU资源是判断系统处理能力以及应用运行是否稳定的重要参数。

  • Load: 系统正在干活的多少的度量,队列长度。系统平均负载,被定义为在特定时间间隔(1m,5m,15m)内运行队列中的平均进程数。

  • I/O: I/O可分为磁盘IO和网卡IO。

  • JVM: 即java虚拟机,它拥有自己的处理器、堆栈、寄存器等,还有自己相应的指令系统。Java应用运行在JVM上面。

  • GC: GC是一种自动内存管理程序,它主要的职责是分配内存、保证被引用的对象始终在内存中、把不被应用的对象从内存中释放。FGC会引起JVM挂起。

  • 网速: 网络中的数据传输速率,一般以Byte/s为单位。通过ping延时来反映网速。

  • 流量: 性能测试中,一般指单位时间内流经网卡的总流量。分为inbound和outbound,一般以KB为单位。

  • VU(并发压测用户数) = TPS(每秒执行事务数) × RT(响应时间)

  • 在寻找合适的并发用户数上,建议使用PTS(淘宝性能自动化:https://pts.aliyun.com/lite/index.htm?spm=0 …

Continue reading

自动化测试之BDD

Posted on 周日 26 二月 2017 in [自动化测试] • Tagged with [BDD]Leave a comment

很久没更博了,不记录点什么会觉得脑子空空的。
前些天在重构接口测试框架的时候,突发奇想的一个念头:就是要采用BDD方式来用作接口测试的数据驱动。于是花了一天时间简单学习了一下python的BDD框架-behave,并做了一个小实践。过程与结果,还算很满意。写此文章,向这些开源工具的贡献者们致敬!

什么是BDD

BDD全称Behavior Driven Development,译作 行为驱动开发,是基于TDD (Test Driven Development 测试驱动开发)的软件开发过程和方法。

BDD可以让项目成员(甚至是不懂编程的)使用自然语言来描述系统功能和场景,从而根据这些描述步骤进行系统自动化的测试。

常用BDD框架

目前常用的BDD框架有:ruby的cucumber,python的behave、lettuce等。
所实践项目 使用python开发自动化测试代码,故选用behave框架。总结从环境搭建 到运用 以及最后的测试报告集成到Jenkins上展示。

Behave使用介绍

1、安装

pip install behave ---首次安装  
pip install -U behave ---更新

2、运行第一个测试

测试的功能场景——测试网站的登录功能:
账号密码输入正确--登录成功;
账号密码输入错误--登录失败。

建立框架结构
$PROJECT/
+-- features/                   -- Contains all feature files.
|       +-- steps/
|       |     +-- login.py      -- Step definitions for features.
|       +-- reports/            -- Save test reports
|       |      +-- jsonDumps/   -- Save behave json reports
|       |      +-- jsonReports/ -- Save behave to cucumber json reports
|       +-- environment.py      -- Environment for global setup...
|       +-- login.feature       -- Feature files.
Behave 框架说明:
  • features/.feature文件用于编写测试场景,可以把各种场景和数据写在里面,支持中文;
  • steps/.py文件就是根据所写的测试场景和数据来执行测试;
  • features/.feature文件与steps/.py文件必须一一对应。
  • features/.environment.py 用作测试环境统一配置。
environment.py 部分方法说明
  • before_step(context, step), after_step(context, step)
    These run before and after every step.

  • before_scenario(context, scenario), after_scenario(context, scenario)
    These run before and after each scenario is run.

  • before_feature(context, feature), after_feature(context, feature)
    These run …

Continue reading

用Shell部署测试环境

Posted on 周三 04 五月 2016 in [环境搭建] • Tagged with [shell]Leave a comment

测试环境介绍

Testing environment(测试环境)是指测试运行其上的软件和硬件环境的描述,以及任何其它与被测软件交互的软件,包括驱动和桩。
测试环境=软件+硬件+网络+数据准备+测试工具
以上为百科定义

说的通俗一点,测试环境就是为了测试一个系统而应该具备的所有初始条件.
比如说---喝水,必须有:喝水的东西(软硬件)、水(数据)...

项目环境举例

服务端开发语言:Java
Web应用服务器:Tomcat
项目构建工具:Maven
数据库:Mysql
版本控制:Git
...
如上环境所需的工具安装不再啰嗦,下面简述一下服务端代码的整个部署过程:

1、开发童鞋提交最新代码
2、QA合并代码到测试专用分支
3、QA童鞋需要登录测试机并从测试分支上拉取代码到本地
4、打包代码(war包)
5、将War包Copy到Tomcat的webapps目录下
6、重启Tomcat...可以在启动时查看其日志/logs/catalina.out

Shell脚本一键部署

开发童鞋每一次提交,QA都需要重新部署一遍。一次两次没事,一天好几次你就能尝到那种头冒烟的感觉了。
所以啊,该懒还得懒。这些重复性的劳动就交给机器去执行吧...
挤出来的时间来杯Coffee还是可以的 哈哈

开发每次提交代码后,只需执行一下脚本即可完成部署,是不是很省心呢~
Shell就是这么 牛掰

#!/bin/sh

#进入到工程目录
cd /data/testProject

#切到qa分支
git checkout qapri/test

#从当前qa分支上拉取最新代码
git pull

#进入到工程目录
cd /data/testProject/

#用mvn clean package命令清除之前的war包并重新打包。
#-Dmaven.test.skip过滤测试用例。
#-U从Mav仓库强制更新依赖包
mvn clean package -Dmaven.test.skip -U

#获取XX工程的进程号
APIPROCESS=`ps -ef | grep java | grep tomcat_testProject/ | awk '{print $2}'`

#输出进程号
echo $APIPROCESS

#判断进程号是否真实存在,不为空则Kill掉
if [ -n "$APIPROCESS"  ];then
        kill -9 $APIPROCESS
fi

#删除当前项目tomcat webapps目录下的所有文件
rm -rf /data/tomcat/tomcat_testProject/webapps/*

#拷贝工程war包到tomcat中的web目录
cp /data/car-home/car-home-api/target/ROOT.war /data/tomcat/tomcat_testProject/webapps

#进入到项目tomcat bin目录下
cd /data/tomcat/tomcat_testProject/bin …
Continue reading

接口测试之基础篇

Posted on 周三 20 四月 2016 in [接口测试] • Tagged with [接口测试]Leave a comment

接口测试简介

  • 百度百科中为接口测试给出的定义:
    接口测试是测试系统组件间接口的一种测试。
    接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。
    测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。
  • 接口测试通常包括两类,模块之间的接口测试和 Web 接口测试。
    前者通常是由开发人员在单元测试中进行测试,后者则通常由测试人员进行测试。
    后面的内容主要为 Web 接口测试。

接口测试的意义

测试人员都知道,在整个软件生命周期中,测试介入的越早,成本越低,收益越好。
通常,前端的实现,依赖于后端的接口,测试人员需要在开发人员输出接口文档后,就立即开始设计接口测试用例,在开发人员将接口开发完成后,就可以进行接口测试了。
接口测试,可以提前暴露很多问题,此时开发解决问题,相对在前端的功能测试中发现的问题,其代价要小的多。接口的正确和稳定,会为后面前端的功能测试减少很大一部分工作量。另外接口的自动化、持续集成也相对的比较容易去实现。

接口测试的内容

  • 测试返回值是否正确
  • 测试返回值类型是否符合设计文档
  • 测试返回的 error 信息是否符合设计
  • 对输入进行类型、边界测试,测试接口是否有对异常数据做处理

需要掌握或了解的知识

  • 了解后端常用开发语言,java、php、python 等
  • 了解各种开发语言的某些特性。比如在 php 中的 empty() 方法,有开发同学会用这个方法判断一个字符串是否为空,但这里如果传入的值为0,empty 方法也会判断为空,即 empty(0) 返回的值为 true!因此设计接口用例的时候,要增加此类含有特殊值的 case
  • 了解 tcp/ip、http、https 协议
  • 掌握常用的请求方式,get、post、put
  • 掌握 json、xml、html 的语法
  • 掌握常用的抓包方法
  • 掌握基本的增删改查 sql 语句
  • 掌握一种语言,python、java 或其他语言
  • 掌握 jenkins 环境的搭建

接口测试工具

  • Postman
  • Jmeter
  • SoapUI
  • Fitnesse

接口测试框架或测试库

  • RobotFramework
  • python 的 requests

其他开源库

moco

Continue reading