1. 程式人生 > >記一次企業傳統業務成功的上雲的實戰

記一次企業傳統業務成功的上雲的實戰

前言:你試過把本地伺服器上的應用遷移到雲上嗎?我們見過,試過;你知道本地應用遷移到上之後的表現嗎?我們也知道。本文記錄了一次上雲實戰,並且通過對比測試呈現了上雲後的效能表現。

640?wx_fmt=jpeg

淡漠,在大多數時候,都可以用來形容傳統企業對熱鬧非凡的IT行業的反應。

傳統企業對IT系統的要求是:現在好用夠用就成,這也是傳統企業對運維人員的要求,用慣了Windows作業系統的使用者們對Windows Server接受起來更容易些。

好在雲端計算的發展足夠深入了,傳統企業也在做上雲這件事兒。企事錄作為神農一樣的嚐鮮者,此前在京東雲上做過一系列企業級應用測試,這次首次嘗試把本地物理機上的傳統企業應用向雲上遷移。

感謝京東雲的平臺支援和北京德勝軟體的協助,企事錄順利地把跑在本地8核16GB記憶體物理伺服器上的應用遷移到了雲上,遷移很成功,遷移後的功能、效能如何呢?

測試檢驗功能和效能表現

為了降低系統遷移的難度,也為了能較為公平地對比物理伺服器和雲主機,企事錄在京東雲基礎雲平臺上建立了一套在配置上完全等同於物理伺服器的雲主機平臺,配置如下:

640?wx_fmt=png

京東雲基礎雲平臺雲主機配置

640?wx_fmt=jpeg

這是跑在該物理伺服器上的一套CMS管理平臺,前端是Tomcat伺服器,後端是Postgre SQL資料庫

640?wx_fmt=jpeg

這是管理平臺的系統介面——感謝德勝軟體協助將此基於傳統Windows Server平臺下的傳統應用系統移植到京東雲平臺

為了確保測試系統的瓶頸不會出現在網路部分,我們先確認位於同一VPC環境下的WEB主機和壓力工作情況,做法是在兩臺主機間發起網路頻寬驗證。

640?wx_fmt=jpeg

Web主機和壓力機之間網路頻寬驗證

結果顯示,兩臺主機間頻寬接近10Gbits/s。

測試環境分析

綜合管理平臺是基於Java開發的,跨平臺能力較好,相容性也比較好,符合傳統企業級使用者的應用需求,但缺點是對系統的計算資源開銷比較大,設計之初,就是為峰值200人同時使用準備的,因此在伺服器配置並不是很高,用的是一臺配有一顆至強2620 v3處理器,16GB記憶體的伺服器。

原系統實測在200人併發時系統延時可以控制在3秒左右,基本不影響使用者使用體驗,常規幾十人使用時延時會低於1秒。如果遷移到京東雲上之後,這套系統在公有云上的表現要接近物理機的表現就非常好了。

系統遷移出奇的順利,半天時間就在京東雲上部署完成了,這對於企事錄而言已經習以為常,但是協助我們部署環境的德勝工程師對此相當驚訝,相比在物理機上部署要快幾倍(物理機需要自行安裝系統等諸多基礎性的工作)。

接下來進入測試環節,測試方法步驟:

測試工具選用的是LoadRunner,這是一款壓力測試軟體,通過模擬真實的使用者行為,可顯示負載、併發和效能實時監控情況而且可自動完成最終測試報告,幫助分析系統可能存在的瓶頸,LoadRunner最厲害的地方在於同時模擬成千上萬的使用者進行操作。

第一步,在區域網安裝壓力測試軟體進行指令碼錄製;

第二步,LoadRunner 通過錄制登入瀏覽退出指令碼進行壓力測試;

第三步,進行壓力測試。

Loadrunner錄製了登入、瀏覽等操作,一組大約有200個事件。

640?wx_fmt=jpeg

Loadrunner錄製的登入、瀏覽等操作一組大約有200個事件

640?wx_fmt=jpeg

測試狀態下的系統開銷監控

上圖顯示測試狀態下的系統開銷監控:左側為壓力機,右側為應用主機,在300以上併發的測試壓力下,WEB主機計算資源已經完全被佔用,而壓力機計算開銷只有一半,這就充分說明壓力瓶頸在應用平臺上,壓力機一使勁兒就能讓測試的主機吃不消,測試結果可信有效。

我們來看一下該系統分別在100個、200個和300個使用者併發操作下的效能表現:

100個使用者併發響應

640?wx_fmt=jpeg
模擬100個使用者併發效能測試時,響應時間很快,平均在0.5秒以內

640?wx_fmt=jpeg

網路頻寬在100個使用者併發時佔用約119M,整套管理系統響應及時,主機計算資源開銷只有60%左右,系統可輕鬆應付100個使用者

200個使用者併發響應

隨著使用者的增多,此時WEB主機的計算資源佔用達到了85%,網路頻寬開銷215M,與物理主機狀態下系統資源開銷比較類似。

640?wx_fmt=jpeg
隨著使用者的增多,系統響應時間開始增加,平均響應時間在2.5秒左右

上文提到,物理機200個使用者併發響應時間可控制在3秒,上雲後的系統縮短了0.5秒左右,這應該是得益於京東雲主機系統盤是SSD,且不限IOps效能的緣故,比物理機的HDD響應要好很多。雲主機SSD系統盤的效能優勢得以顯現。

300個使用者併發響應

640?wx_fmt=jpeg
300個使用者的併發響應時間約3.5秒,如果是物理伺服器主機,300個併發就已經卡的很厲害了,而在京東雲主機上依然有較高的可用性,這主要是因為SSD作為系統盤的的原因

繼續增加併發到500使用者,京東雲主機依然能保證響應,正常執行,看來京東雲的抗壓能力不錯。

通過這次測試,企事錄發現:

傳統的應用上雲比我們想象中要簡單,上雲後的效能表現不弱於物理主機。雲平臺的配置更靈活更強大,如果像京東雲一樣配置SSD之後提升了IO效能,從而還可保證系統在超負荷訪問時的可用性,這點也許是很多使用者都需要的優勢。

640?wx_fmt=png

相關推薦

企業傳統業務成功實戰

前言:你試過把本地伺服器上的應用遷移到雲上嗎?我們見過,試過;你知道本地應用遷移到上之後的表現嗎?我們也知道。本文記錄了一次上雲實戰,並且通過對比

zabbix啟動不成功

ges roc type ffd size fff vpd text color 記一次zabbix啟動不成功

不太成功的爬取dingtalk企業的信息

原來 oda gen 鏈接 master ref apc rate oss 首先打開這個鏈接https://www.dingtalk.com/qiye/1.html,可以網頁列出了很多企業,點擊企業,就看到了企業的信息。所以,我們的思路就很明確了,通過https://www

構建SaaS平臺專案失敗後的反思-技術VS產品哪個更重要-如何權衡-程式設計師職業生涯的自我批判與成長-業務型程式設計師的商業視角-多維度分析研發型企業管理之道

記一次構建SaaS平臺專案失敗後的反思 前言: 筆者從2017年起開始著手將公司現有的軟體系統改造成多租戶模式,以降低整

成功的redis訪問

redis spring-data linux window 在虛擬機上面安裝redis,在本機上面使用spring-data-redis寫一個存取kv的單元測試類。本來是一個很簡單的demo實驗,結果還是趟了不少坑。之前都是連接測試別人安裝好的redis,或者自己安裝的redis使用redi

業務復雜的解決流程

控制 blog 修改 流程 block 今天 原子性 道理 復雜 一、遇到的問題:   今天在搬磚的時候,分類情況比較多,多次修改後,總是會報出一些問題   大概條件有兩種摻雜:表類型、列包含標誌    二、解決思路:   1、縮小到最小變化量,首先確定有兩種

成功的arp流量轉發以及實驗過程中出現的問題

0x00    前言 之前筆者仔細學習了arp協議和arp欺騙的原理和細節,這裡通過kali linux和其他虛擬機器完成一個實驗 實驗環境: kali linux 2018.2(32位)  winxp(32位) ,均為虛擬機器 實驗工具:arpspoof,

[雜]買膝型電腦

那啥,最近雙十一,想起現在用的這臺本本,已經站崗四年了,現在卡得不要不要的,像lol/unity/vs這些軟體是能跑的,但是慢,很影響心情和效率,所以還是選擇換臺配置高點的。目前想要的定位是中高階,預算四五千,換作以前的我,可能想著越高配置越好,但是出來混社會了,不一樣了,已經不能再花太多的時間和精力在各種3

Oracle -- ADG庫遷移過程小結 -- 篇(ADG建庫)

背景:   客戶新採購一批機器,需要把原ADG庫資料移到新機器上,作業系統不變,資料庫版本不變。   遠端安裝,採用xmanager軟體連線搭建。   環境:   作業系統:Oracle Linux Server release 6.8    oracle資料庫版本:11g r

業務上線出現的故障---微信轉發信用卡邀約開卡業務出現高几率失敗情況

具體情況: 在一次協助xx銀行上線時,遇到這樣的一個問題:此業務功能是將信用卡邀約開卡的頁面轉發給微信好友,好友點開連結後可以直接跳轉到申請信用卡的頁面; 出現的問題是經過大量的測試,有50%的是友點開頁面後還是一個邀請信用卡開卡的頁面。 故障原因是: 程式碼的問題 是soc

在64位Ubuntu 16.04下成功安裝arm-none-eabi-gcc交叉編譯器的過程

2018.07.28 剛開始在網上找了很多教程,都是大同小異的步驟: 在官網下載arm-none-eabi-gcc的.tar.bz2壓縮包 解壓到自定義目錄 開啟.bashrc和.profie新增環境變數和路徑 生效更改 查詢編譯器是否配置成功 上面的安

【報錯記錄】Springboot 打包jar後放在伺服器執行失敗的排錯

使用mvn package -DSkipTests打包成jar包,然後上傳到伺服器。執行java -jar XXX.jar --env=pro後丟擲: [localhost-startStop-1] ERROR o.s.boot.web.embedded.tomcat.TomcatStart

在公司伺服器安裝fastdfs的歷程

1.確保已安裝了gcc,unzip(基本工具) 2.安裝libfastcommon-master 步驟: unzip libfastcommon-master.zip cd libfastcommon-master ./make.sh ./make.sh install

傳jar到maven中央倉庫記錄

最近利用工作閒暇之餘,開發了一個基於logback底層的日誌脫敏工具jar 包(歡迎大家吐槽:logback日誌脫敏工具),同事推薦上傳到maven中央倉庫,方便大家使用。於是萌生了上傳jar 包到maven中央倉庫的想法,在此分享一下將jar包釋出到Maven中央倉庫的

godaddy同一虛擬主機部署多站

題外話,專案上的一些感觸:非同步處理的目的不是為了聽起來很高階,而是為了更快速的響應客戶端且在背地裡準確的完成業務處理。 前提:你的主機支援多站部署,有的伺服器產品型別不支援。比如我的是godady的虛擬主機的旗艦版。 如果你有兩個域名,其中一個a.com已經部署在了go

ZooKeeper啟動成功,卻無法檢視status——Zookeeper“異常”

今天在使用storm時,需要啟動zookeeper依賴叢集。於是使用命令啟動zookeeper叢集,使用命令bin/zkServer.sh start [[email protected] bin]# ./zkServer.sh start ZooKeeper J

填坑,在伺服器安裝jupyter並遠端使用

先說我經歷了什麼吧,首先是py3的坑 ## py3安裝的坑 首先我們拿到雲主機,連線上去,過程略 通過python看到預設版本為py2.7,不支援最新的jupyter 之前安裝的python3在過一陣之後會莫名其妙的崩潰,首先要安裝python的依賴 yum -y

Hive庫裡手動刪除表,但是HDFS還存在表文件奇怪問題

正常在hive庫即hive命令列中刪除一張表,hdfs上也是同步的被刪除的,但是這次發現在hive裡手動建了一張表,然後使用drop table 表名後,hive庫裡的確沒發現這張表了,但是HDFS上還是有。 我使用的建表建庫語句: create database&nbs

伺服器配置GPU版本tensorflow的經歷

早就耳聞tensorflow-gpu與CUDA,cudnn三者之間版本匹配很複雜,今天算是見識到了。 首先看了下伺服器上的CUDA、cudnn版本,分別是CUDA8.0,cudnn7.0.4 這個匹配很奇怪,一般都是CUDA8 + cudnn6或者 CUDA9 + cudnn7 後來知

SpringBoot 的WebSocket前端連線不的處理方法

首先,按照別人的程式碼一步步實現,程式碼順利執行 問題:websocket一直連線不上,前端報403錯誤,由此可見,伺服器主動拒絕了。找了好多方案不得果,然後就看到了https://blog.csdn.net/qq_33547169/article/details/80084231這篇文章,