聲明：本系列文章只提供交流與學習使用。文章中所有涉及到?？低曉O備的SDK均可在?？低暪俜骄W站下載得到。文章中所有除官方SDK意外的代碼均可隨意使用，任何涉及到?？低暪纠娴姆钦Ｊ褂糜墒褂谜咦约贺撠煟c本人無關。

題外話：

為什么在開始之前先說題外話呢？主要是為了怕有人誤會，以為這里要寫的是一個關于視頻流處理的文章。其實這個系列的幾篇文章可能和視頻流的處理半毛錢關系都沒有，沖著視頻技術來的看官們，可能讓你們失望了。這個系列里主要涉及的技術大概有.net的socket處理，C#寫ActiveX插件，少量的線程處理，以及對非托管C++庫的調用。

另一方面，這個系列文章說的是一個綜合的小項目，沒有復雜的功能，沒有嚴謹?shù)捻椖抗芾磉^程，但卻有一個技術探索的一般過程。好了，題外話到此結束，下面是正題了。

需求描述：

前一段時間公司兄弟部門提出需求，希望能夠把公司部分公共區(qū)域的監(jiān)控視頻共享出來給員工查看，這個事情最后落地到鄙人身上。經過多方聯(lián)系，了解到需求實現(xiàn)的兩個制約條件。

網絡條件：員工使用網段與監(jiān)控設備所在網段為不同網段，之間有物理隔離，無法直接訪問。這個問題比較容易解決，遷移一下設備所在的網段就能解決。
設備限制：?？档谋O(jiān)控攝像頭最多只支持6個客戶端同時連接，無法滿足現(xiàn)有需求。這個比較難搞，聯(lián)系廠商，廠家說不提供這一塊的服務，需要自己解決。這態(tài)度，我就呵呵了。

方案思路：

現(xiàn)狀就是這樣，沒有其他辦法，只能開發(fā)來解決這些問題了。其實想想問題也沒多麻煩，數(shù)據(jù)只要采集到服務器上一切就搞定容易了。沿著這條初步思路，在海康官網下了一堆SDK，你還別說，東西挺全的，什么方法都提供現(xiàn)成的了。什么視頻采集、設備設置、視頻播放這些都有現(xiàn)成的接口可以直接使用。更讓我驚喜的是，SDK里居然還提供C#和Java版本的DEMO，好吧，看到這些前面聯(lián)系客服碰的釘子就不放心上了，可能客服MM那天失戀了，心情不好也說不定。

說回正題，既然有這些給力的SDK就該搭建一個原型來驗證把視頻數(shù)據(jù)通過服務端接到客戶端這種思路是否正確，具體實現(xiàn)下一篇會細說，這里就長話短說，原型驗證成功。說明思路很正確，下一步就是具體的開發(fā)工作了，在原型基礎上一步步的重構，最后一個從視頻設備讀取視頻數(shù)據(jù)轉發(fā)給客戶端的系統(tǒng)就搞定了。

經過進一步壓力測試以后發(fā)現(xiàn)有性能不能滿足需求，需求要求能夠滿足公司近千人的使用，并發(fā)要求很高，并且視頻服務器要求必須及時處理所有數(shù)據(jù)到客戶端的轉發(fā)，否則客戶端將出現(xiàn)跳幀，卡頓的問題。解決壓力問題從兩個方面著手：

進一步重構優(yōu)化現(xiàn)有代碼，提高性能。
設計分布部署。

最后的最后上線的系統(tǒng)，部署方案如圖所示：

從操作數(shù)據(jù)流方面整個序列圖如下：

從兩個圖中很清楚的能夠看出這個系統(tǒng)的設計思路，

視頻中轉服務器不斷從設備將視頻數(shù)據(jù)讀入本地；
客戶端打開訪問頁面時先從Web服務器獲取到視頻服務器的地址；
客戶端插件直接連接視頻服務器，讀取視頻數(shù)據(jù)解碼顯示。

當然從圖中也很容易發(fā)現(xiàn)系統(tǒng)的不足之處。

系統(tǒng)沒有對各視頻中轉服務器狀態(tài)進行跟蹤，可能分配給客戶端一個異常的節(jié)點；
由于視頻中轉服務器之間無法通訊并且不存在管理節(jié)點，所以無法做負載均衡；
視頻當中轉服務器節(jié)點書超過監(jiān)控設備最大連接數(shù)時，無法進一步擴容。

關于系統(tǒng)的不足之處，是下一個階段處理的問題，在這個系列里不會處理。但是非常歡迎各位大仙大神討論。。。這里就不多說了。

最后，細心的讀者一定已經發(fā)現(xiàn)前面段落中出現(xiàn)的橙色標記的關鍵字。

初步思路
搭建一個原型
原型驗證
重構
測試
進一步重構
循環(huán)5、6直到系統(tǒng)上線但不截止上線為止。。。

一個簡單方法論的實踐過程。希望對大家有用。

亂七八糟的寫了一堆，實在是想寫的點太多，寫的時候覺得這個重要，那個也重要，最后貌似什么也沒寫，讓大家見笑了。下一篇應該是要寫服務端的功能設計及實現(xiàn)，希望有需求的人多關注。

總結

以上是生活随笔為你收集整理的海康威视频监控设备Web查看系统（一）：概要篇的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。