原文出處: 後端技術雜談java
好比,沒有把一些須要併發執行時使用的線程數設置成可在屬性文件中配置。那麼你的程序不管在DEV環境中,仍是TEST環境中,均可以順暢無阻地運行,可是一旦部署在PROD上,把它做爲多線程程序處理更大的數據集時,就會拋出IOException,緣由也許是線上環境併發形成也許是其餘。若是線程數目能夠在屬性文件中配置,那麼使它成爲一個單線程應用程序就變得十分容易了。咱們再也不須要爲了解決問題而反覆地部署和測試應用了。這種方法也一樣適用於配置 URL、服務器和端口號等。git
這裏推薦使用屬性文件外化這些配置,文件格式使用properties、yaml、hocon、json均可以。下面的類實現了對這些格式的文件的spring注入支持,包括佔位符支持。github
生產過程當中一個典型的場景就是隻使用1到3個賬戶進行測試,而這個數量本應是1000到2000個的。在作性能測試時,使用的數據必須是真實而且未經裁剪的。不貼近真實環境的性能測試,可能會帶來不可預料的性能、拓展和多線程問題。這裏也能夠採起預發佈環境的方式來解決部分問題。sql
不論是RPC調用仍是對於第三方服務的調用,都不能想固然的認爲可用性是100%的。不容許出現服務調用超時和重試,將會對應用程序的穩定性和性能形成不利的影響。數據庫
網絡服務隨處可見,從而使得黑客能夠輕易地利用它進行拒絕服務攻擊。因此,設計系統時,須要遵循「最小權限」原則,採用白名單等方式。json
不只僅對於傳統的開發流程,即便對於敏捷開發,這些文檔也是必不可少的,不然在後續的維護、交接上會帶來很大的不便。後端
對於系統一些相當重要的功能模塊要作好對其的監控,防止其影響系統的運行,形成不可估算的損失。另外,若是能夠,監控到故障後去去試圖恢復,恢復失敗再發送告警。對於一些很重要的數據文件,還要作到冗餘備份,防止發生一些忽然故障形成數據丟失。設計模式
好比create_time、update_time能夠說明記錄的建立和更新時間。create_by、update_by能夠說明記錄是由誰建立和更新的。緩存
此外,刪除記錄有時候並不是真正刪除,這時須要設計表示此記錄狀態的列,如能夠取‘Active’或‘Inactive’的 ‘status’列。
新的功能上線時,若是發生故障,沒有一份回滾計劃,那麼可能會手忙腳亂而形成線上服務一段時間不可用。有一個良好的回滾計劃,可讓你可以有條不紊的執行相關操做,在可控時間內將系統恢復到一個可運行的狀態。
對於項目中用到的內存、數據庫、文件、緩存等,要作好量化分析。預估出將來一段時間的空間佔用,給運維分配機器時一個參考。防止,因爲數據量增加過快,致使存儲不夠。這一點是很是重要的,否則很容易形成線上服務不可用。
系統部署的平臺是一個相當重要的部分。對於部署平臺的描述,不能僅限於一臺服務器、兩個數據庫這個層面,至少須要包括
不少狀況下,開發者會在生產系統中使用一門想要學習的語言或某種工具。一般這不是最好的選擇。好比,爲已經其實是關係型的數據使用NoSQL數據庫。不論是語言仍是工具,都有其適用的場景。不能求新,也不能以「自我」爲標準。