我們的系統也從第一代平臺開始到現在第四代平臺更換中，對這四代平臺做一個簡單的介紹： 第一代平臺，主要是集中式，以快速上線為目的；第二代平臺主要是分布式改造，緩解各服務壓力；第三代平臺主要做服務端SOA治理，后臺統一賬戶中心；第四代微服務化改造，已達到灰度上線、動態部署集中管理的目的。?

引自這里?六年程序生涯

最近面試node,在一些小型企業都會問到這個問題:如果讓你部署一個網站,從在阿里云買服務器到最后的上線后期維護,你一個人搞的定嗎?你用node部署整個網站,整個流程需要注意哪些點.這個問題當時回答上了一部分,后來自己考量,在這里做個總結.如果有哪位覺得下面說的不對或者有補充,歡迎提出.

引子這段話是這個問題的一部分答案.我這里總結為以下幾個階段: 穩定地快速上線=> 高并發 => 安全 => 公共系統提取(多為用戶系統) => 多系統之間的交互(調度系統的建設) => 其他

穩定地快速上線

這一階段更多的是有時間作為摸底,所以很少有優化,更多情況下是跑通整個流程,盡可能的減少bug,先快速上線再說.這一階段最重要的是做好功能測試.

高并發

處理高并發的方法從大方向上分為兩種:一種是加快響應速度;另一種是減少請求數量.服務器上線以后,很容易遇到高并發的問題,node本身就是處理高并發的好手,在這方面有得天獨厚的優勢;以下是幾種處理高并發的方法:

加快響應速度

• node的特點是異步IO,事件循環,在網絡IO及文件IO中優先選擇異步方式進行,能用數據流(pipe)的盡量使用數據流;
• 數據庫讀寫分離,盡量使用索引查詢;避免向客戶端返回大數據,盡可能使用分頁;
• nodejs子開啟子進程,用于處理非主線任務(有條件另開服務器);
• 代碼優化:可以搭配node壓力測試工具進行代碼優化apache bench;ab測試是對接口的測試,通過他我們可以完整的將一個接口在request/response間的每一步需要的時間打印出來,通過修改并發數進行測試對比,從而判斷出哪段代碼需要優化.這里有個小工具可能會好一些.

減少請求數量

• 分散請求數量.這里有個名詞是負載均衡,標準是nginx.快速而又不經濟的做法,可以通過更多的服務器做負載均衡;對于多核CPU,我們可以同時啟動多個Nodejs進程,外部通過nginx做負載均衡;

• 靜態資源減少請求數量

  • 對于靜態資源可以盡可能的走CDN或者部署到壓力較小的服務器上,優先CDN,用戶體驗好,服務端壓力小,缺點燒錢;
  • 可以緩存,靜態資源客戶端緩存也有著減少服務器請求;
  • 合并請求,減少請求數量,多指css/js;
  • 頁面優先只加載首屏資源或者模板資源,剩余使用ajax延后加載;

安全

服務端: 這方面沒做過,可以直接購買阿里云或百度云的云盾服務;

數據安全: 數據庫安全同上;注意經常備份;處理好并發控制等;

客戶端安全: 升級網站協議為HTTPS;

公共系統提取

當我們的產品系統開發的越來越多的時候,將一些公共系統提取出來顯得尤為必要,就像前端的組件化一樣.一方面資源信息共享,一方面減少了開發量,加快開發效率,還促進了分工.

調度系統建設

當子系統越來越多的時候,就需要建設調度系統,來幫助管理員維護子系統間的負責通信,功能調度等.

當然后面其實還有很多內容,監控報告分析,發布與回滾(灰度發布)等等.

轉載于:https://www.cnblogs.com/zhaowinter/p/6715105.html

總結

以上是生活随笔為你收集整理的node服务成长之路的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。