博客

我們在伺服器和儲存做raid的時候，常常說做了raid後磁碟的IO會提升很多，資料會條帶化寫入。那麼，到底什麼是條帶化呢？ ？ ？

條帶（strip）是把連續的資料分割成相同大小的資料區塊，把每段資料分別寫入到陣列中的不同磁碟上的方法。
簡單的說，條帶是一種將多個磁碟機合併為一個磁碟區的方法。 許多情況下，這是透過硬體控制器來完成的。
當多個進程同時存取一個磁碟時，可能會出現磁碟衝突。
大多數磁碟系統都對存取次數（每秒的 I/O 操作，IOPS）和資料傳輸速率（每秒傳輸的資料量，TPS）有限制。
當達到這些限制時，後面需要存取磁碟的進程就需要等待，這時就是所謂的磁碟衝突。
避免磁碟衝突是最佳化 I/O 效能的重要目標，而 I/O 效能的最佳化與其他資源（如CPU和記憶體）的最佳化有著很大的差異 ,I/O 最佳化最有效的手段是將 I/O 最大限度的進行平衡。
條帶化技術是一種自動的將 I/O 的負載平衡到多個實體磁碟上的技術，條帶化技術就是將一塊連續的資料分成很多小部分並把他們分別儲存到不同磁碟上去。
這就能使多個進程同時存取資料的多個不同部分而不會造成磁碟衝突，而且在需要對這種資料進行順序存取的時候可以獲得最大程度上的 I/O 並行能力，從而獲得非常好的效能。
由於條帶化在 I/O 效能問題上的優越表現，以至於在應用系統所在的運算環境中的多個層次或平台都涉及了條帶化的技術，如作業系統和儲存系統這兩個層次中都可能使用條帶化技術。
條帶化後，條帶磁碟所能提供的速度比單一碟所能提供的速度要快很多，由於現在儲存技術成熟，大多數系統都採用條帶化來實現系統的I/O負載 分擔，如果OS有LVM軟體或硬體條帶設備，決定因素是條帶深度(stripe depth)和條帶寬度(stripe width)。
條帶深度指的是條帶的大小，也叫條帶大小。
有時也被叫做block size, chunk size, stripe length 或granularity。這個參數指的是寫在每塊磁碟上的條帶資料塊的大小。
RAID的資料塊大小一般在2KB到512KB之間(或更大)，其數值是2 的次方，即2KB,4KB,8KB,16KB這樣。
條帶大小對效能的影響比條帶寬度難以量化的多。
·減小條帶大小: 由於條帶大小減小了，則檔案被分成了更多個，更小的資料塊。
這些資料塊會分散到更多的硬碟上存儲，因此提高了傳輸的效能，但是由於要多次尋找不同的資料區塊，磁碟定位的效能就下降了。 ·增加條帶大小: 與減少條帶大小相反，會降低傳輸效能，提高定位效能。 根據上邊的論述，我們會發現根據不同的應用類型，不同的性能需求，不同驅動器的不同特點(如SSD硬碟)，不存在一個普遍適用的”最佳條帶大小”。
所以這也是儲存廠家，檔案系統編寫者允許我們自己定義條帶大小的原因。
條帶寬度是指同時可以並發讀或寫的條帶數量。這個數量等於RAID中的實體硬碟數量。
例如一個經過條帶化的，具有4塊實體硬碟的陣列的條帶寬度就是 4。增加條帶寬度，可以增加陣列的讀寫效能。
道理很明顯，增加更多的硬碟，也就增加了可以同時並發讀或寫的條帶數量。
在其他條件一樣的前提下，一個由8塊 18G硬碟組成的陣列相比一個由4塊36G硬碟組成的陣列具有更高的傳輸性能。
下面先看下影響IO大小的作業系統和Oracle的相關參數：db_block_size oracle資料區塊的大小，也決定了oracle一次單一IO請求中oracle資料區塊的大小db_file_multiblock_read_count：在多資料區塊讀取時，一次讀取資料區塊的數量，它和參數db_block_size一起決定了一個多資料區塊讀的大小作業系統的資料塊大小：這個參數決定了Redo Log和Archive Log操作時的資料塊大小，對於大多數Unix系統來說，該值為512K。
最大作業系統IO大小：決定了一次單一的IO操作的IO大小的上限，對於大多數Unix系統來說，由參數max_io_size設定。
sort_area_size：記憶體中sort area的大小，也決定了並發排序操作時的IO大小。
hash_area_size：記憶體中hash area的大小，也決定了哈希操作的IO大小。在OLTP系統中，會存在大量小的並發的IO請求。
這時就需要考慮選擇比較大的條帶深度。
使條帶深度大於IO大小就稱為粗粒度條帶（Coarse Grain Striping）。在高並行度系統中，條帶深度為（n * db_block_size），其中n為大於1的整數。
透過粗粒度條帶能實現最大的IO吞吐量（一次物理IO可以同時回應多個並發的邏輯IO）。
大的條帶深度能夠使像全表掃描那樣的多資料塊讀取操作由一個磁碟驅動來回應，並提高多資料塊讀取操作的效能。
在低併發度的DSS系統中，由於IO請求比較序列化，為了避免出現熱點磁碟，我們需要避免邏輯IO只有一塊磁碟處理。
這是，粗粒度條帶就不適合了。
我們選擇小的條帶深度，使一個邏輯IO分散到多個磁碟上，從而實現IO的負載平衡。
這就叫做細粒度條帶。條帶深度的大小為（n * db_block_size），其中n為小於多資料區塊讀取參數（db_file_multiblock_read_count）大小的整數。可以簡單地理解為並發程度高的IO採用粗粒度條帶化，並發程度低的IO採用細粒度條帶化。
在IO過程中，你無法保證Oracle資料塊的邊界能和條帶單元的大小對齊。如果條帶深度大小和Oracle資料塊大小完全相同，而它們的邊界沒有對齊的話，那麼就會存在大量一個單獨的IO請求被兩塊磁碟來完成。
在OLTP系統中，為了避免一個邏輯IO請求被多個物理IO操作完成，條帶寬度就需要設定為兩倍或兩倍以上於Oracle資料塊大小。例如，如果條帶深度是IO大小的N倍，對於大量並發IO請求，我們可以保證最少有（N-1）/ N的請求是由一塊磁碟來完成。

01 OTV技術解析
隨著資料中心和虛擬化技術的快速發展，傳統的二層網路架構逐漸暴露出許多問題，尤其是在多資料中心互聯的場景中，如何實現高可靠、高效且能夠保證業務連續性的解決方案，成為當前網路架構設計中的重要課題。
面對這些挑戰，如何透過新技術來應對並滿足這些需求？
OTV（Overlay Transport Virtualization）作為一個成熟的解決方案，成功地為資料中心之間的二層網路互聯提供了有效的支援。
02傳統資料中心建置面臨的挑戰
1.泛洪問題傳統的二層VPN技術依賴廣播泛洪來進行MAC位址學習。廣播轉送的封包會擴散到所有資料中心，這種泛洪機制可能導致環路的產生，造成嚴重的網路效能問題。
尤其在資料中心互聯（DCI）場景中，廣播風暴可能會影響整個網路的穩定性。
2.偽線維護問題傳統的二層網路協議，如偽線（Pseudowire）技術，需要在所有站點之間建立隧道。
由於隧道的數量隨著站點數增加而呈平方增長（N * (N-1) / 2），導致了管理上的複雜性，增加了維護難度並大大降低了線路的利用率。
3.多歸屬問題隨著資料中心內組網高可用性的提升，DCI也需要考慮冗餘性來確保業務的連續性。
傳統的DCI冗餘方案需要依賴多個裝置來實現，這不僅可能引發二層環路，還會導致鏈路利用率低且易出錯。
03OTV技術OTV技術作為目前市場上最成熟的資料中心間二層網路互聯方案之一，成功解決了傳統網路架構中存在的泛洪問題、隧道維護問題以及多歸屬問題。
1.OTV基本原理OTV（Overlay Transport Virtualization）是一種基於MAC位址的路由技術。
它透過將MAC位址封裝在傳統IP套件中進行轉發，從而在資料中心之間建立一張二層路由表。
與傳統的二層轉送方式不同，OTV採用資料平面建立MAC路由表，並在控制平面透過協定同步路由訊息，從而避免了生成樹協定帶來的環路問題。
2.OTV的核心角色OTV系統包含四種主要角色：
邊界設備：用於資料中心間的互聯，建立OTV鄰居關係，並傳遞MAC可達資訊。一般採用支援OTV的交換器、路由器等設備。
內部連接埠：OTV的內部連接埠為傳統二層介面（如Trunk和Access），用於連接內部網路。
加入端口：這是一個三層接口，多個Overlay可以共享一個加入端口，用於連接外部網路。
Overlay連接埠：OTV中的邏輯接口，用於封包的封裝。
3.OTV鄰居關係的建立
OTV邊界設備透過兩種方式來建立鄰居關係：群播和單播。
群播環境下的OTV鄰居建立在多播網路環境中，OTV邊界設備透過組播技術建立鄰居關係，具體步驟如下：每個邊界設備透過加入OTV的連接埠發出IGMP封包，加入特定的ASG群組，用於交換控制協定的資訊。
OTV控制協定產生Hello包，宣告設備的存在，並觸發與其他邊界設備的鄰居建立過程。
Hello包透過Overlay介面傳送給遠端邊界設備，發送前會進行OTV封裝，來源IP為發送端加入端口，目的IP為組播位址。
群播複製封裝後的Hello包，發給其他遠端邊界設備。收到Hello包的遠端設備進行解封裝，完成鄰居關係的建立。
單播環境下的OTV鄰居建立在單播環境中，OTV設備需要註冊到一個或多個鄰居伺服器，這些伺服器負責動態發現鄰居訊息，並將這些資訊週期性地單播給所有OTV邊界設備。
每個設備可以根據鄰居伺服器的更新，動態調整其鄰居資訊。
04OTV技術的優勢與其他資料中心互聯技術相比，OTV具備以下幾項明顯的優勢：

1. 轉送與控制分離OTV採用了軟體定義的設計模式，將資料中心互聯的控制平面和轉送平面進行分離。
   這樣不僅有效防止了二層廣播泛洪影響到IP骨幹網絡，而且能夠自動處理多歸屬問題，提高了網路的穩定性和可擴展性。
2. 故障隔離能力強OTV透過分離轉送與控制，增強了多資料中心之間的故障隔離能力。它能有效控制STP（生成樹協定）域的隔離，防止未知單播和廣播封包泛洪，優化ARP封包的處理，並大幅提升了網路的可靠性。
3. 技術成熟度高OTV經過多個版本的迭代，從最初的依賴CPU轉發到現在依賴硬體晶片轉發，技術性能得到了大幅提升。
   OTV在業界已有大量的多活資料中心部署案例，技術的穩定性和可靠性已被廣泛驗證。
4. 骨幹網路依賴性低OTV的部署不依賴特定類型的骨幹網路。無論是自建的裸光纖、營運商專線或網際網路鏈路，OTV都能在這些網路環境中實現資料中心間的互聯，適應跨二層、跨三層、單播可達和組播可達的不同網路架構。
   05總結透過OTV技術，資料中心的網路能夠在確保高可靠性和高效能的同時，解決傳統二層網路架構中的泛洪問題、隧道管理問題和多歸屬問題。
   作為目前市場上最成熟的解決方案之一，OTV已經在多個行業中得到了廣泛的應用，尤其是在金融、互聯網等對業務連續性要求極高的行業。隨著資料中心虛擬化、雙活集群、虛擬機器遷移技術的廣泛應用，OTV技術將在未來的資料中心互聯中扮演更重要的角色，為全球資料中心網路提供更穩定、靈活和高效的互聯解決方案。

導讀：前端開發者正在回歸原生 JavaScript。
本文內容將闡述原生 API 和 AI 工具如何讓純 JavaScript 成為框架疲勞的解藥。
大家都累了，框架疲勞不再只是頑梗，而成了一種集體倦怠。曾經爭相想掌握 React、Vue 和 Svelte 的開發者們，如今正悄悄回歸他們曾經放棄的簡單：原生 JavaScript。
Web開發世界的風向標正在回歸極簡主義。
原生瀏覽器 API 正在興起、對效能的重視以及人工智慧輔助編碼的浪潮，使得純 JavaScript 不僅再次可行，而且令人耳目一新。
它是多年來臃腫的程式碼、抽象的概念以及 npm 依賴噩夢的「解藥」。
框架時代的轉捩點來了
多年來，框架一直是前端開發的預設選擇。
這些框架們承諾提供秩序、可擴展性和社區支持。
但隨著每個框架的不斷演進，其複雜性也隨之增加。
打包工具變得越來越龐大，建置時間越來越長，甚至一個普通的「Hello World」專案在運行任何一行程式碼之前就需要幾兆位元組的依賴項。
開發者開始質疑：使用這些鷹架真的值得嗎？
問題不在於框架本身，而是圍繞著它們滋生的文化。
新的框架層出不窮，每個框架都聲稱能夠修復前一個框架的缺陷。為了跟上不斷變化的生態系統，開發團隊不得不重構整個產品。
結果呢？無止盡的更迭，偽裝成創新的技術債出現，開發者也深陷於不斷重複學習的惡性循環之中。
到了2025年，人們終於意識到：Web不需要再增加一層，它需要一次徹底的重置。
而這次的重置正是以原生JavaScript的形式出現。
原生 API 已然成熟
其一，現代瀏覽器不再是過去那種笨拙的沙盒。
在過去幾年裡，Fetch、Web Components和 ES 模組等 API 已經發展成為成熟的生產級工具，取代了框架曾經提供的功能。
以前需要 React Hooks 或狀態管理函式庫才能完成的任務，現在只需幾行簡潔的程式碼，就能使用原生解決方案流暢地運作。
特別是 Web Components 標準，徹底改變了遊戲規則。它賦予開發者框架的模組化和封裝性，同時又不會將人們限制在其他人設計的架構中。
結合 Shadow DOM、自訂元素和模板字面量，開發者現在可以建立可重複使用、自包含的元件，這些元件可以在任何地方運行。
這種新出現的成熟度意味著開發者終於可以僅使用瀏覽器自帶的功能來建立動態、響應式且易於維護的介面。
依賴項、建構工具和樣板程式碼所帶來的「框架稅」不再是必要的。
因此，原生 JavaScript 不再老舊過時，而是再次變得高效潤滑。效率就是“新貨幣”
如今，Webr 運行更加講求速度與效能。
使用者期望近乎即時的互動體驗，而搜尋演算法則會懲罰反應緩慢的頁面。
框架繁多的應用，即便技術精湛，也難以提供穩定的性能，尤其是在行動端。
開發者們重新認識到，最佳的最佳化方法並非添加新的最佳化庫，而是減少程式碼編寫量。
原生 JavaScript 在 2025 年已經再次回歸主流，主要原因在於其應用程式啟動速度更快、渲染速度更快、調試也更方便。
它無需龐大的套件、載入腳本或協調演算法，載入時間大幅縮短。因為節省的每1 KB 空間都意味著留住一位使用者。
這種轉變是務實的：反應速度提升 50 毫秒遠比 JSX 或響應式綁定的語法糖更有價值。
前端風向已經轉向「無框架區域」。
但這並不意味著框架已經消亡，它們仍然主導著企業環境，但對於那些敏捷性和性能比傳統框架和抽象更重要的專案而言，風向已經轉向了「無框架區」。
解決這問題的關鍵不在於反叛，而是清晰。
AI工具再次賦予簡潔強大力量
諷刺的是，人工智慧加速了回歸簡潔的趨勢。
如今，開發者使用人工智慧助理來產生樣板程式碼、調試程式碼並推薦簡潔的原生程式碼。
語法越直接，效用越高。
而框架專有約定和層層抽象往往會讓人感到困惑。有了 AI 處理重複性模式，開發者不再需要框架來提高效率。
只需一個簡單的提示，就能建立響應式 UI 或直接在原生 JavaScript 中實現事件處理，完全避免了框架帶來的額外負擔。
突然間，「框架節省開發時間」這種常談的論調不再成立。
此外，人工智慧輔助重構讓梳理遺留框架變得更加容易。團隊可以逐步遷移，用原生元件取代框架元件。
這並非出於對早期 Web 開發的懷舊，而是在智慧工具時代對基本原理的深思熟慮的回歸。
微前端與無建構架構的興起
越來越多的現代級Web專案採用了微前端原則：小型、獨立的 UI 模組可以獨立加載，並透過共享契約進行通訊。
這種模組化轉變也符合現代貨櫃安全實踐，其中隔離單元可以部署和更新，從而實現更嚴格的控制和最小的表面暴露。
同樣，這種理念與原生 JavaScript 完美契合。
無需集中式建置系統或複雜的依賴關係樹，開發者可以模組化地推送更新，並在團隊間保持靈活性。
最終之目標：完全取消建置步驟。例如 ESBuild 和 Vite這樣的工具已經將編譯過程簡化到幾乎看不見的地步，但人們最終目標是完全消除建置步驟。
原生模組的導入功能使這個願景成為現實。開發者可以直接從編輯器將更新推送到生產環境，而無需等待管線進行轉譯或打包。
這種轉變重新定義了「輕量級」的真正意義。
2026 年的現代原生 JavaScript 專案不再是原始的，而是精準的。它只做需要做的事情，不多也不少。
在一個追求速度與控制的世界裡，這不僅是優雅，更是一種競爭優勢。
學習曲線疲勞與開發者自主性
開發者們這幾一些似乎已經筋疲力盡，每隔幾個月，就會有一個新的框架出現，聲稱能帶來救贖，結果卻只是用另一種抽象取代了舊有的抽象。
為了保持「最新」而付出的認知成本已經令人難以承受。
原生 JavaScript 提供了一個喘息之機，一個不會隨著 GitHub 的下一次更新而失效的通用基礎架構。
我們無需記住新的鉤子系統、狀態 API 或指令語法，只需理解語言本身即可。
這種自主性的回歸讓開發者重新掌握了程式設計的創造性。
他們可以專注於解決問題，而不是記憶語法模式。隨著教育程度和能力的提高，JavaScript 實踐營也開始重新強調基礎知識。
結果是依賴框架的開發者減少了，而能夠從核心層面思考表現、結構和行為的開發者增加了。
這種轉變既是技術層面的，也是文化層面的。生態繫再平衡
回歸原生 JavaScript 並不意味著框架的立即消亡，而是重新定義了它們的用途。
框架正在從預設設定演變為可選層。
它們的存在是為了解決特定的、大規模的問題，而不是被嵌入到每個落地頁與元件中。
生態系統正圍繞著原生標準而非專有語法而凝聚。
如今，React、Vue 和 Svelte 正在悄悄精簡功能，更加重視互通性。
整個生態系統正圍繞著原生標準而非專有語法而凝聚。
框架開發者現在的設計理念是“漸進式採用”，這意味著開發者可以選擇加入，而不是被鎖定在某個框架中。
這種重新平衡反映了其他技術領域同樣正在發生的事情。
就像 DevOps 從關注工具轉向關注文化一樣，2026 年的前端開發也不再關注你使用什麼，而是關注你如何有效地使用它們。
原生 JavaScript 並非一種否定，而是一種重新調整。
結語
框架帶來的後遺症並非永久性的──它只是一記警鐘。
開發者終於意識到，進步的關鍵不在於堆砌抽象，而是掌握背後的基本原則。
曾經被認為「過於簡陋」的原生 JavaScript，如今已演變為建立精簡型 Web 的真正強大引擎。
2026 年，使用原生 JavaScript 編寫程式碼將是一種趨勢，它絕不意味著倒退，而是意味著向前發展——程式碼清晰、可控，而且五年後依然適用。
框架會不斷演進，工具會不斷湧現，但根本的解決方法始終如一：回歸 Web 運行的本質。
作者：場長