[b]1.優化 [/b]
不要過度優化。這可能會從你的重要函式中拿走一些寶貴的資源。
不要過早考慮擴充套件。考慮你系統當前面臨的或可能支援的 10 倍負載，在大多數情況下會影響生產效率。在無法滿足 2 個或 3 個服務前，關聯式資料庫還是不錯的選擇。
為了水平擴充套件性而優化和重構前，先優化單個節點的效能。
[b]2.工具 [/b]
工具是熟練的技師造的。工具不能使技師變得熟練。
工具本身不能解決問題，但正確的使用它可以解決問題。
想要短期內熟練掌握一種工具用來生產，在遇到不是很棘手的問題時查詢這些工具使用者手冊。
[b]3.cookies [/b]
盡量使用 cookies 來儲存資料。
如果你擔心損害，給它們簽名。
如果你擔心使用者看見它們的內部，給它們加密。
和構建過多的服務端相比，使用使用者的瀏覽器作為資料儲存的複製節點還是比較廉價的。
[b]4.資料儲存 [/b]
nosql 不能解決所有問題。
關聯式資料庫也不能解決所有問題。
其他的一切也不能解決所有問題。
找到需求，了解原因，然後找解決方案。
[b]5.自動化 [/b]
當你發現你做某件同樣的事超過 2 次，寫指令碼讓它自動執行。
當使用者在監控系統發現前報告了錯誤，寫個更好的監控工具。
[b]6.版本控制 [/b]
版本控制同樣重要。
提供審計跟蹤來幫助了解之前發生了什麼。人不可能記住所有事情。當很難解決產品問題時，這將是乙個很好的查詢問題的地方。
[b]7.網路 [/b]
考慮包而不是位元組來節省負載時間。
壓縮乙個 400 位元組的 css 檔案是沒必要的，因為最小的 ip 資料報的大小是 1300 位元組左右（如果資料小於這個大小，餘下的包會被空位元組填充）。
事實上，壓縮和解壓縮會消耗服務端和客戶端的 cpu 資源。
不要有在 html 中嵌入 css 檔案來節省一些額外包的想法。
[b]8.快取 [/b]
快取所有靜態資料
給物件新增隨機數或字元來強制載入該物件。
如請求「 /images/myphoto.12345.jpg 」而不是「 /images/myphoto.jpg 」。
去掉隨機 id ，使用如 htaccess 重寫規則。
盡可能使用 cdns ，但確保你切換到 cdn 之前，了解你頁面的所有物件。無意義的**可能會損失掉以前很好的載入時間。
[b]9.人 [/b]
當你為運維團隊招人時，千萬不要僱傭連他 / 她遇到的乙個生產問題都記不住的人。你要識別出那些遇到問題並能解決問題的人。
允許他們在生產中冒險，觀察他們如何完成它。冒險是適應新思想的一部分。讓他們失敗並幫助他們知道怎樣提高。
[b]10.系統 [/b]
了解你的系統的基線。系統當前統計的乙個例項或快照不能滿足系統的所有當前的狀態。
使用工具每隔一段時間取得資料會幫助你了解這些資訊。
11.moderation
moderate the tools and process you use
moderate the moderation
本文摘自：[url= [/url]
Flume的可擴充套件性
flume的可擴充套件性 flume採用了三層架構，分別為agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和 collector由master統一管理，這使得系統容易監控和維護，且master允許有多個 使用zookeeper進行管理和負載均衡 這就避 ...
Flume的可擴充套件性
flume的可擴充套件性 flume採用了三層架構，分別為agent，collector和storage，每一層均可以水平擴充套件。其中，所有agent和 collector由master統一管理，這使得系統容易監控和維護，且master允許有多個 使用zookeeper進行管理和負載均衡 這就避 ...
系統的可擴充套件性
到底什麼是可擴充套件性？這年頭，作為軟體設計架構師如果系統沒有可擴充套件性對外交流時都不好意思。但是如何選擇可擴充套件性方案？水平擴充套件還是垂直擴充套件？是不是很矛盾呢，本文為你分析可擴充套件性的真實含義和實際專案中的取捨。每每和別人提及可擴充套件性的含義時，很多人開始討論提高效能，實施高可用性，...