Ⅰ 前端工具裡面gulp和fis，有哪些優缺點
優點和缺點：
gulp輕量級，你的項目可能由於歷史原因，或者其他原因，fis的一些基礎要求可能和你項目有沖突。比如你可能只想處理整個項目中的一個模塊，或者你不太想在本地開發使用絕對路徑，或者你的項目和程序員分工頁面模板（jsp，php等）和前端資源不在同一個資源位置。這個時候你更適合使用gulp來定製自己的解決方案。
但是gulp使用者來說，並不是每個人都有非常強的處理錯誤能力，如果遇到插件bug（當然這種情況很少見），需要聯系作者，這個是一件非常棘手的事情。但是這種風險是存在的。
fis相對來說因為有專門的QQ群天天為用戶答疑解惑收集bug處理bug，壓根就不用擔心太多問題。另外fis的一些解決方案確實是目前前端優化裡面會需要真實考慮面對的。接觸fis會讓你對整個前端的優化和載入管理有更深入的了解，當然如果你已經了解很透徹了。我相信對於選擇gulp 和fis這種困惑應該也不會存在。
Ⅱ 常用的Web前端框架優缺點分析
今天小編要跟大家分享的文章是關於常用的web前端框架優缺點分析。正在從事web前端工作的小夥伴們一定不會對web前端框架陌生，那麼這么多的框架各有什麼優缺點呢?為了幫助小夥伴們提高工作效率，今天小編為大家整理了不同框架的優缺點分別是什麼，下面來和小編一起看一看吧！
一、web前端框架之Angular2+
Angular2+優點解析：
Angular2+的最大優勢在於它的流行程度。也有人認為它和Google密切相關的名字，會影響團隊使用它。Angular1
的迅速流行是因為那些來自其他互動式應用程序開發環境的人會發現對於開發單頁面web應用程序具有相似的模型-視圖模式。通過對Angular1
進行現代化演變和重新構建框架的某些部分，Angular2+
已經真正的爆發了，大量的正式的和非正式培訓機構數量都讓人印象深刻，開發者有很強的市場競爭力。對於用戶來說它有一套用於構建用戶界面的豐富組件，這也是本系列中少有的幾個框架能夠做到這點。
缺點解析:
我們覺得Angular框架著重於在單個頁面應用程序中創建用戶界面並沒有處理構建完整的web
應用這個更大的關注點，如果不及早確定下來，這將會導致整個項目難以維護，在實際項目中，運行時提供不屬於核心框架的技術往往讓人覺得不可思議，這大大降低了
TypeScript對最終開發者的價值。
發展方向：
Angular5剛剛發布，這看來是Angular已經成功的印證了快速發布版本的承諾，在Google的持續支持下，Angular
會越來越成熟。
像許多的大型組織一樣，Google具有多重(分裂)的人格，從外表上看，Angular
團隊和那些專注於瀏覽器標準的團隊之間顯得很和諧。但我們的觀點是，和諧只是一層薄薄的窗戶紙。Angular團隊對於web組件和漸進式web
應用沒有一個真正解決方案。我們認為，業界普遍認可的標准將會在Angular框架中會逐步實現，這將會影響到如何更好的構建Angular
應用將成為一個中/長期的風險。
使用環境:
如果你需要在一個大型的框架內獲取技術資源，框架內的技術通常很容易移植;或者你需要在框架中訓練開發人員，並且還要有一定的信心，他們會在短期內獲得一定的開發能力，這樣的話你可以考慮
Angular2+。需要注意的是Angular1(angular.js)與Angular2+是截然不同的，其中的應用、技術和經驗不能直接移植到
Angular2+的開發中去。
如果你的web應用能夠很好的轉化為標準的模型-視圖模式，那麼你也可以忽略其他直接考慮使用Angular2+。
如果你對GoogleMaterialUX設計模式滿意，那麼MaterialAngular
是遵循該模式的一種快速、簡單且可靠的方式。
二、web前端框架之React+Rex
React+Rex優勢解析：
React和Rex
的最大優勢在於它們相對簡單和專注。做一件事情並把它做好是非常困難的，但這兩個庫都很有效地完成了它們的目標。雖然對於某些狀態容器方法可能是外部的，但大多數開發人員還是可以輕松掌握概念，並了解單向數據體系結構的好處，簡化大量的用戶界面應用程序。
缺點解析:
React和Rex最大的弱點不是它們是什麼，而是它們不是什麼。要構建一個功能豐富的Web應用程序，你需要許多功能，一旦脫離React
和Rex和其他一些庫的核心，你將發現一個非常分散的社區，擁有無數的解決方案和模式，不容易整合在一起。
因此，雖然React和Rex
都是非常專注的庫，但缺乏經驗的團隊還是會很容易地生成不可維護的解決方案，而不是意識到他們所做的選擇會導致性能不佳或錯誤。即使有經驗的開發人員也可能意識到，一個鬆散的架構或慣例可能會在未來困擾他們。
假省錢是一種對自己的欺騙，組織范圍內採用React和Rex將輕松降低無效率問題。沒有其他庫和模式的廣泛約定和標准化，標准化React+
Rex比較於我們正在採用的JavaScript來編寫我們的應用程序效率要高。
發展方向:
Facebook和React最近從繁瑣的附加專利糾紛中抽離，他們認識到，就像其他項目一樣，更廣泛的社區能夠提高自己的聲音。我覺得這有助於
Facebook意識到他們還不能更好地了解我們，相信我們來引導項目。希望這將繼續貫穿項目的特點和技術方向。
很難預測React和Rex的未來。但是，將庫集中在一起，確實會顯著提高適應性，大多數React+Rex
模式都會促進一個分離的體系結構，從而可以輕松地進行重構和迭代。兩年前，大家喜歡的還是React+
Flux，但整個社區很快就擁抱了Rex。思維或模式的其他重大轉變可能很容易被採納。這種關鍵能力可能會持續到未來。
使用環境：
如果你很少需要手把手指導，並且正在尋找更好的庫而不是全面的框架，那麼React+Rex
可能是正確的。在這一過程中，你不僅需要對你的團隊和組織的能力保持誠實，還要在你的初始開發過程中，以及在整個應用程序的長期維護過程中保持誠實。
三、web前端框架之Vue.js
vue.js優勢介紹：
漸進式構建能力是vue.js最大的優勢，vue有一個簡潔而且合理的架構，使得它易於理解和構建。
vue有一個強大的充滿激情人群的社區，這為vue.js增加了巨大的價值，使得為一個空白項目創建一個綜合的解決方案變得十分容易。
缺點介紹：
在模型-視圖應用程序和狀態容器類型的應用程序之間的互相轉換可能會令人感到困惑，即使沒有完美包含一個模式到另一個模式的完美轉換，但讓人感覺希望能維持兩個模式的相關性。對於那些期待
vue.js完美解決方案，並可能導致難以維護不一致的應用程序的人來說，這至少是令人困惑的。
一個更大的挑戰是vue.js
依賴於一個單獨的人，很明顯，其他的項目基本是由一個組織提供支持，但這讓人感覺更加有意義，雖然它有一個強大文件的社區和許多有創新的新增項目，但是vue
核心的開發基本落在一個人身上。
我們很高興看到vue更加容易接受新興的標准方法，但是它的類似於web組件的模式，而不是真正的web組件，這可能是vue
所得不償失的地方。
發展前景：
雖然vue.js
有相當廣泛的應用，但也很難預測在中期發展中這個勢頭能持續多久，它不是由一個商業組織直接支持並維護，因此，這很大程度上依賴於維護者的生存能力和繼續維護下去的願望來決定。
它也表現出了一定程度的語言適應能力，並且隨著某些模式的落伍和失寵而繼續保持自身語言的現代化和時代性，目前沒有跡象表明vue.js
架構將來無法適應進一步發展。
使用場景：
如果你有一個傳統的web應用程序，並需要一個強壯穩健的應用程序層，那麼vue.js
可能是一個很好的選擇，它有清晰的模式，即使沒有經驗的團隊也能正確或者錯誤的使用它。盡管vueUX框架沒有開箱即用的功能，但在vue.js
上也能大量持續性構建應用，這將有利於你的項目。
以上就是小編今天為大家分享的關於常用的web前端框架優缺點分析的文章，希望本篇文章能夠對正在從事web前端工作的小夥伴們有所幫助，想要了解更多web前端知識記得關注北大青鳥web培訓官網，最後祝願小夥伴們工作順利，成為一名優秀的web前端工程師。
Ⅲ webstorm和dreamwear都是web前端開發利器，他倆的優缺點分別是
我是做前端開發的，以前用的是dreamwerver.軟體都是各有千秋吧，看你習慣或者喜歡哪一個了。現在我一直使用webstorm。。這個軟體很智能，編碼的時候都有提示。可以在軟體裡面進行代碼提交，可以進行代碼比較等等各種功能。。。自帶了很多內部插件！你可以在網上搜搜它的快捷鍵。經常使用就順手了。還是很不錯的。希望對你有幫助。。。望採納
Ⅳ 動態IP地址方案有什麼優點和缺點
優點：可以減少網路管理員管理IP地址的工作量；提高IP地址的使用率，節約IP地址。
缺點：主機獲得的IP地址不固定，對於提供網路服務的主機不適用；需要DHCP伺服器。
所以關於IP的使用，具體情況，具體對待，更多關於Linux的學習，請參考書籍《Linux就該這么學》
Ⅳ 常見的前端集成部署方案有哪些各自的優缺點是什麼
您好，這樣的：
磁碟陣列的由來： 由美國柏克萊大學（University of California-Berkeley）在1987年，發表的文章：「A Case for Rendant Arrays of Inexpensive Disks」。文章中，談到了RAID這個字匯，而且定義了RAID的5層級。柏克萊大學研究其研究目的為，反應當時CPU快速的性能。CPU效能每年大約成長30～50%，而硬磁機只能成長約7%。研究小組希望能找出一種新的技術，在短期內，立即提升效能來平衡計算機的運算能力。在當時，柏克萊研究小組的主要研究目的是效能與成本。 另外，研究小組也設計出容錯（fault-tolerance），邏輯數據備份（logical data rendancy），而產生了RAID理論。研究初期，便宜（Inexpensive）的磁碟也是主要的重點，但後來發現，大量便宜磁碟組合並不能適用於現實的生產環境，後來Inexpensive被改為independence，許多獨立的磁碟組。 磁碟陣列，時勢所趨： 自有PC以來，硬碟是最常使用的儲存裝置。但在整個計算機系統架構中，跟CPU與RAM來比，硬碟的速度是PC中最弱的設備之一。所以，為了加速計算機整體的數據流量，增加儲存的吞吐量，進階改進硬碟數據的安全，磁碟陣列的設計因應而生。 硬碟隨著科技的日新月異，現在其容量已達1500GB以上，轉速到了1萬轉，甚至15000轉，而且價格實在是很便宜，再加現在企業流行建造網路，企業資源計劃（Enterprise Resource Planning：ERP）是每個公司建構網路的主要目標。所以，利用區域網絡來傳遞數據，伺服器所使用的硬碟顯得非常重要，除了容量大、速度快之外，穩定更是基本要求。基於此因，磁碟陣列開始被廣泛的應用在個人計算機上。 磁碟陣列其樣式有三種，一是外接式磁碟陣列櫃、二是內接式磁碟陣列卡，三是利用軟體來模擬。外接式磁碟陣列櫃最常被使用大型伺服器上，具可熱抽換（Hot Swap）的特性，不過這類產品的價格都很貴。內接式磁碟陣列卡，因為價格便宜，但需要較高的安裝技術，適合技術人員使用操作。另外利用軟體模擬的方式，由於會拖累機器的速度，不適合大數據流量的伺服器。 由上述可知，現在IDE磁碟陣列大行其道的道理；IDE介面硬碟的穩定度與效能表現已有很大的提升，加上成本考量，所以採用IDE介面硬碟來作為磁碟陣列的解決方案，可說是最佳的方式 在網路存儲中，磁碟陣列是一種把若干硬磁碟驅動器按照一定要求組成一個整體，整個磁碟陣列由陣列控制器管理的系統。磁帶庫是像自動載入磁帶機一樣的基於磁帶的備份系統，磁帶庫由多個驅動器、多個槽、機械手臂組成，並可由機械手臂自動實現磁帶的拆卸和裝填。它能夠提供同樣的基本自動備份和數據恢復功能，同時具有更先進的技術特點。掌握網路存儲設備的安裝、操作使用也是網管員必須要學會的。在架構無線區域網時，對無線路由器、無線網路橋接器AP、無線網卡、天線等無線區域網產品進行安裝、調試和應用操作。 磁碟陣列的主流結構： 磁碟陣列作為獨立系統在主機外直連或通過網路與主機相連。磁碟陣列有多個埠可以被不同主機或不同埠連接。一個主機連接陣列的不同埠可提升傳輸速度。 和目前PC用單磁碟內部集成緩存一樣，在磁碟陣列內部為加快與主機交互速度，都帶有一定量的緩沖存儲器。主機與磁碟陣列的緩存交互，緩存與具體的磁碟交互數據。 在應用中，有部分常用的數據是需要經常讀取的，磁碟陣列根據內部的演算法，查找出這些經常讀取的數據，存儲在緩存中，加快主機讀取這些數據的速度，而對於其他緩存中沒有的數據，主機要讀取，則由陣列從磁碟上直接讀取傳輸給主機。對於主機寫入的數據，只寫在緩存中，主機可以立即完成寫操作。然後由緩存再慢慢寫入磁碟。
編輯本段磁碟陣列的優點
RAID的採用為存儲系統（或者伺服器的內置存儲）帶來巨大利益，其中提高傳輸速率和提供容錯功能是最大的優點。 RAID通過同時使用多個磁碟，提高了傳輸速率。RAID通過在多個磁碟上同時存儲和讀取數據來大幅提高存儲系統的數據吞吐量（Throughput）。在RAID中，可以讓很多磁碟驅動器同時傳輸數據，而這些磁碟驅動器在邏輯上又是一個磁碟驅動器，所以使用RAID可以達到單個磁碟驅動器幾倍、幾十倍甚至上百倍的速率。這也是RAID最初想要解決的問題。因為當時CPU的速度增長很快，而磁碟驅動器的數據傳輸速率無法大幅提高，所以需要有一種方案解決二者之間的矛盾。RAID最後成功了。 通過數據校驗，RAID可以提供容錯功能。這是使用RAID的第二個原因，因為普通磁碟驅動器無法提供容錯功能，如果不包括寫在磁碟上的CRC（循環冗餘校驗）碼的話。RAID容錯是建立在每個磁碟驅動器的硬體容錯功能之上的，所以它提供更高的安全性。在很多RAID模式中都有較為完備的相互校驗/恢復的措施，甚至是直接相互的鏡像備份，從而大大提高了RAID系統的容錯度，提高了系統的穩定冗餘性。
編輯本段磁碟陣列問答
1. 什麼是磁碟陣列（Disk Array）? 磁碟陣列（Disk Array）是由一個硬碟控制器來控制多個硬碟的相互連接，使多個硬碟的讀寫同步，減少錯誤，增加效率和可靠度的技術。 2.什麼是RAID? RAID是Rendant Array of Inexpensive Disk的縮寫，意為廉價冗餘磁碟陣列，是磁碟陣列在技術上實現的理論標准，其目的在於減少錯誤、提高存儲系統的性能與可靠度。常用的等級有1、3、5級等。 3.什麼是RAID Level 0? RAID Level 0是Data Striping(數據分割)技術的實現，它將所有硬碟構成一個磁碟陣列，可以同時對多個硬碟做讀寫動作，但是不具備備份及容錯能力，它價格便宜，硬碟使用效率最佳，但是可靠度是最差的。 以一個由兩個硬碟組成的RAID Level 0磁碟陣列為例，它把數據的第1和2位寫入第一個硬碟，第三和第四位寫入第二個硬碟……以此類推，所以叫「數據分割"，因為各盤數據的寫入動作是同時做的，所以它的存儲速度可以比單個硬碟快幾倍。 但是，這樣一來，萬一磁碟陣列上有一個硬碟壞了，由於它把數據拆開分別存到了不同的硬碟上，壞了一顆等於中斷了數據的完整性，如果沒有整個磁碟陣列的備份磁帶的話，所有的數據是無法挽回的。因此，盡管它的效率很高，但是很少有人冒著數據丟失的危險採用這項技術。 4.什麼是RAID Level 1? RAID Level 1使用的是Disk Mirror(磁碟映射)技術，就是把一個硬碟的內容同步備份復制到另一個硬碟里，所以具備了備份和容錯能力，這樣做的使用效率不高，但是可靠性高。 5.什麼是RAID Level 3? RAID Level 3採用Byte－interleaving(數據交錯存儲)技術，硬碟在SCSI控制卡下同時動作，並將用於奇偶校驗的數據儲存到特定硬碟機中，它具備了容錯能力，硬碟的使用效率是安裝幾個就減掉一個，它的可靠度較佳。 6.什麼是RAID Level 5? RAID Level 5使用的是Disk Striping(硬碟分割)技術，與Level 3的不同之處在於它把奇偶校驗數據存放到各個硬碟里，各個硬碟在SCSI控制卡的控制下平行動作，有容錯能力，跟Level 3一樣，它的使用效率也是安裝幾個再減掉一個。 7.什麼是熱插拔硬碟？ 熱插拔硬碟英文名為Hot－Swappable Disk，在磁碟陣列中，如果使用支持熱插拔技術的硬碟，在有一個硬碟壞掉的情況下，伺服器可以不用關機，直接抽出壞掉的硬碟，換上新的硬碟。一般的商用磁碟陣列在硬碟壞掉的時候，會自動鳴叫提示管理員更換硬碟。
編輯本段RAID技術規范簡介
在計算機發展的初期，「大容量」硬碟的價格還相當高，解決數據存儲安全性問題的主要方法是使用磁帶機等設備進行備份，這種方法雖然可以保證數據的安全，但查閱和備份工作都相當繁瑣。1987年， Patterson、Gibson和Katz這三位工程師在加州大學伯克利分校發表了題為《A Case of Rendant Array of Inexpensive Disks（廉價磁碟冗餘陣列方案）》的論文，其基本思想就是將多隻容量較小的、相對廉價的硬碟驅動器進行有機組合，使其性能超過一隻昂貴的大硬碟。這一設計思想很快被接受，從此RAID技術得到了廣泛應用，數據存儲進入了更快速、更安全、更廉價的新時代。 磁碟陣列對於個人電腦用戶，還是比較陌生和神秘的。印象中的磁碟陣列似乎還停留在這樣的場景中：在寬闊的大廳里，林立的磁碟櫃，數名表情陰郁、早早謝頂的工程師徘徊在其中，不斷從中抽出一塊塊沉重的硬碟，再插入一塊塊似乎更加沉重的硬碟……終於，隨著大容量硬碟的價格不斷降低，個人電腦的性能不斷提升，IDE-RAID作為磁碟性能改善的最廉價解決方案，開始走入一般用戶的計算機系統。 RAID技術主要包含RAID 0～RAID 7等數個規范，它們的側重點各不相同，常見的規范有如下幾種： RAID 0：RAID 0連續以位或位元組為單位分割數據，並行讀/寫於多個磁碟上，因此具有很高的數據傳輸率，但它沒有數據冗餘，因此並不能算是真正的RAID結構。RAID 0隻是單純地提高性能，並沒有為數據的可靠性提供保證，而且其中的一個磁碟失效將影響到所有數據。因此，RAID 0不能應用於數據安全性要求高的場合。 RAID 1：它是通過磁碟數據鏡像實現數據冗餘，在成對的獨立磁碟上產生互 為備份的數據。當原始數據繁忙時，可直接從鏡像拷貝中讀取數據，因此RAID 1可以提高讀取性能。RAID 1是磁碟陣列中單位成本最高的，但提供了很高的數據安全性和可用性。當一個磁碟失效時，系統可以自動切換到鏡像磁碟上讀寫，而不需要重組失效的數據。 RAID 0+1: 也被稱為RAID 10標准，實際是將RAID 0和RAID 1標准結合的產物，在連續地以位或位元組為單位分割數據並且並行讀/寫多個磁碟的同時，為每一塊磁碟作磁碟鏡像進行冗餘。它的優點是同時擁有RAID 0的超凡速度和RAID 1的數據高可靠性，但是CPU佔用率同樣也更高，而且磁碟的利用率比較低。 RAID 2：將數據條塊化地分布於不同的硬碟上，條塊單位為位或位元組，並使用稱為「加重平均糾錯碼（海明碼）」的編碼技術來提供錯誤檢查及恢復。這種編碼技術需要多個磁碟存放檢查及恢復信息，使得RAID 2技術實施更復雜，因此在商業環境中很少使用。 RAID 3：它同RAID 2非常類似，都是將數據條塊化分布於不同的硬碟上，區別在於RAID 3使用簡單的奇偶校驗，並用單塊磁碟存放奇偶校驗信息。如果一塊磁碟失效，奇偶盤及其他數據盤可以重新產生數據；如果奇偶盤失效則不影響數據使用。RAID 3對於大量的連續數據可提供很好的傳輸率，但對於隨機數據來說，奇偶盤會成為寫操作的瓶頸。 RAID 4：RAID 4同樣也將數據條塊化並分布於不同的磁碟上，但條塊單位為塊或記錄。RAID 4使用一塊磁碟作為奇偶校驗盤，每次寫操作都需要訪問奇偶盤，這時奇偶校驗盤會成為寫操作的瓶頸，因此RAID 4在商業環境中也很少使用。 RAID 5：RAID 5不單獨指定的奇偶盤，而是在所有磁碟上交叉地存取數據及奇偶校驗信息。在RAID 5上，讀/寫指針可同時對陣列設備進行操作，提供了更高的數據流量。RAID 5更適合於小數據塊和隨機讀寫的數據。RAID 3與RAID 5相比，最主要的區別在於RAID 3每進行一次數據傳輸就需涉及到所有的陣列盤；而對於RAID 5來說，大部分數據傳輸只對一塊磁碟操作，並可進行並行操作。在RAID 5中有「寫損失」，即每一次寫操作將產生四個實際的讀/寫操作，其中兩次讀舊的數據及奇偶信息，兩次寫新的數據及奇偶信息。 RAID 6：與RAID 5相比，RAID 6增加了第二個獨立的奇偶校驗信息塊。兩個獨立的奇偶系統使用不同的演算法，數據的可靠性非常高，即使兩塊磁碟同時失效也不會影響數據的使用。但RAID 6需要分配給奇偶校驗信息更大的磁碟空間，相對於RAID 5有更大的「寫損失」，因此「寫性能」非常差。較差的性能和復雜的實施方式使得RAID 6很少得到實際應用。 RAID 7：這是一種新的RAID標准，其自身帶有智能化實時操作系統和用於存儲管理的軟體工具，可完全獨立於主機運行，不佔用主機CPU資源。RAID 7可以看作是一種存儲計算機（Storage Computer），它與其他RAID標准有明顯區別。除了以上的各種標准（如表1），我們可以如RAID 0+1那樣結合多種RAID規范來構築所需的RAID陣列，例如RAID 5+3（RAID 53）就是一種應用較為廣泛的陣列形式。用戶一般可以通過靈活配置磁碟陣列來獲得更加符合其要求的磁碟存儲系統。 RAID 5E RAID 5E(RAID 5 Enhencement): RAID 5E是在 RAID 5級別基礎上的改進，與RAID 5類似，數據的校驗信息均勻分布在各硬碟上，但是，在每個硬碟上都保留了一部分未使用的空間，這部分空間沒有進行條帶化，最多允許兩塊物理硬碟出現故障。看起來，RAID 5E和RAID 5加一塊熱備盤好象差不多，其實由於RAID 5E是把數據分布在所有的硬碟上，性能會與RAID5 加一塊熱備盤要好。當一塊硬碟出現故障時，有故障硬碟上的數據會被壓縮到其它硬碟上未使用的空間，邏輯盤保持RAID 5級別。 RAID 5EE RAID 5EE: 與RAID 5E相比，RAID 5EE的數據分布更有效率，每個硬碟的一部分空間被用作分布的熱備盤，它們是陣列的一部分，當陣列中一個物理硬碟出現故障時，數據重建的速度會更快。 開始時RAID方案主要針對SCSI硬碟系統，系統成本比較昂貴。1993年，HighPoint公司推出了第一款IDE-RAID控制晶元，能夠利用相對廉價的IDE硬碟來組建RAID系統，從而大大降低了RAID的「門檻」。從此，個人用戶也開始關注這項技術，因為硬碟是現代個人計算機中發展最為「緩慢」和最缺少安全性的設備，而用戶存儲在其中的數據卻常常遠超計算機的本身價格。在花費相對較少的情況下，RAID技術可以使個人用戶也享受到成倍的磁碟速度提升和更高的數據安全性，現在個人電腦市場上的IDE-RAID控制晶元主要出自HighPoint和Promise公司，此外還有一部分來自AMI公司。 面向個人用戶的IDE-RAID晶元一般只提供了RAID 0、RAID 1和RAID 0+1（RAID 10）等RAID規范的支持，雖然它們在技術上無法與商用系統相提並論，但是對普通用戶來說其提供的速度提升和安全保證已經足夠了。隨著硬碟介面傳輸率的不斷提高，IDE-RAID晶元也不斷地更新換代，晶元市場上的主流晶元已經全部支持ATA 100標准，而HighPoint公司新推出的HPT 372晶元和Promise最新的PDC20276晶元，甚至已經可以支持ATA 133標準的IDE硬碟。在主板廠商競爭加劇、個人電腦用戶要求逐漸提高的今天，在主板上板載RAID晶元的廠商已經不在少數，用戶完全可以不用購置RAID卡，直接組建自己的磁碟陣列，感受磁碟狂飆的速度。 RAID 50 RAID 50：RAID50是RAID5與RAID0的結合。此配置在RAID5的子磁碟組的每個磁碟上進行包括奇偶信息在內的數據的剝離。每個RAID5子磁碟組要求三個硬碟。RAID50具備更高的容錯能力，因為它允許某個組內有一個磁碟出現故障，而不會造成數據丟失。而且因為奇偶位分部於RAID5子磁碟組上，故重建速度有很大提高。優勢：更高的容錯能力，具備更快數據讀取速率的潛力。需要注意的是：磁碟故障會影響吞吐量。故障後重建信息的時間比鏡像配置情況下要長。
Ⅵ 代理伺服器方案有哪幾種他們的優缺點分別是什麼
摘要 代理伺服器的主要功能是:
Ⅶ 前後端分離方案以及技術選型
作者：關開發
一.什麼是前後端分離？
理解前後端分離大概可以從3個方面理解：
1. 交互形式
2. 代碼組織形式
3. 開發模式與流程
1.1 交互形式
前後端不分離
後端將數據和頁面組裝、渲染好了之後，向瀏覽器輸出最終的html；瀏覽器接收到後會解析html，解析引入的css、執行js腳本，完成最終的頁面展示。
前後端分離
後端只需要和前端約定好接收以及返回的數據格式（一般用JSON格式），向前端提供API介面。前端就可以通過HTTP請求調用API的方式進行交互。前端獲取到數據後，進行頁面組裝、渲染，最終在瀏覽器呈現。
1.2 代碼組織形式
前後端不分離
在web應用早期的時候，前端頁面以及後台業務數據處理的代碼都放在一個工程下，甚至放在同一目錄下，前端頁面夾雜著後端代碼。前、後端開發工程師都需要把整套代碼導入開發工具才能開發。此階段下前後端代碼以及工作耦合度太高，前端不能獨立開發和測試，後端人員也要依賴前端完成頁面後才能完成開發。最糟糕的情況是前端工程師需要會後端模板技術（jsp），後端工程師還要會點前端技術，需要口頭說明頁面數據介面，才能配合完成開發。否則前端只能當一個「切圖仔」，只輸出HTML、CSS、以及很少量與業務邏輯無關的js；然後由後端轉化為後端jsp，並且還要寫業務的js代碼。
前後端分離
前後端代碼放在不同的工程下，前端代碼可以獨立開發，通過mock/easy-mock技術模擬後端API服務可以獨立運行、測試；後端代碼也可以獨立開發，運行、測試，通過swagger技術能自動生成API文檔供前端閱讀，還可以進行自動化介面測試，保證API的可用性，降低集成風險。
1.3 開發模式與流程
前後端不分離
在項目開發階段，前端根據原型和UI設計稿，編寫HTML、CSS以及少量與業務無關的js（純效果那些），完成後交給後台人員，後台人員將HTML轉為jsp，並通過JSP的模板語法進行數據綁定以及一些邏輯操作。後台完成後，將全部代碼打包，包含前端代碼、後端代碼打成一個war，然後部署到同一台伺服器運行。頂多做一下動靜分離，也就是把圖片、css、js分開部署到nginx。
具體開發流程如下：圖略
前後端分離
實現前後端分離之後，前端根據原型和UI設計稿編寫HTML、CSS以及少量與業務無關的js（純效果那些），後端也同時根據原型進行API設計，並與前端協定API數據規范。等到後台API完成，或僅僅是API數據規范設定完成之後。前端即可通過HTTP調用API，或通過mock數據完成數據組裝以及業務邏輯編寫。前後端可以並行，或者前端先行於後端開發了。
具體開發流程如下：圖略
二、前後端分離的好處與壞處。
從上面3個方面對比了之後，前後端分離架構和傳統的web架構相比，有很大的變化，看起來好處多多。到底是分還是不分，我們還是要理性分析是否值得才去做。
從目前應用軟體開發的發展趨勢來看，主要有兩方面需要注意：
· 越來越注重用戶體驗，隨著互聯網的發展，開始多終端化。
· 大型應用架構模式正在向雲化、微服務化發展。
我們主要通過前後端分離架構，為我們帶來以下四個方面的提升：
· 為優質產品打造精益團隊
通過將開發團隊前後端分離化，讓前後端工程師只需要專注於前端或後端的開發工作，是的前後端工程師實現自治，培養其獨特的技術特性，然後構建出一個全棧式的精益開發團隊。
· 提升開發效率
前後端分離以後，可以實現前後端代碼的解耦，只要前後端溝通約定好應用所需介面以及介面參數，便可以開始並行開發，無需等待對方的開發工作結束。與此同時，即使需求發生變更，只要介面與數據格式不變，後端開發人員就不需要修改代碼，只要前端進行變動即可。如此一來整個應用的開發效率必然會有質的提升。
· 完美應對復雜多變的前端需求
如果開發團隊能完成前後端分離的轉型，打造優秀的前後端團隊，開發獨立化，讓開發人員做到專注專精，開發能力必然會有所提升，能夠完美應對各種復雜多變的前端需求。
· 增強代碼可維護性
前後端分離後，應用的代碼不再是前後端混合，只有在運行期才會有調用依賴關系。應用代碼將會變得整潔清晰，不論是代碼閱讀還是代碼維護都會比以前輕松。
那麼前後端分離有什麼不好的地方嗎？我目前是沒有想到，除非你說會增加前端團隊的配備，後端工程師會變的不全能。。。
二、前後端分離架構方案。
實現前後端分離，主要是前端的技術架構變化較大，後端主要變為restfull 風格API，然後加上Swagger技術自動生成在線介面文檔就差不多了。
對於目前用於前後端分離方案的前端技術架構主要有兩種：
· 傳統SPA
· 服務端渲染SSR
2.1 傳統SPA
傳統SPA指的是單頁面應用，也就是整個網站只有一個頁面，所有功能都通過這一個頁面來呈現。因為一個人的肉眼，某一個時間點看一個頁面，既然如此何必要不同功能做多個頁面呢？只保留一個頁面作為模板，然後通過路由跳轉來更新這個模板頁面的內容不就可以了嗎？確實如此，現在通過reac全家桶、tvue全家桶，模塊化、路由、wabpack等技術輕而易舉就能實現一個單頁面應用。
單頁面應用的運行流程
1.用戶通過瀏覽器訪問網站url
2.單頁面的html文件（index.html）被下載到瀏覽器，接著下載html裡面引用的css，js。
3.css，js下載到瀏覽器完成之後，瀏覽器開始解析執行js向後端服務非同步請求數據。
4.請求數據完成後，進行數據綁定、渲染，最終在用戶瀏覽器呈現完整的頁面。
2.2 服務端渲染
服務端渲染的方案指的是數據綁定，渲染等工作都放在服務端完成，服務端向瀏覽器輸出最終的html。大家看完這個是不是有個疑問，這不是又回到了前後端不分離的時代了嗎？答案是否定的，因為這里的服務端是用來執行前端數據綁定、渲染的，也就是把瀏覽器的一部分工作分擔到了服務端。而目前具備這只種能力的服務端是NodeJs服務端。
它的原理其實就是在瀏覽器與前端代碼中間插入了一個NodeJs服務端。瀏覽器請求前端頁面時，會先經過NodeJS服務端，由NodeJs去讀取前端頁面，並執行非同步後端API，獲取到數據後進行頁面數據綁定，渲染等工作，完成一個最終的html然後返回瀏覽器，最後瀏覽器進行展示。
服務端渲染應用的運行流程：
1.用戶通過瀏覽器訪問網站url
2.NodeJS服務端接收到請求，讀取到對應的前端html，css，js。
3.NodeJS解析執行js向後端API非同步請求數據。
4.NodeJs請求數據完成之後，進行數據綁定、渲染，得到一個最終的html。
5.NodeJs向瀏覽器輸出html，瀏覽器進行展示。
PS：其實本質就是把前端編寫成一個nodeJs的服務端web應用。實施服務端渲染後，我們最終運行的是一個Nodejs服務端應用。而單頁面應用是把靜態頁面部署到靜態資源伺服器進行運行。
看到這里，你是否又有疑問，為什麼要這么麻煩搞服務端渲染呢？
2.3 SPA與服務端渲染方案對比
SPA的優點是開發簡單，部署簡單；缺點是首次載入較慢，需要較好的網路，不友好的SEO。
so，以下就是使用服務端渲染的理由了（摘取vue官方說法）：
與傳統 SPA (單頁應用程序 (Single-Page Application)) 相比，伺服器端渲染 (SSR) 的優勢主要在於：
· 更好的 SEO，由於搜索引擎爬蟲抓取工具可以直接查看完全渲染的頁面。
請注意，截至目前，Google 和 Bing 可以很好對同步 JavaScript 應用程序進行索引。在這里，同步是關鍵。如果你的應用程序初始展示 loading 菊花圖，然後通過 Ajax 獲取內容，抓取工具並不會等待非同步完成後再行抓取頁面內容。也就是說，如果 SEO 對你的站點至關重要，而你的頁面又是非同步獲取內容，則你可能需要伺服器端渲染(SSR)解決此問題。
· 更快的內容到達時間 (time-to-content)，特別是對於緩慢的網路情況或運行緩慢的設備。
無需等待所有的 JavaScript 都完成下載並執行，才顯示伺服器渲染的標記，所以你的用戶將會更快速地看到完整渲染的頁面。通常可以產生更好的用戶體驗，並且對於那些「內容到達時間(time-to-content) 與轉化率直接相關」的應用程序而言，伺服器端渲染 (SSR) 至關重要。
使用伺服器端渲染 (SSR) 時還需要有一些權衡之處：
· 開發條件所限。瀏覽器特定的代碼，只能在某些生命周期鉤子函數 (lifecycle hook) 中使用；一些外部擴展庫 (external library) 可能需要特殊處理，才能在伺服器渲染應用程序中運行。
· 涉及構建設置和部署的更多要求。與可以部署在任何靜態文件伺服器上的完全靜態單頁面應用程序 (SPA) 不同，伺服器渲染應用程序，需要處於 Node.js server 運行環境。
· 更多的伺服器端負載。在 Node.js 中渲染完整的應用程序，顯然會比僅僅提供靜態文件的 server 更加大量佔用 CPU 資源 (CPU-intensive - CPU 密集)，因此如果你預料在高流量環境 (high traffic) 下使用，請准備相應的伺服器負載，並明智地採用緩存策略。
以vue為例，實施服務端渲染可以查看官方指南： https://ssr.vuejs.org ，或選擇Nuxt.js
2.4 預渲染技術
如果你調研伺服器端渲染 (SSR) 只是用來改善少數營銷頁面（例如 /, /about, /contact 等）的 SEO，那麼你可能需要預渲染。無需使用 web 伺服器實時動態編譯 HTML，而是使用預渲染方式，在構建時 (build time) 簡單地生成針對特定路由的靜態 HTML 文件。優點是設置預渲染更簡單，並可以將你的前端作為一個完全靜態的站點。
如果你使用 webpack，你可以使用 prerender-spa-plugin 輕松地添加預渲染。它已經被 Vue 應用程序廣泛測試 - 事實上，作者是 Vue 核心團隊的成員。
prerender-spa-plugin: https://github.com/chrisvfritz/prerender-spa-plugin
三、前後端分離技術選型
- artTemplate + bootstrap（不推薦， 不算完全前後端分離）
- vue全家桶（推薦）
- react全家桶 （推薦，生態全）
Ⅷ 面試時被詢問自己的缺點該如何回答
面試中，有一道經典的問題：談談自己的缺點，或者談自己的優缺點。
如果問你，你會怎麼回答？
想起自己第一次被問到這道題，非常緊張，心想，要是把我的缺點暴露給你，那還得了。
於是，盡講些無關的小問題。
比如，說自己有點強迫症，做事情總比別人花多一點時間。又比如，說自己性格著急，一有任務，恨不得趕緊做完，有時還得主動加班。
後來，自己帶團隊、招人，角色變換了，看問題的角度也隨之改變，才發現，自己以前回答的，都是網上所謂面經的套路——把缺點包裝成優點，一點都不走心。
難道面試官不懂這些嗎？這樣只會讓人覺得，你不敢直面問題。
再後來，經過管理培訓，才知這道題背後有深意。
此後，我招人面試都用這道題，考察候選人，特別好用。不過，很少遇見好的回答。
為了幫你真正答好這道題，我總結了「 3 個 3 」：3 個考察重點、3 個答題要點、3 個練習方法，從根本上提升自己，無懼問題。
一、3 個考察重點
以前講過，想答好面試題，關鍵在於，理解題目背後考察什麼。
這道題考察的是候選人的自我認知能力、自我改進能力、與崗位的匹配程度。
1. 自我認知能力
自我認知能力，也是自省能力。考察的是，你對自己的能力、水平，是否有足夠清晰、正確的認識。
不過，人總是習慣性高估自己，覺得自己很好，意識不到問題。
之前網上很火的「達克效應」，說的就是這個，大部分人並不知道自己不知道，要經常自我反省，才能慢慢意識自己存在的問題。
△ 達克效應（圖片來自網路）
2. 自我改進能力
能正確認識自己，還要有相應的解決方案和改進行動。
知道自己有啥問題，確實很不容易。不過，有些人即便知道問題在哪，也總會給自己找各種借口。比方說自己天生就這性格，改不了。
所以，當一個候選人，敢於說出自己的問題，又能說出相應的改進辦法和行動證明，自然能讓面試官對其刮目相看。
這對日後工作是很有幫助的。
我們的工作，也是要不斷地反思、總結，才能進步，越做越好。
3. 與崗位的匹配程度
實際上，招人，不是要找一個很牛、很完美的人，而是要找一個能力強項剛好是崗位所需的，且缺點對工作影響程度可接受的人。
因此，讓候選人講自己的優缺點，可進一步完善面試官的判斷，分析候選人與崗位的匹配程度。
比如，一個高級產品崗位，需要比較強的統籌規劃能力，而候選人卻容易陷入細節，缺乏全局觀，那就不太合適。
二、3 個答題要點
知道題目考察什麼，答題時，還應注意這 3 個要點。
1. 優缺點要與應聘崗位相關
在我聽到的答案中，大部人容易講到與工作無關的事情上，其實是怕暴露自己的問題，或者壓根沒認真思考過自己的優缺點。
想答好這道題，講的優缺點與應聘崗位的工作內容得有關聯。
假設，你面試產品經理，你的優點就應該是能幫助你做好這個崗位的強項能力。
比方說，溝通能力比較好，能夠與業務、運營、開發多種角色順暢地溝通。或者說，你擅長數據分析，能通過數據發現產品可優化的地方。
缺點方面，確實為難人，既要跟工作相關，又不能是致命問題。
同樣面試產品經理，你總不能說自己溝通不行，如果真有這個問題，就得好好反省，是否適合這個崗位了。
你可以說一些這個崗位暫時不是重點能力的方面，假設你應聘的是執行崗，那你可以說高階一點的能力，比如說管理能力還不夠。
2. 談優點，有案例、有評價
談優點容易吹過頭，注意要用案例來證明自己，最好有別人的評價。
比如，說自己的團隊協作能力不錯，應該用實際案例來說明，因為你這個能力，幫團隊解決過什麼問題，取得什麼成績，最後團隊、領導如何評價。別人說好，才是真的好。
3. 談缺點，有方案，有改進
談缺點，除了要足夠坦誠、直面不足，還要有改進的方案。
講出缺點後，告訴面試官自己正在哪些方面改進，目前做得怎樣。有策略、有行動，才是真正的變負面為正面。
Ⅸ 常見的前端集成部署方案有哪些各自的優缺點是什麼
前端行業經歷了這么長時間的發展，技術元素非常豐富，這里列舉出一般web團隊需要用到的技術元素：
開發規范：包括開發、部署的目錄規范，編碼規范等。不要小瞧規范的威力，可以極大的提升開發效率，真正優秀的規范不會讓使用者感到約束，而是能幫助他們快速定位問題，提升效率。
模塊化開發：針對js、css，以功能或業務為單元組織代碼。js方面解決獨立作用域、依賴管理、api暴露、按需載入與執行、安全合並等問題，css方面解決依賴管理、組件內部樣式管理等問題。是提升前端開發效率的重要基礎。現在流行的模塊化框架有requirejs、seajs等。
組件化開發：在模塊化基礎上，以頁面小部件(component)為單位將頁面小部件的js、css、html代碼片段放在一起進行開發、維護，組件單元是資源獨立的，組件在系統內可復用。比如頭部(header)、尾部(footer)、搜索框(searchbar)、導航(menu)、對話框(dialog)等，甚至一些復雜的組件比如編輯器(editor)等。通常業務會針對組件化的js部分進行必要的封裝，解決一些常見的組件渲染、交互問題。
組件倉庫：有了組件化，我們希望將一些非常通用的組件放到一個公共的地方供團隊共享，方便新項目復用，這個時候我們就需要引入一個組件倉庫的東西，現在流行的組件庫有bower、component等。團隊發展到一定規模後，組件庫的需求會變得非常強烈。
性能優化：這里的性能優化是指能夠通過工程手段保證的性能優化點。由於其內容比較豐富，就不在這里展開了，感興趣的同學可以閱讀我的這兩篇文章 [1] [2]。性能優化是前端項目發展到一定階段必須經歷的過程。這部分我想強調的一點是性能優化一定是一個工程問題和統計問題，不能用工程手段保證的性能優化是不靠譜的，優化時只考慮一個頁面的首次載入，不考慮全局在宏觀統計上的優化提升也是片面的。
項目部署：部署按照現行業界的分工標准，雖然不是前端的工作范疇，但它對性能優化有直接的影響，包括靜態資源緩存、cdn、非覆蓋式發布等問題。合理的靜態資源資源部署可以為前端性能帶來較大的優化空間。
開發流程：完整的開發流程包括本地開發調試、視覺效果走查確認、前後端聯調、提測、上線等環節。對開發流程的改善可以大幅降低開發的時間成本，工作這些年見過很多獨立的系統（cms系統、靜態資源推送系統）將開發流程割裂開，對前端開發的效率有嚴重的阻礙。
開發工具：這里說的工具不是指IDE，而是工程工具，包括構建與優化工具、開發-調試-部署等流程工具，以及組件庫獲取、提交等相關工具，甚至運營、文檔、配置發布等平台工具。前端開發需要工具支持，這個問題的根本原因來自前端領域語言特性（未來我會單獨寫一篇文章介紹前端領域語言缺陷問題）。前端開發所使用的語言（js、css、html）以及前端工程資源的載入與定位策略決定了前端工程必須要工具支持。由於這些工具通常都是獨立的系統，要想把它們串聯起來，才有了yeoman這樣的封裝。前面提到的7項技術元素都直接或間接的對前端開發工具設計產生一定的影響，因此能否串聯其他技術要素，使得前端開發形成一個連貫可持續優化的開發體系，工具的設計至關重要。