如何開發伺服器器

㈠ 雲伺服器是通過什麼軟體開發的

雲伺服器雲計算計算具體來說又運用了許多技術方案，比如虛擬化技術、分布式存儲、數據管理技術、編程模型、雲計算平台管理、能耗管理技術等。

虛擬化技術

虛擬化是雲計算最重要的核心技術之一，它為雲計算服務提供基礎架構層面的支撐。從技術上講，虛擬化是一種在軟體中模擬計算機硬體，以虛擬資源為用戶提供服務的計算形式。旨在合理調配計算機資源，使其更高效地提供服務。

它把應用系統各硬體間的物理劃分打破，從而實現架構的動態化，實現物理資源的集中管理和使用。虛擬化的最大好處是，增強系統的彈性和靈活性，降低成本、改進服務、提高伺服器資源利用效率。

分布式數據存儲

為保證高可用性、高可靠性和經濟性，雲計算伺服器採用分布式存儲的方式來存儲數據，採用冗餘存儲的方式來保證存儲數據的可靠性，即為同一份數據存儲多個副本。由於雲計算系統需要同時滿足大量用戶的需求，並為大量用戶提供服務，因此，雲計算的數據存儲技術必須具有高吞吐率和高傳輸率的特點。

分布式網路存儲系統採用可擴展的系統結構，利用多台存儲伺服器分擔存儲負荷，利用位置伺服器定位存儲信息，它不但提高了雲主機系統的可靠性、可用性和存取效率，還易於擴展。

數據管理技術

處理海量數據是雲計算的一大優勢。由於雲計算需要對海量的分布式數據進行處理、分析，因此，數據管理技術必需能夠高效的管理大量數據。

㈡ asp怎麼開發web伺服器

你是要配置asp環境嗎？

㈢ 如何自己開發一套伺服器管理系統

轉載 表面上看，是一套基於B/S方式實現的分布式管理系統，但其實背後的架構是基於C/S完成的。你以為他是一隻鞋嗎？其實他是一個吹風機。作為界面化的系統，瀏覽器框架是不可或缺的，但更加重要的東西在Socket上面。

一、需要解決中央控制端到各節點伺服器之間的通信。
這個其實牽扯到一個通信協議的問題，各語言都有自己的socket，thread的庫，直接調用即可。但是這個通信協議就需要自己來完成了。既不能太簡單，太簡單了，明碼傳輸，如果別人獲知了這個介面，就很容易執行一些令人討厭的操作。也不能太復雜，太復雜了等於是給自己找麻煩，所以簡單的數據包編解碼的工作或者用token驗證的方式是需要的。通信協議起碼要兩種，一種是傳輸命令執行的協議，一種是傳輸文件的協議。

二、跨語言的socket通信
為什麼要跨語言，主控端和代理端通信，用什麼語言開發其實無所謂。但是為了給自己省事，盡可能使用伺服器上已經有了的默認語言，Ambari前期採用php+puppet的方式管理集群，這不是不可以，puppet自己解決了socket通信協議和文件傳輸的問題，可你需要為了puppet在每台伺服器上都安裝ruby。我是個有點伺服器和代碼潔癖的人。光是為了一個puppet就裝個ruby，我覺得心裡特對不起伺服器的資源。所以我自己寫了一個python的代理端。python是不管哪個linux系統在安裝的時候就都會有了。然後主控端的通信，可以用python實現，也可以用php實現，但是考慮到對於更多的使用者來說，改php可能要比改tornado簡單許多，所以就沒用python開發。hadoop分支版本眾多，發布出去，用戶要自己修改成安裝適合自己的hadoop發行版，就勢必要改源碼，會php的明顯比會python的多。php裡面的model封裝了所有的操作，而python只是個操作代理人的角色而已。

所以也延伸出一個問題，什麼語言用來做這種分布式管理系統的代理端比較合適，我自己覺得，也就是python比較合適了，操作系統自帶，原生的package功能基本夠用。用java和php也可以寫agent，但是你勢必在各節點預先就鋪設好jre或者php運行環境。這就跟為什麼用python和java寫mapred的人最多是一樣的。沒人攔著你用nodejs寫mapred，也可以寫，就是你得在每個節點都裝v8的解釋引擎，不嫌麻煩完全可以這樣干。原理參看map/rece論文，不解釋。perl也是操作系統原生帶的，但是perl的可維護性太差了，還是算了吧。

所以這就牽扯到一個跨語言的socket問題，理論上來說，這不存在什麼問題。但這是理論上的，實際開發過程中確實存在問題，比如socket長連接，通信數據包在底層的封裝方式不同。我沒有使用xml-rpc的原因之一就是我聽說php的xmlrpc跟其他語言的xmlrpc有不同的地方，需要修改才能用,我就沒有用這種辦法。最早是自己定義的操作協議，這時就遇到了這些問題，所以後來直接採用了thrift方式。就基本不存在跨語言的socket通信問題了。

三、代理端執行結果的獲取
無論命令還是文件是否在代理端執行成功，都需要獲取到執行結果返回給中央端。所以這里也涉及一個讀取節點上的stdout和stderr的問題。這個總體來說不是很難，都有現成的包。當然這個時候你需要的是阻塞執行，而不能搞非同步回調。
還有個問題是，我要盡可能使用python默認就帶的包，而盡量不讓伺服器去訪問internet下載第三方的包。

還有代理端最重要的一點，就是python的版本兼容性。centos5用python 2.4，centos6用python 2.6，ubuntu基本默認都是2.7。所以一定要最大限度的保證語言的跨版本兼容性，要是每個操作系統和每一個版本我都寫一個代理，我一個人就累死了。

四、瀏覽器端的model，view，controller
這裡面你要封裝好所有的通信協議，以及需要在節點上面執行的腳本。發送文件的操作和資料庫操作也要在model裡面完成。
如果對tcl/tk很熟，也可以寫基於操作系統界面方式的管理，不用瀏覽器就是了。
view對我來說是最痛苦的事，都是現學的jQuery怎麼用，前端的工作太可怕了。關於這方面，沒有太多可描述的，html和js帶給我的只有痛苦的回憶，萬惡的undefined。

五、跨操作系統的安裝文件封裝。
要適應不同的操作系統也是個很麻煩的事情，需要用agent提前獲知操作系統的發行分支，版本號。然後去找到對應的安裝文件去執行。你不能保證一個分布式系統的集群中所有的節點都可以訪問internet，更多的情況是這些節點都存在在一個安全的內網中。只有個別幾個節點是可以訪問外網的。所以，我勢必要把所有的安裝文件以及他們的依賴盡可能集中起來。我不確定安裝操作系統的lzo，yum或者apt-get會去下什麼鬼東西，甚至無論是yum還是apt-get，裡面都沒有hadoop-lzo的庫文件。所以，最好的辦法是自己編譯打包rpm和deb包。直接安裝就好了，別去找repo下載什麼。

這就是第五步工作，把需要的依賴的東西自己編譯打包成rpm和deb。

deb包很好解決，但是rpm就沒那麼好辦了，需要學習rpm的編譯文件如何編寫，這塊是挺麻煩的，但是這玩意用好了還是挺不錯的。現在我自製的安裝包裡面就已經包含了自己編譯的lzo和snappy兩種壓縮庫，以及hadoop-gpl-packaging的rpm和deb。下一個發布的easyhadoop將直接支持centos5,6，suse，以及ubuntu/debian的系統上安裝hadoop。已經自帶了lzo和snappy以及lzop和snzip。

六、把這些所有東西，整合到一個系統裡面。

關聯這些所有事情間的聯系，整合到一個瀏覽器界面裡面去。寫一個分布式的管理腳本不難，寫一個界面也不難，但是也許是我的水平不行，這兩件事結合起來讓他們協同工作還是有點難度的。對我來說，寫界面的工作可能更難一點。

Cloudera可能是十來個人在寫Manager的東西，ambari也是放到github和apache svn上面，apache基金會的各種committer在寫。easyhadoop沒他們功能那麼強大，一年來只有我一個人設計架構，功能，各種語言的編碼，測試，發布。For the love of god, What have I done(英文部分請站在山頂仰天長嘯)? T_T。從前台到後台，到hadoop和生態系統以及他們的依賴軟體的單獨patch、編譯打包。(系統yum或者apt-get的包不如自己打的好使。)

從時間上來看，全球第一款開源的hadoop部署管理系統應該還是屬於ambari，2011年8月開始寫的，2012年9月底進入apache的incubator。我是大概2012年8月開始寫的easyhadoop，全球第一沒趕上，估計國內第一個開源的hadoop管理系統還是可以排上的。

㈣ 如何一步步學習開發伺服器

因為題目中提到了Nginx和Tengine，所以這里假設是Linux下面的HTTP伺服器的開發。
HTTP伺服器開發是個漫長的體力活，如果真的想做下去，必須要有強烈的興趣支撐。但是除此之外，HTTP伺服器開發並沒有什麼特別高深的演算法在裡面，好好努力的話，做出來自己的HTTP伺服器也並不是一件太難的事。
需要准備的有：
扎實 的C語言編程基礎。相信到了大三的時候，你已經有了幾年的變成經驗，但是對於開發HTTP伺服器來說，還是遠遠不夠。課本中會給你C語言的一個大概講解，但是在現實世界中，還是會有很多課本中覆蓋不到的地方。因為你已經在閱讀Nginx的代碼了，所以建議你首先檢查一下代碼中是否有不認識的C語言語法和用法。如果有，那麼就自己Google學習一下。如果沒有，那麼說明你的C語言學的足夠好，不存在語言層面上的問題。接下來，非常推薦學習一下這本經典的The Practice of Programming。學校里學習到的知識太書本化，代碼又太專業，不好懂。這本書能幫你在兩者之間找一個平衡，讀了之後就會知道很多地方為什麼要這么做。
C語言准備的差不多了之後，可以開始准備網路編程的知識。Unix Network Programming的確是本好書，但是問題在於，它太厚了。對於初學者來說，它提供的東西太多了。從實用的角度，我更推薦Beej』s Guide to Network Programming，不太長，但是涵蓋了網路編程的基本上所有常用的內容。全部讀完也不過幾個小時的時間。UNP可以用來在修煉的差不多了之後用來做參考書。或者用來學習網路編程中具體某個細節的知識。
接下來，因為是要寫HTTP伺服器，所以對HTTP協議需要有很深入的了解。當然最權威的資料就是一系列的RFC，比如HTTP 1.1的hwww ietf.org/rfc/rfc2616.txt。這時候就到了最開始講的體力活的地方。不斷的仔細閱讀RFC，然後把它講到的內容全部用代碼實現一遍。當然，也有偷懶的辦法，直接使用現有的HTTP解析庫，比如h2o/picohttpparser · GitHub。
另外，關於Nginx的架構設計，Andrew Alexeev在 The Architecture of Open Source Applications (Volume 2): nginx裡面講的很清楚。這個會對你讀代碼有很大的幫助。

㈤ linux伺服器開發需要哪些知識'

[開發前准備]
在進行linux伺服器開發之前，必須很清楚地了解所開發的對象需要考慮的相關問題
比如：
功能架構：提供服務的模塊體系結構
穩定性：伺服器的出core率，內存泄露情況
性能：請求與返回的速度與正確性
負載能力：能同時訪問的最大數量和頻度
根據不同伺服器對象的環境和應用，伺服器開發的對應手段相差甚遠。比如就客戶端連接時間較短卻又比較頻繁的伺服器（例如HTTP伺服器）而言，
在可選的伺服器結構中，預先派生進/線程的結構就要比並發式結構高效
總之，在開發伺服器之前，必須進行完整的伺服器開發需求分析，否則一旦你的伺服器開發完成而因為效率或者其他某項事物不能滿足你的客戶，那麼很有可能失敗！
[伺服器讓我明白了這件事情]
伺服器一般在後台運行，與客戶端的交互通過請求和返回兩種方式進行通信。
以epoll為例，一個epoll開發的伺服器程序，等待著一百萬的客戶端用戶的請求，輪詢觀察某個時刻是否有客戶端發來的請求；排隊依次處理發來的請求，並將結果返回給
客戶端應用程序。
涉及到幾個技術問題：
第一，客戶端訪問進入epoll輪詢隊列的優先順序是否需要控制。比如甲是我們的vip白金用戶，那麼，我始終先處理甲發來的請求，不然白金用戶要生氣的。
第二，極大可能程度上優化處理請求的速度，這是伺服器設計的核心業務。
第三，如果客戶端請求了這樣一個事情：我需要看這一百年來某企業所有的信息，那麼我想這個信息量是很大的，也就是現在很熱門的大數據大文件傳輸問題，如何快速
將服務端的這些結果傳給客戶端，在帶寬允許的情況下當然越快越好！這里會有很多處理措施，當然你可以打成一個包直接扔過去，但是這樣是愚蠢的，像蝸牛背著一個
重殼在挪動，用戶可等不了這么久；聰明的做法當然很多，根據你的實際需要，比如，你可以壓縮，你可以分批，等等。
等等，其實伺服器的整個開發，每個細節都決定了你的伺服器的成敗優劣。在開發linux伺服器的項目後，我個人決定，一個讓你的伺服器變得強大的很重要的因素是——
——你不願意放棄任何一個可以挺高性能的因素，即使是快0.01ms或者少傳1bt的數據！
[流行的伺服器模型]
1 PPC/TPC 模型
這兩種模型思想類似，就是讓每一個到來的連接一邊自己做事去，別再來煩我 。只是 PPC 是為它開了一個進程，而 TPC 開了一個線程。可是別煩我是有代價的，
它要時間和空間啊，連接多了之後，那麼多的進程 / 線程切換，這開銷就上來了；因此這類模型能接受的最大連接數都不會高，一般在幾百個左右。
2 select 模型
2.1. 最大並發數限制，因為一個進程所打開的 FD （文件描述符）是有限制的 由 FD_SETSIZE 設置，默認值是 1024/2048 ，因此 Select 模型的最大並發數就被相應限制了。
自己改改這個 FD_SETSIZE ？想法雖好，可是先看看下面吧 …
2.2. 效率問題， select 每次調用都會線性掃描全部的 FD 集合，這樣效率就會呈現線性下降，把 FD_SETSIZE 改大的後果就是，大家都慢慢來，什麼？都超時了？？！！
2.3. 內核 / 用戶空間 內存拷貝問題，如何讓內核把 FD 消息通知給用戶空間呢？在這個問題上 select 採取了內存拷貝方法。
3 poll 模型
基本上效率和 select 是相同的， select 缺點的 2 和 3 它都沒有改掉。
4 Epoll 模型
把其他模型逐個批判了一下，再來看看 Epoll 的改進之處吧，其實把 select 的缺點反過來那就是 Epoll 的優點了。
3.1. Epoll 沒有最大並發連接的限制，上限是最大可以打開文件的數目，這個數字一般遠大於 2048, 一般來說這個數目和系統內存關系很大 ，
具體數目可以 cat /proc/sys/fs/file-max 察看。
3.2. 效率提升， Epoll 最大的優點就在於它只管你「活躍」的連接 ，而跟連接總數無關，因此在實際的網路環境中， Epoll 的效率就會遠遠高於 select 和 poll 。
3.3. 內存拷貝， Epoll 在這點上使用了「共享內存 」，這個內存拷貝也省略了。
等等。
在開發你的伺服器之前，應根據自己的業務需求和實際情況，恰當地選擇伺服器的模型，這對這個伺服器的功能效率都是具有很重要的意義的

㈥ 自己如何搭建伺服器。

1、打開控制面板，選擇並進入「程序」，雙擊「打開或關閉Windows服務」，在彈出的窗口中選擇「Internet信息服務」下面所有地選項，點擊確定後，開始更新服務。

(6)如何開發伺服器器擴展閱讀：

入門級伺服器所連的終端比較有限（通常為20台左右），況且在穩定性、可擴展性以及容錯冗餘性能較差，僅適用於沒有大型資料庫數據交換、日常工作網路流量不大，無需長期不間斷開機的小型企業。

不過要說明的一點就是目前有的比較大型的伺服器開發、生產廠商在後面我們要講的企業級伺服器中也劃分出幾個檔次，其中最低檔的一個企業級伺服器檔次就是稱之為"入門級企業級伺服器"，這里所講的入門級並不是與我們上面所講的"入門級"具有相同的含義，不過這種劃分的還是比較少。

還有一點就是，這種伺服器一般採用Intel的專用伺服器CPU晶元，是基於Intel架構（俗稱"IA結構"）的，當然這並不是一種硬性的標准規定，而是由於伺服器的應用層次需要和價位的限制。