压测全链路日志的时候，不知道怎么监测ES的实时入库速度，于是在Chrome的浏览器里写了点js脚本，实现了对ES实时入库速度的监控，不能说是百分之百实时，不过满足压测的数据观察。
二话不说上JS
var startTime = new Date(); var baseCount=0;
var showStat = function(){ $.getJSON("http://es.yue.ma:9200/_stats",null,function(d){ console.log(d._all.primaries.docs.count); ……
自从团队自研全链路日志系统上线后，一直想分享一下本人对日志系统的一些感受与记得，今天正好是周未，仔细回想了一下有关日志的点滴，因为涉及到全链路日志的概念，由于我打算从非全链路日志（普通）到全链路的演化路线做一次分析，就打日志关系的一次业务问题做一些简单的案例剖析。请搬个小凳子，开场了。**非链路日志（普通日志）**如果没有链路的概念，那恭喜，您正在使用普通的日志。普通的日志没有链路标识，不同请求的日志可能穿插在一起，查看的时候不太好串起来，分析日志有点点眼花缭乱。尤其是出现线上问题的时候，面对一团无序的日志，心急如焚。如果站点业务机有10台，定位日志的范围，也成为一个不太愉快的时候。若是多线程……
时间的轮回就像无息的风声，嗖的一下就离首次接入支付宝手机安全支付产品有好多年的光景。这个时候，接到一个紧急需求，需要更新支付宝手机安全支付产品密钥。密钥是RSA密钥，意味着我需要生成一对商户的私钥、公钥，将商户公钥提供给支付宝，再将支付宝的公钥拿到手。凭借接入支付宝的丰富经验，直接掉坑里，因为这么坑太坑了，且看我慢慢写。一、支付宝新旧产品变迁，支付宝bug无情打脸原签约的支付宝安全支付产品时间比较早，当时估计支付宝的开放平台还没有“诞生”。出于于产品兼容性的问题考虑，大概明白这个产品属于老产品，更新密钥不是在开放平台的应用里。自信满满的帮同事去更新密钥，被支付宝无性的打脸！ 提示语定格……
今天有法务部门的同事前来咨询，需要查询一些账号信息用于诉讼。看要求非常简单，就是需要查询支付流水单，找到支付方的具体信息，支付邮箱或手机号。这对于一个IT系统来说，已经融入了业务、商务、法务多个领域的需求。本文从面向法务编程的角度，分享支付产品对接心得，主要分析了支付宝新旧产品的在法务合规方面的差异，结合新产品的特征，设计了满足法务例规性要求的IT系统实现。 对于一个公司而言，不仅是为正常用户提供服务，也要防范不法分子利用公司的平台进行诈骗，保护公司的名誉与声望。虽然不良青年占比很少，却是公司很为头疼的事情。支付产品一直是不良青年的切入点，与不良青年的斗争，建立在数据凭证上，每一笔支付流水的都……
我们熟悉面向过程编程，也了解面向对象编程，在我们日常研发的过程中，往往需要我们采用编程手段将一些固化的业务逻辑采用代码的方式程序化。我们能很好的完成一个又一个新功能，还能随着业务的增长，不断的调整代码适应新的业务。
然而有的时候，我们会发现，我们所掌握的面向过程编程与面向对象编程，解决不了我们编程中的困境。于是，通过引入几个真实的案例，介绍一下面向商务编程的方式与优点。
真实案例一：对接阿里短信
从短信对接的历史来看，通常都是传手机号与短信内容，阿里的玩法改变成了手机号、短信模板、参数。依据传统的做法，我们需要为两百多个短信模板配置阿里短信模……
作为甲方，我们经历一场凌晨短信通道异常的煎熬，这个时候正是多数人睡梦中。我们却睡梦中惊醒。短信通道异常，用户无法收到短信，我们非常被动。出了什么问题，哪个环节出了问题，我们如何处理？见到问题后，我们首先排查了自身短信服务的情况，均无问题，于是问题的重点在短信服务商出了问题。下面详细介绍一下我们排查问题的关键要素与处理方案，最后我们来分析乙方如何答复，阐述了为什么我只打50分，连及格分也没有给。
短信流水
我们能看到的短信流水是乙方提供的流水，仅代表了短信被乙方收到，乙方将短信送到移动电信联通运营商的过程与结果，完全是在黑盒子里。比较尴尬的是乙方不提……
近期做压测优化时，特意选用了无侵入式代码注解方式[OutputCache(Duration = 300)] 对接口做了5分钟缓存。依据业务预期，5分钟的缓存能确保我们的接口顺利通过压测。就在满怀信心等着通过的报告时，却被打脸了。
报告显示，在前2分钟，接口返回都正常无错误，接下来就出现了错误返回。仔细想想，这个问题在于，缓存失效的一瞬间，大量的请求穿透过去，导致请求直接压到了需要保护的后端服务。
于是，采用lock的方式,防止缓存击穿!
protected static object sysncObject = new object();
// 开缓存了，防止缓存失效的……
最近遇到2个非常真实的案例，一个参数控制2种不同的业务，虽然业务有所关联，但是严格的来讲，又属于两种不同的业务，导致花费了不少时间去梳理与配置。这让我不得不思考一下如何设计参数防止新人踩坑。真实的案例，真实的感受。
案例一 开始时间 结束时间
2个业务A、B都有开始时间与结束时间，业务场景一【开始时间X，结束时间Y】使用业务A，其他时间使用业务B，业务场景二【开始时间X，结束时间Y】使用业务B，其他时间使用业务A。
如果设计参数的时候，仅设计2个参数开始时间与结束时间，还允许出现参数配置中出现开始时间大小结束时间的配置方式，的确，2个参数满足……
有的人，一帆风顺，有的人，注定要经历各种坎坷。每个人会有自己的坎，站在不同的角度，也许是自己难以越过去的，在别人眼里却是简单的事情。无所谓与不幸，真正静下心来想想，什么是自己能hold住的，什么是自己所向往的，技术的生活，有技术的好与不好。
技术的层次
技术也分难与易，底层与高层，思维方式大不一样。不同的思维方式，体现在产出的代码。自己在哪个层次？我们是否需要写算法？算法在工作中占多大的比重？在什么位置平衡？这些都是一致需要思考的。
2019一直在思考这些，思考随着年龄的压力，随着时光的流逝，我们应该如何面对社会给过来的“压力”，如何调整自我的心态？不因物喜，关注自我的能力、……
![](https://mmbiz……