官方总是喜欢留一个小坑，提供了python示例代码，也提供了java示例，就是没有提供php代码，折腾了许久，真的要抓狂了！
sleep5
这几天同事对图书云很感兴趣，想着使用java对图书云进行一次重构。也有团队成员认为不需要。但是从工程化的角度出发，我们在重构的路上回不了头，就开始准备java项目自动构建。为了节省创业成本，我们的服务器配置是比较低的，我们的第一个目标就是，在自己的电脑上配置好自动构建。
不过，经过这2天的折腾，对于在windows上构建java项目，再部署到linux上运行，算是摸到一条路子。pipeline脚本没有精修，无数次尝试，踩坑的结果。
以下jenkinsfile是实战能正常跑，可以将jar包从windows传输到linux的。
初始压测环境
1.yue.maES-9100-9200-93002.yue.malogstash-zookerper-2182stormui-8080nimbus-166273.yue.makafka-9092redis-637054.yue.mamysql5.7-33065.yue.maiis、filebeat、LogGenerator服务、WebGenerator站点6.yue.maiis、filebeat、LogGenerator服务、WebGenerator站点7.yue.ma压测客户端8.yue.ma压测客户端
以上机器均为8核16G内存，[1-8].yue.ma为脱敏host，仅做示例
压测优化思路
依据120万条日志/分钟的要求，我们通过ES查看工具，配合自己写的ES入库速率实时分析显示工具，实时观察入库速度，未达到要求，就分析，调整，直到满足目标。
日志生成
我们采用了服务生成日志、站点生成日志两种不同的方式，分别代别了实时业务中的场景。LogGenerator服务生成服务类日志，WebGenerator站点生成站点日志，站点的日志生成需要压测机器发起大量的请求。有同事基于jmeter做好了压测工具。
优化后的压测环境
1.yue.maES-9100-9200-9300logstash-2.yue.malogstash-zookerper-2182stormui-8080nimbus-166273.yue.makafka-9092redis-637054.yue.mamysql5.7-3306logstash-5.yue.maiis、filebeat、LogGenerator服务、WebGenerator站点6.yue.maiis、filebeat、LogGenerator服务、WebGenerator站点7.yue.ma压测客户端8.yue.ma压测客户端
实时优化措施
历史经验
优化LogStash批量写调整ES模板
没有设计任何场景与验证，直接向同事打听到去年压测的经验。
压测结论
测压解读，我们压到40万长日志/分钟的时候，就停止了进一步压测。依据长短日志的压测优化经验，日志系统的吞吐量可以通过调整kafka、logstash、ES的节点数来适应目标容量要求。Kafka的节点数大概为每分钟日志量的大小除以每分钟带宽满载的传输量，Logstash的数量可以观察消费堆积情况，增加数量。本次压测的经验是将kafka中topic的partion数量配置为logstash消费线程数，这样子，每个logstash都能保持工作状态。然后，每种topic的日志量占比不尽相同，可以在实战中进一步优化配置。ES侧的优化未进行，依据这次优化的经验，同样可从日志传输量与带宽角度，推测出ES节点数要求。有一个合理的初始配置，再在初始配置的基础上进行优化。
干货
kafka的图形管理工具，是开源WEB管理工具
ES入库速率实时分析显示工具，这个工具是DIY的，能实时显示当前入库到ES的日志速度，感兴趣的可以留言索取。
本次压测收集到的命令集合，感兴趣的可以留言索取
LogGenerator服务，感兴趣的可以留言索取
WebGenerator站点，感兴趣的可以留言索取
非链路日志（普通日志）
如果没有链路的概念，那恭喜，您正在使用普通的日志。普通的日志没有链路标识，不同请求的日志可能穿插在一起，查看的时候不太好串起来，分析日志有点点眼花缭乱。尤其是出现线上问题的时候，面对一团无序的日志，心急如焚。如果站点业务机有10台，定位日志的范围，也成为一个不太愉快的时候。若是多线程的服务日志，日志穿插得眼花缭乱。非链路日志（普通日志）在实时排查问题的过程中，存在的最大问题就是定位分析问题，简单的示例如下图，日志穿插在一起，不易分析同一个请求的情况。
我收到一个请求，参数是我收到一个请求，参数是我收到一个请求，参数是我收到一个请求，参数是我收到一个请求，参数是用户账号BBB未认证单链路日志
当我看到有同事使用GUID将日志请求串在一起的时候，我就这应该算是单链路日志了。站点的单次请求或服务的业务操作日志能够很好的被标识出来，在分析日志的时候，需要搜索同GUID的日志，请能定位到一个请求或作业的日志，不用提心其他日志的干扰。单链路日志对于分析单个站点或单个服务的日志情况，还是很有帮忙。我们已经能从日志中挑出日志，专注于重点日志。
请求3fba452e-d9c9-45ee-96cb-19280fa59673我收到一个请求，参数是请求b3a45dec-7667-4822-b7b9-7db1eec11a8b我收到一个请求，参数是请求3e2f3851-9491-4f97-a47c-53d1001278ba我收到一个请求，参数是请求6180a2f7-d9bf-4612-9d23-c5e6d46a079d我收到一个请求，参数是请求26a9d771-f2f3-47fa-b810-d3071a1d98ca我收到一个请求，参数是请求3fba452e-d9c9-45ee-96cb-19280fa59673用户账号BBB未认证全链路日志
全链路日志在单链路日志的基础上进行跨站点，跨服务逻辑的日志追踪。分我们排查问题的时候，往往是一个完整业务排查，不单是涉及一个站点的，可能需要顺藤摸瓜，一点一点回溯。单链路日志对此就无能为力了。所以引身出了全链路日志，我们需要为每个完整的请求分配一个追踪id，称之为TraceId，这个追踪id将在业务站点间流转，将业务日志串起来。当我们查看日志的时候，可以完整得看到业务日志的流转明细。同样的道理，服务日志在入口处，也将分配一个完整的TraceId，标识出完整的日志。
一、支付宝新旧产品变迁，支付宝bug无情打脸
提示语定格在“系统异常，请稍后再试”！
二、让人无语的机器人客服时代
每次与支付宝打交道都有一种想吐血的节奏，支付宝客服不知道哪里来的自信，总会将我引导到一个机器人客服系统，答非所问，提工单，工单让我找商服，找到商服，商服就是一个自动回复机器人。技术人工客服问半闰，又给我导向了商服，商服又是一个没完没了的自动回复，真的把人气得要吐血。什么AI什么智能机器人，都是忽悠人。若非工作需要，把阿里系的所有东西全卸载都不解气。技术人工客服唯一有用的一点就是，回复了一个问题，在哪里更新手机安全支付产品密钥，只有支付宝的人才知道，到底是什么产品，到底哪里是密钥更新的，这个答复，还是不错的。于是，我求证了一个密钥的问题，到底是使用java版密钥，还是非java版密钥，客服答复我，使用什么语言就使用什么密钥。听起来是那么的开心，我感觉不会掉坑里了。
三、支付宝支付密钥系统BUG确认
在我满腔怒气不受控制的情况下，我自己在钉钉群里圈了支付宝的对接人，将支付宝后台报错页面发过去，把人工客服答复，把商户机器人答复统统发过去，直接告诉TA，我已经吐血了。我知道钉钉对接群里有很多人，很从同事，我也顾及不了这么多。从上午开始，到下午，换电脑、换浏览器、清缓存、简直就是被耍了一天。支付宝最终确认是自己的系统问题。于是拉了一个小群，让我配合他们进行进一步的排查与处理问题，我到是非常关心更新密钥的事情，于是就接着配合。
四、一个低级的支付宝系统BUG
原以为支付宝出现了重大的系统BUG，新旧产品有重大的兼容问题。实际上却是支付宝产品的调整。更新密钥要求先入驻开放平台，从支付宝排查的结果来看，当点击查看开发者公钥时，会提示“系统异常，请稍后再试”，实际的请求情况如下
五、小心翼翼的掉支付宝的坑里
前面有提到为了防止生成密钥出问题导致我们的业务中断，特意向客服求证了密钥需要生成什么版本的密钥。在支付宝提供的密钥生成工具里，我们可以看如下图所示的提示。
六、支付宝产品密钥防坑总结
支付宝的产品可以划分为新老产品，老的产品采用用md5加密，也有采用rsa密钥加密（1024位）。老的rsa密钥在mapi网关产品密钥中管理。老产品是没有开放平台应用的概念，sdk调用也不需要传appId，新产品需要在开放平台后台配置，需要为每一个应用进行配置，sdk调用需要传appId。新产品密钥支付1027位、2048位。依据目前踩坑的经验来看，老产品的sdk采用的是PKCS8密钥，无论是java语言，还是.net语言都是使用PKCS8密钥。在更新密钥的时候，千万不能被支付宝提供的密钥工具所迷惑，老版本使用的是PKCS8，.Net也是使用PKCS8，支付宝的老版本demo就是这么提供！慎重，这是一个巨大的坑，一不小心，就会出线上生产事故，扣钱扣绩效，背黑锅，太容易掉坑里。
七、跨部门沟通
更新密钥是一件非常重要的事情，协调不同部门的人一起完成一件神坑不断的事情，非常虐心。大家都有手上的活，自然会影响到他人的工作。一点都不影响到别人，那是表面上的友好，其实换位思考也是，背着支付宝的黑锅来回找要验证码、要财务登陆，换浏览器尝试，打断了别人工作，换谁都会有点情绪。我的目标是将支付宝手机安全密钥更新好，别人开心不开心，不管，这是工作，有点耍赖了！人在江湖啊！
八、与支付宝沟通
8.1戏如支付宝
8.2老接口文档索取
有不少支付宝老产品已经没有公开的入口了，有的老接口文档如果能搜索到，那就是见鬼了，搜索到了，估计也会有一个收费码，要求付费10块钱才可以下载。对于老接口文档，可以向客服经理要，一定要提供签约的pid，具体的接口名称。一般大客户会有此服务，如果连客服经理都没有，说明不是支付宝的重要客户，基本上只有冷冷的机器人服务，你说什么都是很nice的自动回毛复，直到你放弃。
能在财务下班前更新好支付宝手机安全支付产品密钥，虽然过程是那么煎熬与不顺，想想事办成了，还是有些开心。我跟同事聊了聊，觉得这个密钥更新是一个必踩的坑，想想就扎心，这么多同行要更新密钥，这么多同行要踩坑！如果有幸看到，希望你能收藏起来，好好看看，也许能避免一场无辜的线上支付事故！
对于一个公司而言，不仅是为正常用户提供服务，也要防范不法分子利用公司的平台进行诈骗，保护公司的名誉与声望。虽然不良青年占比很少，却是公司很为头疼的事情。支付产品一直是不良青年的切入点，与不良青年的斗争，建立在数据凭证上，每一笔支付流水的都是诉讼的核心凭证，凭证对应到具体的自然人，对助于公司进行司法诉讼，维护平台的声望，打击不法份子。
新版支付产品报文
我们熟悉面向过程编程，也了解面向对象编程，在我们日常研发的过程中，往往需要我们采用编程手段将一些固化的业务逻辑采用代码的方式程序化。我们能很好的完成一个又一个新功能，还能随着业务的增长，不断的调整代码适应新的业务。
然而有的时候，我们会发现，我们所掌握的面向过程编程与面向对象编程，解决不了我们编程中的困境。于是，通过引入几个真实的案例，介绍一下面向商务编程的方式与优点。
真实案例一：对接阿里短信
从短信对接的历史来看，通常都是传手机号与短信内容，阿里的玩法改变成了手机号、短信模板、参数。依据传统的做法，我们需要为两百多个短信模板配置阿里短信模板，还要做参数映射。依据阿里短信模板的审核流程来看，基本上是没有尽头的项目了。短信内容审核老是被打回来，参数不能过多，完全是一个无底的黑洞。针对我们业务的短信，要转化成阿里的短信参数，挑战还是很大，改造切入点还不少，还不能完全确保万无一失，使用维护管理都是一个挑战。采用面向商务的编程方式，由商务出马，结果一切变得那么顺利，谈妥一个万能参数，兼容了我们的短信平台，无需切入修改代码，新增一个短信服务商的实现。
真实案例二：网银直连
很多人以为网银直连一个技术问题，一直在寻找技术解决方案，其实网银直连、转账到银行卡等产品，都不是技术问题了，而是商务问题。所谓的大客户服务，就是别人享受不了的服务，你却能享受。这不是一个技术领域的问题，而是商务之间的互动。偶尔有人问我网银直连怎么接，我都感觉就像一个诡异的灰色游戏。
真实案例三：支付费率
传统的编程方式是不需要考虑支付费率的，无旨是一个冷凉凉的参数。面向商务编程，会要考虑，一年流水多少，5个点一年能省多少钱。一个简单的例子，如果率费是1%，一年200亿流水，手续费是多少？如果率费能到0.5%，又能省多少？
真实案例四：短信监控
一般我们接入短信，就是简单的把短信送到运营商，然后就了事了。如果我们按面向商务编程的思维方式再思考一下，月底怎么对账？哪条短信成功了，哪条短信失败了？这钱花得冤不冤？
作为甲方，我们经历一场凌晨短信通道异常的煎熬，这个时候正是多数人睡梦中。我们却睡梦中惊醒。短信通道异常，用户无法收到短信，我们非常被动。出了什么问题，哪个环节出了问题，我们如何处理？见到问题后，我们首先排查了自身短信服务的情况，均无问题，于是问题的重点在短信服务商出了问题。下面详细介绍一下我们排查问题的关键要素与处理方案，最后我们来分析乙方如何答复，阐述了为什么我只打50分，连及格分也没有给。
短信流水
我们能看到的短信流水是乙方提供的流水，仅代表了短信被乙方收到，乙方将短信送到移动电信联通运营商的过程与结果，完全是在黑盒子里。比较尴尬的是乙方不提供短信回执，整个流程就变得不可监控，无法预知了。我方收到的流水均是乙方返回的成功流水，对于短信的真实发送状态，完全没有了参考意义。
紧急预案
非常幸运的是我们接入了多个短信平台，对于某个短信平台出现异常问题，我们采取了快速的通道切换措施。面对紧急情况，我们关心的是业务如何快速恢复可用状态，短信服务商如不能给出一份具有负责感的短信故障分析报告，估计是很难切回去。表面上大家一团和气，似乎不是什么大问题，作为甲方，一群人半夜无眠，也许都没有人愿意再切回去了。
短信数据核对
乙方如何答复
出现这种事故，乙方如何争取甲方切回通道呢？一份详尽的报告与整改措施是必不可少的，切记，不要一份甩锅的事故报告，把自己的责任推得一干二净的。至少从一个甲方的角度考虑，问题这么久，乙方有没有机制自动发现问题自动修复。如何避免重复问题的产生？若答复踩不到要点，让甲方爸爸怎么安心开启通道。
后记
做为甲方爸爸，我在想什么，乙方要好好想想，现在短信平台太多了，竞争那么激烈，我们程序又能做通道切换，服务不好，就切走了。估计乙方看不到我写的东东，还在纳闷，为什么给了一份“专业”的事故报告，我们也没有在群里生气，通道却没有再切回去。
近期做压测优化时，特意选用了无侵入式代码注解方式[OutputCache(Duration=300)]对接口做了5分钟缓存。依据业务预期，5分钟的缓存能确保我们的接口顺利通过压测。就在满怀信心等着通过的报告时，却被打脸了。
报告显示，在前2分钟，接口返回都正常无错误，接下来就出现了错误返回。仔细想想，这个问题在于，缓存失效的一瞬间，大量的请求穿透过去，导致请求直接压到了需要保护的后端服务。
于是，采用lock的方式,防止缓存击穿!
protectedstaticobjectsysncObject=newobject();
//开缓存了，防止缓存失效的时候发现穿透效应lock(sysncObject){//原来的业务逻辑}
经过lock处理后，压测顺利通过。目前没有发现，OutputCache的Cache保护措施，只能使用DIY进行击穿保护。