Ⅰ 大型互聯網公司項目如何架構
初始階段的網站架構
大型網站都是從小型網站發展而來，網站架構也是一樣，是從小型網站架構逐步演化而來，小型網站最開始沒有太多人訪問，只需要一台伺服器就綽綽有餘，這時的網站架構如圖。
應用程序，資料庫，文件等所有的資源都在一台伺服器上。通常伺服器操作系統使用Linux，應用程序使用PHP開發，然後部署在Apache上，資料庫使用MySql，匯集各種開源軟體及一台廉價伺服器就可以開始網站的發展之路了。
應用服務和數據服務分離
隨著網站業務的發展，一台伺服器逐漸不能滿足需求：越來越多的用戶訪問導致性能越來越差，越來越多的數據導致存儲空間不足，這時就需要將應用和數據分離，應用和數據分離後整個網站使用三台伺服器：應用伺服器，文件伺服器和資料庫伺服器，如下圖所示，這三台伺服器對硬體資源的要求各不相同，應用伺服器需要處理大量的業務邏輯，因此需要更快更強大的CPU,資料庫伺服器需要快速磁碟檢索和數據緩存，因此需要更快的硬碟和更大的內存，文件伺服器需要儲存大量用戶上傳的文件，因此需要更大的硬碟。
應用和數據分離後，不同特性的伺服器承擔不同的服務角色，網站的並發處理能力和數據存儲空間得到了很大改善，支持網站業務進一步發展，但是隨著用戶逐漸增多，網站又一次面臨挑戰：資料庫壓力太大導致訪問延遲，進而影響整個網站的性能，用戶體驗受到影響，這時需要對網站架構進一步優化。
使用緩存改善網站性能
網站訪問特點和現實世界的財富分配一樣遵循二八定律：80%的業務訪問集中在20%的數據上。淘寶買家瀏覽的商品集中在少部分成交數多、評價良好的商品上；網路搜索關鍵詞集中在少部分熱門詞彙上；經常登錄的用戶才會發微博、看微博，而這部分用戶也只佔總用戶數目的一小部分。
既然大部分的業務訪問集中在，那麼如果把這一小部分數據緩存在內存中，就可以減少資料庫的訪問壓力。網站使用的緩存分為兩種：緩存在應用伺服器上的本地緩存和緩存在專門的分布式緩存伺服器上的遠程緩存。本地緩存的訪問速度更快一些，但是受應用伺服器內存限制，其緩存數量有限，而且會出現和應用程序爭用內存的情況。遠程分布式可以使用集群的方式，部署大內存的伺服器作為專門的緩存伺服器，可以在理論上做到不受內存容量限制的緩存服務。
使用緩存後，數據訪問壓力得到有效緩解，但是單一應用伺服器能夠處理的請求連接有限，在網站的訪問高峰期，應用伺服器會成為整個網站的瓶頸。
使用應用伺服器集群改善網站的並發處理能力
使用集群是網站解決高並發，海量問題的常用手段，當一台伺服器的處理能力、儲存空間不足時，不要企圖去換更強大的伺服器，對大型網站而言，不管多麼強大的伺服器，都滿足不了網站持續增長的業務需求，這種情況下，更恰當的做法是增加一台伺服器分擔原有伺服器的訪問及存儲壓力。
對網站而言，只要能通過一台伺服器的方式改善負載壓力，就可以以同樣的方式持續增加伺服器不斷改善系統性能，從而實現系統的可伸縮性，應用伺服器實現集群是網站可伸縮集群架構設計中較為簡單成熟的一種。如下圖所示。
通過負載均衡調度伺服器，可將來自用戶瀏覽器的請求分發到應用伺服器集群中的任何一台伺服器上，如果有更多的用戶，就在集群中加入更多的應用伺服器，使應用伺服器的負載壓力不在成為網站的瓶頸。
資料庫讀寫分離
網站使用緩存後，大部分數據操作訪問都可以不通過資料庫就能完成，但是仍有一部分讀操作，(緩存訪問不命中、緩存過期)和全部的寫操作，需要訪問資料庫，在網站的用戶達到一定規模後，資料庫因為負載壓力過高而成為網站的瓶頸。
目前大部分的主流資料庫都提供主從熱備功能，通過配置兩台資料庫主從關系，可以將一台資料庫伺服器的數據更新同步到另一台伺服器上。網站利用資料庫的這一功能，實現資料庫讀寫分離，從而改善資料庫負載壓力。
應用伺服器在寫數據的時候，訪問主資料庫，主資料庫通過主從復制機制將數據更新同步到從資料庫，這樣當應用伺服器讀數據的時候，就可以通過從資料庫或得數據。為了便於應用程序訪問讀寫分離後的資料庫，通常在應用伺服器端使用專門的數據訪問模塊，使資料庫讀寫分離時對應用透明。
使用反向代理和CDN加速網站響應
CDN和反向代理的基本原理都是緩存，區別在於CDN部署在網路提供商的機房，是用戶在請求網站服務時，可以從距離自己最近的網路提供商機房獲取數據；而反向代理則部署在網站的中心機房，當用戶請求到達中心機房後，首先訪問的伺服器是反向代理伺服器，如果反向代理伺服器中緩存著用戶請求的資源，就將其直接給用戶。
使用分布式文件系統和分布式資料庫系統
分布式資料庫是網站資料庫拆分的最後手段，只有在單表數據規模非常龐大的時候才使用，不到萬不得以時，網站更常用的資料庫拆分手段是業務分庫，將不同業務的資料庫部署在不同的物理伺服器上。
使用NOSQL和搜索引擎
對於海量數據的查詢，我們使用nosql資料庫加上搜索引擎可以達到更好的性能。並不是所有的數據都要放在關系型數據中。常用的NOSQL有mongodb和redis，搜索引擎有lucene。
業務拆分
隨著業務進一步擴展，應用程序變得非常臃腫，這時我們需要將應用程序進行業務拆分，如網路分為新聞、網頁、圖片等業務。每個業務應用負責相對獨立的業務運作。業務之間通過消息進行通信或者同享資料庫來實現.
分布式服務
這時我們發現各個業務應用都會使用到一些基本的業務服務，例如用戶服務、訂單服務、支付服務、安全服務，這些服務是支撐各業務應用的基本要素。我們將這些服務抽取出來利用分部式服務框架搭建分布式服務。淘寶的Dubbo是一個不錯的選擇.
Ⅱ 開發大型網站需要注意什麼
在實際操作中，一個大型網站開發項目有數十人並同工作，項目過程被分解成幾個部分，盡管如此，歸根到底還是這幾個工作流程在並發進行。
方法/技巧
程序框架：我們想開發的網站，往往市面上會有很多同類的開源程序，所以大家選擇程序上並不難，但是大家不要隨便的選擇了一個框架，要看該程序的二次開發性能、弊端、結構優化等幾方面是否適合自己。以及網站未來發展規劃，都要考慮在內。所以選擇程序不是意見簡單的事情。
開發過程：對前台開發大家都知道要用到設計師、網站布局人員、JS工程師等等還有。。我這里就對JS方面闡述一下，大型網站得對前端有一個整體規劃，所以JS規劃是不可缺少的，以下我自己歸納的3種JS編寫方案：
1、零散型：什麼是零散型的呢，這是我自己定義的，就是說當我們用到什麼效果的時候就去針對性的寫一塊，這樣的好處是方便，省事，哪裡需要就在哪裡寫，也不用外部文件調用，對於JS要求不多的網站來說很實用，缺點是不好管理，修改代碼時候往往會找不到代碼。
2、封裝型：和零散型區別是，把代碼都封裝起來，用文件調用，封裝好處是，不和別的函數發生沖突，做成一個個的封裝類，很實用，現在大多數網站是用這種方法。缺點是，仍然不是一個整體的類庫，但要比零散的好管理的多，因人而異吧。
3、JS類庫：JS類庫很多，用的比較多的有prototype，jQuery，我們拿jQuery舉例，現在大型網站總的來說用JS無非是兩種方式，一個是原生JS，純JS編寫的網站(以上的兩種方法包含在內)，再就是利用jQuery框架，兩種方式過程是截然不同的，但是用戶看到的效果卻是一樣的，有的大型網站單純就是JS編寫，不用任何框架，這是一種技術上的硬性標准，對於不同的公司而言，這樣做是對單純技術上的考驗，高手很多，用JS同樣能寫出和jQuery一樣的類庫，但是如果用jQuery的話就會節省大量的時間，因為jQuery本身就有很多的插件供大家使用，完全開源。不過另一方面說，jQuery可能確實是屬於應用的APP，和自己編寫的代碼是有本質區別的。我看過很多有名的網站，有JS和jQuery結合的，有單純JS的，也有純jQuery的，不管怎麼使用瀏覽者所看到的效果是一樣的，區別是我們在擴展上、維護上、管理上是有區別的。所以大家寫前端代碼時候用到的JS要謹慎考慮，也要根據自己的能力來判斷該如何使用JS。
團隊配合：好的產品是離不開整個團隊配合的，因為你不是一個人在戰斗。在技術開發上，要時刻保持溝通，哪怕一丁點問題，能問同事就多問，一句話的事情總比去網路上找強吧，特別是核心上的問題，策劃上的問題，不能自己單方面的去想，要一起來決定這件事是否正確，是否可以實施。往往返工就因為配合的不默契導致技術上失誤，造成時間的開銷和領導的指責。要記住，自己在怎麼有能力，也不會勝於整個團隊的努力。
找BUG：BUG在技術領域上是很熱的一個詞了，我們開發過程中，每時每刻都在找BUG，BUG也是無形中發現的。發現一個BUG有時候甚至要比你學了好幾天的東西要強的多，因為BUG是你最容易忽視的問題，你學漏的知識。產品發布有時候會因為一個BUG降低知名度、權威度。所以在產品發布之前，找BUG是最重要的，但我想說的是，找BUG不是要專門等到一定的時機在去找，我們要在工作中，休息中，睡不著覺的時候都應該來想，今天我寫了什麼代碼。會不會有問題。這個時間是比專門騰出來的時間找BUG要多的多。這是技術上的細節，我們要利用有效的時間做一些無限的事
Ⅲ 網站的基本架構是什麼
網站架構按照製作步驟分為硬架構和軟架構。
一、硬架構
1、機房：在選擇機房的時候，根據網站用戶的地域分布，可以選擇網通、電信等單機房或雙機房。
2、帶寬：預估網站每天的訪問量，根據訪問量選擇合適的帶寬，計算帶寬大小主要涉及峰值流量和頁面大小兩個指標。
3、伺服器：選擇需要的伺服器，如圖片伺服器，頁面伺服器，資料庫伺服器，應用伺服器，日誌伺服器，對於訪問量大點的網站而言，分離單獨的圖片伺服器和頁面伺服器相當必要。
二、軟架構
1、網站的框架：現在的PHP框架有很多選擇，比如：CakePHP，Symfony，Zend Framework，根據創作團隊對各個框架熟悉程度選擇。
2、邏輯的分層
1）表現層：所有和表現相關的邏輯都應該被納入表現層的范疇。
2）應用層：主要作用是定義用戶可以做什麼，並把操作結果反饋給表現層。
3）領域層：包含領域邏輯的層，就是告訴用戶具體的操作流程的。
4）持久層：即資料庫，保存領域模型保存到資料庫，包含網站的架構和邏輯關系等。
(3)大型網站核心架構怎麼解決問題擴展閱讀
網站的分類
1、根據網站所用編程語言分類：例如asp網站、php網站、jsp網站、Asp. net網站等；
2、根據網站的用途分類：例如門戶網站（綜合網站）、行業網站、娛樂網站等；
3、根據網站的功能分類：例如單一網站（企業網站）、多功能網站（網路商城）等等。
4、根據網站的持有者分類：例如個人網站、商業網站、政府網站、教育網站等。
5、根據網站的商業目的分類：營利型網站（行業網站、論壇）、非營利性型網站（企業網站、政府網站、教育網站）。
Ⅳ 大型網站技術架構 核心原理與案例分析 有用么
編輯推薦
編輯
本書作者是阿里巴巴網站構建的親歷者，擁有核心技術部門的一線工作經驗，直接體驗了大型網站構建與發展過程中的種種生與死，蛻與變，見證了一個網站架構從幼稚走向成熟穩定的歷程。
沒有晦澀難懂的術語，沒有詰屈聱牙的文句，沒有故弄玄虛的觀點……
明明白白的語句，清清楚楚的文法，干凈利落的建議——讓讀者直接體會網站架構的緊要處，不容馬虎的關鍵點——這恰好是一個優秀的網站架構所必備的要素。
如果說「水不在深，有龍則靈」，那麼對於想了解網站架構的讀者而言，這本書恰好是「書不在多，有它則行！」
還猶豫什麼呢？
內容簡介
編輯
本書通過梳理大型網站技術發展歷程，剖析大型網站技術架構模式，深入講述大型互聯網架構設計的核心原理，並通過一組典型網站技術架構設計案例，為讀者呈現一幅包括技術選型、架構設計、性能優化、Web 安全、系統發布、運維監控等在內的大型網站開發全景視圖。
本書不僅適用於指導網站工程師、架構師進行網站技術架構設計，也可用於指導產品經理、項目經理、測試運維人員等了解網站技術架構的基礎概念；還可供包括企業系統開發人員在內的各類軟體開發從業人員借鑒，了解大型網站的解決方案和開發理念。
Ⅳ 大型網站架構該怎麼優化設計
你得把你的網站拿出來看了才知道怎麼優化改進。並不是說每個網站的優化思路都一樣。比如，你優化結構之前你得考慮你的長尾關鍵詞要怎麼擴展，長尾詞是不是有規律可循。如果有規律，你可以直接利用程序生成標題，生成內容。要根據你的設計思路去設計網站結構。要是每個網站優化思路都一樣，那為什麼不直接程式化，還拿優化運營來做什麼？自動化多好。但是，這是不現實的。所以，你的提問沒人能幫得到你。
Ⅵ 關於大型網站架構問題
1、HTML靜態化
其實大家都知道，效率最高、消耗最小的就是純靜態化的html頁面，所以我們盡可能使我們的網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。但是對於大量內容並且頻繁更新的網站，我們無法全部手動去挨個實現，於是出現了我們常見的信息發布系統CMS，像我們常訪問的各個門戶站點的新聞頻道，甚至他們的其他頻道，都是通過信息發布系統來管理和實現的，信息發布系統可以實現最簡單的信息錄入自動生成靜態頁面，還能具備頻道管理、許可權管理、自動抓取等功能，對於一個大型網站來說，擁有一套高效、可管理的CMS是必不可少的。
除了門戶和信息發布類型的網站，對於交互性要求很高的社區類型網站來說，盡可能的靜態化也是提高性能的必要手段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再重新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。
同時，html靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用資料庫查詢但是內容更新很小的應用，可以考慮使用html靜態化來實現，比如論壇中論壇的公用設置信息，這些信息目前的主流論壇都可以進行後台管理並且存儲再資料庫中，這些信息其實大量被前台程序調用，但是更新頻率很小，可以考慮將這部分內容進行後台更新的時候進行靜態化，這樣避免了大量的資料庫訪問請求。
2、圖片伺服器分離
大家知道，對於Web伺服器來說，不管是APACHE、IIS還是其他容器，圖片是最消耗資源的，於是我們有必要將圖片與頁面進行分離，這是基本上大型網站都會採用的策略，他們都有獨立的圖片伺服器，甚至很多台圖片伺服器。這樣的架構可以降低提供頁面訪問請求的伺服器系統壓力，並且可以保證系統不會因為圖片問題而崩潰，在應用伺服器和圖片伺服器上，可以進行不同的配置優化，比如apache在配置ContentType的時候可以盡量少支持，盡可能少的LoadMole，保證更高的系統消耗和執行效率。
3、資料庫集群和庫表散列
大型網站都有復雜的應用，這些應用必須使用資料庫，那麼在面對大量訪問的時候，資料庫的瓶頸很快就能顯現出來，這時一台資料庫將很快無法滿足應用，於是我們需要使用資料庫集群或者庫表散列。
在資料庫集群方面，很多資料庫都有自己的解決方案，Oracle、Sybase等都有很好的方案，常用的MYSQL提供的Master/Slave也是類似的方案，您使用了什麼樣的DB，就參考相應的解決方案來實施即可。
上面提到的資料庫集群由於在架構、成本、擴張性方面都會受到所採用DB類型的限制，於是我們需要從應用程序的角度來考慮改善系統架構，庫表散列是常用並且最有效的解決方案。我們在應用程序中安裝業務和應用或者功能模塊將資料庫進行分離，不同的模塊對應不同的資料庫或者表，再按照一定的策略對某個頁面或者功能進行更小的資料庫散列，比如用戶表，按照用戶ID進行表散列，這樣就能夠低成本的提升系統的性能並且有很好的擴展性。sohu的論壇就是採用了這樣的架構，將論壇的用戶、設置、帖子等信息進行資料庫分離，然後對帖子、用戶按照板塊和ID進行散列資料庫和表，最終可以在配置文件中進行簡單的配置便能讓系統隨時增加一台低成本的資料庫進來補充系統性能。
4、緩存
緩存一詞搞技術的都接觸過，很多地方用到緩存。網站架構和網站開發中的緩存也是非常重要。這里先講述最基本的兩種緩存。高級和分布式的緩存在後面講述。
架構方面的緩存，對Apache比較熟悉的人都能知道Apache提供了自己的緩存模塊，也可以使用外加的Squid模塊進行緩存，這兩種方式均可以有效的提高Apache的訪問響應能力。
網站程序開發方面的緩存,LINUX上提供的Memory Cache是常用的緩存介面，可以在web開發中使用，比如用JAVA開發的時候就可以調用MemoryCache對一些數據進行緩存和通訊共享，一些大型社區使用了這樣的架構。另外，在使用web語言開發的時候，各種語言基本都有自己的緩存模塊和方法,PHP有Pear的Cache模塊，Java就更多了，.net不是很熟悉，相信也肯定有。
、鏡像
鏡像是大型網站常採用的提高性能和數據安全性的方式，鏡像的技術可以解決不同網路接入商和地域帶來的用戶訪問速度差異，比如ChinaNet和ENet之間的差異就促使了很多網站在教育網內搭建鏡像站點，數據進行定時更新或者實時更新。在鏡像的細節技術方面，這里不闡述太深，有很多專業的現成的解決架構和產品可選。也有廉價的通過軟體實現的思路，比如Linux上的rsync等工具。
6、負載均衡
負載均衡將是大型網站解決高負荷訪問和大量並發請求採用的終極解決辦法。
負載均衡技術發展了多年，有很多專業的服務提供商和產品可以選擇，我個人接觸過一些解決方法，其中有兩個架構可以給大家做參考。
硬體四層交換
第四層交換使用第三層和第四層信息包的報頭信息，根據應用區間識別業務流，將整個區間段的業務流分配到合適的應用伺服器進行處理。 第四層交換功能就象是虛IP，指向物理伺服器。它傳輸的業務服從的協議多種多樣，有HTTP、FTP、NFS、Telnet或其他協議。這些業務在物理伺服器基礎上，需要復雜的載量平衡演算法。在IP世界，業務類型由終端TCP或UDP埠地址來決定，在第四層交換中的應用區間則由源端和終端IP地址、TCP和UDP埠共同決定。
在硬體四層交換產品領域，有一些知名的產品可以選擇，比如Alteon、F5等，這些產品很昂貴，但是物有所值，能夠提供非常優秀的性能和很靈活的管理能力。Yahoo中國當初接近2000台伺服器使用了三四台Alteon就搞定了。
軟體四層交換
大家知道了硬體四層交換機的原理後，基於OSI模型來實現的軟體四層交換也就應運而生，這樣的解決方案實現的原理一致，不過性能稍差。但是滿足一定量的壓力還是游刃有餘的，有人說軟體實現方式其實更靈活，處理能力完全看你配置的熟悉能力。
軟體四層交換我們可以使用Linux上常用的LVS來解決，LVS就是Linux Virtual Server，他提供了基於心跳線heartbeat的實時災難應對解決方案，提高系統的魯棒性，同時可供了靈活的虛擬VIP配置和管理功能，可以同時滿足多種應用需求，這對於分布式的系統來說必不可少。
一個典型的使用負載均衡的策略就是，在軟體或者硬體四層交換的基礎上搭建squid集群，這種思路在很多大型網站包括搜索引擎上被採用，這樣的架構低成本、高性能還有很強的擴張性，隨時往架構裡面增減節點都非常容易。這樣的架構我准備空了專門詳細整理一下和大家探討。
對於大型網站來說，前面提到的每個方法可能都會被同時使用到，我這里介紹得比較淺顯，具體實現過程中很多細節還需要大家慢慢熟悉和體會，有時一個很小的squid參數或者apache參數設置，對於系統性能的影響就會很大，希望大家一起討論，達到拋磚引玉之效。
其實這樣的手段還很多,總結:第一,頁面靜態化(CMS)
第二,用鏡像或者CDN(這一塊可以付費完成)
第三,資料庫庫表分離,並且部署多台資料庫伺服器集群
第四,分化伺服器,分成WEB伺服器,FTP伺服器,圖片伺服器,DNS伺服器.
第五,DNS伺服器,分流到各功能應用伺服器(如博客,論壇,問答)
此外,這樣的手段還有很多....注意重點學習,你一定會有所成就
Ⅶ 大型網站架構設計
大型網站架構設計是非常復雜的事情，一個近千萬用戶的網站自然在各個方面與傳統的網站有著必然的區別。
網站靜態。一個每天有著數千頁面的網站也要實現靜態化的頁面，這只有依託一些程序來自動實現了，人工完成這樣的工作是幾乎不可能的。
系統架構。一個大型的網站要在內容上可以不斷的擴充，要在結構上進行不斷的深入發展，這就需要進行一個很好的優化，而對於資料庫或者網站程序都要全面的進行統一的規劃與籌備，這就需要一個團隊一起為了一個目標而努力。
存儲。一個網站如果做到很大的規模，它的存儲也應該進行統一的規劃，圖片如何存儲，信息如何存儲，來自各個搜索引擎的索引如何設置等等，這都要進行一個合理的分配。
資料庫技術。大的網站每天有著巨大的流量，在訪問的需求方面也是非常突出的，我們要用必要的資料庫技術來應對這些巨大流量的挑戰，從而讓網站的瀏覽體驗保持良好。www.21-mars.com採用了庫表散列就解決了大數據的問題。
Ⅷ 網站架構的問題
直接開一個商城算了
Ⅸ 網站結構該怎麼去優化 關於當當網架構優化的幾點心得
第一點：用戶體驗。
我覺得這是SEO里的重點，因為如果一個用戶體驗都不良好的網站，搜索引擎也不會認為你是一個好的網站，搜索引擎的排名演算法有很大程度的去考慮用戶體驗的。所以我們建設一個網站要讓用戶訪問到我們的網站中能夠很清楚的自己在什麼地方，接下來要去什麼地方，很方便的點擊鏈接，得到他想要得到的信息。假如你進一個網站，網站內部混亂不堪，沒有清晰的導航，沒有你像看到的信息錨文字，你是是不是也會不假思索的關閉這個網站，去尋找另一個網站。
第二點：收錄量。
我們進行網站結構優化的目的就是利於SEO，SEO的最基礎前提是你的網站有收錄，如果一個良好的網站結構，搜索引擎蜘蛛也很容易爬行到你的網站內頁對你的網站進行收錄，像我的tuihongbao.cn這個網站網站結構就是很清晰的，雖然收錄量不是很(尷)大(尬)。
第三點：網站權重的分配。
網站的哪些內容是你最想給用戶展現的，哪些內容是比較次要的，那麼這個在網站結構規劃的時候，就要對網站進行權重分配，權重高的網站自然排名就會比較高。這樣才能突出我們的主要業務。
第四點：錨文字。
要說網站的站外錨文字自己控制不了，那麼在站內，錨文字站長都是可以控制的。為什麼要達到錨文字清晰的目的，因為錨文字是搜索引擎排名中很重要的一部分。
關於當當網架構優化的幾點心得
第一，對技術部組織架構進行調整。
將原來的職能化組織中的產品、研發和測試部門按照產品線進行整合，轉型為Unit化，以加強同一產品線不同職能團隊之間的配合協作，溝通更高效，團隊更為聚焦。
這樣的組織結構更易於應用敏捷，與實施敏捷的前提同理，產品線拆分建立在系統架構解耦基礎之上，在這一點上，系統架構與組織架構異曲同工且相輔相成。解耦越充分，系統邊界越清晰，模塊越小，越適合敏捷團隊，能夠快速響應業務需求。
業務相近的產品線組成一個產品研發部，這樣多數的小型需求在部門內就可以解決，面對緊急項目還可以靈活使用人力資源，並為員工創造接觸更多類型業務需求的機會。
第二，系統分層依賴。
隨著業務邏輯越來越復雜，系統越來越多，相互依賴也越來越多。比如我的當當中就聚合了安全中心、用戶、賬戶、訂單、收藏夾、推薦等多維度的信息，需要調用多個系統服務。經過討論，決定將用戶交互層面的前端頁面與原有的後端系統拆分，並入前端的產品線，以便為用戶提供更好的服務。
而後端系統之間的依賴關系也需要更為精細的分層定義，對於促銷系統，需要會員系統、訂單系統、價格系統提供基礎數據;對於運費系統需要商品信息和配貨數據，而在精準定位銷售區域的前提下，庫存只是配貨的基礎數據，配貨系統負責判斷是否有貨，Promise則根據配貨結果計算預計送達時間。
調整系統之間的關系是很難的，牽一發而動全身，但重構是契機，2015年，對於電商的核心系統交易和促銷進行了重構，同時價格、配貨、運費等系統也進行了較大調整，從而使系統間依賴問題得到了明顯改善。
第三，服務化。
微服務為互聯網行業的服務化指明了方向，也堅定了我們進行服務拆分和解耦的決心。
原有的架構以系統為維度，服務歸屬於明確的系統，而系統的劃分一般以業務功能為聚合，隨著業務的發展，新的業務功能層出不窮，總會有一些打破原有的系統邊界，給架構提出難題。
服務化，不僅是指系統將能力通過服務對外提供，更重要的是服務本身就是承載業務功能的單元，如果有組合了多個邏輯難以歸入某系統的服務，不必糾結，作為獨立的業務模塊開發就是了，以服務為單元，系統架構更加扁平，簡單清晰。
微服務架構中，服務粒度會更小，服務治理的需求更加迫切，更需要技術手段解決，比如分布式服務框架，當當使用的是基於Dubbo二次研發的DubboX，以及結合ddframe實現的服務調用監控。
去年的容器技術爆發，為微服務架構實施提供了有力工具，當當內部也在部分系統使用了Docker。
微服務大勢所趨，秉承SOA理念，在服務治理中心的基礎上，將系統弱化，提供更多的基礎服務，提高了系統的復用性和靈活性。
第四，平台化。
平台化包括兩個維度，技術平台化和系統平台化。
技術平台化是指在技術層面建立統一的體系，包括根據行業特點進行技術選型，使用穩定可靠的技術組件。
當當從2012年開始將原有的.net平台向Java平台遷移，從封閉到開源，應用電商行業的主流技術棧，到2015年，基本完成了技術轉型，主要後端業務系統都轉移到Java平台。
經過數年的積累，2015年當當架構部研發了Java應用開發框架ddframe，目的是分離技術和業務，封裝技術細節，將應用開發人員的精力集中在業務開發上。
隨後再接再厲，當當架構部又推出了用來替代TBSchele的分布式作業調度框架Elastic-Job。並將之開源，基於JDBC的分布式資料庫中間件Sharding-JDBC也在開發中。
統一的技術棧，能夠復用技術資源，持續積累整體的研發能力，為做精做專提供更好的基礎條件。
系統平台化是指搭建基礎平台，包括測試平台、分布式服務平台、自動化運維平台、監控平台、緩存集群、消息中間件平台、大數據處理平台、項目管理系統、日誌平台、問題跟蹤系統等。
基礎平台是各業務系統有機協作的基礎，保證了整個技術架構的全面可控，能夠降低系統運維復雜度，是大型電商系統不可或缺的組成部分，良好的基礎平台是技術實力和管理能力的雙重體現，而多數公司更注重業務，會在基礎平台建設方面欠下許多技術債務。
2015年，當當搭建了自動化運維平台Pangu、監控平台Radar，重構了項目管理系統，Redis集群管理平台也在搭建中。
第五，核心系統重構。
在電商業務發展的快節奏之下，核心系統持續迭代是常態，而且基本兩、三年以上，就需要考慮重構，否則難以支撐業務的快速變化。
另外，系統重構集中梳理業務邏輯和系統依賴，整理統一的文檔，剔除無用功能，歸並多個版本，甩掉歷史包袱重新設計架構，適度的前瞻性設計使系統在一定周期內具備業務擴展性。
2015年，當當完成了交易系統和促銷系統進行了重構。
交易系統在2015年10月底完成新老版本切換。重構耗費約1500人天，重構代碼17萬行，全部切換至Java開源技術架構，為公司節約大量成本，並進行了架構優化，整體性能平均提升25%，經受住了雙十一和雙十二的考驗。
在當當，有一些「類促銷」業務，從廣義上可以歸入促銷范疇，但業務與數據均不屬於促銷系統，在促銷系統重構設計中，我們考慮將這類業務逐漸回收;另外，促銷系統能不能承擔一些營銷的功能?帶著這兩點考慮，在促銷基礎上進一步抽象出活動模型。
Ⅹ 大型網站建設過程要注意什麼問題
隨著互聯網的發展對我們的生活也有很大的提升，但是現在互聯網上的網站有很多，想要建設一個更好的效益較大化的網站。一個網站的建設能不能滿足用戶的需求，同時有良好的體驗呢？這都是大型網站建設要考慮的問題。
大型企業門戶網站建設首要目的是要展示企業的形象，宣傳企業文化擴大行業內的影響力。網站製作注重企業的穩定性和豐富的信息量，配合旗下的產品和主打系列進行聯合推廣，部分網站建設在此基礎上添加了旗下產品的在線商城建設和交流平台建設。 大型企業門戶網站建設主要是為瀏覽者提供信息服務的，作為大型企業信息門戶網站，必須首先提供種類繁多內容豐富的資訊，使不同的訪問者都能夠訪問到自己想要的信息。
一、首頁設計很重要
網站首頁就像一個人的整體面貌，所以相當重要。大型網站建設，自然要豎立好自己的形象，所以在設計上一定要保持干凈簡潔的風格，並且是類別鮮明。一般網友們瀏覽網頁，都是希望找到吸引自己的東西然後進行閱讀，如果網站首頁類別不鮮明，讓網友找了很久都無從下手，不知該如何進入主題，那這個首頁就太失敗了。並且首頁也盡量不要放太多的FLASH和圖片，這樣不僅會給網友瀏覽網站帶來視覺障礙，也會延長緩沖時間，消磨網友的耐心。所以，可以總結出，網站首頁風格要簡潔鮮明，並且內容要直白清楚，能一下子進入正題，給閱讀的人一個直接的解釋，讓人對這個網站有一個初步的正確的印象。
二、設計和策劃的准確性和完整性
網站建設是要先經過策劃和設計的，通過需求文檔才能繼而鎖定功能的設計，通過設計網站整體框架，才能有序進行網站的建設。沒有計劃而盲目地實行建設，最後一定會產生很多漏洞。由此可見，網站建設離不開各種策劃和設計，而這些策劃和設計的准確性和完整性也決定了整個工程的成敗。做什麼事規劃都是很重要的，在開始實質工作之前，必須要確定自己網站需要什麼適合什麼，才能根據自身的特色順利開始建設工作。
三、程序要選好框架
網站建設必然要用到程序，而如今網路上各種程序都不缺，一般網站建設的開源程序都有很多，所以在程序方面上並不難解決，但是需要注意的是，任何選擇都需要有前瞻性，考慮到程序的各方面，例如利弊、二次開發性等等，還有是否適合自己的網站，所以程序的選擇也需謹慎對待。
四、時刻記得找漏洞
一個小小的BUG可能造成整個程序無法運行，而這個小小的BUG偏偏在整個程序中很不起眼，難以讓人察覺，這是個很讓人頭痛的問題。所以，在開發和建設過程中，要時刻記得尋找漏洞，不然等到所有工作都做完了再去運行，結果發現出現了問題，從頭找起，那時候的工程實在是很浩大。BUG往往是很容易忽視的地方，所以在整個過程中都要保持時刻的認真和謹慎，當然再謹慎的人也沒法保證不出錯，所以後期的找錯工作不能馬虎。
五、團隊配合很關鍵
一個大型網站的開發不可能由單人作戰完成，一定是需要一個團隊的合作才能做好的。在開發和建設過程中一定要時刻注意團隊問題。在技術方面，要經常交流和溝通，畢竟一個人的力量是有限的，經常和隊友交流技術的經驗和感想，也能解決很多技術上的問題。另外，在策劃和後期運行維護之類的工作中，也需要團隊交流，只有協調了團隊所有人的想法，之後的工作才不會有沖突，只有所有人明確了各方面的任務，之後如果工作出現問題才能更容易地解決。