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

{%hackmd MNcuRlXoQDak0uCmtaJKwA %}

###### 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](https://stackoverflow.com/questions/27652831/slow-or-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
+ 後端工程師
+ 前端工程師
+ 產品規劃

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