一直都有看InfoQ上面的各种技术文章，感觉InfoQ算是国内组织技术会议与传播技术做的比较好的了，所以其组织的各种大会一直以来都想去参加，但是限于门票比较贵与路费就没有动买票参会的念头。正好组织要在北京开UP大会，所以组内有几个名额可以去参加下QCon2018在北京站点的全球软件开发者大会，我运气好，获得了一张票。

在我们的日常开发过程中，少不了需要提供服务给比人使用，可能是一个接口，也可能是一个服务。我们当然希望我们提供的服务具备低延迟、高并发的特点，那么从哪些地方可以优化我们的程序或者说是服务呢？
该部分分14个部分加以说明.

我知道A/B Test还是从几年前的一位女产品经理那里听到的，然后专门去搜索了一下这到底是个什么东西，才对它有个大概的认识。前些时间看了一些文章说今日头条与国外的一些游戏公司搭建了一套系统，能够非常方便的使用A/B测试来推出新的功能，看到这个的时候我自己挺震惊的，没有想到A/B测试还可以这么玩啊。

A/B测试是什么

就是说对于一个需求有存在大于一种方案的时候（一般会有两种方案），每种方案都有优缺点但是难以取舍，即方案A与方案B，从整体用户中挑选样本量相同的两组样本，一组应用方案A，另外一种应用方案B。然后在一定的观察周期后（基本是1到2周吧），观察两组方案的数据指标，数据优的那个方案就可以合入到主干版本中去全量发行了。

A/B测试的优点

1. 是一种科学的线上预测方法，基于样本可以代替总体的统计学原理，很容易看出哪种方案更优。
2. 数据化决策，以线上实际结果为导向，符合数字化世界的发展趋势。
3. 搭建测试框架，使得A/B测试这种方法可以很快的流水化进行，比传统的产品经理更能把握产品的走向。

A/B测试的缺点

1. 实现成本较高，使用它的前提是会形成犹豫不决难以取舍的多套方案
2. 结论得出的周期较长，一般都需要一到两个自然周。

总结

1. 该方法是一种很棒的方法，思想兼具灰度与线上对比，让用户来决定他们需要的。值得所有的产品使用。
2. 最好的搭建一套框架，使得该测试可以流水的进行，形成一种常态的测试模式，是产品决策中关键的一环。

背景：在日常开发的过程中，开发更多的关注在功能开发上，对于接口性能与服务能力关注较少，但是无论是对内还是对外提供接口与服务，都应该明白的给出服务能力界限的说明，而且需要对方给出调用量的评估，这样才能在一定程度上做到心中有数，从而维护系统的安全。压测系统不是一蹴而就的，据了解业内大公司的压测系统基本经过了几轮迭代，而且耗时基本需要3年。

1. 思路

压测系统的设计最后会走上类似阿里双十一、微信等全链路压测的道路，但是这两个系统都是花费了至少3年的时间打磨完成，所以我们也分四大步走：
1.提供压测的url、ip+port+协议栈 +参数，来进行简单的分布式压测，（预期完成时间2018年上半年)
2.改造目前项目的上下游路由机制（目前使用的是L５，但是L５不具备准备的流量分配机制），使得能方便快速的切换流量到单台机器上，从而得出单台机器的负载上限。（预期完成时间2018年下半年)
3.复制目前项目单日所有用户的流量，清洗后进行重放，来大规模的压测整个系统，目的是在大流量的压力下发现系统瓶颈与隐藏故障点。（预期完成时间2019年全年)
4.压测常规化，定时的来进行流量压测，完成自动化压测系统的进化。（预期完成时间2020年上半年)

2. 同类型产品分析

2.1 压测大师

压测大师可以很方便的实现第一步，但是具备如下缺点：
1.被压测机器的负载不能很方便的展示出来，最关键的是需要在被压测机器上装个软件，路径较长
2.压测大师对每个Url的并发上限为200，虽然可以通过开启白名单的方式来提升，但是感觉还是不太方便。
3.最主要的一点是，压测大师是一个独立的系统，虽然能大概cover住我们的第一步，但是对于我们的长期目标来说并不能很好的满足。

3. 压测架构图

模块介绍：
web controler: 显示与控制模块，显示压测的结果数据与agent的负载数据、agent的状态数据、dispatch模块的分发状态。
Manager：任务管理模块，通过从web controler获取任务配置，然后进行任务分配与启动停止。
Register: agent节点注册模块，可以获取agent的空闲繁忙状态，一般是分布式节点，推荐使用zk
dispatch: 文件分发模块，将提交的任务文件通过dispatch模块分发到各agent机器中。
agent: 真实的压测发起模块，从dispatch模块获取压测文件，从manager获取启停命令。
monitor: 监控统计模块，agent的负载信息上报至monitor模块。
MQ: agent获取压测结果，将其写入MQ
Collector: 收集器模块，将压测结果与agent的负载信息汇聚处理。
DB/DR：信息储存模块，存储web controler需要显示的各项数据。

4. 设计要点

1.能模拟线上流量（真实请求回放、自己模拟请求）
2.能区分模拟流量与真实流量
3.在线压测
4.物理隔离存储 正常存储+影子存储
5.能快速的进行流量路由，将单个模块的请求打满，直到错误率上升为止，因为具备重试的逻辑，所以问题不是很大。

4.参考文档

有赞
http://www.infoq.com/cn/articles/youzan-11-11-stress-testing
云集
https://github.com/yunjiweidian/TITAN
滴滴
http://gitbook.cn/books/58edf24902c60a2473618fac/index.html

2018计划

1. 加强锻炼，减轻体重

在新的一年里，这是最重要的

2. 持续写博客

锻炼自己的写作能力

3. 加强英文阅读能力

不会英文阅读能力的程序员不是好程序员，不会走很远的

数据在二十一世纪第二个十年的末段，在各种互联网技术层出不穷的今天，愈发显得重要起来。数字化生活日益深入，终端设备日益丰富，数据的产生呈现爆炸的形态。数据是信息的载体，信息对于各种经济活动是至关重要的。所以数据的存储于处理就是一个非常有活力、前途的方向。

马云说过：二十一世纪是DT时代，是数字技术的时代。可见数据的重要性。

1. 禁止嵌套循环

将嵌套循环改为二次循环 （新手常犯该错误）

2. 单次循环读写

单次循环读写改为批量读写，单次循环会占用非常多的开销 （新手常犯错误）

3. 超时时间设置

不设置超时会引起雪崩，连接超时与执行超时都需要设置，udp有回包也需要设置超时时间

自动化

自动化是相对手工运行来说的，手工运行存在误操作的可能，但是自动化不会，自动化会提升效率。如果数据在5分钟内会被再次用到，那么它应该进缓存，如果一个任务需要执行多次，那么它应该配一个脚本。

智能化

AI浪潮下，让机器释放生产力

数据化/量化

一切皆可计算，量化的才是公平的。

预加载

有时候服务端需要一些资源文件，特别是在一些特殊的时间节点上，比如年底的微信红包、双11的天猫全球网络购物节。

如果等到节日的当天再由客户端来服务器拉取资源，那无疑对服务器是巨大的冲击，对带宽资源是严重的挑战。即使带宽可以被无限满足，那么用户下载资源等待的时间也是难以忍受的。

所以可以将服务器资源有计划的提前下发到客户端，这样就可以大大的减轻服务器在节日时间的压力。

分离与异步，是计算机技术中的两个伟大思想，分离分为时间分离与空间分离，预加载与延迟加载就是时间分离的典范。

有时候在移动端服务器侧开发的时候，某些接口的性能得不到优化，可以看看是不是该接口做了太多的事情，提取了太多的数据，看看能否将这一个接口做的事情拆分为几个接口来做。

有时候我们总想着一个接口提供大而全的数据供前端使用，但是却没有去想提供的数据是不是会马上就用到，如果提供的部分数据永远不会被用到或者是很小概率会用到，那么我们为什么还需要在这个接口里面返回，是不是可以考虑延迟加载。

移动APP的位置有限，所以都十分重要，越浅的层级就需要越快的加载速度，越高的并发性能，所以首页等页面一定要做到非常轻量。