整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
欲善其事必先利其器，好的工具能夠提高工作效率?，F在網上有很多實用的小工具，可以幫助你解決工作中的小問題。下面就一一分享給大家。
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小時內與您取得聯系。
