一個運維工程師對網(wǎng)站制作的看法

2010-01-03 企業(yè)官網(wǎng)建設(shè)專題

杭州網(wǎng)站建設(shè)照片中的人物是杰夫德恩、谷歌分布式系統(tǒng)的靈魂人物，具體內(nèi)容都可以在谷歌看到。他的許多分布式系統(tǒng)設(shè)計思想影響著技術(shù)趨勢。用谷歌實現(xiàn)具體工作，領(lǐng)導未來。

由于目前網(wǎng)絡(luò)上有很多類似的文章，該文僅僅記述了LNMP(LVS+NGINX+MYSQL+PHP )結(jié)構(gòu)的個人看法，對于共同的做法，如運動分離、讀寫分離、cache為王、CDN等大型分布式系統(tǒng)的做法、靈活性、過載保護、動態(tài)運行等介紹其他個人經(jīng)驗

一)簡化體系結(jié)構(gòu)的原則。一定要保證框架的簡化，在不引入多馀節(jié)點的情況下，盡量不引入多馀節(jié)點，保證框架的極度簡化。如果將體系結(jié)構(gòu)拓撲圖拆分為單個點和線，則必須基于java容器、jetty、resin和tomcat等標準來選擇點。只能選擇一個。在線定義是客戶端如何實現(xiàn)對后端服務(wù)的調(diào)用、使用命名服務(wù)使用DNS的方案以及使用LVS和haproxy的方案。事實上，更好的方法是使用客戶端API為小型系統(tǒng)提供連接管理、狀態(tài)管理和容錯管理。在大接入系統(tǒng)中，利用統(tǒng)一名稱服務(wù)實現(xiàn)了從前端到后端的服務(wù)尋址，通行方式使用zookeeper，具有高分散特性，實現(xiàn)了高可用性( 5個節(jié)點)。

2 )框架分離原則。這個原則似乎與第一條有些矛盾，其實不然。業(yè)務(wù)越來越復雜，搭載的功能越來越多，必須分離不同的服務(wù)功能。分離原則:以節(jié)點一定能夠擴展為首要原則，其次參考業(yè)務(wù)邏輯分離的必要性。在許多早期體系結(jié)構(gòu)設(shè)計中，服務(wù)節(jié)點通常不具有擴展能力是致命的，通常是文件服務(wù)，通過將文件上載到web服務(wù)器，web服務(wù)器具有非常邏輯的狀態(tài)。改進的一點是使用NFS。此時，我們發(fā)現(xiàn)NFS仍然無法擴展，單瓶頸仍然存在，今后的發(fā)展是FastDFS/MFS等分布式文件系統(tǒng)，在更大規(guī)模的文件服務(wù)中，GFS ( googledistributedfilesystem )/TFS ( googledistributedfilesystem ) 需要考慮方案，并且業(yè)務(wù)在線時，業(yè)務(wù)功能單一，此時所有服務(wù)都可以軟件化，隨著業(yè)務(wù)量的增大，分離一些功能，構(gòu)成統(tǒng)一的呼叫服務(wù)。

以前，體系結(jié)構(gòu)隔離只有3層，但存取層、邏輯層(根據(jù)集成的server框架開發(fā))和數(shù)據(jù)存儲層( NOSQL的接口都一致，也有mysql )。

3 )避免過度的設(shè)計原則。典型的規(guī)則是設(shè)計比當前業(yè)務(wù)容量大10倍的體系結(jié)構(gòu)，而不是設(shè)計比當前容量大100倍的體系結(jié)構(gòu)。 100倍的體系結(jié)構(gòu)意味著需要重建。過度的設(shè)計還會給輕量系統(tǒng)投入大量不必要的成本。例如，如果業(yè)務(wù)容量較小，則單實例mysql支持足夠的業(yè)務(wù)容量，但在這種情況下，不需要部署庫表算法。

4 )客戶端智能策略。客戶機智能是指客戶機確定返回后端中哪些服務(wù)節(jié)點，并且當服務(wù)節(jié)點的健康不滿足標準時直接排除服務(wù)。對于LVS，我們知道它有很好的四層容錯，但是不能徹底應(yīng)用協(xié)議層容錯(可以通過寫少量的腳本插件實現(xiàn))，后端服務(wù)容錯和容錯在常規(guī)方法中，客戶端收集后端服務(wù)訪問錯誤和延遲，并使用特定算法(獨立于本地代理)評估后端服務(wù)節(jié)點，以確定要在下一次訪問中使用哪些節(jié)點。

5 )無狀態(tài)化原則。無狀態(tài)是指任何服務(wù)節(jié)點關(guān)機都不會影響服務(wù)。要從用戶訪問進入我們的服務(wù)節(jié)點，您必須始終記住此標準。 LVS我們不采用主仆，采用LVS+OSPF方案可以徹底解決主仆的問題nginx，web服務(wù)器都不保持業(yè)務(wù)狀態(tài)信息，完全消除狀態(tài)(常見的狀態(tài)數(shù)據(jù)，例如用戶的頭像，用戶的session數(shù)據(jù)等)。在數(shù)據(jù)存儲層，NOSQL具有很好的分布式方案(請參見bigtable和GFS )，但是我們常用的mysql仍然沒有相應(yīng)的群集方案( mysql cluster尚未成熟)，但庫表sharding方案

6 )透明度服務(wù)原則。 Zbus是很好的例子，服務(wù)的位置關(guān)系，內(nèi)部訪問統(tǒng)一控制等。在很多系統(tǒng)中，不能這樣做也是運動維持只有結(jié)合子的重要原因之一。服務(wù)具有透明能力，一些變化可以完全控制運維，大大提高運維故障處理和應(yīng)急能力。順便提一下，有一天，當不同的系統(tǒng)需要不同的ZBUS服務(wù)群集時，我們將如何管理這些群集？請想想服務(wù)如何透明地應(yīng)對這些群集？

7 )端到端的監(jiān)視原則。這個日志寫著日志，特別是重要的錯誤日志。這對初期障礙的定位非常有幫助。運輸服務(wù)必須從基礎(chǔ)設(shè)施層到應(yīng)用程序?qū)油耆O(jiān)控。更高級的方法是結(jié)合用戶訪問流完成端到端監(jiān)控。這個難度很大，無論這個監(jiān)視設(shè)計本身如何，都選擇了監(jiān)視進行大量的數(shù)據(jù)分析，并且頭痛，通常的通行方法是采樣收集。

8 )場景決定記憶原則。存儲選擇必須從場景開始。以下幾個維度在儲存選擇時總是要問自己的問題:高存取量和低存取量？單用戶數(shù)據(jù)是大、小還是熱點集中還是分散？總數(shù)據(jù)量大還是小，有事務(wù)嗎？存儲本身的群集能力？等等。 redis可以處理的不是memcache，而是mysql可以處理的不是memcache。我們看著存儲界面，知道他們的API是絕對不同的。許多存儲部署會使開發(fā)變得困難，更困難的是這些存儲之間的數(shù)據(jù)同步，而且很難完全了解存儲。以前凱西和mongodb很多時候都無法切換mysql，最大的禁忌是根據(jù)網(wǎng)上的文章來選擇記憶。

對于NOSQL，在我們現(xiàn)階段，無需考慮，我們的業(yè)務(wù)增長了10倍。

建議的存儲方案: mysql+redis或mysql+handlesocket具有持久性能力+cache能力。

九)數(shù)據(jù)隔離原則。核心數(shù)據(jù)保護尤其重要，它是數(shù)據(jù)安全的重要組成部分，運輸策略有很多種類，包括數(shù)據(jù)分層、數(shù)據(jù)區(qū)保護、數(shù)據(jù)審核、定時密碼交換機制、數(shù)據(jù)操作可視化等。然而，從開發(fā)角度來看，提供統(tǒng)一數(shù)據(jù)訪問保護的重要保護措施是必要的。我的建議在數(shù)據(jù)庫之前隔離數(shù)據(jù)訪問層( DAL )，該層能夠完成數(shù)據(jù)庫路由訪問控制、庫表訪問控制以及過載控制。這種分離可以進一步提高數(shù)據(jù)的安全性，并且通過以接口的形式提供外部服務(wù)，可以有效地防止數(shù)據(jù)存取信息的泄露。

10) Zookeeper的活用。這是一個非常令人興奮的組件，從基本算法到設(shè)計的實現(xiàn)，到核心應(yīng)用場景的壟斷，特別的東西很少，所以可以單獨說。這是google chubby的開放源代碼的實現(xiàn)，有被廣泛使用的場合，可以管理運輸維的構(gòu)成，可以管理業(yè)務(wù)的構(gòu)成，可以提供名稱服務(wù)，可以編程生產(chǎn)編號，可以進行分布式消息隊列。重要的是超越IDC，能夠保證一致性。在分布式系統(tǒng)中，這是必不可少的。

十一)控制一切的原則。大家一定在構(gòu)筑你的系統(tǒng)和感情。但是，這種感情沒有給予足夠的自由，受到控制。從瀏覽器、DNS、LVS、web服務(wù)器、邏輯層和數(shù)據(jù)存儲層。自己能開發(fā)的是自己，自己不能開發(fā)的，要深刻理解它的特性，更好地控制它。前端瀏覽器需要知道IE的整體分布，尤其是IE6(影響web服務(wù)器壓縮算法的部署)，不同版本的ie有多少并發(fā)連接？ IE內(nèi)核與其他瀏覽器內(nèi)核的區(qū)別chrome有什么新特性？對于DNS也是如此，隨著系統(tǒng)規(guī)模的加大，必須走到自己的DNS水平，其他架構(gòu)部分也是如此。我相信中心的未來也一定會向這個方向發(fā)展。

12 )中心化和非中心化的想法。谷歌是中心化設(shè)計的杰出代表( GFS/BigTable都是如此)，而Amazon代表非中心化( DYNAMO一致性HASH架構(gòu)模型)。我有不同的認識，在不同的時刻可以采用不同的框架策略，在前端服務(wù)框架中可以完全集中，在數(shù)據(jù)存儲層個人也可以提出集中化設(shè)計，集中化設(shè)計可以減少內(nèi)部消息通信量

13 )框架是進化而來的，不是設(shè)計的。它是業(yè)務(wù)主導框架的改版，隨著業(yè)務(wù)量和業(yè)務(wù)模式的變化，框架也同時考慮變化。

上一篇：給網(wǎng)站文字添加高逼格效果返回觀點列表下一篇：一張圖讓你看懂hzpady.com 網(wǎng)站是如何訪問的

本文標簽：

本文地址： http://www.bmwdream.cn/a/807.html

相關(guān)專題

品牌官網(wǎng)設(shè)計
杭州派迪科技為高端客戶提供品牌官網(wǎng)咨詢策劃，品牌官網(wǎng)設(shè)計，品牌官網(wǎng)建設(shè)開發(fā)服務(wù)，以國際化視野和標準為基礎(chǔ)，為各行業(yè)領(lǐng)軍品牌提供高端企業(yè)網(wǎng)站定制、策劃、設(shè)計、互動與制作
查看詳情
大策略營銷門戶網(wǎng)站
杭州派迪科技有自己的營銷型網(wǎng)站CMS系統(tǒng)，適合白帽SEO網(wǎng)站。特別對大策略的營銷型門戶網(wǎng)站制作有一定的經(jīng)驗，曾經(jīng)為上海天擎外貿(mào)行業(yè)網(wǎng)站、浙江兆龍營銷型門戶、先臨三維門戶營銷網(wǎng)站提供全程的技術(shù)支持及SEO優(yōu)化指導
查看詳情
集團/上市公司網(wǎng)站
杭州派迪科技為杭州本地集團公司提供網(wǎng)頁設(shè)計、制作、開發(fā)服務(wù)，為集團公司網(wǎng)站建設(shè)提供了響應(yīng)式、營銷型、品牌型、門戶型網(wǎng)站建設(shè)需求，歡迎廣大集團公司客戶咨詢
查看詳情
外貿(mào)網(wǎng)站建設(shè)
杭州派迪科技為高端客戶提供外貿(mào)網(wǎng)站咨詢策劃，外貿(mào)官網(wǎng)設(shè)計，外貿(mào)官網(wǎng)建設(shè)開發(fā)服務(wù)，以谷歌搜索引起算法為基礎(chǔ)，為各行業(yè)外貿(mào)公司提供高端企業(yè)外貿(mào)網(wǎng)站定制、策劃、設(shè)計、互動與制作
查看詳情
企業(yè)網(wǎng)站建設(shè)
高端專業(yè)、令人印象深刻的用戶界面、易于訪問——企業(yè)網(wǎng)站必須反映一切，因為派迪科技在這里提供幫助，憑借精湛的技術(shù)、豐富的經(jīng)驗、與客戶的持續(xù)溝通以及對每一個細節(jié)的關(guān)注，我們確保在快速的周期時間內(nèi)提供優(yōu)質(zhì)的服務(wù)。
查看詳情
半定制網(wǎng)站
杭州派迪科技模板網(wǎng)站建設(shè)專題_各行業(yè)方案專題欄目提供各行業(yè)產(chǎn)品適合的網(wǎng)站建設(shè)方案,幫助企業(yè)了解派迪科技建站效果等信息,您可以通過本站了解各行業(yè)網(wǎng)站建設(shè)方案,如需要獲取本行業(yè)定制網(wǎng)站建設(shè)方案,可以聯(lián)系在線客服或撥打電話咨詢
查看詳情