TGONext 軟體技術架構雜談 : 關於 Migration, 架構演進, Queue
本篇是 TGONext 架構組 - Ant 組在 2020-03-27 第二次聚會的內容整理。這些經驗與能力決定了你的價值。
第一篇是 軟體技術架構如何正確與商業需求快速對齊：談 MAU 換算至 RPS，SLA 回推至 SLI。
此次聚會是雜談，關於 Migration, 架構演進, Queue。
架構組 - Ant 組，與大家互動討論了許多有趣的議題。
1. Migration & Version control
Database migration 更本質的問題，我提出的是「版本控制」的接受程度。不少軟體工程師覺得自己的產品或專案，都有符合「版本控制」的要求，可回溯可往返。但通常都僅止於「程式碼」，而不包括「資料」。
穩定的「版本控制」，應該要能夠有信心的回到過去某個時間點，又可以再回到現在。如果程式碼使用了類似 Git 工具則問題通常不大，而 Data 可能會套用 Migration 等工具。可是多數人的習慣是，在 up 段 CREATE TABLE / ADD COLUMN，在 down 段 DROP TABLE / DROP COLUMN。當然，很多書或網路教學也是這麼教的。可當我們 rollback 時，因為 DROP TABLE / DROP COLUMN 的操作反而會造成 Data 遣失，失去了整體「版本控制」的意義。
所以，我們可以思考的是，「版本控制」的可接受程式為何，再回頭檢視手中的產品或專案，是否真的符合我們的版本控制要求。
2. Migration & Tools
很多時候，技術會被要求做到不停機的 Database migration (飛行中加油)，可能是 Schema migration 可能是 Data migration。
提及的作法有很多種，在 RDBMS 領域，有比較知名的 gh-ost 工具。我的建議是可以進一步瞭解他的做法為何，把這個當做標準流程樣板，就可以依據自己的環境做調整，畢竟在討論過程中，我也有提及 gh-ost 可能引發的問題。
過程順帶提及 NoSQL 與 RDBMS 的特色，從底層資料結構往上推展到業務層級。包括 MongoDB 為何不像 MySQL / PostgreSQL 使用 B+ tree 而是 B tree。
3. 軟體架構的演進
演進沒有一定的答案，每個故事都有他的答案，而在我們的討論過程中，重要的是可以分享彼此的故事。
若真要把演進體系化分析，我提出 x-y-z 軸的架構。x 指的是 Scale UP / Scale Out，y 指的是業務層的拆分 (可以是金流與客服拆分)，z 指的是邏輯層的拆分 (可以是 PARTITION 或是 SHARDING)。透過 x-y-z 可能理解多數拆分手法的原因與理由，也讓我們有個基本的選擇方向。
然而重點是，何時該選擇哪個方案變得更重要了，這也可以體現出軟體架構師的重要性 (人人都可以是軟體架構師)。
但軟體架構不能不談及資源的控制。以電腦資源來說，常見的有 CPU, Memory, Storage space, Storage IOPS, Network bandwidth, Network latency 等。這與我之前提出的 Performance triangle 有個類似的目的，就是當你選擇克服什麼問題的時候，也要注意你用了什麼去交換。這邊我也帶出了為何會有 protobuf, msgpack & thrift 的需求，而他們又是用了什麼去交換了什麼呢？
4. Queue
軟體架構常見的 State services，除了這兩次討論會提及的 Database 與 Cache 外，還有一個很多人也會用到的 Queue，包括 Kafka 及 RabbitMQ。
Queue 其實是一個非常複雜的系統，有 Ordered, Priority, Persistent, Durable 的差異，也有 at-most-once, at-least-once, exactly-once 的選擇。
但什麼時候要用 Queue 又是一個問題了。Queue 與 Cache 一樣，在使用上我有一些前提會想要團隊注意，是希望在未來遇到某些問題時，能夠提出相應的手法不慌亂，或超前預想而避免。
而我在討論會中有先提出了兩點。這兩點很高興地讓與會者們表示同意，看來大家都是有經驗的踩坑人。至於是哪兩點，就看有沒有寫出心得文分享，不先劇透。
5. Queue & RabbitMQ
關於昨天提到的 RabbitMQ 與記憶體用量的問題，官方有正式的解釋。如果為了此問題，而僅能使用到 40% 的記憶體，這對有些人會覺得顯得太浪費了。但 40% 是個表象，原因是什麼才是我們應該深入去探求的。
請參考 Memory Alarms。