日日摸夜夜爽人人添,97精品国产自在现线免费观看,国产成人精品综合网站,中文字幕伦视频

深圳搬家搬廠網站建設公司
當前位置:網站首頁 > 新聞動態 > HTTP500解決辦法(記一次K8S POD頻繁重啟的優化之旅)1.背景 返回列表

HTTP500解決辦法(記一次K8S POD頻繁重啟的優化之旅)1.背景

發布時間:2023-12-05來源:網站建設公司

1.背景

最近有運維反饋某個微服務頻繁重啟,客戶映像特別不好,需要我們盡快看一下。

聽他說完我立馬到監控平臺去看這個服務的運行情況,確實重啟了很多次。對于技術人員來說,這既是壓力也是動力,大多數時候我們都是沉浸在單調的業務開發中,對自我的提升有限,久而久之可能會陷入一種舒適區,遇到這種救火案例一時間會有點無所適從,但是沒關系,畢竟......

“我只是收了火,但沒有熄爐”,借用電影中的一句話表達一下此時的心情。

2.初看日志

我當即就看這個服務的運行日志,里面有大量的oom異常,如下:

org.springframework.web.util.NestedServletException: Handlerdispatchfailed; nestedexceptionisjava.lang.OutOfMemoryError: GCoverheadlimitexceeded

整個服務基本可以說處于不可用狀態,任何請求過來幾乎都會報oom,但是這跟重啟有什么關系呢?是誰觸發了重啟呢?這里我暫時賣個關子,后面進行解答。

3.k8s健康檢查介紹

我們的服務部署在k8s中,k8s可以對容器執行定期的診斷,要執行診斷,kubelet 調用由容器實現的 Handler (處理程序)。有三種類型的處理程序:

  • ExecAction:在容器內執行指定命令。如果命令退出時返回碼為 0 則認為診斷成功。
  • TCPSocketAction:對容器的 IP 地址上的指定端口執行 TCP 檢查。如果端口打開,則診斷被認為是成功的。
  • HTTPGetAction:對容器的 IP 地址上指定端口和路徑執行 HTTP Get 請求。如果響應的狀態碼大于等于 200 且小于 400,則診斷被認為是成功的。

每次探測都將獲得以下三種結果之一:

  • Success(成功):容器通過了診斷。
  • Failure(失敗):容器未通過診斷。
  • Unknown(未知):診斷失敗,因此不會采取任何行動。

針對運行中的容器,kubelet 可以選擇是否執行以下三種探針,以及如何針對探測結果作出反應:

  • livenessProbe:指示容器是否正在運行。如果存活態探測失敗,則 kubelet 會殺死容器, 并且容器將根據其重啟策略決定未來。如果容器不提供存活探針, 則默認狀態為 Success。
  • readinessProbe:指示容器是否準備好為請求提供服務。如果就緒態探測失敗, 端點控制器將從與 Pod 匹配的所有服務的端點列表中刪除該 Pod 的 IP 地址。初始延遲之前的就緒態的狀態值默認為 Failure。如果容器不提供就緒態探針,則默認狀態為 Success。
  • startupProbe: 指示容器中的應用是否已經啟動。如果提供了啟動探針,則所有其他探針都會被 禁用,直到此探針成功為止。如果啟動探測失敗,kubelet 將殺死容器,而容器依其 重啟策略進行重啟。如果容器沒有提供啟動探測,則默認狀態為 Success。

以上探針介紹內容來源于https://kubernetes.io/zh/docs/concepts/workloads/pods/pod-lifecycle/#container-probes

看完探針的相關介紹,可以基本回答上面的疑點**“oom和重啟有什么關系?”,**是livenessProbe的鍋,簡單描述一下為什么:

  1. 服務啟動;
  2. k8s通過livenessProbe中配置的健康檢查Handler做定期診斷(我們配置的是HttpGetAction);
  3. 由于oom所以HttpGetAction返回的http status code是500,被k8s認定為Failure(失敗)-容器未通過診斷;
  4. k8s認為pod不健康,決定“殺死”它然后重新啟動。

這是服務的Deployment.yml中關于livenessProbe和restartPolicy的配置

livenessProbe:failureThreshold:5httpGet:path:/healthport:8080scheme:HTTPinitialDelaySeconds:180periodSeconds:20successThreshold:1timeoutSeconds:10restartPolicy:Always

4.第一次優化

內存溢出無外乎內存不夠用了,而這種不夠用又粗略分兩種情況:

  1. 存在內存泄漏情況,本來應該清理的對象但是并沒有被清理,比如HashMap以自定義對象作為Key時對hashCode和equals方法處理不當時可能會發生;
  2. 內存確實不夠用了,比如訪問量突然上來了;

由于我們這個是一個老服務,而且在多個客戶私有化環境都部署過,都沒出過這個問題,所以我直接排除了內存泄漏的情況,那就將目光投向第二種“內存確實不夠用”,通過對比訪問日志和詢問業務人員后得知最近客戶在大力推廣系統,所以訪問量確實是上來了。

“不要一開始就陷入技術人員的固化思維,認為是程序存在問題”

知道了原因那解決手段也就很粗暴了,加內存唄,分分鐘改完重新發布。

http500解決辦法(記一次k8s pod頻繁重啟的優化之旅)1.背景

終于發布完成,我打開監控平臺查看服務的運行情況,這次日志里確實沒有oom的字樣,本次優化以迅雷不及掩耳之勢這么快就完了?果然是我想多了,一陣過后我眼睜睜看著pod再次重啟,但詭異的是程序日志里沒有oom,這一次是什么造成了它重啟呢?

我使用kubectl describe pod命令查看一下pod的詳細信息,重點關注Last State,里面包括上一次的退出原因和退回code。

http500解決辦法(記一次k8s pod頻繁重啟的優化之旅)1.背景

可以看到上一次退出是由于OOMKilled,字面意思就是pod由于內存溢出被kill,這里的OOMKilled和之前提到的程序日志中輸出的oom異常可千萬不要混為一談,如果pod 中的limit 資源設置較小,會運行內存不足導致 OOMKilled,這個是k8s層面的oom,這里借助官網的文檔順便介紹一下pod和容器中的內存限制。

以下pod內存限制內容來源于https://kubernetes.io/zh/docs/tasks/configure-pod-container/assign-memory-resource/

*要為容器指定內存請求,請在容器資源清單中包含 *resources:requests字段。同理,要指定內存限制,請包含 resources:limits。

以下deployment.yml將創建一個擁有一個容器的 Pod。容器將會請求 100 MiB 內存,并且內存會被限制在 200 MiB 以內:

apiVersion: v1 kind: Pod metadata: name: memory-demo namespace: mem-example spec: containers: - name: memory-demo-ctr image: polinux/stress resources: limits: memory: "200Mi"requests: memory: "100Mi"command: ["stress"] args: ["--vm", "1", "--vm-bytes", "150M", "--vm-hang", "1"]

當節點擁有足夠的可用內存時,容器可以使用其請求的內存。但是,容器不允許使用超過其限制的內存。如果容器分配的內存超過其限制,該容器會成為被終止的候選容器。如果容器繼續消耗超出其限制的內存,則終止容器。如果終止的容器可以被重啟,則 kubelet 會重新啟動它,就像其他任何類型的運行時失敗一樣。

回歸到我們的場景中來講,雖然把jvm內存提高了,但是其運行環境(pod、容器)的內存限制并沒有提高,所以自然是達不到預期狀態的,解決方式也是很簡單了,提高deployment.yml中memory的限制,比如jvm中-Xmx為1G,那memory的limits至少應該大于1G。

至此,第一次優化算是真正告一段落。

5.第二次優化

第一次優化只給我們帶來了短暫的平靜,重啟次數確實有所下降,但是離我們追求的目標還是相差甚遠,所以亟需來一次更徹底的優化,來捍衛技術人員的尊嚴,畢竟我們都是頭頂別墅的人。

http500解決辦法(記一次k8s pod頻繁重啟的優化之旅)1.背景

頭頂撐不住的時候,吃點好的補補

上一次頻繁重啟是因為內存不足導致大量的oom異常,最終k8s健康檢查機制認為pod不健康觸發了重啟,優化手段就是加大jvm和pod的內存,這一次的重啟是因為什么呢?

前面說過k8s對http形式的健康檢查地址做探測時,如果響應的狀態碼大于等于 200 且小于 400,則診斷被認為是成功的,否則就認為失敗,這里其實忽略了一種極其普遍的情況“超時”,如果超時了也一并會歸為失敗。

為什么這里才引出超時呢,因為之前日志中有大量的報錯,很直觀的可以聯想到健康檢查一定失敗,反觀這次并沒有直接證據,逼迫著發揮想象力(其實后來知道通過kubectl describe pod是可以直接觀測到超時這種情況的)。

現在我們就去反推有哪些情況會造成超時:

1.cpu 100%,這個之前確實遇到過一次,是因為宿主機cpu 100%,造成大量pod停止響應,最終大面積重啟;

2.網絡層面出了問題,比如tcp隊列被打滿,導致請求得不到處理。

3.web容器比如tomcat、jetty的線程池飽和了,這時后來的任務會堆積在線程池的隊列中;

4.jvm卡頓了,比如讓開發聞風喪膽的fullgc+stw;

以上四種只是通過我的認知列舉的,水平有限,更多情況歡迎大家補充。

現在我們一一排除,揪出元兇

1.看了監控宿主機負載正常,cpu正常,所以排除宿主機的問題;

2.ss -lnt查看tcp隊列情況,并沒有堆積、溢出情況,排除網絡層面問題;

3.jstack查看線程情況,worker線程稍多但沒有到最大值,排除線程池滿的情況;

4.jstat gcutil查看gc情況,gc比較嚴重,老年代gc執行一次平均耗時1秒左右,持續時間50s到60s左右嫌疑非常大。

通過上面的排除法暫定是gc帶來的stw導致jvm卡頓,最終導致健康檢查超時,順著這個思路我們先優化一把看看效果。

開始之前先補一張gc耗時的截圖,為了查看的直觀性,此圖由arthas的dashboard產生。

http500解決辦法(記一次k8s pod頻繁重啟的優化之旅)1.背景

說實話我對gc是沒有什么調優經驗的,雖然看過比較多的文章,但是連紙上談兵都達不到,這次也是硬著頭皮進行一次“調參”,調優這件事真是不敢當。

具體怎么調參呢,通過上面gc耗時的分布,很直觀的拿到一個訊息,老年代的gc耗時有點長,而且次數比較頻繁,雖然圖里只有40次,但是相對于這個服務的啟動時間來講已經算頻繁了,所以目標就是降低老年代gc頻率。

從我了解的gc知識來看,老年代gc頻繁是由于對象過早晉升導致,本來應該等到age達到晉升閾值才晉升到老年代的,但是由于年輕代內存不足,所以提前晉升到了老年代,晉升率過高是導致老年代gc頻繁的主要原因,所以最終轉化為如何降低晉升率,有兩種辦法:

1.增大年輕代大小,對象在年輕代得到回收,只有生命周期長的對象才進入老年代,這樣老年代增速變慢,gc頻率也就降下來了;

2.優化程序,降低對象的生存時間,盡量在young gc階段回收對象。

由于我對這個服務并不是很熟悉,所以很自然的傾向于方法1“調整內存”,具體要怎么調整呢,這里借用一下美團技術博客中提到的一個公式來拋磚一下:

http500解決辦法(記一次k8s pod頻繁重啟的優化之旅)1.背景

圖片內容來源于https://tech.meituan.com/2017/12/29/jvm-optimize.html

結合之前的那張gc耗時圖可以知道這個服務活躍數據大小為750m,進而得出jvm內存各區域的配比如下:

年輕代:750m*1.5 = 1125m

老年代:750m*2.5 = 1875m

接下來通過調整過的jvm內存配比重新發布驗證效果,通過一段時間的觀察,老年代gc頻率很明顯降下來了,大部分對象在新生代被回收,整體stw時間減少,運行一個多月再沒有遇到自動重啟的情況,由此也驗證了我之前的猜測“因為持續的gc導致健康檢查超時,進而觸發重啟”。

至此,第二次優化告一段落。

6.第三次優化

第二次優化確實給我們帶來了一段時間的安寧,后續的一個多月宕機率的統計不至于啪啪打架構部的臉。

http500解決辦法(記一次k8s pod頻繁重啟的優化之旅)1.背景

剛安生幾天,這不又來活了

http500解決辦法(記一次k8s pod頻繁重啟的優化之旅)1.背景

有運維反饋某服務在北京客戶的私有化部署環境有重啟現象,頻率基本上在2天一次,接收到這個訊息以后我們立馬重視起來,先確定兩個事:

1.個例還是普遍現象-個例,只在這個客戶環境出現

2.會不會和前兩次優化的問題一樣,都是內存設置不合適導致的-不是,新服務,內存占用不高,gc也還好

結合前面的兩個推論**“個例”+“新服務,各項指標暫時正常“,**我懷疑會不會是給這個客戶新做的某個功能存在bug,因為目前使用頻率不高,所以積攢一段時間才把服務拖垮。帶著這個疑惑我采取了守株待兔的方式,shell寫一個定時任務,每5s輸出一下關鍵指標數據,定時任務如下:

#!/bin/bash whiletrue; do/bin/sleep 5 netstat -n | awk ''/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}''>> netstat.log ss -lnt >> ss.log jstack 1 >> jstack.log done

主要關注的指標有網絡情況、tcp隊列情況、線程棧情況。

就這樣,一天以后這個服務終于重啟了,我一一檢查netstat.log,ss.log,jstack.log這幾個文件,在jstack.log中問題原因剝繭抽絲般顯現出來,貼一段stack信息讓大家一睹為快:

"qtp1819038759-2508"#2508 prio=5 os_prio=0 tid=0x00005613a850c800 nid=0x4a39 waiting on condition [0x00007fe09ff25000]java.lang.Thread.State: WAITING (parking)atsun.misc.Unsafe.park(Native Method)-parking to wait for <0x00000007221fc9e8> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)atjava.util.concurrent.locks.LockSupport.park(LockSupport.java:175)atjava.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2044)atorg.apache.http.pool.AbstractConnPool.getPoolEntryBlocking(AbstractConnPool.java:393)atorg.apache.http.pool.AbstractConnPool.access$300(AbstractConnPool.java:70)atorg.apache.http.pool.AbstractConnPool$2.get(AbstractConnPool.java:253)-locked <0x00000007199cc158> (a org.apache.http.pool.AbstractConnPool$2)atorg.apache.http.pool.AbstractConnPool$2.get(AbstractConnPool.java:198)atorg.apache.http.impl.conn.PoolingHttpClientConnectionManager.leaseConnection(PoolingHttpClientConnectionManager.java:306)atorg.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:282)atorg.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:190)atorg.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186)atorg.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110)atorg.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185)atorg.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83)atcom.aliyun.oss.common.comm.DefaultServiceClient.sendRequestCore(DefaultServiceClient.java:125)atcom.aliyun.oss.common.comm.ServiceClient.sendRequestImpl(ServiceClient.java:123)atcom.aliyun.oss.common.comm.ServiceClient.sendRequest(ServiceClient.java:68)atcom.aliyun.oss.internal.OSSOperation.send(OSSOperation.java:94)atcom.aliyun.oss.internal.OSSOperation.doOperation(OSSOperation.java:149)atcom.aliyun.oss.internal.OSSOperation.doOperation(OSSOperation.java:113)atcom.aliyun.oss.internal.OSSObjectOperation.getObject(OSSObjectOperation.java:273)atcom.aliyun.oss.OSSClient.getObject(OSSClient.java:551)atcom.aliyun.oss.OSSClient.getObject(OSSClient.java:539)atxxx.OssFileUtil.downFile(OssFileUtil.java:212)

大量的線程hang在了 org.apache.http.impl.conn.PoolingHttpClientConnectionManager$1.get(PoolingHttpClientConnectionManager.java:282

這個是做什么的呢?這個正是HttpClient中的連接池滿了的跡象,線程在等待可用連接,最終導致jetty的線程被打滿,造成服務假死,自然是不能及時響應健康檢查,最終觸發k8s的重啟策略。

最終通過排查代碼發現是由于使用阿里云oss sdk不規范導致連接沒有按時歸還,久而久之就造成了連接池、線程池被占滿的情況,至于為什么只有北京客戶有這個問題是因為只有這一家配置了oss存儲,而且這個屬于新支持的功能,目前尚處于試點階段,所以短時間量不大,1到2天才出現一次重啟事故。

解決辦法很簡單,就是及時關閉ossObject,防止連接泄漏。

7.總結

通過前前后后一個多月的持續優化,服務的可用性又提高了一個臺階,于我而言收獲頗豐,對于jvm知識又回顧了一遍,也能結合以往知識進行簡單的調參,對于k8s這一黑盒,也不再那么陌生,學習了基本的概念和一些簡單的運維指令,最后還是要說一句“工程師對于自己寫的每一行代碼都要心生敬畏,否則可能就會給公司和客戶帶來資損”。

閱讀過此文章的讀者,還閱讀過下面的文章

  • 深圳網站制作好后來年到期了該怎么辦
    <p> 深圳網站制作好后來年到期了該怎么辦,不管是個人還是公司,要想制作好一個網站真的不容易,不僅僅需要做網站前期的規劃和策劃工作,還需要對網站建設的欄目,內容進行填充和建設,面對這一堆的要求和東西,整體還是比較麻煩和費事的,所以,網站建設制作好之后,一定要注意來年的續費問題,好多公司不注意這個問題,造成了網站后期打不開了,不能正常方面了,出現了問題才想起來網站沒有續費,接下來我們來看看深圳網絡公司是如何建議的。 </p> <p> 1.域名到期的影響<br /> &nbsp;一般情況下,網站域名需要一年進行一次續費,也可以一次購買多年,如果域名到期沒有及時續費,網站就會打不開,域名續費期一般是一個月,過了這個時間就會進入贖回期,這時候就不能續費了。<br /> &nbsp;2.服務器到期的影響<br /> &nbsp;服務器到期與域名一樣,到期后網站同樣不能打開,如果之前網站在做推廣,會直接影響展現效果,長時間不續費的話,網站數據就會全部刪除了,之前的努力就全白做了。<br /> &nbsp;3.網站維護服務到期<br /> &nbsp;有些網絡公司服務商會有網站維護費用,一般都是一年為一個期限,如果到期后您沒有及時維護,網站出現問題后就不會有人給您維護,就會造成影響。影響最大的就是網站展現的效果。<br /> </p>
  • 深圳做網站公司做網站時要明白這些
    <p> 深圳做網站公司做網站時要明白這些。其實做網站有的時候不僅僅是在做網站,更多的是在幫助其他公司在做網絡宣傳門戶,站在這個角度上你就知道你所承擔的責任了,作為現在公司網站建設不僅要符合時代潮流,更多的需要緊扣時代網頁設計特色和要求,只有這樣制作設計出來的網站才能更好的滿足現在人們的使用要求和觀念的,不管是在網站設計理念,網站布局規劃,以及網站內容建設等等,這些方面都需要進口時代主題和要求的,接下來我們來看看深圳網站制作公司是如何做的,需要做好那些方面的要求和規范呢? </p> <p> 審美在變,網站設計要緊跟潮流<br /> 也許用戶訪問時,不會逐一閱讀網站內容,但首先映入眼簾的一定是設計。也許網站在幾年前設計制作的確實很漂亮,但是我們無法否認的事實是,用戶對網站設計的審美一直在不斷改變。這個比較容易對比,隨便找一個行業,然后通過百度搜索到十家網站,分別對應年份和網站的網址,讓一個不知情的人去逐一打開并評判感受。大體趨勢是越是新近設計制作的網站,越容易贏得用戶的接受承認。其實這就是用戶的真實感受,每年快速改版重做對于很多公司來說有些壓力,但是筆者認為一般而言網站2-3年是需要重新設計制作快速的。一個通過網站尋找供應商的用戶,其瀏覽網站一般也就幾十秒到幾分鐘時間,先進的網站設計效果是吸引其深入了解進而咨詢的較好方法。<br /> 技術在變,網站制作要貼合需求<br /> 周圍的一切都在發生著巨變,網站技術也是如此,此前被很多網站公司采用的ASP網站開發語言幾乎已經沒人使用,相對于傳統的PC端網站,現在更多看重的是移動端,公司設計制作的網站現在多為自適應PC端、PAD端以及手持移動終端的響應式網站。誰也不知道網站技術會走向哪個方向,但是對于普通的企業而言,我們可以把握趨勢,至少每隔兩三年對網站重新快速設計制作。<br /> 企業在變,網站建設要適應發展<br /> 網站總是為企業服務的,換句話說就是網站的設計制作需要跟上企業的發展步伐。現在急劇變化的市場面前,如果想立于不敗之地,企業的經營策略一定在不斷調整優化。作為給企業發展提供服務的網站,其理應不斷調整不斷優化以適應公司需求。現在是互聯網時代,用戶了解公司更多的也是通過網絡,網站不僅是營銷的工具,更是企業品牌形象的展示窗口。由于人力成本的不斷升高,而網站設計更多的需要技術人員手工完成,所以真正定制開發的網站都價格不菲。但是同樣是網站建設公司網站改版也不一定就選擇定制,如果有合適的模板網站,也是不做的選擇。我們需要的是一個緊跟時代和用戶需求的網站,而非一定采用哪種方式實現它。 </p>
  • 英文網站制作需要注意那些問題和事項
    英文網站制作需要注意那些問題和事項。英文網站制作還是跟中文網站制作有比較大的區別的,應為中文網站面對的客戶群體是國內的用戶,而國內的用戶對網站的使用習慣,要求都是跟國外不一樣的,從而在制作英文網站的時候,一定要注意,像這種英文網站制作還是需要從國外人使用網站的習慣,使用網站的一些喜好出發,只有這樣制作出來的網站滿足國外人的使用的,這是一個方面,另外一個方面就是國外網站面對的搜索引擎,也是不一樣的,國外的搜索引擎跟國內有著比較大的區別的,搜索引擎也是制作英文網站必須要考慮的一個方面了,最后就是網站制作價格方面了,一般英文網站制作價格要比國內的網站制作價格高一些,這是一定的,畢竟國外網站制作的細節要求,以及針對搜索引擎優化方面還是有比較高的要求的,所以,這些都是工作量,也都是需要處理好這些方面的細節工作的。
  • 網站設計公司的發展趨勢詳解
    <p> 網站設計公司的發展趨勢詳解,目前網頁設計公司慢慢的轉型升級成為一種綜合性的設計公司了,不僅僅是在網站設計了,如果單純的依賴于網站設計,對于這樣的公司來說現在還是很被動的,并且目前的網站制作價格已經白熱化了,競爭也是很大的情況下,好多公司已經賺不到什么錢了,面對這樣的市場形式,作為網站設計公司要不斷的擴大和嘗試新的方式和方法,實現公司業務的升級和轉型,這也是擺在深圳<a href="http://www.szbc888.com" target="_blank"><strong>網站制作公司</strong></a>面對不可逾越的一個問題了,畢竟現在網站制作公司的活量不大,如果養一個專業的網頁設計技術團隊專門作網站,根本養活不了這樣的公司的發展了,更多的還需要通過其他的渠道,其他的平臺上獲得更為有質量的客戶,這也是當下網站制作公司不得不面對的一個話題了。 </p> <p> <img src="static/picture/20231030113846_47114.jpg" alt="" /> </p> <p> <a href="http://www.szbc888.com" target="_blank"><strong>網頁設計公司</strong></a>業務范圍擴大,于是著這個網站制作行業市場需求量在逐漸的縮小,并且凡是使用到網站的多半集中在一些公司,單位方面的需求了,對于一些個人對網站的需求還是很少的,除非一些專業化路線的個人才會這樣做的,網站設計公司的轉型升級,不僅提升的服務質量,更多的將服務方位不斷的擴大,從而得到更好的市場群體,能夠為更多的市場客戶服務。 </p>
  • 網站制作低價格策略已經成為網站制作行業的殺手锏
    <p> 網站制作低價格策略已經成為網站制作行業的殺手锏,整個大環境不好的情況下,好多公司在制作網站的時候,已經在想盡辦法降低網站制作的成本了,從當初的網站制作就直接去搜索引擎上搜索網站制作公司了,而如今制作網站已經發生變化了,從搜索引擎走向了淘寶,拼多多這些低價平臺了,并且這些平臺都是擔保交易了,好多的需要<a href="http://www.szbc888.com" target="_blank"><strong>制作公司網站</strong></a>的商家慢慢轉向這個方面來了,所以制作出來的網站不是模板的就是仿制的網站,價格的確很低,并且效率也是很高的,這也是聰明的用戶慢慢的轉型和變化了,如果這些模板網站放在搜索引擎來的客戶的話,這些網站制作下來的費用基本上在好幾千了,面對這樣的市場轉型和升級,這也讓好多網站制作公司尋找不同的出路了。 </p> <p> <img src="static/picture/20231030113212_16069.jpg" alt="" /> </p> <p> <a href="http://www.szbc888.com" target="_blank"><strong>深圳網站制作</strong></a>的價格的確沒有那么低,但是作為一些低價平臺上的用戶,他們為了爭取到客戶,低價引流,從而實現了低價格制作網站的形式,作為網站制作公司,你這樣低價格去做的目的就只有一個,那就是辛苦轉不到錢的,都是轉一些辛苦錢而已,面對這樣的市場形式和要求,作為網站制作公司一定要不斷的提升網站制作的附加值,提升<a href="http://www.szbc888.com" target="_blank"><strong>網站制作</strong></a>的質量,讓用戶以質量取勝,不能專門走低價格戰略,不然你的公司是發展不起來的,也作不大的,作為用戶而已,你公司小還可以這樣去做,如果公司發展到一定程度的去制作網站,這對于你的公司來說是滅頂之災了,所以選擇網站制作公司還是要從專業的角度出發去幫助客戶解決實際的問題,從而實現網站制作公司的價值和效益。 </p>
  • 深圳網站定制開發全流程詳解
    <p> 深圳網站定制開發全流程詳解,作為網站定制開發公司接下來給大家普及一下網站定制究竟要經過那些過程呢,前期的網站溝通肯定是少不了的,除此之外,網站備案這塊也是需要的,只要是正規的公司,正常的流程,網站備案也是需要做的,剩下的就是網站制作過程中的一些溝通了,接下來我們來看看<a href="http://www.szbc888.com" target="_blank"><strong>深圳網站制作</strong></a>公司的一個標準的流程。 </p> <p> 需求分析: 通過對客戶業務的了解和與客戶對流程的討論對需求進行基本建模,最終形成需求規格說明書<br /> 總體設計: 通過分析需求信息,對系統的外部條件及內部業務需求進行抽象建模,最終形成概要設計說明文檔<br /> 詳細設計: 此部分在對需求和概要設計的基礎上進行系統的詳細設計(也包含部分代碼說明)<br /> 開發編程: 對系統進行代碼編寫<br /> 測試分析與系統整合: 對所有功能模塊進行模擬數據測試及其它相關性測試并整合所有模塊功能<br /> 現場支持: 系統上線試運行進行現場問題記錄、解答<br /> 系統運行支持: 系統正式推產后,對系統進行必要的維護和BUG修改<br /> </p>

Copyright ? 2015 深圳市鑫惠廣網絡科技有限公司 粵ICP備2023111395號