從後端開始，到架構之路 - 官承翰

tags: MOPCON 2019

Who am I

• LeadBest Consulting Group - 專家工程師
• LIS 情境科學教材 - 維運 / 顧問人員

今天不談技術，談經驗

PHP是世界上最棒的語言 +1

Agenda

• 01 從後端開始
• 02 什麼是架構
• 03 那些年，失敗的架構經驗
• 04 成為一個合格的架構師

從後端開始

• 所有商業上的交易流程都是依靠後端完成
• 壞的
  • 壞的 UI 可能會嚇跑使用者
  • 壞的後端會讓公司連錢都賺不到(想想有些十分醜的 UI/UX 的公司還是照樣活到現在)
  • 24 hr 網拍 PXHOME 前端做得很爛為什麼能賺得到錢，因為它們的後端做得很好

開公司就是為了賺錢，不是慈善機構
所以身為後端工程師一定要懂的架構

程式碼上的架構 - 框架(Framework)

部屬上的架構(laravel, django)

• 程式上的框架定義了：

1. 規範
2. 統一資料匣結構
3. 統一的命名規則

但這些真的有幫助嗎？

框架良好的區分模組

• Laravel ['lærəvel]

程式上的框架或規範往往都會困擾些剛入門的後端工程師

後端的進步延伸了不同系統架構

系統上的架構 (Architecture)

後端的結構越來越複雜，需要 Jobs 時，就有 Job queue
框架造就了系統架構的演進

什麼是架構

• 架構跟框架的差別？
  • 一個強調程式上(框架)
  • 一個是程式上更加優化，主要是部署方面(架構)
• 跟框架一樣，強調模組化，元件可以被重複使用(component)
• 為了高性能高擴展(scalability)而進行架構設計

對架構的誤解

1. 不要太相信雲(cloud)
2. 不要太相信容器(container)
3. 不要認為一定要上 Kubernetes(K8s)
4. 過度設計往往會帶來災難，除非你很厲害

You went full docker man -> never go full docker

對，我是過度設計的信仰者，但我不建議你這樣做。(流量可能沒高到需要做)

slow of timeout of dns resolving inside docker

案例1: 資料庫上線後莫名掛掉

半夜兩點被 call 起來，結果 900 多個使用者的資料都不見了，後來還是靠著其他服務才救回來的

盡量不要使用不熟架構去做使用，因為可能會有例外的問題發生，導致問題很難解決

案例2: API 對接超過 30 分鐘沒有回應

不要太相信雲，因爲沒有辦法預測雲中間是不是正常的
在考慮使用對外服務時，請先考慮容錯

如何成為一名合格的架構師

1. 永遠對自己的技術提出質疑
2. 不盲從潮流
   • 基於商業或是技術考量，選擇適合自己的架構
3. 永遠遵守 best practice
4. 監控是整個架構中最最最重要的東西
   • 先做監控在做架構
5. 做後端的，最後都要走向架構

監控可以怎麼做？

sentry.io

1. 一個codebase error tracking monitoring system
2. 結合了 Laravel, Rails, Express 等多種知名框架###

Stackdriver

1. 被google 整合至GCP下面

盲從未必是好事

案例1 - 非營利組織（靠捐款過活）需要降低開支

1. Daily Active Users(DAU) ≤ 2000 人
2. Azure SQL Database
3. Azure Cache for Redis
4. Azure Kubernetes

NTD 13,000 -> NTD 4,700 (減少了 64% 的主機開銷)

任何架構都需要審慎規劃 - 不要用自己不熟的東西

好，還可以更好

• 完善的監控計畫
  • 考量使用者多少
  • 服務提供的大小為何
• 不要濫用 NoSQL
• 做好規劃，並且符合需求

工商時間

LeadBest Consulting Group

• 後端工程師
• 前端工程師
• 產品規劃

如果想留在高雄不想去台北的話,有機會可以遠端工作