踏浪无痕 岂安科技高级架构师

十余年数据研发经验，擅长数据处理领域工作，如爬虫、搜索引擎、大数据应用高并发等。担任过架构师，研发经理等岗位。曾主导开发过大型爬虫，搜索引擎及大数据广告DMP系统目前负责岂安科技数据平台开发与搭建。

项目背景

公司项目需要将分布在多台机器中的日志统一收集管理。笔者先后使用logstash，flume等开源项目。并最终自研一套基于Java语言的日志收集系统 Bloodhound。以下从项目关注的角度对开源系统与自研进行分析。

1开源日志收集系统特征

Logstash 和 Flume 都是很成熟的日志收集平台，结构清晰，插件丰富，文档简明易懂，示例代码非常多。其中 Logstash 侧重对字段的预处理，Flume 侧重不同的网络拓扑中日志的传递，通过Agent打通各个网络结点。

2关于日志收集系统的考量

开发语言的选择

公司的开发团队主要集中在 Java，Python。而 Logstash 的插件使用 Ruby，从团队角度，不太具备扩展性。在使用 logstash 增加一个插件比较痛苦，同时几个月使用下来，感觉性能偏低，启动时较慢。

性能的考虑

➦ Flume性能相对比较低，主要有以下几点：

① 单线程。
Flume 每个 Agent 分为 source,channel,sink 等插件。每个插件都只启用单线程处理。如果任务是写数据库等 IO 操作，性能必然会被拖累。

②source的Timer机制
Source 线程在检测有新的更新，会一直读取推向 Channel，当所有的更新处理完毕，线程会退出。启动一个 Timer 线程。定期3秒重新启动，如此反复。在这个过程中，没有充分利用 Java 的多线程通知机制，每次启动都有一些调度，排队，检测及任务初始化过程。影响性能。

③Flume事务机制
Flume 本身已对事各进行了优化，允许批量提交事件。但本质上还是需要检测Sink的处理结果，再进行 Commit 或 Roolback。

管理的考虑

如果将一个 agent 的任务处理串，source->channel->sink 理解为一个任务(这个任务是个抽象的概念，Flume 里并没有这个概念)，那么 Flume 从业务脚度上看，就是单任务收集系统。如果需要同时处理两个任务，必须开启两个 Flume Agent 进程。随着收集任务的增加，必然会大大增加管理成本。

(flume处理：多进程处理多任务)

(Bloodhound处理：单进程处理多任务)

此外，我们还有监控需求，统计需求，任务管理等。这些任务需要和我们的 grafana 平台打通。综合考虑下，我们选择自研日志收集系统。

BloodHound系统

项目名称来源

From wikipedia:

The Bloodhound is a large scent hound, originally bred for hunting
deer, wild boar, and since the Middle Ages for tracking people.
Believed to be descended from hounds once kept at the Abbey of
Saint-Hubert, Belgium, it is known to French speakers as the Chien de
Saint-Hubert. This breed is famed for its ability to discern human
scent over great distances, even days later. Its extraordinarily keen
sense of smell is combined with a strong and tenacious tracking
instinct, producing the ideal scent hound, and it is used by police
and law enforcement all over the world to track escaped prisoners,
missing people, lost children and lost pets.

嗅觉最灵敏的猎犬，寓意是能从包括流量在内的各种粗糙的原始数据中提炼中初步有价值的信息。

项目需求

• 多任务管理系统
• 强扩展性
• 任务监控
• 高性能

项目架构

系统分层

核心框架层

为了充分利用Flume的功能特性，我们也将Bloodhound拆分层source->channel->sink三个层次。这个设计是为了充分利用Flume中的丰富插件资源，请参照以下配置文件。

时序图

source 层

source为数据输入，通常为文件，消息系统等。示例中的Source为Redis，Source为单独运行的线程，从Redis中指定的队列中获取输入，读取完成后则推向 Channel。当 Channel 中队列已满时，则 source 线程则进入等待。

Channel 层

Channel 作为枢钮,连接 Source 和 Channel，主要功能如下：

• 维护一个队列，接受 source 的 put，向 Sink 发送处理。
• 管理一个线程池，调度 Sink 任务。由于 Sink 通常较慢，因此整个核心模块中，只有 Sink 为多线程处理，其余均为单线程执行。
• 控制QPS，可以使用令牌或漏斗，主要目的是保护高并发写入的环境下，Sink 对应的数据库或 Redis。不至于压力过大，影响正常业务请求。
• 发送 Metrics，提供实时监控数据来源。

Channel 层主要的方法有：popEvents, addEvents, notifyEvents, sendMetrics等。

Sink 层

Sink 层为一个 Runnable，接受 Events，被 Channel 调度，执行最终的落地逻辑。
以上三层中，Channel 层有 MemoryChannel 和 FileChannel，如果任务比较重要，应该选择 FileChannel，可以保证进程中断后，Event 不会被丢失。MemoryChannel 管理一个 Queue，性能相对比较高。Source 和 Sink 可以大量复用Flume中的插件代码。

任务管理器

任务管理器，故名思义是管理整个日志收集系统的管理模块。

1任务管理

任务注册接口

可通过任务注册接口向整个进程提交一个任务，如配置所示，任务注册接口是通过一个 http post 方法提供注册并启动一个新的任务。

数据提交接口

默认情况下，Source 是 pull 模式，从文件中，队列中拉取日志。同时也支持 http 方式提交。数据提交接口需要传递两个参数，jobName 和 events 。

2任务监控

查看任务执行情况

在grafana中查看各个任务执行情况，这个数据由核心框架层提供。

查看任务运行情况

提供列表，查看任务状态，启动，停止任务。

系统运维层

进程管理

使用supervisor管理进程。

调度器

根据各个业务情况，使用调度任务对任务进行管理。调用任务管理中的任务启动，停止等。这一块和日志收集核心不太相关，就不再赘述。

结语

笔者从事过多个项目需要使用日志收集，同时也使用了 logstash, flume 等开源系统，总体感觉开源系统比较成熟，有大量插件，事务管理。但和自已业务系统结合不够紧密。自研框架工作量较大，也会有很多坑，优势是较好的和业务接轨。

前言

之前的一个人安全部的77大师傅把我们拉在了一起，然后逐渐发现群里大师傅们也发了建设经验文章。好吧，这么懒得我也分享下自己的经验，也就当对这2年多来的甲方经验的总结。感谢群里的小伙伴们，感谢安全圈的各路大牛们和小伙伴们的帮助，更感谢朝夕相处的同事们的帮助。

概述

首先，把要说的重点总结下，时间就是金钱，剩下的都是废话围绕这些去说的。（PS。本文所说的甲方安全，全部指一个或者两三个普通人的小团队，非大佬团队，非互联网航母企业）

• 安全一定要由上往下去推动
• 不制定奖惩措施的制度是很难推行落地的
• 外部机构的检查远远比自己找出来的问题更有影响力
• 作为甲方安全，你要以主人翁的角度去思考和推动，不要把开发看成敌人
• 不要任何事都自己造轮子，在现有的基础上加以改造
• 不要一直做救火队员，要推行有利于安全的流程
• 把安全做得有声音，最好有产出物（P神总结的）

好了，开始废话了

之所以把一个人加引号，是因为在甲方做安全，真的不能靠一个人来做，而是需要周围一切可以借助的资源去做，才能够做起来，否则很多事情举步难行，到头来树敌万千，工作也无法顺利进行。

接下来是我做过的事情时间点

• 2015年一套合规各类检查的管理体系，熟悉基础架构、初步了解业务。
• 2016年救火的一年，发现问题修复问题，同时规范流程（基础建设）
• 2017年把一些开源项目加入到环境中，弥补某些方面空缺（逐渐完善）

今年618买了本书，《互联网企业安全高级指南》，神级的甲方建设指导的书，覆盖很全面，思路很清晰。

☞三张表

1. 组织架构图
2. 产品和负责人对应表
3. 全网拓扑、逻辑架构、物理图、各系统间调用关系、数据关系流等

后面还有各类技术介绍，讲的很全面。

很庆幸自己没有走弯路，大体方向还对，不幸的是都是摸索的去做，会耽误时间，有些客观因素不能实现，比如团队。。。

2015

8月入职，一家具有支付牌照的互联网金融公司，网络运维部下。正好赶上支付牌照的认证，互金企业的监管机构太多了，等级保护，PCI DSS，ADSS，中金认证，人民银行……

于是，为了应对检测，先把现有制度熟悉了一遍，长远考虑，打算重新搞一套符合各位大爷的制度，在原有不熟悉的制度上改造不如重新做。

管理制度制定的思路是依据 ISO27001 建立框架，分级制定“制度流程–操作手册–记录”。结合等级保护（许多人说等保只是应付，其实等保结合了各种标准，形成了一个安全基本要求，挺全面的）、ITIL（流程上可参考）、BS25999（业务连续性可参考）、NIST SP800-53 和ISO27005（风险评估可参考），管理专业人士请教育，毕竟我也不太懂…

因为金融业的合规要求很多，仅仅27001的覆盖面是不够的，因此结合多一些完全覆盖各类合规检测。

其实我国的GB系列标准，已经引进了多个ISO标准，而且全中文看着很方便。下面是推荐参考的内容，完全足够。

✪ ISO/IEC 27001:2013信息技术 安全技术 信息安全管理体系要求
✪ ISO/IEC 27002:2013信息技术 安全技术 信息安全控制实用规则
✪ GB/T 22239-2008 信息安全技术 信息系统安全等级保护基本要求
✪ JR/T 0122-2014 非金融机构支付业务设施技术要求
✪ GB/T 20271-2006 信息安全技术 信息系统通用安全技术要求
✪ GB/T 18336-2008 信息技术 安全技术 信息技术安全性评估准则
✪ GB/T 20984-2007 信息安全技术 信息安全风险评估规范
✪ GB/T 20269-2006 信息安全技术 信息系统安全管理要求
✪ GB/T 27910-2011 金融服务 信息安全指南
✪ GA/T 708-2007 信息安全技术 信息系统安全等级保护体系框架
✪ ISO 22301：2012 公共安全-业务连续性管理体系-要求
✪ GB/T 20988—2007 信息安全技术-信息系统灾难恢复规范
✪ GB/Z 20985-2007 信息技术 安全技术 信息安全事件管理指南
✪ GB/Z 20986-2007 信息安全技术 信息安全事件分类分级指南
✪ GB/T 24363-2009 信息安全技术 信息安全应急响应计划规范

制度的制定并不仅仅是应对检查，最终还是要落实，所以制度的细节一定要切合公司自身情况，尽量简单易于执行。虽然落实比较难，但流程的东西一定要落实，比如系统上线、变更要规范其安全标准化。一般安全是挂在运维下……就算不是也要和运维打好关系，把基础安全这层打牢，可以在运维推行部分流程，前面提到的4级文件形式，做过的事情要记录，记录尽量电子化，便于查阅，一是检查的时候真的有，没必要再造假了 – -！二是记录也可便于事后的总结、追溯，有一天会帮助到你的。等大家适应了流程，再一点点细化、增加，如果一口气推下去所有制度，很难落实。不想要一口吃成胖子，有了部分框架标准和流程，对于安全很重要了，你不会再浪费时间去查看对外开放端口、之前的struts漏洞新上的系统是否存在等等。

安全一定要由上往下去推动
不制定奖惩措施的制度是很难推行落地的

这是两条制度落地的关键，说多了都是泪，自己体会吧。最理想的状态是形成PDCA闭环，不断完善改进。

ps，互金企业更重视结果的记录，因此在做类似系统变更、补丁修复这样的操作时候要有记录，无论纸质或者电子的。

2016

这一年公司业务发展迅速，上线的系统也多了，起初还有时间挖挖漏洞，后来就是疲于上线扫描、定期扫描、漏洞修复，然而可怕的是同样的漏洞会再次出现，开发小伙伴们忙于进度是不会太注意安全的，立场不同。还好当时的CTO重视安全，运维领导极其重视安全，对于新公开的高危漏洞，群发邮件后，都会把各个技术负责人召集起来开会，自己评估是否影响并确定整改期限，领导的强势会有助于工作的进行。

这一年与某大互联网公司合作，签了安全服务，包括培训、渗透、抗D等等。他们挖出来的漏洞会被更重视（同类型问题自己找出来不会很受重视 > <）。所以啊安全开发、上线安全检测流程是必要存在的。

外部机构的检查远远比自己找出来的问题更有影响力

除了救火，其实另一半的工作是把基础安全做好，不要想一口气做好所有，一步一步来，让大家有个“温水煮青蛙”的过程，渐渐的都会适应。

个人感觉初期建设流程2个步骤足够了：

1. 发现目前不足
2. 针对不足加以完善

不要任何事都自己造轮子，在现有的基础上加以改造

具体工作如下：

1网络方面

确认开放端口，nmap或masscan扫下，然后和防火墙策略对照下。只提供必要服务的端口，SSH这样的坚决不对外提供。
交换机路由器基线配置，比如snmp配置不能用public
网段的重新划分，访问控制策略的重新制定（起初提过但改动太大，后来外部渗透服务，拿到内网权限后坚决整改，事件驱动）。根据重要性划分网段，网段间严格访问策略（通过路由或ACL都行，目的达到即可），可做部分mac绑定，比如网关、重要网段，办公区wifi只允许连接互联网。
堡垒机，所有设备、服务器均通过堡垒机访问
IPS和WAF设备的规则优化，每周的攻击日志分析

2系统方面

其实运维团队基本都会有自己的一套标准，包括自动化部署、监控、日志收集等。因此要做的就是熟悉现有方法，加以完善。

如果在没有任何监控、安全措施的环境下，可以自己搭建一套SIEM，但是拿我们的环境来说，目前已经有了nagios、cacti监控网络、性能、进程，服务器文件完整性检测、puppet配置同步，定制的加固过的系统镜像，时间同步、日志收集措施，我觉得覆盖面已经足够了，不如在现有基础上进行优化。

欢迎大佬指教还欠缺哪些方面。

实现安全目标的方式有很多种，只要达到目的，最切合企业自身利益便好。

数据库真心不太懂，而且我们有oracle、mysql、SQLserver、mongoDB，核查下安全基线关注下漏洞动态…比如启动数据库的账号权限，数据库内的默认账号，生产库账号限制，访问权限限制。数据库审计我见到的基本没人开的，影响效率。但是对于数据安全，互金企业对其要求极高，数据的存储、加密、传输、备份恢复都有严格要求，按照监管机构的要求去做就好了╮(╯▽╰)╭

ps，作为互金企业，对灾备切换极其重视，因此每年的灾备演练要确实去做。

应用安全，其实本质还是要提高代码安全，请了外部培训、外部渗透测试，也没有搞好这方面，这也是甲方安全的一个痛点。其实人与人之间的交流都一样的，与开发交流，要用“咱们”，不要挑开发的问题，要说成那些讨厌的人会不正常的去输入内容，绕过web界面直接修改数据包等等，原则上是找共同利益点，多赞美，人性所在啊。换个角度去想，作为开发任务挺紧的，实现功能、赶进度、改bug，突然来了个人和我说你的代码不安全，这样不行，WTF，你丫哪根葱你来写啊。所以互相理解吧。

1.作为甲方安全，你要以主人翁的角度去思考和推动，不要把开发看成敌人

题目是带引号的一个人，因此我们要借助可以利用的各种资源去做安全。比如DDOS防御，我们是把服务器托管到IDC机房，对于DDOS防御肯定要借助外部力量，机房的流量清洗以及安全公司提供的抗D服务。再比如我们自己的DNS服务器，每天很多的攻击流量，于是采用外部的DNS服务，自己不再做DNS解析。

把自己无法做到的事情和非关键业务又浪费精力资源的事情，转交给专业的外部服务团队，性价比更高。

2. 作为甲方安全，其实起初在技术深度上下功夫，并不能给整体企业安全带来太多显著提升，反而流程上安全优化会有显著提升。先做纬度，再做深度。

比如你的开发同学将源码传到git上公开…

不要一直做救火队员，要推行有利于安全的流程

于是在频频救火的过程中，即使领导再重视，你依旧处于救火中。流程制定好，处理事情有条理，整体的企业安全会有显著提高。

最关心的流程我觉得就是安全事件，那么安全事件发生后第一时间得知，就需要一个监控汇上报过程，包括技术上的监控系统，非技术层面的运营人员发现系统故障。向谁上报，上报哪些内容，如何处理，由谁处理，处理优先级，处理方法，总结积累。

从这个流程可以看到，我们需要业务连续性分析（处理优先级），应急手册（处理方法），可能这些东西太虚，但起码你要了解自己公司的哪些业务重要，遇到不同安全事件如何处理，需要外部资源联系谁。

每一年可以集中对这些事件进行分析总结，然后根据结果进一步优化代码也好，架构也好，进一步提升安全能力。

总之，我觉得重要的2个流程：

安全事件处理流程
系统上下线流程（资产信息变更、基线确认、安全测试等，最有效的把系统安全提升到及格分数）

这一年还确定了安全预警流程、漏洞修复流程以及下图中运维相关的流程。

制定流程要切合实际，便于落地执行，精简。至于是否完全合理，在今后的工作中逐渐微调，总之先有一个流程先让大家适应。其次，要把权限责任分散出去，流程可以是自己制定或者和同事一起，但至于流程的执行负责人分开管理，让大家知道谁负责哪些，该有什么流程，既起到了规范作用，又减少了出现坑的机率了。

2017

这一年，日常的安全日志分析、漏洞预警、季度扫描、上线测试、漏洞修复、安全事件处理、合规检查已经轻车熟路了，再在原有基础上优化流程，就可以腾出来时间搞些开源的东西。当年做计划的时候写了威胁感知，那时候概念很火，后来给了自己一个大嘴巴，没有大数据根本搞不了这玩意。

目前环境中，没有源代码扫描、日志分析系统，ips和waf都是商业化产品，有时发现一些细节问题无法定制化，资产的管理系统是人工录入，存在延迟更新、失误导致的错误数据风险。于是应用了下面这些开源项目

• 巡风扫描，感觉最好用的是资产管理，可以查看哪些IP开放了什么端口，开放了某端口有哪些IP…可以比我们的监控系统更简单更全面搜索（毕竟服务器多了人为操作难免会有遗漏加监控等等），还可以自己尝试写写漏洞检测脚本。
• Nginx-lua-waf，很实用，基于openresty，可以自己写规则防御某些有针对性的攻击，然而总是与时代慢了一步，AI联动waf的时代已经来临了，尤其兜哥出了AI安全三部曲以后…
• Yasca，源代码扫描，几年前的东西了，支持Java, C/C++, HTML, JavaScript, ASP, ColdFusion, PHP, COBOL, .NET…支持挺多的还免费…而且集成了PMD，JLint等很多常用源代码检测工具，建议在git下载，版本较新。如果是PHP大神还可以定制更改。
• ELK，日志分析，后来公司买了套类似产品…然后我就不再花费精力研究这个了。

推荐些常用的吧，小伙伴们都说好的，很多我都没用过。

网络入侵检测snort的时代过去了，现在基本用suricata。主机入侵检测ossec。Siem产品ossim，跳板机jumpserver，蜜罐t-pot、Awesome Honeypots。

还有个安全思维导图大全：
https://github.com/SecWiki/se...

当基础安全做好，纬度够了，接下来就是要做深度的事情了。

安全开发知识库：对应各类威胁，不断积累的一个代码库。

蜜罐系统：知己知彼，百战不殆。

AI：先看书学习吧 > <

业务安全：互金行业对业务的功能要求蛮多的，而作为互金企业，风控是一个重点工作，我不清楚大的互联网公司风控和业务安全是如何归属，但是业务安全做得好，防止企业利益受损，是看的见的收益。

总结

产出物这个问题，很多人总要搭建一个乌云知识库，一个XSS平台等等，我心想有哪个公司的开发会有时间去玩他，乌云知识库网上有，公司资源紧张我没必要再搞了。现在我终于清楚为什么要搭建了。

把安全做得有声音，最好有产出物（P神总结的）

甲方安全的痛点，在于话语权，公司是以业务为重，安全只是个辅助。因此前面提到的从根本上提高代码安全，推行制度落地流程，都是一个长期的缓慢工作。大的互联网公司安全都很强势，安全不达标系统不能上线，漏洞未按时修复直接影响绩效考核，但有能力做到流程化的基础安全后，才有精力去做业务安全，总之感觉路还很长……

烦请各位大佬指点，灰常感谢。新年快乐～

*本文作者：pur0，
来源：http://www.freebuf.com/articl...

撸主： 阿木 岂安科技项目经理
基础开发出身，目前主要负责岂安产品的项目资源规划和过程管理。

企业对应用集成（EAI）的需求

企业不断发展，很多长期需要人为操作或者流程定制来处理的业务问题，为了提高效率会考虑引入软件应用系统来解决，比如，CRM（客户管理管理）系统，SCM（供应链管理）系统，ERP（企业资源计划）系统等。引入这些系统在当时是解决了一部分的问题，但是随着应用系统数量的增加，新的问题也慢慢暴露了出来。因为，每个应用系统都有不同的开发需求前提和问题背景，系统之间数据也是相互孤立；所以在企业内部，每个应用系统其实就是一个“孤岛”，相互之间没有畅通的信息交流与数据共享。于是经过一段时间之后新的问题就出现了：比如，信息和数据的更新的不同步甚至不一致的问题，更严重的是给客户也经常提供一些前后不一致的信息，导致客户无法接受，这会严重影响到企业的形象和信誉。

企业要解决这些矛盾，一种办法是对现有系统推倒重来：将企业引入的各个信息系统全部更新成一个统一的管理系统，并要求各个部门都在这个统一的系统上工作（如：整个企业的所有应用都在一个ERP系统上运行），但考虑到成本、实施周期和难度因素，这不是一种切实可行的解决方案。还有另一种办法，就是企业从整体来考虑整个信息系统，根据实际需要，对各个应用系统进行总体规划，选择一个合适的集成平台，把企业的各个“信息孤岛”合理的集成起来。这种解决方案不管是从实施难度，还是从实施成本、周期和技术上考虑都是切实可行的。

什么是企业应用集成（EAI）

一般的应用系统是属于独立完成一项应用的软件产品，比如：ERP系统、OA系统、库存管理系统、人事管理系统等等；而系统集成是指将两种、甚至多种类型的应用系统通过二次开发将他们互相集成在一起，可以进行信息资源的共享和相互调用，比如将库存管理系统和ERP系统进行集成后，管理员可以通过ERP系统方便地查看物料零件的当前库存和标准价格等信息；而ERP系统也可以直接将库存管理统中单个零件清单和入库、出库、货品盘点操作等信息自动进行导入，以提高工作效率。

图源百度

企业应用集成（EAI）的分类

关于企业应用集成，可以从深度和广度两方面来理解，然后进行分类。
从集成广度来看：
✦部门内部集成到部门间的集成
✦企业范围内和企业间的集成

部门内部集成到部门间的集成可以理解为一个商业实体（企业）的信息系统进行业务应用集成，比如酒店各部门之间消费的统一结算、直销企业的网上订单到送货的后台过程；但当在多个企业系统之间进行商务交易的时候，也可以表现为不同企业实体之间的企业系统集成，例如跨行信用卡在ATM上的互通、超市与供应商间的电子数据交换。

从集成深度上理解，企业应用集成应该还可以归类为：数据集成、业务集成、应用集成三大类。

数据集成

数据应用集成是企业实施EAI的基础。数据集成的目的是将不同的数据库集成起来，提供一种单一的虚拟数据库，这样就不会出现与核心业务不一致的多个数据库。数据集成直接和企业应用系统的数据库打交道，对数据库进行直接的读写操作。数据层的集成可能是EAI里相对简单的一种集成技术。再简单点理解，就是将企业的签约客户信息与财务的合同收款记录在数据库的基础上打通，保持一致性。

应用集成

应用集成主要是指通过应用接口对应用系统实现集成。应用接口（API）是指应用系统以及客户自建系统为方便和外部应用系统连接而对外开放的软件接口。目前市场上的一些标准商业软件，例如ERP系统，CRM系统，电子商务系统等，为了更好的满足企业应用集成的市场需求，都有非常成熟的API。

业务集成

业务集成是将不同单位部门的不同业务流程利用应用集成技术集成在一起，实现跨部门、跨系统、跨企业的流程共用。

企业应用集成（EAI）的目标

目前企业应用面临着：多对多的数据交换，牵一发动全身；商业逻辑多出重复，浪费开发资源；难以进行业务修改，无法快速推出新产品，新业务；开发质量难以控制等问题。所以，企业需要实现应用集成，马上就可以降低IT成本。因此，可以认为采用企业应用集成的主要目的就是：

实现符合业务流程需要的信息交互。
满足企业实施并行工程和经营过程重组的扩展需要。
充分利用已有资源，通过实现已有应用系统的集成和封装保护企业过去在信息化建设上的投资。
实现应用逻辑和过程逻辑的分离及过程建模与具体数据、功能的分离，支持在不修改功能的前提下，通过修改过程模型来完成集成系统功能的改变，以提高企业的灵活性和反应能力。

企业应用集成（EAI）的步骤

1. 业务模式分析
2. 企业现状分析
3. 确定集成策略
4. 确定集成技术架构
5. 统一元数据标准
6. 分析关键集成店
7. 制定实施计划
8. 分步骤实施
9. 不断优化

一般应用集成实施步骤图

采用企业应用集成（EAI）给企业带来的好处

企业应用集成就是将企业内部已经引入的“信息孤岛”连接起来，实现数据共享和业务流程的共享，可为企业带来以下一些好处：

充分利用企业已有的信息系统，保护企业在信息资源方面的投资

企业的信息资源不仅包括大家所熟知的企业各类数据，还包括企业的管理与决策模式，而这种管理方式体现在电子化上就是企业的各类信息系统（例如：ERP，MIS，财务，销售，SCM等），这些资源是企业花费了大量资金与心血组建起来的。企业应该充分利用好现有的信息系统和数据资源，将这些分离的“信息孤岛”连接起来，避免信息重复多次输入，减少信息存在的冗余，消除大量的垃圾信息，保证信息交流的一致性，保证部门之间进行信息共享，方便领导统揽全局。

优化企业内部的业务流程

1. 利用EAI技术可简化企业内部的信息流，可以将企业传统的业务流程通过信息技术进行整合，实现企业内部业务流程自动化。
2. 利用EAI技术减去不必要的数据重复输入，简化企业内部流程。
3. 利用EAI技术可以将分散在企业内部不同地方的数据进行汇总，为领导决策提供服务。

总结

随着时代的发展，企业迫切需要把自身业务精简化、自动化，使得内部业务直接实现无缝对接，所有应用系统之间的集成将成为企业信息化系统发展的最终目标。

附录：关键词

关键词：信息系统、信息系统集成、应用集成、企业应用集成

信息系统
是用信息化的手段将业务逻辑固化，是人、设备、应用软件、操作环境、业务流程的集合体。

信息系统集成
是根据应用的需求，将硬件产品、网络设备、系统软件、工具软件以及相应的应用软件等集成为一个具有优良性能价格比的计算机系统的全过程。

应用集成
是遵循规范的开放标准，并用技术手段通过系统间的功能交互，实现之间的信息交互。

企业应用集成
实现企业多个应用系统构建之间的协同，将孤立到的应用过程集成起来，形成一个面向需求的、协调的、高度伸缩的、集成的企业信息系统。

撸主：
烟烟 UX设计师
主要负责岂安科技的UI界面和交互设计。

前言

从客观逻辑来讲，直观的数字的确比抽象的图形更有可信度，但是大脑却对处理图形内容上会更容易理解。就像下图一样，我只是给你光秃秃的数据表格，也许你会漏掉一些有价值的东西。但是好的可视化来表达这些数据，你会挖掘数字背后的信息。

之前列举过很多复杂又有趣的可视化案例，这次准备谈一谈数据可视化图表中的视觉暗示。
当我们设计可视化图表的时候，首先，我们要知道我们有什么数据，需要哪些元素来二次加工这些数据。这时，我们就要先了解到可视化的组件有哪些？在这里我将它分为几个部分用下图作示范。

视觉暗示

这些组件相互协作。其中视觉暗示是组件中重要的一部分，如果选择错误的视觉暗示便会影响到其他的组件，使图表变成无用的图形。我们能用到的视觉暗示通常有:长度、面积、体积、角度、弧度、位置、方向、形状和颜色。所以正确的选择哪些视觉暗示就取决于你对形状、颜色、大小的理解，以及数据本身和目标。

1长度

我们经常看到的柱状图、条形图，这就是长度的视觉暗示。数值越大，长度就会越长。经常用于对比类数据里。长度是图形中两端之间的距离，坐标中最小值要从0值开始，否则并不能准确的反映出真实的价值。

2面积和体积

我们普遍都会将数值大小用物体的大小来表达。长度和面积通常用在二维空间里的数值大小对比，体积则用在三维空间里进行多维度对比。这里要强调两点：第一，你要注意你用的是几维空间；第二，面积大小应该按照面积进行扩大缩放，而不是长宽。

3角度和弧度

角度是相交于一个点的两个向量，取值范围在0度到360度,形成一个圆形。
角度的视觉暗示一般都用在饼图。这时候你也许会联想到饼图的近亲:环形图，但环形图的本质是将饼图的中间区域切除，所以环图的视觉暗示并不是角度，而是弧度。
饼图和环形图的优势是让用户快速的了解到数据之间的占比分配，但是如图，它们不适用于过多分类的数据。

4方向

方向是指坐标系上一个向量的斜度，可以看到上下左右及其他方向。一般用在折线图上，表现是增长、下降还是波动。这里要注意一点，随着坐标轴的比例变化，斜度的大小也会受到很大影响。所以根据实际情况，适当调整比例，使变化大的数据放大比例来突出差异，反之，变化微小且不重要的，避免放大比例。

5位置

散点图就用了空间中的位置作为视觉暗示，通过点的形式展现在x、y坐标轴上。每个点代表一个数据，点的位置由变量的数值决定。当大量数据展示出来的时候，就可以看出趋势和相关性，并且比别的视觉暗示占用空间更少。
趋势：上升、下降；
相关性：集群、离群。

6形状

当在一个图表中有多个对象和分类时，用不同形状或者符号来表示。这就是形状上的暗示，通常运用在散点图内，符号或者形状比颜色更容易区分类别。比如用文字符号表示不同分类。

7颜色

在图表的颜色视觉暗示中分为两种，色相和饱和度。
色相是指区别红、黄、绿、蓝等各种颜色，运用在在图表中不同颜色可以表示不同的数据分类。
饱和度是指色彩的纯度，颜色的纯度越高则饱和度越高，如鲜红；混杂了白色、灰色或其他色调的颜色，则饱和度越低，如粉红、黄褐等。在图表中可以用一种颜色饱和度的高低表示同一变量程度的高低。
运用颜色做暗示时，要注意考虑到色盲、色弱人群可能不容易通过颜色来区分图表的纬度和变量。

下面结合多个视觉暗示的举例

色相+位置+长度 ☟

颜色(色相+饱和度)+面积+位置 ☟

符号+颜色+位置 ☟

Jason 岂安科技前端研发工程师

三年互联网前端开发经验，曾参与过多个系统框架的搭建和组件开发，负责岂安科技产品的数据可视化和公用组件开发。

1前言

RAP 是一个可视化接口管理工具， 通过分析接口结构，动态生成模拟数据，校验真实接口正确性， 围绕接口定义，通过一系列自动化工具提升我们的协作效率。
在 RAP 中，您可定义接口的 URL、请求和响应细节格式等等。通过分析这些数据，RAP 提供 MOCK 服务、测试服务等自动化工具。

2为什么要选择 RAP？

轻松编辑和分享

可视化编辑，完善的版本控制，各种格式的导入导出。让前后端约定接口的工作变得十分简单。

Mock服务

RAP会自动根据接口文档生成Mock接口，这些接口会自动生成模拟数据，并支持复杂的生成逻辑。

实力的保障

覆盖阿里几乎所有部门，有数百家公司正在使用RAP，历经4年积累大量经验，可适应各种复杂的业务场景。

3开始 RAP

1轻松编辑和分享

要求环境：
✦ JDK 1.8+
✦ MySql 5.6.12+
✦ Tomcat 8.*+
✦ Redis 3.0+

RAP的部署方式有两种：
一种是直接采用阿里编译好的 war 包，放入 tomcat 即可。
另一种是获取源码后自己编译，或者修改一些代码、做一些个性化的功能之后编译，然后打成 war 包再放入 tomcat。
具体搭建方法参考官方文档：
https://github.com/thx/RAP/wi...

2注册 RAP 账号，创建团队和项目

部署到自己服务器上之后，先注册账号后登录，然后创建团队和项目。

创建之后可以修改项目和添加项目成员，项目成员可以访问该项目的内容和添加修改接口。

3编写接口文档

登录账号后在首页，可以看到“我的项目”，选择一个项目点击进入，就可以开始编写我们的接口文档了。
进入页面后点击编辑，可以看到如下界面：

我们可以将我们的接口文档写在这个地方，备注中可以写出模拟的数据格式，具体规则参考官网用户手册：
https://github.com/thx/RAP/wi...
我们可以定义接口返回固定的字符串、返回随机数，甚至定义方法根据传参做一些处理之后再返回。

4使用接口

一直看到这里，大家可能有疑问，这个文档写出来，好像和普通的文档没有什么区别啊，甚至更加繁琐。这里我们就要说到RAP与其他文档不同的地方：
写完文档之后，我们可以直接调用接口来返回数据，这些数据是根据我们编写的规则动态生成的，前端不需要等到后台开发好接口之后再调用，而是可以和后台同步开发 。
我们来看看返回的数据吧：

这里可以模拟请求来看返回的数据是否是自己想要的结果，确定没有问题之后，我们就可以使用该接口了。因为后台工具暂时还不成熟，所以该处我们介绍一下前端如何使用该接口：

✫ 前端调用接口时，host 和 url 与平常调用有所不同，如上图，请求的 url 为右下方的 url（并始终为 get 请求，无论接口是 post 还是其他的 method），而返回的内容也并不是返回的对象，而是文档转换成的一串字符串。

✫ 在这里我们需要安装 mockjs，用于解析接口返回的内容（安装方法参考： https://github.com/nuysoft/Mo...）

✫ 拿到接口返回的内容后，使用 const result = eval((${res})) ; 解析返回内容，而不是使用 JSON.parse，原因是文档中编写的内容可能有 function，不能使用 JSON.parse 去转换。解析完成后使用 const data = mockjs.mock(result) ; 这时候变量 data 就是我们需要的数据了，也就是图中所返回的结果。

✫ 通过上面三步，我们就可以拿到数据去写我们的代码了。

4结束语

RAP 的基础用法，看完上面的内容我们可以了解的差不多了，缺点也比较明显，调用接口时比较麻烦，但是我们可以通过封装请求方法来减少麻烦程度。总的来说 RAP 平台还是比较实用的。

目前RAP1已经停止更新，官方开始推行 RAP2，界面更加简洁易用，但是没有什么文档，大部分文档还是使用的 RAP1 的文档（也就是今天我们介绍的 RAP 平台）。

RAP的介绍，到这里也就告一段落了，如果大家比较感兴趣可以去官方部署的 RAP 平台（http://rap.taobao.org/org/ind...）用用看，所有功能和自己部署的是一模一样的，大家可以先用用看，如果觉得还不错，就可以部署在自己的服务器上使用了。

撸主： 小思敏儿 岂安科技ui设计师
自我介绍不知道说啥，就是妹子一枚，刚刚入职，在设计届属于晋级级别，热爱设计，我就是这样一个耿直的girl，哈哈哈……

作为设计师寻找到高质量的图片素材是不可或缺的必备技能，除了摄影师和影楼 P 工以外，设计师是最多和图片打交道的职业了，做 BANNER 需要图片素材，做网站和 APP 需要图片素材，甚至连 PPT 和 keynote 也是离不开高清图片素材，接下来我就推荐几个我经常会用到的高质量的图片网站给大家。

500px

如果只能推荐一个网站的话，我会毫不犹豫的推荐 500px，这是全球最老牌的专业摄影分享社区，汇集了全球各种各样的优秀摄影师，这里的照片特别全，摄影师将照片放在网站上供大家交流和下载，网站有很强的社交属性，如过照片特别出色就会被顶到首页，从而获得关注。网站有免费和付费两种账户，可以在这里搜索照片然后付费购买和下载。
网站地址：https://500px.com/

Unsplash

Unsplash 中的图片是免费下载和使用的，不用担心版权问题。Unsplash 中的图片品质都相当高，每张图片的构图和色彩都很棒，不会有图库感，比较有小众的感觉。
网站地址：https://unsplash.com/

Flickr

国外最受欢迎的摄影作品分享网站，不过需要搭梯子。Flickr 提供免费和付费图片，除了有许多用户在 Flickr 上分享他们的私人照片，也可以作为博客图片的存放空间，受到国外许多博主的喜爱。
网站地址：https://www.flickr.com/

Pexels

PEXELS是提供免费高品质图片下载网，也是一个提供海量共享图片素材的网站，每周都会定时更新，所有的图片都会显示详细的信息，例如拍摄相机的型号，光圈，焦距，ISO,图片大分辨率等等，图片质量还是很不错的。
网站地址：https://www.pexels.com/

Interfacelift

Interfacelift 的图片都是风景图片，是我很喜欢的一个风景图片网站，每张照片都是由摄影师精心拍摄的，在这里可以找到很多让人震撼的照片，一些雪地和星空的照片非常棒，而且分辨率很高，从 5K 的 iMac 到手机分辨率都支持，很多图片下载下来当做壁纸也不错。
网站地址：https://interfacelift.com/

Pixabay

Pixabay这个免费的图库提供大量可以使用的照片、向量图和艺术插图，所有在 Pixabay 的图片皆为cco授权，可以被用于任何地方。就像 Flickr，有提供选项来浏览特定相机型号所拍摄出来的效果。
网站地址：https://pixabay.com/

1x

1x也是一个摄影社区，是一个小众且高品质的图片站，从网站的 UI 设计就可以看出来它不是大众审美的产物，纯黑色的背景和现代的字体相结合，展现出一种极高的逼格和品质感。有很多优秀的摄影师在这里交流摄影技巧，灵感枯竭的时候可以到这里寻找灵感。值得一提的是网站每年都会有比赛奖项，任何上传到网站的作品都可以参加比赛，网站图片是付费的，如果想下载图片的话需要到 Prints 页面购买。
网站地址：https://1x.com/

Gratisograph

Gratisograph是一个提供免费高品质摄影图片的集散地，所以图片都可以用于个人或者商业用途，里面有的图片趣味性十足，很适合用作海报图片素材，好图片的站点部好找，尤其是这类站点，几乎都是私藏的，轻易不分享的。
网站地址：https://gratisography.com/

StockSnap

Stocksnap网站是由多位摄影师组成的，提供种类繁多的免费优质高清照片，随意使用无需经过授权，所提供的照片资源很实用。
网站地址：https://stocksnap.io/

Jay Mantri

Jay Mantri是一位自由摄影师，擅长于拍摄自然风景和人文地理类的摄影作品，鉴于推广自己的摄影技巧和作品，创建了以自己名称命名的照片网站，在这里你可以欣赏到很多优秀的摄影作品，这些优秀的摄影作品都是大图，高分辨率的，网站不定时更新照片。
人文地理类。
网站地址：http://jaymantri.com/

希望这次的分享对大家有所帮助！

我们发现很多 Mac 用户对自身的安全并不是很重视，针对用户的恶意软件逐渐增多，窃取用户的隐私, 监控用户的日常行为, 恶意推广广告, etc。因此，我们应该提高自身的安全意识, 警钟长鸣。

1前言

小夏是一名普通 Mac 用户，某天，他打算试试思维导图来记录工作学习。

他问同事小芳：“Mac 下有啥好用的思维导图软件？”
小芳：“XMind 呀，很实用的思维导图软件。”
小夏：“那到哪里下载，要钱吗？”
小芳：“哎，你百度 XMind 破解版呀! 不需要花钱的，直接安装!”
小夏：“这么方便！我试试！”

2样本概述

Xmind 是一款实用的思维导图软件，正版官网售价高达99刀, 这个价格当然对普通用户无法承受, 通过搜索，很多站点都提供了破解版下载

对比相同版本号的正版和破解版, hash 如下:

dab95dbad19995aeb88cc5d1bb0a7912 XMind_orig //正版 v3.7.1

我们发现该样本采集了用户的很多隐私信息, 上传到了第三方服务器,采集信息如下图

目的：1、黑产非法售卖用户信息, 泄漏用户隐私

    2、广告推广, 获取盈利
    3、钓鱼执法, 发送侵权律师函
    4、etc

下面我们对该样本详细分析

3基本信息

在 Mac 应用中，OSX 系统下的 Mach-O 是可执行文件格式，程序跑起来解析 Mach-O，然后链接系统的库文件以及第三方动态库。

我们使用 MachOView 进行解析

在可执行文件 Load Commands 字段中记录了程序的加载指令，LC_LOAD_DYLIB 是程序加载的动态库，其中 Name 字段记录了该动态库的路径，通常程序启动会根据该字段加载动态库。这里发现其加载了新增的两个动态库文件 libcJFishPoolHook.dylib、libXMindHook.dylib。除此之外，XMind使用 Java 编写，移植到 Mac 平台，可执行文件也没有什么值得重点分析。

总结一下，主要做了如下事情:

1、程序启动初始化，获取资源文件。
2、加载 .ini 配置文件，得到启动的参数键值对。
3、将参数解析，然后运行加载 Library(Java 打包的动态库).

直接对比正版和破解版的包目录，在包中我们发现了多出来的2个 dylib 文件。

libC.JFishPoolHook.dylib
libXMindHook.dylib

下面对这2个 dylib 进行详细分析。

4dylib分析

对于 Mac/iOS 中使用到的 dylib，可以使用 class-dump 和 hoppper 结合进行反汇编分析。class-dump 又是一款开源解析 MachO 利器，与 MachOView 相似的是，他可按照 MachO 偏移量，找寻符号表( Symbol Table )，从而导出类名和方法名，但是他提供了诸多参数用于导出不同架构的 MachO 链接符号表。使用如下命令导出类名方法名到文件中：

$ class-dump --arch x86_64 libCJFishPoolHook.dylib > header.txt
$ cat header.txt

从导出结果来看，很可疑的是 CJFishPoolHook 类，该类有多达 16 个成员， 写该动态库的程序员非常老实，没有进行任何加密、混淆类名、方法名的操作，因此从字面上也不难猜出其含义为 qq 号、微信号、手机号、邮箱号、操作系统、CPU 类型、内存、MAC 地址、内网 IP、公网 IP、用户名、应用列表、设备 ID，是否上传信息、开启应用和关闭应用的时间。

第二个动态库的类方法较少，很明显能猜出，hook 了程序的函数，修改程序运行逻辑。
主要方法为:

• 1、init 初始化方法
• 2、ExChangeImp，Method Swizzling 动态交换函数指针，用于 hook
• 3、BuyHook
• 4、CheckUpdatesHook
• 5、HelpHook
• 6、TitleHook
• 7、OpenURLHook
• 8、DateMenuItemHook

最后还使用了一个加密方法方法，该方法传入第一个参数(明文)，第二个参数 key 用于加密内容。

@interface NSString (AES)
+ (id)AESDecrypt:(id)arg1 password:(id)arg2;
+ (id)AESEncrypt:(id)arg1 password:(id)arg2;
@end
@interface NSString (Number)
- (BOOL)isPureFloat;
- (BOOL)isPureLongLong;
- (BOOL)isPureInt;
@end

5抓包分析

通过上面的简单分析不难猜测, 他把采集的信息发送到服务端了, 通过抓包分析该样本与服务端通信的过程如下：

第一次向服务端发送了 checklocked, 返回值为 0, 说明可以传输设备信息

接下的 data 是用来上传用户信息的。Body 是经过 AES 加密后 base 编码的密文，既然 key 已经有了，可以尝试解开请求密文

通过静态分析我们知道他使用了 AES 加密算法, 而 key 就硬编码在代码中。

结合上述过程，了解到加密算法的第一个参数为 kCCEncrypt，第二个为 kCCAlgorithmAES128，第三个为加密的填充模式 kCCOptionECBMode。 依据此我们写出的 AES 解密方法应该为：

 CCCryptorStatus cryptStatus = CCCrypt(kCCDecrypt,kCCAlgorithmAES128,kCCOptionECBMode, //ECB Mode   keyPtr,kCCKeySizeAES128,iv,[self bytes],dataLength, /* input */buffer,bufferSize, /* output */numBytesEncrypted);

key为：iMdpgSr642Ck:7!@

解开的密文为

下面我们看看该样本是如何获取这些用户隐私的。

6静态分析

用户隐私收集

CJFishPoolHook.dylib 中会获取用户的隐私信息, 其流程如下：

在应用初始化过程中，单例类的 CJFishPoolHook 执行初始化 Init，随后，在 Init 方法中进行初始化成员操作，包含上述的 16 个信息。

在初始化过后，开启捕获用户信息 startCapture。这其中包含获取用户联系方式( getContact )，获取设备信息( getDevice )，判断设备是否需要上传信息( checkLocked )，获取应用 ID( getProduct )，获取设备上的应用列表( getFeature )，获取地理位置( getLocation )，获取启动时间( getHabitStart )。

最后一步，上传所有数据到服务器，并且使用 AES 加密算法加密 httpbody。

恶意收集QQ信息, 电话, 微信号，应用列表

应用从 Library/Containers/com.tencent.qq/Data/Library/Application Support/QQ 目录获取个人 QQ 信息。在该目录下，保存着用户的临时聊天记录，截图等信息。

从/Applications遍历本机安装的应用，形成应用列表。

恶意推广

libCJFishPoolHook.dylib 修改了更新 xmind 的官方网站, 推广其自己的广告站点

进程注入后，使用 Method Swizzling 挂钩 MenuItem、Button 等按钮，使其失效或重定向跳转到其他网站，屏蔽注册、激活检查更新功能。难怪启动应用后发现激活按钮失效，无法进行版本更新，购买激活产品却跳转到另一个网站。

7小结

本次的逆向分析过程清晰，单从网络传输和静态分析上就能了解到该重打包应用运行状态的全部过程。对此公司搜集用户信息的这种行为，不想做过多评价。

主要还是从两个方面进行总结：

对于开发者而言，要了解一些基本的防御手段，注重网络传输安全、存储安全，在开发过程中，尽量不要把 key 明文编码于程序中，哪怕是将二次编码后的 key 放到应用内也好。我们无法得知软件是否会被破解，key 是否会泄露，而一旦暴露出来，则很容易被利用从而解开密文信息。更有甚者，直接使用 base 编码内容、数据位亦或运算编码，这种更容易被分析。同时我们可以混淆加密、反调试等手段增加软件破解的难度。

另一方面，站在用户的角度，下载安装未经验证的软件，是一件很危险的事情，例如著名的 XcodeGhost事件，其实就是开发者安装了非官方验证的开发软件，导致开发的程序带有后门，窃取和上传大量用户信息。

本文所述的只是个人信息安全的一角，但却不能忽视他的存在。就同本文中 libCJFishPoolHook 命名一样，真正的含义是鱼塘，软件使用者是鱼，养在破解者的鱼塘中，等鱼养大了，也该收网了。

过去六年间，Mac 销量越来越高，也意味着苹果用户越来越多。而用户一多，生态圈内的软件产出势必增长, 同时也会出现更多恶意软件浑水摸鱼。

Mac恶意软件发展历史

*本文作者：eleme_sec，转载请注明来自 FreeBuf.COM

由于segmentfault编辑器上传图片错误，小编试过多种方式试图拯救，还是未能成功，所以如要看完整文章请至http://t.cn/R8njjaT

miaomiao 高级测试工程师
7年测试工作经验，参与产品的功能/自动化/性能测试；目前负责 Red.Q、Warden 产品的质量保障工作。

背景

Red.Q 是岂安为客户提供业务风险情报服务的产品。API 是该产品的一个模块，客户可以通过输入不同的参数获取不同的风险数据。
在测试该 API 的过程，就是对这个接口的测试，不同的 Token 对应不同的订单,对应不同的标签,对应不同的返回。本文主要介绍在测试该接口时总结的一些场景用法。

工具介绍

目前接口测试的工具，例如 Postman/SoupUI，等大多都提供了接口的发送、响应结果的获取、以及针对响应结果的断言，都可以用来做接口的自动化测试，我们目前选用的工具是 JMeter，各种工具大同小异。如对 JMeter 工具不了解的同学请戳 Bioneck 分享的 Jmeter+Jenkins 文章。
实现本次自动化测试用到的组件介绍 ：

1. Threads--> 线程组
2. 配置元件--> HTTP 请求默认值
3. 配置元件--> JDBC Connection Configuration
4. 配置元件--> HTTP 信息头管理器
5. 定时器--> 高斯定时器
6. Sampler--> HTTP 请求
7. Sampler--> JDBC Request
8. 后置处理器--> 正则表达式提取器
9. 断言--> BeanShell 断言
10. 断言--> 响应断言
11. 监听器--> 查看结果树

测试场景与测试实现

1使用Token调用API

一个最简单的 HTTP 请求，由 host+ 端口 + 路径 + 参数构成，调用 API 的设置如下：

1) HTTP 请求默认值，设置好服务器 IP 和端口，所有作用范围内的 HTTP 请求可以不再指定。

2) HTTP 请求，设置路径和参数

• Red.Q 的请求是 GET 方法，参数可以加入 Parameters ; 如果是 POST 方法的 JSON body，参数可以放入 Body Data 内。
• POST 请求时，参数内有中文，需要设定 Content encoding 为 utf8

3) 调用完成后，通过查看结果树查看调用结果。

2Mock-server 的机制

需要每次请求时，把 request_id 放到 Header 内，随请求一起调用（HTTP 信息头管理器）。
1) HTTP 信息头管理器
将 HTTP 信息头管理器放入 HTTP 请求下，该 HTTP 信息头管理器内的参数，只对该 HTTP 请求生效。
右边的设置，每次 HTTP 请求 Mock-server 时，会将 REQUEST-ID 加入到请求 Header 内。

2)查看结果树内，可以看到发送的 Header。

3断言：响应结果的文本断言

每次执行测试后，需要了解本次执行的结果正确与否，以上的步骤只能知道我们返回了什么，不能确认到底返回的对不对。这个时候需要用到断言，对响应结果进行验证。

1）响应断言，提供对所有请求的响应结果内的内容进行断言，一般为文本断言。

将响应断言放入HTTP请求下，会对该HTTP请求调用的响应结果进行断言。
要测试的文本放入测试的模式内，可添加多个验证文本。

2) 查看结果树内，如果与指定的内容不一致，请求会标记为失败，并给出失败原因。

4断言：响应的结果与数据库内的字段比较

部分场景下，要求每次调用 API 后，需要验证对应的 [风险等级] 符合预期。而 [风险等级] 保存在数据库内，需要通过 JDBC Request 来实现对数据库的操作。

1）JDBC Connection Configuration，提供对数据库的连接配置。

2) JDBC Request，设置查询 SQL

验证结果一般是查询类的 SQL，QueryType 选择 Select Statement；
如果需要在某个请求开始前对数据库内的数据做新增修改删除，则需要选择 QueryType为Update Statement;

3)在 JDBC Request 下，添加响应断言，验证响应结果与字符串一致。

5断言：使用 BeanShell 编写手工断言

每次调用 API 后，需要验证 Token 的 [最近调用时间字段] 。该时间字段是存在数据库内的时间戳，而我们需要验证 token 的最近调用时间在 15s 以内，而响应断言组件无法做到日期的比对，需要用正则表达式提取器将请求的响应结果提取出来，然后作为一个变量，在 Bean Shell 内进行比对。

1)调用完请求后
添加 JDBC Request，设置查询条件如下

响应结果

2) 在 JDBC Request 下添加正则表达式提取器，提取数据库返回的时间戳字段，保存到变量内。

3) 在 JDBC Request 下添加 BeanShell 断言，对正则表达式提取器内提取的变量与当前时间进行比对。

6异步调用，等待一定时间后获取调用结果数据

某 API 支持客户进行异步调用，先发送一个异步请求提交数据（获取一个 token)，然后隔一断时间后再(使用获取到的 token）请求上一个请求的返回结果；需要用到定时器组件。
1）异步调用请求接口设置。

2）异步调用请求成功后，返回一个 query_id，如果要拿到真正的处理结果，需要在调用获取结果的请求时，把 query_id 作为一个参数。

3) 在异步请求下添加一个‘正则表达式提取器’，将异步调用返回的 query_id 保存到参数内。

4) 获取异步调用结果的请求内，引用正则表达式提取出来的 query_id ,并作为参数提交。

5) 异步调用一般不会马上出结果，需要在获取异步调用的结果请求之前等待一段时间

BeanShell Timer 内可设置线程等待 5s;
添加高斯定时器、固定定时器等定时器也可达到等待的效果；
定时器放在 HTTP 请求下，会先执行定时器，如果与 HTTP 请求是同级目录，则每个 HTTP 请求都会受定时器的时间影响。

总结

现在几乎所有从事 Web 测试的同学都会使用 JMeter 或某种 API 工具来调用几把接口，而需要做到接口自动化，免不了要加入参数化、关联、断言等高级用法，本文仅列出工作中用到的常见场景中的用法，有不对之处或测试之间的交流欢迎指出，谢谢。

以上。

toyld 岂安科技搬运代码负责人

主导各处的挖坑工作，擅长挖坑于悄然不息，负责生命不息，挖坑不止。

起源

1我们是谁，为什么要做这些

我们是一家业务风控公司， 公司的一项主要业务是提供给客户私有化部署的风控系统和长期的风控分析服务，最后提供给客户的产出，简单归纳来说就是哪些ip，哪些用户，哪些设备，哪些页面存在风险，并提供确实的证据。因为客户的需求、访问流量、内部架构情况各不相同，前期双方对接中涉及爬虫、订单、营销活动等大量业务信息需要大量的时间投入，接入之后分析师需要大量的时间来观察、分析、跟客户的不断沟通，因为当遇到某些业务细节的时候，沟通的成本就会被放大，才能确认最后完成策略的制定，然后观察效果，如此反复来确定风险IP、风险用户、风险设备和风险页面，即客户所需的业务风险评估。

2为什么要分析网站结构、网站关键路径？

分析、计算成本的上升

一个最简单的博客，只有博文的增删改查4个功能，1个URL接口，但是这样一个博客现在是不可能作为产品投入使用的，自然而然的，评论、标签、类别、用户权限系统、分享... 随着功能的不断完善，接口数量也随之不断增加，更恐怖的是后端程序经常将id之类的非固定内容放到URL当中，所以我们在给客户提供私有化风控服务的时候常有几十万甚至百万量级的URL进行数据统计，这一点在一开始的时候确实会造成我们计算和运营分析资源的浪费，因为分析的对象远远超过了可人工审查的范围，最后也只能靠分析师通过和客户的交涉和自己去使用客户网站的最原始的方法来缩减需要特别关注或需要制定阻断策略的。
简而言之就是随着业务的不断发展， 复杂度无疑是以更快的速度增长，由此带来我们运营分析的沟通、时间成本和我们风控系统计算成本的浪费，我们迫切的想解决这个问题。

报警监控

最基础的监控可能只是针对访问量、流量和一些服务器机器性能指标的，如果监控所有的页面，又显得目标太散，换句话说就是我们盯着全北京的所有路面情况全面标红没有意义，我们只关心我们到家的路径上是否堵车，对客户也是一样，只关心核心资源、活动页面这样的关键节点是否被攻击就足够了。但是只是简单的筛选出需要监控的页面，监控其余所有页面的系统资源也是一种奢侈的浪费，所以我们的结论就是：只监控我们关心的重要页面就好，不关心多余的页面，不需要多余的服务器计算资源，岂不是一步到位？

北京交通流量全线标红

目的地: 家， 导航全绿

机器学习

和报警监控的需求类似，机器学习需要关注的只是少量关键资源节点上IP、用户、设备的行为统计数据，因为爬虫、订单之类业务风险流量是不会盯着一个404页面做文章的。

3为什么要用机器学习来分析风险IP、用户、设备？

咋眼一看，风险分析师根据一个IP、用户或者设备的各种统计性数据来分析风险的IP、用户或者设备，这个分析判断的过程是适合机器学习的目的。

人工分析的成本

笔者所接触到的传统风控都是世代累计的案例构成的成百上千的策略来完成的，通过初筛一些可疑的用户，然后堆人来分析案例，然后复审，逐渐累计汇总成为策略，口耳相传。但是我们的风控服务是面向各行业的客户的，所以只靠堆人已经不能满足我们的，我们还需要加快效率。我们的愿景是教会机器学习这个学生，能够帮助分析师更快的发现风险，最终不断的自我学习，接近人工分析的准确。

过程

那么分析网站结构、网站关键路径我们遇到了哪些坑呢？

理想中的架构

少量的网站入口，层次分明的访问层级，每个关键资源都是这棵树的一个叶子节点，一颗理想完美的网站树结构，只要找到了网站的入口，剩下的问题只是遍历图中的路径了，单纯的笔者，一开始是这么以为的。

现实

当网站被搜索引擎全网索引的时候，网站的大量流量是直接从搜索引擎页面直接抵达，网站的入口成了摆设，人们可以直达想要的内容页面，从此没有了清晰的访问路径， 对于用户可能是一件好事，但是网站规划的访问路径被绕过，损失的可能就不止是广告的浏览量了，一旦爬虫之流伪装成搜索引擎，到时候的难题就是无法分辨真实的爬虫还是真实的流量。

App端，随着移动端的流量逐年增大，很多公司的后端架构都往微服务方向转型，既后端只提供API，具体的业务是放到了具体平台的App中，这样带来的结果是，虽然用户可以离线使用任何不带网络访问的本地内容，但是用户在App客户端中的访问路径之类的数据的不再像传统网站一样是现成的了。

单页应用这样动态前端的网站，随着前后端分离的趋势，跟App端流量类似的是业务、页面访问的逻辑都放到了前端，前端控制后端接口调用，所以我们只知道了用户调用了什么接口，不知道用户从哪里来在什么地方调用的接口。

很多URL是由像id这样的动态内容构成的，所以没人知道URL究竟有多少个。

机器学习来预测业务风险我们遇到了哪些坑呢？

理想情况

机器学习来根据客户流量日志来预测风险就跟机器学习来判断瓜是否好吃的经典案例一样，我们清楚的知道瓜的好吃与否与你看到瓜时残留的藤的长度无关(既特征筛选符合直觉), 只跟瓜的外表图案、响声，品种等有限的特征有关(特征新增、挑选简单)， 结果是否准确，吃一口就知道了(判断条件简单，可解释性就强，特征好坏容易判断), 判断错了，反省一下挑的原则就好了(几乎没有错误惩罚)。

回归现实

样本少，靠人工复审效率也不高；因为每个客户的实际情况不同，模型的通用性有待考证的情况下，初始样本就只有传统策略引擎贡献的相对少的量，另外的话，因为我们的风控服务追求的是准确，所以只能牺牲分析师的时间效率，初期训练模型的话，还需要分析师的复审之后筛选出新的样本，扩充了样本库之后，再重新训练如此反复，反而增加了分析师的分析负担。

训练出来的模型通用性， 因为我们服务的是各行业的客户，各个客户的现实问题各不相同，有的被爬虫困扰，有的是活动营销被薅羊毛，所以在每个客户的私有化部署环境里面训练出来的模型很有可能是不具备通用性的。

特征的增加和筛选很纠结；当一些常见的统计特征，例如总量、比率，都加上之后，可能就一百出头的特征，这时候训练的效果并不是太好 ，愁的是如何增加特征，但是当我们的特征增加到十几k的时候，训练结果并没有飞跃性的提升，这时候我们愁的是如何自动化的筛选出完全无关的特征，特征太多的时候，不仅仅是无法解释，数据量过大，对于程序而言，还需要针对内存使用进行专门的优化。

因为错误惩罚的后果严重仍然无法完全脱离分析师的复审； 跟挑西瓜失败不同的是，我们不能简单的重头来过，因为这样错怪一个好人导致的结果很可能是客户需要面对一个愤怒的正常用户的投诉，一个失误就可能引发对我们系统可靠性的严重怀疑，面对如此严重的错误惩罚，所以我们只能对于模型预测的风险再通过分析师的专家复审去寻求一个合理的解释，才能加入到传统策略引擎的风险预测的结果中。

成果

分析网页重要性的解决方案

• 第一步，折叠动态URL, 简单说来就是通过将URL分层，通过配置的阈值来控制动态层次的总体大小 ，一旦超过阈值就自动折叠， 最后的结果是我们page页面维度的对象数量下降了至少2个数量级，从一般几十万缩减到了几千，我们满意了么？还没有。
• 第二步，在折叠URL的基础上，构建网站的访问图，再进一步通过pagerank算法的计算和我们自己累计的一些统计指标，分析得出流量入口、关键索引页面、关键资源节点、必经路径，一些黑名单页面(例如404跳转页面), 然后再通过访问流量构建这些关键节点之间的访问关系图，至此我们成功的将page页面维度的对象数量减少至小于100的常数级别。

基于机器学习的风险预测的解决方案

• 我们在分析好的网站重要网页关系图上重放流量，根据统计的IP、用户、设备的各种行为作为特征，每个小时跟策略引擎产生的风险IP、用户、设备做新的样本集，来继续增强学习已有的模型，并且产出一些不在样本集的风险IP、用户、设备供给分析师做复审。
• 每个小时会以上个小时的模型为基础，根据样本集，来遍历所有算法、自动调优所有的特征，给出一个当前小时最佳模型。

叶孤城 岂安科技售前顾问

9年互联网项目支持经验，涉猎各类体育项目

无处不在的劫持

利用饿了么2块钱的补差价就能划走用户支付宝的2000元、利用订购的机票信息，就能获取到用户信任，骗取财产、总是被跳转到一些自己不想访问的页面上、为什么总有那么多自己跳出来的广告？为什么一个正常的链接点进去之后会出现下载界面？我们的数据信息怎么就这么不安全？

对于普通用户来说，你的请求数据发出去以后，会经过哪里，最终去到哪里，怎么处理响应，这后面的一切都是黑洞。而对于想利用你的信息做坏事的人来说，每一个环节都是他们的机会。

先不说坏人通过爬虫、撞库等手段获取用户信息。最直接的我们数据接入的运营商都可能会对我们的数据分析监控。比如敏感信息信息的监控、涉黄涉恐信息的过滤，而我们能够感受到影响的可能就是网络劫持了。那么运营商为什么要做网络劫持，通过什么手段来做劫持，网络劫持的利弊在哪呢？

劫持的产生

近年来随着网上购物、直播、物联网、共享经济、人工智能等不断深入我们的生活，互联网行业取得飞速的发展。根据最新的第40期《中国互联网发展统计报告》显示，截止2017年6月，中国互联网用户已经达到7.51亿，占全球网民的1/5。随之而来的是网络流量的不断增加，目前中国的国际网络出口的带宽已经高达8T，而国内用户产生的网络流量要远远大于这个数字。与之相对应的是中国复杂的网络环境。除了电信、联通、移动是比较大的网络接入厂商，此外包含长城宽带、鹏博士、教育网、科技网、广电等等不少于20多家的小运营商。而且各个省市是相互独立运营。这就会导致网络出现跨网、跨运营商的情况会特别多，基本上很难避免。而各个运营商之间的出口带宽不尽相同，这很能是成为网络高峰的瓶颈。同时这种大量跨网访问的流量，在运营商之间会产生一笔很大的结算费用。也就是说运营商之间的互通是需要收费的。
作为运营商，面对这么大的带宽流量。该如何保障用户体验，减小自身成本呢。于是，他们找到了网络劫持的方案。

劫持的原理

运营商劫持大致分为两种方式：
➤DNS强制解析的方式
➤访问请求的302跳转。

DNS强制解析是通过修改运营商的本地DNS记录，来引导用户流量到缓存服务器。工作的方式如下：

• 用户通过域名发起访问请求；
• 请求通过本地DNS进行解析；
• 运营商DNS设置强制解析策略；即所有该域名的请求都解析到事先写好的服务器上；
• 终端用户到劫持服务器交互访问；
• 劫持服务器如果有需要的访问内容，则直接返回响应给用户；如果没有，则去源站同步内容。

302跳转的方式和DNS强制解析的方式主要在引流的方式上有所区别。内容缓存是通过监控网络出口的流量，分析判断哪些内容是可以进行劫持处理的。再对劫持的内存发起302跳转的回复，引导用户获取内容。其需要对上行的请求流量进行端口镜像或者分光处理。可以理解成复制一份上行的流量信息 。工作的方式如下：

• 终端用户发起访问请求；
• 流量通过网络出口对外发起访问；
• 访问流量被镜像一份给劫持系统的DPI设备；
• DPI对流量进行分析判断，比如http get、80端口等数据
• 缓存系统判断是否热点资源，比如连续请求5次的相同内容；
• 给用户发送响应请求，告诉客户本地即是客户需要访问的内容；
• 由于本地的缓存系统离客户更近，所以客户更早收到缓存系统的响应；
• 用户和本地的缓存系统建立网络交互，源站的响应回来的晚，会自动断开；
• 如果本地有缓存内容，则给用户响应内容，如果本地没有，会计算访问次数。当达到响应的内容时。

劫持的影响

从两种运营商缓存的特点来看，二者都是通过获取用户的数据流量，引导用户访问内容缓存的服务器。区别在于引导用户的方式，DNS强制解析是通过修改域名解析记录，强制将域名下的所有请求引导到劫持服务器上。这种方式简单粗暴，也容易造成很多问题。比如域名下有动态内容，也会被缓存下来。这样会造成登录的串号的问题。缓存的内容更新不及时，访问的都是老内容。这也是很多用户所不能接受的地方。一些冷门资源的缓存，会造成存储的浪费。流量劫持的方式需要镜像用户流量，进行分析判断。缓存一些系统判断是可以缓存的热点内容。DNS强制解析主要针对图片，302跳转主要针对下载文件，音视频等大文件。

运营商应用劫持系统可以带来的好处是：

1. 减少跨网传输的访问，减少运营商之间的网间费用结算。国内各个地区、运营商都是独立运营的，日常互联产生的流量是需要进行费用结算的。而这笔费用其实是一笔庞大的开销，而且需要持续结算。
2. 大多数运营商之间的网络出口都在几十至几百G不等，内容缓存系统可以有效减小网络高峰时出口带宽的压力，这样既可减少对互通网络的扩容。减少网络建设的费用。
3. 由于缓存系统可以支持本地化服务，在一定程度上也可以达到加快网络访问的目的，提升用户体验。

由于运维系统的人员不可能及时获取到劫持内容的更新，或者对劫持的内容做其他的，坏处是：

1. 经常访问到过期的内容，文件更新缓慢。导致获取不到自己想要的信息。
2. 跳转到其他网站页面，或者被插入牛皮癣广告。

为了减少运营商缓存和劫持带来的影响，目前很多企业开始使用HTTPS的方式。包括苹果公司之前要求所有的域名必须是HTTPS的，那么HTTPS能从根本上解决这类的问题吗？通过上面的分析，很显然并不能有效的得到解决。https因为使用了加解密的手段，保证内容被篡改的可能性被降低，但是从运营商劫持的原理上来说，并不能有效的降低被劫持的可能性。