2020ironman 12th – Modern Web – Day01 – 為什麼要寫這個主題以及進化路線

分享

為什麼要寫這個主題

歸納出多套屬於自己的獨特的技術體系因該是每個工程師一直以來的必修功課

從七八年前以Wordpress作出大量的行銷用網頁與電商系統供公司同仁使用

到後幫客戶搬遷與優化各種服務到雲端上

由簡至繁、由繁至簡,一直是一個很大的課題

我們可以使用很複雜但是很棒的工具達成目的,但是絕大部分的人只會希望給我個解決方案直接使用就好

如果凡事都可以那麼簡單就好了

就如同PHP,入門很容易但是要做到專家需要非常大的努力

我在PHP領域中不是個專家,但是我對於PHP底層能怎樣拆分已經練就一身功夫

藉由這次活動整理出對於自身的一個技術體系,整理出到底還有哪邊是可以補足相關技術細節

PHP網站底層進化路線

傳統上大多數的PHP網站本著能用就用一台打天下的形式運行,但就這幾年網路行銷的興起與廣告難度降低,人人都可以對網站進行大幅度的導流,不進行服務進化勢必會造成障礙。就本系列粗估拆分的工作上就可以看出一個網站如果進行拆分可以分出多少服務項目。在整理技術體系的同時也進行自身的提升。

本次進化路線

  • VPS(web+db)(Lightsail)
  • CDN(cloudfront) + VPS(web+db)(Lightsail)
  • CDN(cloudfront) + VM(web+db)(EC2)
  • CDN(cloudfront) + VM(web+db)(EC2)+ VM(DB)(RDS)
  • CDN(cloudfront) + 附載平衡(ALB) + VM(web)(EC2) + VM(DB)(RDS)
  • CDN(cloudfront) + 附載平衡(ALB) + VM(web)(EC2) + VM(DB)(RDS) + File(EFS)
  • CDN(cloudfront) + 附載平衡(ALB) + VM(web)(EC2) + VM(DB)(RDS) + File(EFS) + S3(EFS)
  • CDN(cloudfront) + 附載平衡(ALB) + VM(web)(EC2) + VM(DB)(RDS) + File(EFS) + S3(EFS)
  • CDN(cloudfront) + 附載平衡(ALB) + VM(web)(EC2) + VM(DB)(RDS) + File(EFS) + S3(EFS) + 監控(Cloudwatch)
  • CDN(cloudfront) + 附載平衡(ALB) + VM(web)(EC2)(Auto Scaling) + VM(DB)(RDS) + File(EFS) + S3(EFS)+ 監控(Cloudwatch)
  • CDN(cloudfront) + 附載平衡(ALB) + VM(web)(EC2)(Auto Scaling) + VM(DB)(RDS) + File(EFS) + S3(EFS) + Cache(Redis)+ 監控(Cloudwatch)
  • CDN(cloudfront) + 附載平衡(ALB) + VM(web)(EC2)(Auto Scaling) + VM(DB)(RDS) + File(EFS) + S3(EFS) + Cache(Redis) + 監控(Cloudwatch) + log server(Cloudwatch logs)
  • CDN(cloudfront) + 附載平衡(ALB) + VM(web)(EC2)(Auto Scaling) + VM(DB)(RDS) + File(EFS) + S3(EFS) + Cache(Redis) + 監控(Cloudwatch) + log server(Cloudwatch logs) +(監控中心)cloudwatch dashboard
  • CDN(cloudfront) + 附載平衡(ALB) + VM(web)(Container)(Auto Scaling) + VM(DB)(RDS) + File(EFS) + S3(EFS) + Cache(Redis) + 監控(Cloudwatch) + log server(Cloudwatch logs) +(監控中心)cloudwatch dashboard

Read more

雲端架構延遲問題:為什麼AP與DB不能放太遠?

雲端與地端的架構差異認知不足導致的性能陷阱 前言 許多企業在上雲初期,經常基於成本考量或錯誤認知,將應用程式伺服器(AP)與資料庫(DB)部署在不同區域。這種做法在地端環境中影響較小,但在雲端環境中卻會造成嚴重的性能問題。本文透過台北-東京的實際案例,說明距離對雲端架構的致命影響。 核心問題: * 地端思維:同個機房內不同區域延遲可忽略 * 雲端現實:跨區域延遲可達數十毫秒 * 結果:連線建立時間從毫秒級暴增到秒級 1. 地端 vs 雲端的延遲差異 1.1 地端環境的延遲特性 傳統地端機房: 同機房不同機櫃:RTT < 1ms 同城市不同機房:RTT < 5ms 同國家不同城市:RTT < 20ms 地端架構師的經驗: * AP和DB分別放在不同機櫃:幾乎無延遲影響 * 災備機房放在不同城市:RTT約10-15ms,可接受 * 習慣性認為「網路延遲不是問題」

By Albert Yu