Java互聯網架構-直播互動平臺高併發分佈式架構應用設計

概述

網頁HTML 靜態化： 其實你們都知道網頁靜態化,效率最高,消耗最小的就是純靜態化的 html 頁面,因此咱們儘量使咱們的網站上的頁面採用靜態頁面來實現,這個最簡單的方法其實也是最有效的方法，可是對於大量內容而且頻繁更新的網站,咱們沒法所有手動去挨個實現,因而出現了咱們常見的信息發佈系統 CMS,像咱們常訪問的各個門戶站點的新聞頻道,甚至他們的其餘頻道,都是經過信息發佈系統來管理和實現的,信息發佈系統能夠實現最簡單的信息錄入自動生成靜態頁面,還能具有頻道管理,權限管理,自動抓取等功能,對於一個大型網站來講,擁有一套高效,可管理的CMS 是必不可少的，除了門戶和信息發佈類型的網站,對於交互性要求很高的社區類型網站來講,儘量的靜態化也是提升 性能的必要手段,將社區內的帖子,文章進行實時的靜態化,有更新的時候再從新靜態化也是大量使用的策略,像Mop 的大雜燴就是使用了這樣的策略,網易社區等也是如此同時,html 靜態化也是某些緩存策略使用的手段,對於系統中頻繁使用數據庫查詢可是內容更新很小的 應用,能夠考慮使用 html 靜態化來實現,好比論壇中論壇的公用設置信息,這些信息目前的主流論壇都 能夠進行後臺管理而且存儲再數據庫中,這些信息其實大量被前臺程序調用,可是更新頻率很小,能夠 考慮將這部份內容進行後臺更新的時候進行靜態化,這樣避免了大量的數據庫訪問請求；

圖片服務器分離： 對Web 服務器來講,無論是 Apache,IIS 仍是其餘容器,圖片是最消耗資源的,因而咱們 有必要將圖片與頁面進行分離,這是基本上大型網站都會採用的策略,他們都有獨立的圖片服務器,甚至不少臺圖片服務器，這樣的架構能夠下降提供頁面訪問請求的服務器系統壓力,而且能夠保證系統不 會由於圖片問題而崩潰,在應用服務器和圖片服務器上,能夠進行不一樣的配置優化,好比 apache 在配置 ContentType 的時候能夠儘可能少支持,儘量少的 LoadModule,保證更高的系統消耗和執行效率；

數據庫集羣和庫表散列： 大型網站都有複雜的應用,這些應用必須使用數據庫,那麼在面對大量訪問的時候,數據庫的瓶頸很快就能顯現出來,這時一臺數據庫將很快沒法知足應用,因而咱們須要使用數據庫集羣或者庫表散列，在數據庫集羣方面, 不少數據庫都有本身的解決方案, Oracle, Sybase 等都有很好的方案,經常使用的 MySQL 提供的 Master/Slave 也是相似的方案,您使用了什麼樣的 DB,就參考相應的解決方案來實施便可，上面提到的數據庫集羣因爲在架構,成本,擴張性方面都會受到所採用 DB 類型的限制,因而咱們須要從 應用程序的角度來考慮改善系統架構,庫表散列是經常使用而且最有效的解決方案，咱們在應用程序中安裝 業務和應用或者功能模塊將數據庫進行分離,不一樣的模塊對應不一樣的數據庫或者表,再按照必定的策略 對某個頁面或者功能進行更小的數據庫散列,好比用戶表,按照用戶 ID 進行表散列,這樣就可以低成本 的提高系統的性能而且有很好的擴展性，sohu 的論壇就是採用了這樣的架構,將論壇的用戶,設置,帖 子等信息進行數據庫分離,而後對帖子,用戶按照板塊和 ID 進行散列數據庫和表,最終能夠在配置文件 中進行簡單的配置便能讓系統隨時增長一臺低成本的數據庫進來補充系統性能；

核心需求

先說一下這個核心需求爲何會出現。你們在看移動直播的時候，若是有人關注的話，會發現那些主播常常問的一句話就是「卡不卡，是否是又卡了，我要瘋了，又卡住了」。大家看點播的時候，看短視頻的時候，不會有人這麼問吧？不會說大家看短視頻，它又卡了，這種問題是最近纔出現的。真正的客戶都已經返回這種問題了，說明流媒體的門檻又變高了，因此他們對流媒體的需求是在增加的。那咱們就看一下這些需求都有哪些。

一、首先內容產生方就是推流端，如今主流的IOS、安卓，IOS比較簡單，就是那個幾個機型，基本你們適配都很好。可是安卓的碎片化是很是嚴重的，大量的精力都須要作對安卓的適配，並且軟編耗電量廣泛很是高，手機用了一會就會發燙，都擔憂會不會爆炸。用戶體驗就是在不一樣的網絡狀況下，上傳的視頻有可能會卡，有可能不連貫，報各類各樣的錯誤，這個是做爲一個開發者他本身不可能去適配的。說白了從用戶那邊提的需求就是推流端不能卡，畫質要好，不能太燙，這是咱們接觸到的客戶真正提的問題，是咱們從有點偏技術的角度抽取出來的，它背後對應的是哪些事情。

二、而後是分發網絡。分發網絡其實躲在一個很後面的地方，用戶其實看不見的。真正對分發網絡提需求用戶也提不出來，因此基本這部分需求都會提給播放端，提的需求也是不能卡，不能花屏，首屏必定要快，一點就要看到，還不能把延時弄的太大。其實這些不少都是和源站分發網絡有關係的，只是用戶看不到這個需求會跟後面的播放器接在一塊兒。

對這個需求咱們作一些抽象來講就是用戶的可觸達性要好，咱們的CDN節點要在全區域、全運營商有覆蓋，包括教育網。有不少人，像那些小運營商都會忽視教育網，咱們也遇到過這樣的例子，教育網確實很差接，由於節點不夠多，這其實不是什麼難點，只是一個坑，注意到了就能作到。低延時的操做大部分來自端的配合，服務端只要是作好緩存，保證這個數據是連貫的。若是要丟數據的話，把關鍵幀保留好，丟GOP中間那些PB幀，主要是在端上會收到。

首屏時間，就是用戶點開就要看，之前那些開源架構就是rtmp server，它是作不到一點開就能看的，如今一些開源的國內資源寫得也比較好了，能夠看到。咱們是本身開發的，因此也花了一些工做，能保存以前的關鍵幀的信息，用戶一點開就能看，這個就是很細節的東西了。若是這個作很差的話，會黑屏、綠屏，或者是半天看不着圖像。

三、在播放器這邊也是咱們在接業務的時候，遇到用戶投訴最多的，由於全部的問題都是在觀看的時候體現的，全部的雷都得是播放器的同窗去扛。這個需求也是不能卡，不能延遲過高。若是延遲高了，要追回來，追的時候聲音不能變，最好是追的策略也能本身控制，這是用戶真正提出來的需求。

對於咱們來講，要知足這些需求，咱們須要作好多分辨率的適配，保證好流暢性，保證好咱們追趕的策略不會出現任何異常。因此這三個端不少是相互耦合的，像推流和分發在一塊兒，要保障好用戶的流暢性和畫質，分發和播放器在一塊兒要保證好低延時和播放的流暢。全部的這些需求裏共同的一點就是不能卡，後面咱們在設計方案的時候，也是重點考慮怎麼能作到不卡。

解決方案

這個是咱們這邊的系統架構圖。最下層是依託金山的雲服務，由於咱們已經有了很好的平臺，提供了咱們計算資源，提供了存儲，提供了不少自建的節點，固然還不夠多，咱們仍是個融合CDN，而後提供了數據分析的能力。咱們依託它作了橙色的這一層，就是咱們本身的核心，流媒體直播，而後圍繞這個核心咱們再作的回看點播、在線轉碼、鑑權、內容審覈。

爲何要作回看點播？由於這不是一個短視頻錄播的項目，而是一個直播，直播就決定它的併發不會很高，內容不會不少，熱點比較少。若是你不回看的話，用戶很難維持它的日活，很難維護用戶黏度，因此用戶必定會要求作回看的。

爲何要作在線轉碼？推流端其實作了不少把更好的畫質想盡辦法傳上來的工做，投了不少人力來作。傳上來以後，觀看也在移動端，它不必定看得了。若是他看不了怎麼辦？咱們就須要在線轉，在線轉碼其實承擔的更多更重要的事情。

鑑權，用戶都不想被盜鏈，尤爲是推流的時候，若是我不鑑權，誰均可以來推，推個法lun功怎麼辦？這是必需要有的。內容審覈，如今咱們沒有辦法幫他作到自動審覈，技術還不夠。如今作到的是截圖，按用戶指定的時間按期截圖，這樣的話，用戶就能夠請一些外包來看是否是有敏感內容，是否是要下線，這個對於如今這種三四秒延遲的直播來講很是重要。你作不到的話，沒準政策因素你就作不下去了。

數據分析一部分是依託金山已有的，一部分是咱們本身作的，由於咱們延遲性，時效性要求更高。客戶會常常大半夜忽然提出一個主播看起來特別卡，問你爲何，要是像之前那種方式，一個小時生成報表，而後出體驗圖，告訴他爲何卡了，客戶可沒有這個耐心。

咱們如今基本能作到5秒間隔就出以前的各類問題定位，這個定位包括從源站收集的數據畫的曲線。還有從端上，若是端上用戶容許的話，推流和拉流端咱們都會有上報數據，幾個曲線一擬合，咱們就知道問題出在哪裏。因此如今不止是RD能夠來查這個問題，咱們不少售前都在承擔着幫用戶出這個圖的工做。

這個是介紹業務具體的流程圖，這個流程圖並無什麼特別，只是通常的流媒體的數據走向、各類請求。可是其中有一些坑我能夠跟你們重點說一下，首先看一下直播發起流程，這確定是由應用向本身的服務端去請求一個推流地址，這個推流地址他就用來向咱們的流媒體服務器推，而後咱們給它鑑權。

鑑權以後，它能夠在參數裏選擇是否是要錄像。若是須要錄像截圖，或者須要HLS的分發，咱們均可以幫他作，作完以後存到咱們的存儲裏，這也是後面會提到的，咱們各個業務之間在作隔離、分不一樣的優先級，這種後端的多媒體的處理儘可能都會依賴別的服務，而後就是正常的結束流程。

這個是實際中遇到的一個問題，如今作流媒體，用戶推流，他想知道這個流結沒結束，通常互聯網公司作雲服務都怎麼作？都是給回調，若是這個推流結束了，我來回調業務方，讓業務方知道我結束了，你能夠作你的邏輯了。

但實際操做中咱們遇到了問題，就是業務方的服務器沒那麼可靠，咱們可能過去時間特別久，有延時，有丟，或者他們的服務穩定性咱們也確認不了，這其實就是一個雙方的耦合了。並且它的服務器，因爲是咱們來調，它的鑑權功能沒有辦法作得很複雜，他本身的服務器也存在安全漏洞。若是有人來攻擊他的話，他的整個業務流程的狀態全是亂的。

在試了幾家客戶以後，咱們就改爲另一種方式，也是你們廣泛都接受的，就是由APP和本身的Server發心跳，若是APP的網絡不異常的話，它本身結束它的Server確定是知道的。若是異常的話心跳斷了，他也會判斷出是結束了的。並且咱們這邊源站服務也會保證，你5秒鐘沒有數據就必定是結束的了，咱們會把你的流給踢掉，這樣就能達到用戶的業務狀態也是穩定的，咱們的流媒體服務也是穩定的，並且耦合也會比較少。

這是咱們實際遇到的一個坑，這個其實不難，只是看如今廣泛雲服務提供商還都是在用回掉的方式，因此我特別提一下另外還有一種可選的方式，效果更好。

播放的流程，播放器會先向他本身的服務請求播放地址，而後來咱們這拉流，能夠是鑑權也能夠不鑑權，取決於它的業務形態。若是拉流失敗，咱們有一些定製化的操做，他用RTMP來拉流的話，咱們會告訴他具體是什麼錯，包括鑑權失效，鑑權參數錯誤，仍是這個流有問題，咱們都會在狀態告訴他的。這是以前用戶提到的需求，說是播放須要知道哪裏出了問題，因此咱們儘可能把狀態碼都特別詳細的返回給用戶。包括咱們原站也有查詢接口，若是他須要那種統一查詢也能夠來查。

一、推流端實現方案

這是推流端的實現，推流端設計的原則總結下來就是自適應，推流誰均可以作，開源的也不少。可是爲何有的作得好，有的作得很差呢？就是看自適應作的好很差。

總結下來有三點自適應，一個是幀率和碼率自適應，這是你們都能想到的。我推流，若是網絡卡了，我就降點幀率或者降一點碼率，把這個事情作好，把流能正常推上去，不要卡頓。也是這張圖裏畫到的，在發送網絡的時候，咱們作了一個QS模塊，咱們團隊除了作工程化的人以外，還會有四五個博士專門作算法的。

在這裏就有一些體現，咱們在碼率自適應的時候，是直接能夠回饋給編碼器的，讓編碼器動態調整本身的碼率，儘可能保證質量無損，傳出來的視頻碼率降低，視頻平滑。幀率的控制就比較簡單了，當咱們發現網絡卡頓了，咱們就會反饋給幀率控制模塊。

在採集的時候作一些丟棄的操做，目的就是把咱們發送的帶寬降下來。這個咱們是基於TCP作的，確定沒有UDP的效果好，UDP是咱們下一步的嘗試，如今尚未開始。由於UDP還涉及到源站的一些架構重構，咱們尚未來得及作，如今基於TCP的效果其實已經不錯了。後面除了這種簡單的自適應以外，咱們還加了一個算法類的，那個效果就會更明顯。

第二種自適應是軟硬自適應，這個很好理解，像硬件編碼的優勢就是手機不燙，缺點一大堆，用MediaRecorder的話，音視頻很難同步，用MediaCodec的話，版本兼容有問題，如今還不太好普及。用軟編的話碼率低，畫質好，除了CPU特別燙，別的都是優勢。

怎麼能把這兩個結合起來？咱們如今在作的一些策略性的東西，這個就是個體力活，就咱們在本身這邊來配置黑白名單，有一些Top50到Top100的高端機型咱們用人來測，性能沒有問題的話，咱們就上軟編。由於剛纔也聽到了軟編都是優勢，除了燙。

熱門機型有一些低端的，軟編受不了的就改爲硬編。由於硬編是體力工做，因此適配的機型確定是有限的，沒有誰敢保證可以全平臺、全機型適配硬編，因此下面的一些非熱門機型，咱們來不及適配就軟編。這樣作下來的話，基本能達到99%以上的適配率。在一些大用戶那邊已經驗證過了這個數據。

第三個自適應，算法自適應。咱們是真正的第一家可以把h.265作成商業化的公司。如今全部的都在提h.265，不知道你們對h.265了不瞭解，有沒有人據說過h.265能夠商業化在Web端無插件播放？咱們如今作到了在賽揚機器上能夠播30FPS的720P視頻，在瀏覽器上不用裝任何插件，這是咱們持續優化的結果。固然這個不適合移動的場景，是咱們在接另一個場景的時候用到的。

在移動端咱們作到了IOS手機720P編碼，作到15FPS，而後CPU不會打滿，多是50%到70%之間。以前數據是打滿一個核。這是由於咱們以前有不少作算法的團隊，最開始是作技術受權，後來想在一些產品上落地，移動直播實際上是h.265的一個很好的落地的場景，爲何這麼說呢？

推流端的任務是把更好的畫質推上來，網絡有限的狀況下，我怎麼能推上來更好的畫質？h.265相對h.264來講能把帶寬省掉30%。30%的概念是在視頻點播類的應用裏能省點錢，在初創應用來講根本就不在意，由於主播更貴，誰在意這樣30%的帶寬。

可是在移動推流就不同了，30%是從480P到720P的變化，就是你原本只能推480P上來的畫質，通過h.265這種編碼以後能推上來720P的，主播的需求就是網絡夠好，CPU夠好，我爲何不推更好的視頻上去呢？這就是h.265的一個場景，我用算法的優點，你的機器只要可以讓我作到用265來自適應，我就能夠推上去更好的畫質。

二、分發網絡-多集羣源站設計

分發網絡是躲在很遠的一個地方了，咱們當時設計的三個原則就是高併發、高可用、系統解耦，前兩個很虛了，只要是作系統都會想怎麼高併發，怎麼高可用，怎麼橫向擴展最容易。

咱們作了一個多源站，相對於不少公司在作單源站的方式，咱們就是爲了讓用戶能更好的觸達咱們的網絡。在各個集羣、各個城市作了多源站，如今不光是國內有幾個點，在香港和美國咱們也各作了一個點。這樣怎麼能作到橫向的擴容和數據與業務中心的隔離，是花了一些心思的。這種方案並非很難，用一些存儲作好同步其實也作到了。

高可用，就像DNS這種，保證服務單點的，高可用都能作到。怎麼作到系統解耦，由於傳統的CDN只是負責流媒體的分發，咱們相對於它的優點就是咱們除了作流媒體分發之外，還作了不少多媒體的功能，像截圖、錄像、轉碼、多分辨率適配這些東西，這些東西是會影響系統穩定性的。怎麼能在這裏作到真正的解耦，保證系統穩定是下了不少工夫的。

一些開源服務，也作多分辨率適配，可是它全部的轉碼調度都是由它的流媒體服務來調起的。包括轉碼的生命週期也是流媒體服務來控制的，他們都在同級部署。其實這是有很大問題的，多分辨率適配和原畫的推送和分發徹底不是一個優先級的服務。作系統定級的時候就應該把它們分離開，應該分離在不一樣的系統來作。

多集羣源站就是剛纔說到的，儘可能用三線機房，或者BPG機房，而後在各個城市南北都布點，儘可能的更近的觸達用戶，讓用戶推流更容易。同時咱們在每一個源站都部署了金山雲的存儲，KS3。

部存儲的目的也是爲了可以更好的保證用戶截圖和錄像的文件的可靠性，存下來以後咱們就無論了，交給KS3，固然KS3多媒體服務也是咱們維護的。作轉碼截圖，或者是轉分辨率合併一系列操做，是由另一套系統來作，咱們把這些多媒體的服務和源站的服務作了解耦。

在線轉碼是一個很是耗CPU的業務。一臺如今很高端配置的24核機器，若是我想轉一些畫質比較好的視頻，每一個視頻轉三個分辨率，這樣我轉八路就把它打滿了，這是很耗CPU的。若是我轉了沒人看，這個CPU就在那耗着，並且這個是不適合和源站混部的一個服務。

轉碼要和數據離的近，在那個源站集羣的同一機房，咱們會申請一些轉碼的資源，而後由核心機房來統一調度。咱們把調度和具體的功能分離開，根據你這個流推到哪，咱們就就近在哪裏轉碼。轉碼也加了一些實時轉碼的策略。

爲何要作在線轉碼？由於推流端已是盡最大努力把最好的畫質、最高的帶寬傳上來。可是播放端不必定看得了，這樣咱們就須要把它轉出來，並且h.265雖然好，可是有個最大的問題就是在移動端的瀏覽器上沒有辦法播。分享出來的必須是h.264，要否則去微信或者是QQ瀏覽器，你是看不了的。

就是若是我用了很高深的技術手段，把你的h.265的視頻推上來了，畫質很好。但不在咱們端上就看不了，你要想分享的話，咱們能夠幫你轉出一份h.264的來分享。轉碼是一個高CPU佔用的場景，若是我不對CPU作合理的分配的話，很快個人機器資源就會被打滿。

咱們作了兩種策略，一種是有限的機器合理調度。咱們的轉碼系統是個分佈式，流水線式的，相似Storm那種系統，可是咱們本身作得更適合轉碼。任務進來以後，咱們第一個流程不是轉，而是分析，看看你是要轉成什麼樣，你是什麼畫質，大概會用什麼CPU。

若是你的CPU佔用不少，我會認爲這是一個很難再次被調度的服務，好比你一下進來一個佔四個核的轉碼服務，後來再來一堆佔一個核的，確定是一個核的比較好調度，這個機器資源緊張了，我能夠給你調度另一臺機器，或者另一臺機器原本就有些空餘，如今剩三個核，我接不了四個核的，我只能先接一個核的，因此咱們會按優先級，優先分配高CPU佔用的任務，而後纔是低CPU佔用的任務，在流式系統裏，會在預分析以後把不一樣的任務扔進不一樣的優先級隊列，這個優先級隊列就承擔着去轉不一樣分辨率視頻的職能。

並且在後頭若是須要降級容災的話，也是靠這個優先級隊列來解決的，每一個用戶會有配額。我剛纔說24和準24路，其實對於一個雲服務公司來講這個量過小了。像我以前在百度作媒體雲的時候，天天轉碼量是有30萬，我以爲一個業務作大了，一天30萬的轉碼量是很正常的。

這是考驗併發的一個項目，怎麼能作到儘可能的把CPU打平，由於波峯波谷很明顯。像h.265這個場景，咱們是作了一套實時轉碼，有人分享就馬上給你轉，讓用戶一旦開始分享的時候，能達到秒開的做用。可是你不看的時候，咱們會有策略儘快幫你停下來。由於這種分享出去的視頻並非一個高併發的業務，有人看咱們纔給他轉是個比較合理的場景。

對於那些低分辨率的如今也在逐步上灰度，不是說全部的你分發了，你發起了，我都給你轉，咱們會逐漸判斷，有人看咱們才轉，儘可能節省系統資源。後面也會考慮存儲資源，由於每一個機房都會有存儲，存儲是徹底不用CPU的，它保證的是磁盤和IO，和咱們徹底是資源不復用的，是能夠混部的，後面咱們會考慮一步一步的混部。

CDN的分發環節，分發環節其實有不少東西是須要播放來配合的，好比說如今推流爲了保證畫質好，我會增長B幀，加大GOP，這樣編碼出來的視頻質量會變好，代價就是我增長了GOP，那個人延遲就會大，用戶必定是從上一個關鍵幀開始看，這樣他看到的可能就是5秒甚至是10秒以前的視頻，這個對社交類的移動直播是不可忍受的。既然有這種需求，源站就須要把以前的都保存好。可是怎麼能讓延時被消化掉，就要靠播放端。

三、播放器端實現方案

這是播放端的實現框圖，中間少畫了一個地方。這就是個傳統的播放器框圖，沒有體現出咱們的核心的技術點，數據從網絡接收進來以後，通過RTMP的Demux以後，咱們是有一個模塊的，這個模塊會去判斷當前視頻是否須要被丟棄，這個原則也和咱們接收緩存有關係，咱們緩存配的是兩秒，若是超過兩秒，或者超過某一個其餘的閾值的話，咱們會開啓丟棄的模式。

這個丟棄有多種策略，有的是直接丟掉幀，有的是快進。若是作過播放器就會知道，傳統的視頻追趕通常都是在視頻解碼以後來作追趕。解碼就意味着會耗CPU，尤爲是如今若是我想播720的視頻，光是解碼就基本上勉強實時的話，根本就沒有什麼追趕的餘地了。

因此咱們在算法上作了一些優化，咱們拿到這個視頻的時候會先去判斷它是否是一個能夠丟的，若是它是能夠丟的，在解碼以前咱們就丟，可是這樣丟會出問題，由於解碼器會內部不連續，一旦解碼器內部不連續了，它可能會產生黑屏，因此咱們即便要丟，也是在解碼器裏邊作了一些定製化的開發，仍是把要丟的視頻傳進去，讓它本身來丟，它不去解，這樣就能達到更快速的把這個視頻丟掉，遇上如今的實際主播的進度。

這樣的話，若是咱們網絡情況很好，不擔憂之後抖動的話，咱們能作到從推流到觀看是2秒的延遲，可是通常咱們都控制在4秒，就是爲了防止抖動產生。

剛纔說的是丟的這種邏輯，若是想快進，相似鬥魚那種，在一點進去以後，開始畫面是很快過去的，可是沒有音頻，咱們如今在作有音頻的方式，視頻在快進，音頻也在快進，這樣的話聲音會變調，由於採樣率變了。之前在作端的經驗的時候，也作過這種變速不變調的算法，不少開源的，改改其實效果都能不錯，這種算法只要作好逆向優化，放進來以後，音頻也能保證不變調。

日誌收集，可能日誌收集不是全部的開發者都願意接受的，可是有的開發者是逼着咱們要咱們作，由於他們須要這個數據來定位問題，就像我剛纔說的，常常有人會問，是否是又卡了，這個問題被問多了以後，你們都但願知道爲何卡，端上的日誌不收集上來是沒有辦法定位出這個問題的。咱們如今有日誌收集的策略在用戶贊成的狀況下，會按期可能幾百條打成一個ZIP包發上來，這個數據是咱們和用戶共享的。

總結

到這裏，直播互動平臺高併發分佈式架構應用設計就結束了，，不足之處還望你們多多包涵！！以爲收穫的話能夠點個關注收藏轉發一波喔，謝謝大佬們支持。（吹一波，233~~）

下面和你們交流幾點編程的經驗：

一、多寫多敲代碼，好的代碼與紮實的基礎知識必定是實踐出來的

2丶 測試、測試再測試，若是你不完全測試本身的代碼，那恐怕你開發的就不僅是代碼，可能還會聲名狼藉。

3丶 簡化編程，加快速度，代碼風騷，在你完成編碼後，應回頭而且優化它。從長遠來看，這裏或那裏一些的改進，會讓後來的支持人員更加輕鬆。

最後，每一位讀到這裏的網友，感謝大家能耐心地看完。但願在成爲一名更優秀的Java程序員的道路上，咱們能夠一塊兒學習、一塊兒進步。