整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
欲善其事必先利其器，好的工具能够提高工作效率。现在网上有很多实用的小工具，可以帮助你解决工作中的小问题。下面就一一分享给大家。
1、汉字拼音在线转换
（https://www.qqxiuzi.cn/zh/pinyin/）
网站支持文字转成拼音大小写，首字母大写、句首大写、标注声调等等。对于不熟悉拼音，常用五笔来打字的人来说，转换出正确的拼音很让人头痛，这个在线网站帮你解决。也能解决普通话不标准的一些家长的困惑，在辅导孩子写语文作业的时候，不知道拼音怎么标注声调。
2、在线英文字母大小写转换
（https://www.iamwawa.cn/daxiaoxie.html）
网站支持字母全大写、全小写、首字母大写、首字母大写、空格转下划线等等，都是很实用的编辑功能，网站还有很多实用的功能，需要的可以自行解锁。
3、二维码图片转矢量
（http://www.zhangqu.org/?page_id=359）
做设计的时候会遇到把二维码转换成矢量的时候，如果用PS或者AI转出来的都不是很好，对于原始文件像素不高的很难解决，这个网站转换出来的就很好，可以直接使用。但是面对特殊的圆形二维码或者其他的识别度都行，网站只能转出方形的二维码。
4、在线书法字转换
（http://www.ziticq.com/Shufa）
这是一个很好的在线书法字转换网站，你可以选择你喜欢的字进行组合。网站提供158,592 幅书法作品中出现的字，可以存svg, png, pdf格式的文件，适用Ai、Ps等软件。
5、人民币大写在线转换
（https://www.917118.com/tool/rmb.html）
这个网站主要是人民币大写的转换、计算机颜色在线查询工具，我主要用在财务报销的时候，填写报销单需要用到人民币的大写。
6、在线修改照片
（https://www.gaitubao.com/）
网站可以在线修改图片像素及尺寸、裁剪、压缩文件大小，对于一些从事文案工作的人来说是个好帮手，可以解决一些问题，不用打开专业的软件去操作，效率低。
这次就分享这些实用的工具网站给大家，欢迎在评论区留言分享你的实用工具，点赞和评论是对我最大的鼓励支持，谢谢大家。
英，黄宇，徐灵飞
（成都理工大学 工程技术学院 电计系，四川 乐山 614007）
：在硬件板卡设计中，对硬件板卡的供电电压范围都有一定的要求，为了方便验证同一批次产品中每张板卡供电电压范围的一致性及板卡跌落电压检测电路是否能有效工作，利用TPS5430DDA开关电源芯片提出了一种板卡拉偏电压自动控制的方法。该方法易于实现,电路简单，可应用于整个生产测试环节。
：TPS5430DDA；硬件板卡；电压拉偏；电压跌落
：TP306+.2文献标识码：ADOI： 10.19358/j.issn.1674-7720.2016.24.010
引用格式：兰英，黄宇，徐灵飞．硬件测试中自动控制板卡电压拉偏的方法［J］.微型机与应用，2016,35（24）：34-35.
0引言
在大多数板卡设计中，针对客户对硬件板卡供电范围的要求，需要在研发阶段进行验证。因此，对批量硬件板卡相关指标的测试尤为重要，其主要工作就是对工作电源电压进行拉偏控制，并对电压跌落信号进行测试。
本文以某主板测试案例为例，说明测试中自动控制板卡电压拉偏的方法。该主板（产品）工作电源为5 V（1±5%），并在背板连接器（主板和测试工具板之间的连接器）中定义了电压跌落（XVccFALL#）信号引脚，要求输入电压跌落时，该引脚能输出跌落指示信号。
为了验证每张板卡供电范围的一致性及板卡的电压跌落检测电路是否能有效工作，在实践中，主板配合硬件测试底板（测试工具板）实现了输入电压拉偏控制，并针对XVccFALL#信号进行自动化测试，无需人工值守，方便在生产测试环节中使用。
1需求分析
从需求来看，验证板卡电压工作范围和电压跌落指示信号很简单，将板卡输出电压改为4.75 V~5.25 V之间，检测XVccFALL#信号高低状态即可，刚开始准备使用可调电源调节输入电压并检测跌落信号电平，但无法与测试程序自动结合起来，仅能作为手动测试项，调节起来比较费时费力，且在一些特殊试验时会加长电源导线，不容易针对板卡末端电压准确控制与测试。因此，提出以下几种实现方法。
（1）底板准备几组固定的电源电压，用主板输出离散量控制场效应晶体管（MetalOxideSemiconductor FieldEffect Transistor, MOSFET）或继电器切换输入电压。
此方法调试简单，但需要几组电源，无论是使用外置电源还是电源芯片产生，都会增加对资源的要求，继电器切换又存在寿命短、耐振动性差等问题；MOSFET切换也存在不同电压间隔离、缓启动电路等问题（若不考虑缓启动的话会对输入电压带负载能力提出更高要求）。
（2）底板使用一个可外部设置输出电压的电源芯片，使用主板输出离散量控制继电器、MOSFET、数字电位器来改变反馈回路阻值，从而改变输出电压。
此方法对资源要求小，不需要太多器件，考虑继电器触点存在抖动、耐振动性差等缺点，数字电位器存在供电电压的限制，因此决定采用MOSFET来实现对反馈回路的控制。
2电路设计
根据需求分析，选择TPS5430DDA、IRF7240（p沟道MOSFET）作为主要器件,结合TPS5430DDA芯片资料［1］，构建图1所示电路。其中，在稳定状态下，VSENSE脚的电压等于电压参考值1.221 V，输出电压VDDM5V0由VSENSE脚外接的电阻R58和R59、R60、R61分压决定。通过跳线帽对插针JUMPER2连接，可手动改变分压值，即可以手动改变拉偏电压；另外，在不用跳线帽时，图中XPOWER端的输入可控制IRF7240（MOSFET）［2］是否导通，而XPOWER端是由主板测试程序通过离散量输出通知底板复杂可编程逻辑器件（Complex Programmable Logic Device，CPLD）打开和关闭，如图2所示，从而实现电压拉偏自动控制。
图2CPLD控制XPOWER输出当场效应管不导通时，VDDM5V0端的输出电压值为：
其中，Rds为场效应管源极和漏极的内阻值，一般为毫欧级，根据所选场效应管的型号，其对输出电压的误差影响只有微伏级。在实际应用中工作原理是预先调节电路，按照板卡要求设置好拉偏电压值。主板测试程序通过离散量输出通知底板CPLD打开和关闭拉偏控制电路，延迟一段时间后，主板测试程序通过离散量输入检测XVccFALL#状态判断是否合格，板卡上电后可自动进行测试。因MOSFET切换无抖动，故电压输出值稳定，超调值较小，实测输出电压如图3所示。
此案例中XVccFALL#信号是一个输入电压跌落的输出指示，本次在已有测试底板上先实现一个负向拉偏的功能，对这种方法进行一次验证，在有此需要的场景中，可以根据此原理举一反三，灵活应用。
3结论
本文介绍的方法原理比较简单，但它可以结合测试程序实现板卡电压拉偏控制及输出指示信号的自动化测试。其优点是不挑剔输入电源，输出电压超调小，输出电压切换时，没有电压跌落，电压变化平缓。在整个生产测试环节（高温、低温、振动等）中都可以使用，检测准确，无需人工值守。该方法已在某项目测试底板上验证，试验结果表明此方法可行。
参考文献
［1］ Texas Instruments. TPS5430 Datasheet［EB/OL］.(200601) ［2015056］http://www.alldatasheet.com/datasheetpdf/pdf/132224/TI/TPS5430.html.
［2］ Internation IOR Rectifier. IRF7240［EB/OL］.(2005106) ［2015056］http://www.infineon.com/cms/en/search.html#!term=IRF7240&view=all.
多深度文章，请关注云计算频道：https://yq.aliyun.com/cloud
如果图片显示异常，请将原文地址复制到浏览器中查看：https://yq.aliyun.com/articles/72514
背景说明
2016年的双11在淘宝上买买买的时候，天猫和优酷土豆一起做了联合促销，在天猫双11当天购物满XXX元就赠送优酷会员，这个过程需要用户在优酷侧绑定淘宝账号（登录优酷、提供淘宝账号，优酷调用淘宝API实现两个账号绑定）和赠送会员并让会员权益生效（看收费影片、免广告等等）
这里涉及到优酷的两个部门：Passport（在上海，负责登录、绑定账号，下文中的优化过程主要是Passport部分）；会员（在北京，负责赠送会员，保证权益生效）
在双11活动之前，Passport的绑定账号功能一直在运行，只是没有碰到过大促销带来的挑战
会员部分的架构改造
接入中间件DRDS，让优酷的数据库支持拆分，分解MySQL压力
接入中间件vipserver来支持负载均衡
接入集团DRC来保障数据的高可用
对业务进行改造支持Amazon的全链路压测
主要的压测过程
上图是压测过程中主要的阶段中问题和改进,主要的问题和优化过程如下：
- docker bridge网络性能问题和网络中断si不均衡 （优化后：500->1000TPS)- 短连接导致的local port不够 （优化后：1000-3000TPS）- 生产环境snat单核导致的网络延时增大 （优化后能达到测试环境的3000TPS）- Spring MVC Path带来的过高的CPU消耗 （优化后：3000->4200TPS)- 其他业务代码的优化（比如异常、agent等） （优化后：4200->5400TPS)
优化过程中碰到的比如淘宝api调用次数限流等一些业务问题就不列出来了
Passport部分的压力
由于用户进来后先要登录并且绑定账号，实际压力先到Passport部分，在这个过程中最开始单机TPS只能到500，经过N轮优化后基本能达到5400 TPS，下面主要是阐述这个优化过程
Passport 核心服务分两个：
Login 主要处理登录请求
userservice 处理登录后的业务逻辑，比如将优酷账号和淘宝账号绑定
为了更好地利用资源每台物理加上部署三个docker 容器，跑在不同的端口上（8081、8082、8083），通过bridge网络来互相通讯
Passport机器大致结构
说明：这里的500 TPS到5400 TPS是指登录和将优酷账号和淘宝账号绑定的TPS，也是促销活动主要的瓶颈
userservice服务网络相关的各种问题
太多SocketConnect异常（如上图）
在userservice机器上通过netstat也能看到大量的SYN_SENT状态，如下图：
因为docker bridge通过nat来实现，尝试去掉docker，让tomcat直接跑在物理机上
这时SocketConnect异常不再出现
从新梳理一下网络流程
docker(bridge)----短连接--->访问淘宝API（淘宝open api只能短连接访问），性能差，cpu都花在si上；
如果 docker(bridge)----长连接到宿主机的某个代理上（比如haproxy）-----短连接--->访问淘宝API， 性能就能好一点。问题可能是短连接放大了Docker bridge网络的性能损耗
当时看到的cpu si非常高，截图如下：
去掉Docker后，性能有所提升，继续通过perf top看到内核态寻找可用的Local Port消耗了比较多的CPU，gif动态截图如下（可以点击看高清大图）：
注意图中ipv6_rcv_saddr_equal和inet_csk_get_port 总共占了30%的CPU
一般来说一台机器可用Local Port 3万多个，如果是短连接的话，一个连接释放后默认需要60秒回收，30000/60 =500 这是大概的理论TPS值
同时观察这个时候CPU的主要花在sy上，最理想肯定是希望CPU主要用在us上，截图如下：
sy占用了30-50%的CPU，这太不科学了，同时通过 netstat 分析连接状态，确实看到很多TIME_WAIT：
于是让PE修改了tcp相关参数：降低 tcp_max_tw_buckets和开启tcp_tw_reuse，这个时候TPS能从1000提升到3000
优化到3000 TPS后上线继续压测
居然性能又回到了500，太沮丧了，其实最开始账号绑定慢，Passport这边就怀疑taobao api是不是在大压力下不稳定，程序员一般都是认为自己没问题，有问题的一定是对方 ：） ，taobao api那边给出调用数据都是1ms以内就返回了（alimonitor监控图表）。
于是怀疑从优酷的机器到淘宝的机器中间链路上有瓶颈，但是需要设计方案来证明这个问题在链路上，要不各个环节都会认为自己没有问题的，当时Passport的开发也只能拿到Login和Userservice这两组机器的权限，中间的负载均衡、交换机都没有权限接触到。
在尝试过tcpdump抓包、ping等各种手段分析后，设计了场景证明问题在中间链路上。
设计如下三个场景证明问题在中间链路上：
压测的时候在userservice ping 淘宝的机器；
将一台userservice机器从负载均衡上拿下来（没有压力），ping 淘宝的机器；
从公网上非优酷的机器 ping 淘宝的机器；
这个时候奇怪的事情发现了，压力一上来**场景1、2**的两台机器ping淘宝的rt都从30ms上升到100-150ms，**场景1** 的rt上升可以理解，但是**场景2**的rt上升不应该，同时**场景3**中ping淘宝在压力测试的情况下rt一直很稳定（说明压力下淘宝的机器没有问题），到此确认问题在优酷到淘宝机房的链路上有瓶颈，而且问题在优酷机房出口扛不住这么大的压力。于是从上海Passport的团队找到北京Passport的PE团队，确认在优酷调用taobao api的出口上使用了snat，PE到snat机器上看到snat只能使用单核，而且对应的核早就100%的CPU了，因为之前一直没有这么大的压力所以这个问题一直存在只是没有被发现。
于是PE去掉snat，再压的话 TPS稳定在3000左右
到这里结束了吗？ 从3000到5400TPS
优化到3000TPS的整个过程没有修改业务代码，只是通过修改系统配置、结构非常有效地把TPS提升了6倍，对于优化来说这个过程是最轻松，性价比也是非常高的。实际到这个时候也临近双11封网了，最终通过计算（机器数量*单机TPS）完全可以抗住双11的压力，所以最终双11运行的版本就是这样的。 但是有工匠精神的工程师是不会轻易放过这么好的优化场景和环境的（基线、机器、代码、工具都具备配套好了）
优化完环境问题后，3000TPS能把CPU US跑上去，于是再对业务代码进行优化也是可行的了。
进一步挖掘代码中的优化空间
双11前的这段封网其实是比较无聊的，于是和Passport的开发同学们一起挖掘代码中的可以优化的部分。这个过程中使用到的主要工具是这三个：火焰图、perf、perf-map-java。相关链接：http://www.brendangregg.com/perf.html ; https://github.com/jrudolph/perf-map-agent
通过Perf发现的一个SpringMVC 的性能问题
这个问题具体参考我之前发表的优化文章http://www.atatech.org/articles/65232 。 主要是通过火焰图发现spring mapping path消耗了过多CPU的性能问题，CPU热点都在methodMapping相关部分，于是修改代码去掉spring中的methodMapping解析后性能提升了40%，TPS能从3000提升到4200.
著名的fillInStackTrace导致的性能问题
代码中的第二个问题是我们程序中很多异常（fillInStackTrace），实际业务上没有这么多错误，应该是一些不重要的异常，不会影响结果，但是异常频率很高，对这种我们可以找到触发的地方，catch住，然后不要抛出去（也就是别触发fillInStackTrace)，打印一行error日志就行，这块也能省出10%的CPU，对应到TPS也有几百的提升。
部分触发fillInStackTrace的场景和具体代码行（点击看高清大图）：
对应的火焰图（点击看高清大图）：
解析useragent 代码部分的性能问题
整个useragent调用堆栈和cpu占用情况，做了个汇总（useragent不启用TPS能从4700提升到5400）
实际火焰图中比较分散：
最终通过对代码的优化勉勉强强将TPS从3000提升到了5400（太不容易了，改代码过程太辛苦，不如改配置来钱快）
优化代码后压测tps可以跑到5400，截图：
最后再次总结整个压测过程的问题和优化历程
- docker bridge网络性能问题和网络中断si不均衡 （优化后：500->1000TPS)- 短连接导致的local port不够 （优化后：1000-3000TPS）- 生产环境snat单核导致的网络延时增大 （优化后能达到测试环境的3000TPS）- Spring MVC Path带来的过高的CPU消耗 （优化后：3000->4200TPS)- 其他业务代码的优化（比如异常、agent等） （优化后：4200->5400TPS)
整个过程得到了淘宝API、优酷会员、优酷Passport、网络、蚂蚁等众多同学的帮助，本来是计划去上海跟Passport的同学一起复盘然后再写这篇文章的，结果一直未能成行，请原谅我拖延到现在才把大家一起辛苦工作的结果整理出来，可能过程中的数据会有一些记忆上的小错误。
*请认真填写需求信息，我们会在24小时内与您取得联系。
