TGONext: 資料庫變遷跟架構改變
這次在開始討論關於架構的主題之前,我們的倒是讓我們提出一些問題。
剛好在兩次聚會的期間,我的客戶因為一些錯誤的計畫讓 Migration 失敗了,所以我提出了關於在不停機的狀況下做 Migration 的規劃問題。
這次在開始討論關於架構的主題之前,我們的倒是讓我們提出一些問題。
剛好在兩次聚會的期間,我的客戶因為一些錯誤的計畫讓 Migration 失敗了,所以我提出了關於在不停機的狀況下做 Migration 的規劃問題。
這次聚會我們先簡單的回顧一下上一次的討論,然後就切換到了下一個主題。基於前一次聚會高併發的討論,我們模擬一個簡單的架構然後開始演進。
因為時間的關係錯過了實體課程,不過利用 228 連假把工作上用得到的函數式程式設計這門課補完。
在 Functional Programming(函數式程式設計)裡面有許多概念是可以提取出來應用的,如果你使用的語言有支援一定程度的特性的話,就能更做出更多的變化。
包括我自己在內,寫測試有時候是一個非常不想面對的工作。也有很多剛入門的工程師覺得很難去分辨該怎麼去寫測試,在今天跟同事說明完一些技巧後就決定來寫一下這篇分享一下我自己的經驗。
去年雙十一活動的時候有一個算是比較急的專案是要做活動網站,當時評估了一下之後決定來嘗試透過 CI 自動生成 GCE 的自訂映像檔然後搭配 Auto Scale 來做部署。
會選擇這樣的方式主要是因為 Rails 或者大多數開發框架的部署工具預設大多是不適合 Auto Scale 的,像是 Capistrano 大多數是手動填入伺服器位置(之前也有實作過透過 GCP API 自動填入)比較適合雲端服務的作法其實就是是製作成一個映像檔來處理,也因此像是 Docker Image 這類型容器化技術在這方面是相對容易做的。
不過考量到容器化本身也還有一些調整問題才適合使用,再加上雲端服務的選擇是使用 GCP 來提供服務,並不像 AWS ECS 有專門針對容器的服務(可能是我不知道)而是提供 K8S 的方案,對一個短期活動來說在整個專案成員都沒有經驗的前提下學習成本還是偏高的。
因此相對適合的做法是用之前我準備好的 Ansible 腳本,搭配 Packer 這套工具直接在 GCP 上面生成一個自訂的映像檔然後直接更新 Instance Group 的設定讓他以新版本 Scale 起來,就能做到基本上網站不斷掉的更新(Health Check 和 Scale 規則需要調整好)
我們大概花了約一天多的時間快速搭起來,這次的開發時間約兩週中間是透過放額外的人力去支援搭建這個部署流程。
前陣子在嘗試一些比較少見的 Google API 時發現,在 Google 提供的 Ruby Gem 裡面並不支援這個 API 的實作,這表示需要自己去想辦法解決如何去呼叫這個 API 的問題。
不過呼叫 API 需要 Access Token 才能夠使用,以往我們都是依靠第三方套件或者 Google 官方提供的 Gem 直接呼叫,似乎很少去直接實作客戶端。另一方面我們對 OAuth2 的認識大多是做 SSO(Single Sign On)而非這種伺服器對伺服器的呼叫。
以 Google 這種規模的公司,如果是直接使用一般 OAuth2 的伺服器對伺服器的作法似乎也不太適合,而 Google 提供的解決方案就是 Service Account 了!
今年把在六月到八月做的一個小專案拿去投稿 Ruby World Conference 意外的獲得了 15 分鐘的時間,於是又展開了一次日本出差之旅,剛好彌補一下今年因為客戶專案需要趕上線而無法參加 RubyKaigi 的遺憾。
跟 RubyKaigi 不太一樣的地方是 Ruby World Conference 雖然叫做「World Conference」但是除了台上的講者之外,幾乎都是日本人(而且是稍微有年紀的大叔)去參加的。
寫完上篇後就開始員工旅遊、鐵人賽(從讀遊戲原始碼學做連線遊戲)反而一直都沒有時間把下篇寫完,離 COSCUP 都已經過了一個多月自己都忘記還剩什麼沒有寫在文章裡面。
中間在鐵人賽的部分花了一些時間把目前理解到關於 Unlight 的一些基本設計整理出來,後面則是實作。至於近期也已經開始在搭建 HTML5 版本的底層設計,還有 mruby 的整合(因為想提供 Mod 功能到遊戲中)等等東西都在進行中,十一月還要飛日本一趟參加 Ruby World Conference,可以說是完全都閒不下來。
總之,讓我們在來看看 COSCUP 這場演講的後續吧 XD