ref: https://medium.com/system-design-concepts/tinyurl-system-design-16868b5435de

本篇又是另外一個系統設計的分享文，想要探討的是如何想要設計一個 tinyurl 的系統，那到底有哪些事項需要注意？

TinyURL 的概念很簡單，使用者輸入一串 URL，最後回傳一串很短的 URL 讓使用者更方便存取，然後整個設計簡單為主。
這次的 tinyurl 先假設該系統需要滿足的條件有
1. 使用者數量: 三千萬使用者
2. 短網址長度: 使用 7 個字元

根據上述需求，先來估計要使用的資料結構與整體大小
1. Long URL: 2KB -> 2048 chars
2. Short URL: 7 bytes -> 7 chars
3. Created at: 7 bytes -> 7 chars
4. Expire at: 7 bytes -> 7 chars

所以每一個欄位大概需要 2069 Bytes，大概就是 2.021 KB，所以三千萬個使用者來說，如果要
1. 保存一個月，那至少需要 60.63 GB
2. 保存一年就需要 727 GB
3. 保存五年則需要 3.6 TB 左右

根據這些使用量會用來幫忙評估最後要使用 RDBMS 或是 NoSQL DB

# 7個字元的產生
作者提出兩種簡易方法來產生一個長度七的URL
1. 給定一個大數，使用 base62(0-9a-zA-Z) 的方式去產生出一個長度七的字串
2. 給定一個唯一字串(Long URL)並且基於 base62 回傳一個長度七的字串，譬如使用 MD5 來處理，但是MD5前七個字元就有可能會發生重複的問題，不同的 Long URL 最後得到相同的 7個字元。

基於 base62 的短網址總共有 62^7 總可能，相對於 Base10 只有一百萬來說，62^7 大概有 3.5 兆左右可能性。
所以如果採用第一個方式就是針對每個 LongURL 去產生一個不重複的隨機數字，並且將該數字以 base62 呈現來代表短網址。

# 第一種方式
假設今天已經選好短網址了，下一個步驟就是要將這個 long url 與 short url 的關係給寫入到資料庫中
但是寫入並不是單純寫入這麼簡單，因為亂數的產生是有可能重複的，因此當前產生的 short url 是有可能已經存在於 DB 之中，這種情況下就需要重新產生亂數直到找到一個沒有被使用過的 short url.
如果整個系統只有一個人會進行讀寫的話，這種操作基本上沒有問題，但是要是同時有多個系統要進行讀寫又沒有相關機制妥善處理的話，就會發生重複資料被同時寫入到DB內了。

一種解決方式就是讓 shortURL 變成所謂的 unique key，同時還可以搭配 `put if not exists` 等概念讓 DB 本身來處理這類型的限制，不過這部分的功能通常只有 RDBMS 有支援，如果是 NoSQL 的話則沒有辦法搞定。


# 第二種方式
假設採用的是 MD5 的方式來處理 long url 並且取前七個字元來使用，基本上跟前述會有一樣的問題，都有可能會發生不同的 long url 最後獲得相同的短網址，
這情況下還是會有重複資料的問題

# 別的想法
使用 counter 的概念，將 counter 以 base62 的方式來呈現，不過這個作法只適合單一 server 來處理，當同時有多個 server 時又變成要維護 counter 的共同讀寫問題。

雖然探討的是 TinyURL 的簡易實作，但是作者後半部分還繼續探討如何導入 ZooKeeper 讓上述的環境可以同時部署多個 server，藉此來處理更大規模的需求。
有興趣的可以閱讀全文

ref: https://www.linuxjournal.com/content/everything-you-need-know-about-linux-containers-part-i-linux-control-groups-and-process

本篇文章是個深度技術文，認真探討 Container 技術底下的 Control Groups 以及 Process Isolation 到底是什麼。
Container 這個詞大家都聽說，也很多人聽過到底如何實作 Container 這種輕量級虛擬化概念的，但是以 Linux 為範例，到底真正技術上的實作是什麼這點則是硬知識，而本篇文章是個 container 系列文
希望能夠讓讀者對於 Container 的實作有更進一步的理解。

為了穩定性與安全性，事實上大部分的應用程式都應該受到相關程度的控管與限制，避免應用程式出現問題影響到其他應用程式或是機器本身，而 Linux Kernel 有提供一個名為
Control Groups (cgroup) 的概念用來限制與隔離不同的資源，譬如 CPU, Memory, DIsk I/O 以及 network。

cgroup 當初設計的目的是希望提供一個統一的介面讓管理者可以去管理多個 process 或是系統本身，該系統能夠達到
1. 資源控管: 控管群組特定資源的使用量不能超過多少
2. 優先順序: 控管該群組可以使用的資源量是更多或是更少，跟其他群組競爭時使用的優先權。
3. 資源監控: 可以監控與測量群組內的資源用量
4. 控管: 可以凍結，停止或是重啟群組內的應用程序

每個 cgroup 都是由數個 process 所組成的，這些 process 都會套用到相同的設定。同時為了提供更好的管理方式， cgroup 還提供了階層式的管理，就像 Tree 的架構一樣，
子節點會繼承自根節點的設定。
Kernel 內根據不同的資源實作不同的 controller，譬如 memory controller 則是專注於 memory 相關的設定，而 cpuacct 則是專注於 CPU 的使用量。

文章後半段就是實戰操控，如何透過系統上的 /sys/fs/cgroup 資料夾來跟 cgroup 互動，包含基本的資料檢查與創建一個範例應用程式
簡易的方式也可以使用 cgroup 系列的工具，譬如 cgcreate, cgexec, cgdelete 來操作。
如果系統中有運行 Kubernetes 環境有設定相關資源控管的話，是很推薦使用這類型的工具來幫忙釐清 YAML 設定與底層的關係，藉此加強自己對這方面的認知。

ref: https://kubernetes.io/blog/2021/11/12/are-you-ready-for-dockershim-removal/

Dockershim 從 Kubernetes 中移除的時間逐漸逼近，所有 Kubernetes 的使用者都明瞭這個改變並且準備好面對了嗎?

Dockershim 這個元件過去設計的目的是為了讓 Kubernetes 可以使用 Docker 作為底層的 Container Runtime，Kubernetes 意圖使用 CRI 來兼容百川，所以需要 dockershim 這層將所有的請求給轉移到 Dockerd 進行處理。
如今有愈來愈多的 Container Runtime 原生或是更容易支援 CRI 的標準，所以 Dockershim 存在的必要性也就逐漸下降。

根據目前的計畫， dockershim 將於 kuvernetes 1.24 給正式移除，大概會於 2022/04 左右發布該版本，對於 1.24 想要進行測試的玩家可以於今年年底先行使用看看 1.24 的 alpha/beta 版本。

文章中還有列出一份 dockershim migration documentation 的文件來介紹該如何檢視當前系統的設定以及要轉移需要注意哪些事項
此外如果你的 Kubernetes 是由第三方服務所架設與維護的，譬如 GKE/AKS/EKS/Rancher..等諸如環境，那就需要去確認這些服務是否有提供其他的 container runtime 選擇以及未來更新時應該要採取何種升級方式。

如果對於 dockershim 移除對於 kubernetes 使用者會有什麼影響還是不清楚的可以參閱這個影片
https://www.youtube.com/watch?v=nc3mBN3LzvM&t=62s

ref: https://medium.com/system-design-concepts/whatsapp-system-design-b094cbded096

本篇也是一個系統設計的分享文，這類型的文章都是從一個真實應用出發去分享一些可能的設計方式，這些設計方式不是萬靈丹也不是準則，單純是一個不同的思考方式
對於讀者我們來說也是一個思考的好機會，看看作者所講述的架構是否合理，以及如果自己去實作的話可能會採取何種架構去實作。

這篇文章想要探討的是類似 WhatsApp 這類型聊天通訊軟體的實作架構，聊天軟體不外乎就是
1. 互相傳遞訊息
2. 訊息是否已讀
3. 傳送不同類型的檔案
4. 加密
5. 通話

而這篇文章大抵上只有涵蓋前面三個功能的探討。

作為一個聊天通訊軟體，基本的架構都會是 Client/Server 架構， Client 就是所有使用該 app 的使用者，而 Server 則是背後幫忙進行訊息交換複雜處理的角色，文章中使用 messaging server 的代號來形容這個 server。
為了能夠處理大量的使用者，適度的根據用量去調整 messaging server 的數量是必要的，所以 client 連接上就不會直接跟這些 server 進行連線，相反的則是會使用 load-balancer 的概念來幫忙處理連線。

接者 server 架構中一定也會有相關資料庫的存在，文章中沒有特別探討要使用 RDBMS 還是 NoSQL。

試想一個情況，當 Client A 想要離線傳送訊息給 Client B 的時候，偏偏這時候 Client A 的手機沒有網路，沒有辦法連上 server，那這些訊息勢必都會存在於
手機端上的空間，可能是伴隨app的小型資料庫或是任何形式。當 Client A 順利連上 server 後就會將這些訊息給傳送到 server 上。
但是如果此時 Client B 也沒有跟 server 有連線，那這些要傳送的訊息理所當然的也要先暫時存放到 server 上，待 Client B 連上線後就會將這些訊息一次性的傳送給 Client B，接者 Client B 就能夠順利的收到這些訊息。

從上述的一個流程就可以看到只是簡單的傳送訊息中間就會牽扯到三個不同的角色，更何況有些軟體想要提供點到點的加密傳送服務，基本上還是要依賴 server 幫忙轉發，只是傳送的內容是否加密與否而已。

文章後去探討使用基於 Thread/Process 的概念來處理每個連線，然後不同的情況下要如何做到已讀的功能，同時如果還想要知道對方上一次看的時間是什麼時候這類型的功能該怎麼實作。
對於傳送檔案如圖檔之類的檔案，如果想要整合 CDN 等概念近來家速食，又會導入其他 HTTP Server 來進行檔案存放，並且讓每個訊息都是夾帶這些媒體檔案的資訊，動態其他的 CDN server 抓取。

對於整體有興趣的可以閱讀全文。

ref: https://medium.com/@arielstkuo/not-just-a-pretty-face-%E9%81%8A%E6%88%B2%E7%95%AB%E9%9D%A2%E5%BE%8C%E4%BD%A0%E4%B8%8D%E7%9F%A5%E9%81%93%E7%9A%84%E4%BA%8B-frame-1-2d-3d-2-5d-f0465ad4b736

本篇不探討 Cloud Native 相關概念，而是從一個科普文來分享一下遊戲世界的基本概念。
作者身為一個前暴雪員工，對於遊戲開發有諸多經驗，且本文非常貼近一般玩家日常同時又不會有太過於艱深的詞彙與技術，更重要的還是一篇實實在在的中文分享文。

資深遊戲玩家來說一定對於 2D(平面)/3D(立體) 世界不陌生，從早期的 Gameboy 到現在 Switch/PS4/PS5 等擁有更佳運算效能的主機後，愈來愈多的遊戲都會採用 3D 的方式來製作，但是你知道除了簡單的 2D 與 3D 之外，還有一個介於中間的 2.5D 嗎?

2.5D 的遊戲想要透過 2D 的平面素材來打造出一個類似於 3D 立體環境，同時看起來又不能太假，不能讓玩家一眼就覺得這整體不協調太奇怪，
文章中列舉了不少範例來解釋不同類型的 2.5D 以及使用最近才重製的 Diablo II 來進行比較，讓你看看到底早期的 Diablo II 是如何用 2D 裝 3D 以及後來採用全 3D 重新製作後的差異。

文章內科普了基本的固定視角模式外，也介紹了利用視差錯覺造成的距離感，可以讓開發商用較低的遊戲成本來打造出一個近似 3D 的遊戲環境。

簡單來說，本篇就是一個遊戲科普文，分享一些關於 2D, 3D, 2.5D 的一些概念，
有興趣的歡迎閱讀全文

ref: https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git/commit/?id=d40ce48cb3a68b54be123a1f99157c5ac613e260

又是一個非常有趣的 kernel patch, 光看標題「af_unix: Replace unix_table_lock with per-hash locks.」就可以感覺到這次的改動很有機會帶來效能上的改變。

過往的 AF_UNIX socket 依賴一個大 lock 來管理 kernel 內所管理的所有 AF_UNIX socket，而這個 patch 就採用基於 hash 的方式創建多個小 lock 來個別管理，光用直覺都覺得整體效能會有進步的空間。

不過要特別注意的是本 patch 修改的只有 AF_UNIX socket 這類型的服務，所以採取 TCP 等 socket 依然還是本來的做法。常見使用這種 domain socket 有 containerd, cri-o 等，不過這類型的服務本身就不是 I/O 為主，所以就算改成多 lock 似乎也不會有什麼明顯的幫助。
不知道大家有沒有注意有什麼 I/O 很重的服務預設都會吃 domain socket 的？
有的話不彷使用包含該 patch 版本的 kernel 來測試看看效能是否有顯著的改變

ref: https://refactoring.guru/design-patterns/

本篇是一個關於重構的教學網站，該網站主要分享重構與設計模式的概念，其中針對設計模式的介紹相對完整與豐富。
網站內從設計模式的基本概念以及設計模式的歷史，大部分人學習設計模式時勢必都聽過所謂四人幫，由 Erich Gamma, John Vlissides, Ralph Johnson, and Richard Helm 四人於 1994 年所發行的書籍 Design Patterns: Elements of Reusable Object-Oriented Software

該書籍介紹了 23 種針對不同問題的設計模式，每個設計模式都是基於物件導向的概念去實作，而這本書可說是設計模式的推手，很多人都是從該本書開始學習設計模式的概念。

註: 之後會再分享一篇文章來探討 20 年後的程式語言特性，還需要過往這些四人幫的設計模式嗎?

網站內最精華的部分大概就屬於程式碼範例的部分，設計模式分為三大類(Creation, Structural, Behavioral)，總共收入 22 種不同的設計模式，而這些模式又基於 C++, C#, Go, Java, PHP, Python, Ruby, Swift, TypeScript 這些程式語言來介紹該如何實作。
所以如果對學習設計模式有興趣的話是可以參考參考這個網站，稍微看一下自己習慣的程式語言可以如何撰寫這些設計模式。

至於到底學習設計模式有沒有必要這又是別的議題，但是時間有餘力的情況下多學一些不同的概念其實也會幫助自己去閱讀程式碼，特別是不同的開源專案時能夠幫助你快速理解其設計的可能目的。

ref: http://blogs.tedneward.com/post/reclaiming-design-patterns/

本週分享了另外一篇探討設計模式與分享相關範例的網站，而今天要分享的也許設計模式有關，不過本文不是宣揚設計模式多好多棒，反而是一個思考文。
本文發表於 2016 年，也就是四人幫著名書籍發行 20 年後的日子，作者想要探討現今的程式語言特性與架構，是否過往的 23 種設計模式都還適用？

這是作者關於設計模式系列文的第一篇文章，實際上沒有探討每個設計模式於現代程式語言的用法與寫法，反而是探討設計模式的歷史與初衷，看完後覺得全文講得非常有趣，非常推薦大家一讀。

以下就幫忙節錄幾個重點

# 到底什麼是模式？
四人幫的書籍也有提到設計模式是一個微妙的藝術與科學，其書籍的最後一章有特別去說明(作者特別說明很少人會讀到最後一章)
1. 本書沒有開創任何新的演算法，沒有任何新的 Coding 技術
2. 相同的也沒有任何新的設計理論，也沒有任何嚴謹的系統設計方式。
3. 整本書就是把一些已知的設計給整理一下，可以說是一個不錯的教學。
4. 一個熟悉物件導向設計的工程師基本上不能從本書中獲得太多新知

作者的朋友甚至說 23 種設計模式就是 23 種指標的用法來戲謔一番XD
千萬不要認為將本書丟給一個新手去學習念一念他們就會功力大增什麼的會了，這跟本不可能。
那到底設計模式有什麼幫助？ 四人幫的書籍中是這樣解釋的
1. 希望讀者可以有不同的思維去面對問題
2. 將已知的設計方法給列舉出來並且給予對應名稱
3. 熟悉它們更能夠讓我們改進它們

後來設計模式逐漸火熱，整個業界都在討論設計模式，甚至從四人幫書籍的 23 種設計模式為基礎延伸出各種不同模式，更重要的是整體事情變得更加抽象更加脫離底層。
設計模式不再只是一個設計模式，而是一個語言了，甚至還有所謂的元模式(Meta Pattern)，以及反面教材的反向模式(Anti-Pattern)。

接者更可怕的事情就是人們發現到設計模式的火熱可以帶動書籍的銷售，因此各種關於模式的書籍開始被出版，IDE 業者開始探討如何自動產生符合各種設計模式的程式碼，連 UML 與其他設計也都搭上設計模式的風潮。

2000 年左右開始迎來一波反感，愈來愈多的反向討論去思辨模式的存在性與必要性。

直到現今，設計模式這個詞還在，其最初定義的模式名稱也還是被廣泛使用。
四人幫的書籍其實有更精準的去探討為什麼要有設計模式這個概念
1. 設計一套通俗的名稱便於交流與討論
2. 用更高的抽象概念來描述一個設計思路，相對於直接撰寫完整程式碼來說會更適合與同事進行早期討論
3. 理解本書的 23 種的設計模式可以幫助你理解現有系統，能夠更有效率的去面對物件導向設計
4. 設計模式提供一種方式去說明“為什麼”如此設計，而不只是一個單純的結果與用法，其背後的思考邏輯反而是更重要的。
5. 開發一個重複使用的軟體本來就會歷經各種重構，好的設計模式會幫助你決定如何重構，可以讓你重構起來更加有效率。

最後該書籍也有去預言設計模式會衰敗的原因，敘述包含
1. 單純把設計模式當作一個可被重複使用的技術，卻沒有辦法去理解為什麼要使用它是不正確的。
2. 就像看別人寫程式一樣，看別人程式做了什麼很簡單，但是為什麼這麼做非常困難，這也就是設計模式想要解決的問題
3. 學習設計模式是要去理解系統的設計，而不只是單純能動就好

大多數的人看到一個模式就會很著急的去 copy/paste 相關程式碼，能動就好，但是都沒有去思考背後的原因，到底該模式為什麼要這麼做，要解決什麼問題，這麼設計有什麼樣的好處，這樣背後的思緒才是學習設計模式的正確態度。

文章後半部還有一些討論，有興趣的可以繼續觀看

ref: https://jpetazzo.github.io/2021/11/30/docker-build-container-images-antipatterns/

本篇文章分享的是建置 Container 中的 Anti-Patterns，不講哪些好反而探討哪些不好。

文內列舉了不同的主題，包含
1. Big images
- All-in-one mega images
- Data sets
2. Small images
3. Rebuilding common bases
4. Building from the root of a giant monorepo
5. Not using BuildKit
6. Requiring rebuilds for every single change
7. Using custom scripts instead of existing tools
8. Forcing things to run in containers
9. Using overly complex tools
10. Conflicting names for scripts and images

以下針對內文幾個部分摘錄一下為什麼作者認為是個不好的模式

# Small Images
Image 小本身不是什麼問題，但是有時候過度追求容量會使得一些常用有幫助的工具沒有辦法於容器內執行，這可能會導致未來要除錯時要花費更多的時間去處理，可能要研究如何重新安裝該工具等。

作者有強調這個議題是非常看環境與需求的，有些情況可能團隊根本不需要進入到容器內去執行 shell 來處理，有些可能會需要到容器內執行 ps, netstat, ss 等指令來觀察不同狀態。
作者推薦可以使用 gcr.io/distroless/static-debian11 這個 image 做為基礎然後將其之間的 busybox 給複製環境中，至少確保有基本工具可以使用

# Not using BuildKit
BuildKit 是 docker build 的新版建置方式，相對於舊版方式來說 Buildkit 提供了更多功能，譬如平行建置，跨平台建置甚至效能上也會比過往的更好。
為了讓舊有使用者可以無痛轉移，所以 BuildKit 完全相容既有的 Dockerfile 的語法，所以切換方面是完全無腦的。
目前新版的 Docker Desktop 基本上已經預設採用 BuildKit 來進行建置，不過某些系統譬如 Linux 的環境下，還是需要透過設定環境變數來啟用這個功能，譬如 DOCKER_BUILDKIT=1 docker build . 等方式來建置。

此外透過 BuildKit 建置的產生結果跟過往不同，所以只要看建置結果的輸出就可以判別自己是否使用 BuildKit。

剩下的8個項目就留給有興趣的讀者自行閱讀

ref: https://matduggan.com/mistakes/

本文是作者踩過的各種 Infrastructure 雷，希望讀者能夠避免這些雷。

總共有幾大類，分別
1. Don't migrate an application from the datacenter to the cloud
2. Don't write your own secrets system
3. Don't run your own Kubernetes cluster
4. Don't Design for Multiple Cloud Providers
5. Don't let alerts grow unbounded
6. Don't write internal cli tools in python

其中第六點簡短扼要，大概就是「沒有人知道如何正確地去安裝與打包你的 python apps, 你真的要寫一個內部的 python 工具就給我讓他完全跨平台不然就給我改用 go/rust, 不要浪費生命去思考到底該如何安裝那些東西」

這讓我想到你的 Python 跟我的 Python 每次都不一樣，有已經不支援的 python 2.x, 還有各種可能會互相衝突的 python 3.x....

ref: https://linuxconfig.org/how-to-propagate-a-signal-to-child-processes-from-a-bash-script

基本 Bash 介紹文，探討 trap 的用法，如何於不同的情況下正確攔截 SIGNAL，同時如果 script 中運行的程式有無背景執行
會有什麼差異，推薦給對 Bash 不熟的讀者閱讀重新複習

ref: https://emmer.dev/blog/docker-shell-vs.-exec-form/

Docker 基本介紹文，不知道常寫 Dockerfile 的讀者能不能分清楚 Dockerfile 內 Shell 與 Exec 兩種格式的差異
RUN, CMD, ENTRYPOINT 等指令都同時支援這兩種格式
Shell 格式就是 RUN command arg1 arg2 arg3 這種直接描述的格式，而 Exec 則是用 [] 包起來，每個參數單獨敘述，譬如
RUN ["command", "arg1", "arg2", "arg3"] 等。

本篇文章推薦 RUN 指令採取 Shell 格式而 CMD/ENTRYPOINT 都應該採用 EXEC 格式。
如果自己不清楚差異以及沒有想法為什麼平常自己這麽寫的話可以參考全文

ref: https://link.medium.com/6uur7w6C1lb

本篇文章不是 Cloud Native 相關的，而是先前遊戲動畫設計的續集，本篇續集探討的是遊戲產業中是如何創造一個 3D 角色。

一個 3D 角色的創造會經歷五個過程，包含概念圖，建模，上色，綁定骨骼，及動畫製作

# Concept Art 概念圖
為了讓之後的建模師能夠將 3D 角色給數位化的建模處理，第一步驟就是概念設計，將團隊討論的結果給初步圖像化，畢竟概念歸概念，需要將概念給實體化才有辦法進行更進一步餓的討論與修正。

# Modeling 建模
有個概念圖之後，下個步驟就是要透過不同的建模軟體來打造一個 3D 建模，軟體如 Maya, Blender, Autocad 等都有不同的支持者。
一個好的建模除了形似概念圖外，更重要的是能夠用更少的資源來打造完成，因為這些建模最後導入到遊戲中後就是一個活生生的資源運算，精確的模型同時很容易伴隨者複雜的模型。
因此這部分就會很仰賴建模師的功力來看看如何達成精準建模的不複雜模型。

# Texturing 紋理與上色
3D 建模師完成後就會得到一個沒有光彩的模型，就如同商場的穿衣模特假人一樣，為了讓其好看還是需要補上貼圖上色讓其看去以來更貼近概念圖的面貌。

# Rigging 綁定骨骼
有了一個賞心悅目的模型後，下一步驟就是要讓該模型有能力動起來像個活生生的樣貌，譬如人的話就會有所謂的四肢與身軀，有了這些關節後該模型才有辦法動起來，從基本的
四肢移動到更為細緻的手指牽動，愈多的細節就要愈多的關節，這意味綁定骨骼就需要更多的時間投入

# Animating 上動畫
一切都完成後最後一個步驟就是將該建模角色給動畫化，藉此能夠於遊戲中的各個場景呈現到遊戲玩家中
文章中還特別提到 恐怖谷理論 的概念，算是一個滿有趣的概念，的確於滿多 3D 遊戲中都有看到這概念的範例

Ref: https://coolshell.cn/articles/21672.html

本篇文章是作者工作 20 年來的經驗分享文，內容非常好，提出了很多不同的觀點，由於是篇中文文章，所以就不幫忙節錄重點，直接列
文章中的十一個原則標題。
每個原則都非常精彩，文章底下的討論也滿有趣的。

原则一：关注于真正的收益而不是技术本身
原则二：以应用服务和 API 为视角，而不是以资源和技术为视角
原则三：选择最主流和成熟的技术
原则四：完备性会比性能更重要
原则五：制定并遵循服从标准、规范和最佳实践
原则六：重视架构扩展性和可运维性
原则七：对控制逻辑进行全面收口
原则八：不要迁就老旧系统的技术债务
原则九：不要依赖自己的经验，要依赖于数据和学习
原则十：千万要小心 X – Y 问题，要追问原始需求
原则十一：激进胜于保守，创新与实用并不冲突

ref: https://pythonspeed.com/articles/stop-using-python-3.6/

本部落格是一個基於 Python & Container 的系列介紹文，而本篇文章是其中一篇探討容器化 Python 要注意的事項。
標題非常簡單：「是時候停止使用 python 3.6了」
Python 3.6 的 EOL 時間就剛好是 2021/12，這也意味到 2022 年後 python 3.6 就不再享受官方的任何維護與更新。
文章中提到建議趕快升級，同時也要注意不要每次都拖到最後一刻才升級相關軟體，應該要把升級軟體的流程給整合到日常流程中，定期掃描定期更新，
否則只會不停的被不同版本的 EOL 追趕而已。

ref: https://docs.microsoft.com/en-us/azure/architecture/patterns/ambassador

微軟文件中的系列好文，探討雲端方面的各種設計模式，而本篇探討的是 Ambassador 模式

想法:
1. 想要提供更多進階的網路功能到應用程式上，譬如 TLS、circuit、breaking、routing 或 metering。
2. 應用程式不太方便修改來符合上述功能。
3. 部署一個跟原應用程式相鄰的應用程式來處理這些網路功能。

應用程式過於古老，團隊沒有辦法進行深度修改或是團隊中的應用程式使用過多的語言與框架完成，很難簡易的將這些功能給導入到既有的應用程式中
這時候部署一個全新的應用程式就可以再不修改既有應用程式的前提下來提供這些進階的網路功能。
這個模式普遍被稱為 ambassador 模式，而本篇文章就是針對該模式進行一個科普概念。
文章最後還要探討使用這種模式的一些注意事項，譬如網路的延遲會因為多一個應用程式而提升，所以使用上也要評估看看是否合適。
也有簡單的列出什麼情況適合使用 ambassador 什麼情況不適合。

ref: https://medium.com/system-design-concepts/dating-application-system-design-aae411412267

本篇是一個系統設計文，探討設計一個如 Tinder 的應用程式該如何去思考整體架構

Tinder 這種交友應用程式有幾個特點
1. 透過 FB 走 OAuth 登入
2. 左滑右滑
3. 配對機制
4. 聊天對話
5. 通知功能

其中 (3) 這個特色是說當使用者開啟 app 之後系統要根據一系列的條件們去推薦可能的對象，條件包含很多
1. 從 FB 中抓到的個人資料，喜好等
2. 地理位置，通常這類型的交友軟體都可以設定希望對象與自己的距離，譬如 10km 內， 50 km 內。

同時這類型的交友軟體支援多語言，支援多語言基本上就是意味多地區，簡單的說法可以說支援全世界不同地區的使用者共同使用，
因此基於效能考量上，通常不會使用單獨使用一個地區的伺服器來提供全球的服務，取而代之的則劃分地區讓每個地方都有一個稍微近的伺服器可以使用。
所以整體架構上還需要考量這類型的分散式架構設計，特別是有一些交友軟體還支援切換地點的功能，使用者可以切換到不同地區去匹配
不同地區的使用者，這意味該使用者的資料也會需要同步到不同地區的伺服器之間，因此資料部分也需要特別注意處理。

接下來就是當使用者希望配對範圍 100km 的使用者，該功能到底該如何實作，要如何將實體的地理位置劃分出來並且有辦法根據該敘述， 100km 內的使用者進行配對。
文章內有針對這部分進行詳細解釋，如何拆分不同的小區塊然後如何後續處理，有興趣的可以參閱全文

ref: https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer

本篇又是微軟 Cloud Design Pattern 系列，要探討的是 Anti-Corruption Layer 模式
該模式的想法是
1. 應用程式很常需要透過其他的服務來提供外部功能或是資料存取。
2. 當應用程式要轉移到新的系統時，可能會需要同時存取新舊系統內的外部功能與資料。

譬如新舊系統內所使用的 API, 資料架構也都完全不同，然後應用程式並沒有辦法一夜之間完全轉移到全新系統，過渡期不可避免。
這種情況下應用程式就必須要相容新舊系統的寫法。

而 Anti-Corruption Layer 的意思就是讓應用程式與舊系統中間塞入一個轉接人，該轉接人同時面向應用程式與舊的系統，然後將彼此的溝通進行轉換。
應用程式不需要使用過往的 API 來處理，這部分都會讓轉接人處理。

上述敘述聽起來跟過往學到的 Adapter 模式大概有 99% 雷同，而 Anti-Corruption Layer 該詞是由 DDD(Domain-Driven Design) 中被初次提起與強調的，與 adapter 的
差異在於層次的不同，Anti-Corruption Layer 想要處理的是跨 Domain 之間的轉換，而 Corruption 的含義就是要避免不同 domain 之間那些不能受控的系統不要 corrupt 既有的應用程式。
因此 Anti-Corruption Layer 還有一個隱含的想法就是背後要處理的服務會有品質的問題，而這個模式就是用來處理這品質不穩的服務，避免這些服務破壞整個應用程式的功能。

詳細的可以參閱全文ref: https://docs.microsoft.com/en-us/azure/architecture/patterns/anti-corruption-layer

本篇又是微軟 Cloud Design Pattern 系列，要探討的是 Anti-Corruption Layer 模式
該模式的想法是
1. 應用程式很常需要透過其他的服務來提供外部功能或是資料存取。
2. 當應用程式要轉移到新的系統時，可能會需要同時存取新舊系統內的外部功能與資料。

譬如新舊系統內所使用的 API, 資料架構也都完全不同，然後應用程式並沒有辦法一夜之間完全轉移到全新系統，過渡期不可避免。
這種情況下應用程式就必須要相容新舊系統的寫法。

而 Anti-Corruption Layer 的意思就是讓應用程式與舊系統中間塞入一個轉接人，該轉接人同時面向應用程式與舊的系統，然後將彼此的溝通進行轉換。
應用程式不需要使用過往的 API 來處理，這部分都會讓轉接人處理。

上述敘述聽起來跟過往學到的 Adapter 模式大概有 99% 雷同，而 Anti-Corruption Layer 該詞是由 DDD(Domain-Driven Design) 中被初次提起與強調的，與 adapter 的
差異在於層次的不同，Anti-Corruption Layer 想要處理的是跨 Domain 之間的轉換，而 Corruption 的含義就是要避免不同 domain 之間那些不能受控的系統不要 corrupt 既有的應用程式。
因此 Anti-Corruption Layer 還有一個隱含的想法就是背後要處理的服務會有品質的問題，而這個模式就是用來處理這品質不穩的服務，避免這些服務破壞整個應用程式的功能。

詳細的可以參閱全文

標題: 「多年工作經驗總是搞砸電話面試， why ?」
類別: 其他
連結: https://kevin.burke.dev/kevin/phone-screens-broken/

本篇是一個面試經驗探討文，作者闡述自己雖然已經有十年多的工作經驗，但是部分面試工作上還是沒有很辦法的去展現自己的能力
特別是那些用電話面試的經驗，而此文就是關於電話面試的小小抱怨文

滿多的電話面試都會搭配 Coderpad 這個網站來要求面試者線上進行程式撰寫，而該網站就要求你使用線上編輯器並且將所有的程式碼都統一到一個檔案中
，同時也不一定有辦法去撰寫相關的測試規則，這對於作者來說非常不喜歡。
作者平常習慣開啟多個視窗進行開發，一邊撰寫程式一邊透過測試來驗證當前撰寫的程式是否往正確的方向前進，同時也花費大量時間去調整自己喜歡的工具來輔助所有
程式碼的撰寫。而上述所有習慣都沒有辦法於 Coderpad 的單一編輯器上去完成。
此外面試過程中還會被問各種問題，譬如為什麼這個變數這樣命名，為什麼blablabla... 對於作者來說，有些概念要到快完成時才會最佳化，就很明顯不符合電話面試這種要一次完美的特色。

最後作者也分享了一下關於電話面試的問題想法，相較於問一些實際上工作根本用不到的演算法問題，不如問一些更貼切真正工作會用到的經驗與概念，譬如
1. 給面試者看一段 opensource 專案產生的 stack trace, 問問面試者能不能從這個 trace 看得出來大概可能是什麼問題
2. 如果你開啟一個 database transaction 過久，有可能會發生什麼問題?
3. 寫檔案到硬碟如果每次都只有寫一個 byte, 這可能會帶什麼樣的壞處?
4. 給定一個函數，請面試者描述會如何針對這個函式去寫測試案例

這讓我想到多年前也有接過電話面試直接問我 Linux 用幾個bit實作權限，但是面試官本身也非這個專業，是哪個權限也沒辦法回答，也不能給清楚的 context，就如同教科書一樣一個問題一個答案，沒辦法針對面試者的疑問去解惑...

標題: 「Meta 如何打造一個供多團隊使用的 SLI/SLO 設定與觀測平台」
類別: usecase
連結: https://engineering.fb.com/2021/12/13/production-engineering/slick/

本篇文章是 Meta 公司的技術分享文，探討內部如何搭建一個觀測 SLO 的大平台，讓不同的應用程式團隊都可以更方便地去觀察是否有達到其設定的 SLO。

文章內容有點長，這邊稍微節錄一些重點，非常推薦大家花點時間看完全文
1. Meta 的產品多，同時規模又大，背後又有數千的工程師不停地部署新版本，因此維運團隊必須要有一個好的方式來維運這些服務，包含預期狀態，當前狀態以及有能力去分析問題。
2. 團隊決定從 SLI/SLO 為基準點去設定預期狀態以及量測所有服務的效能。
3. 團隊決定打造一個名為 SLICK 的系統來視覺化與控管所有服務的 SLI/SLO
4. 沒有 SLICK 以前，每個服務的團隊都有各自的處理與儲存方式，所以都要花費很多時間去研究每個開發團隊的文件與用法，整體工作效率會下降
5. 過去的系統也沒有維護超過一週以上的資料，所以後續團隊也沒有辦法針對這些部分去分析。

透過 SLICK 可以讓整個 Meta 達到
1. 每個服務都可以用一個統一的方式去定義 SLO
2. 可以維持資料長達兩年且資料的細度達到每分鐘等級
3. 有個標準化的視覺方式來呈現 SLI/SLO
4. 定期地將當前服務狀態發送到內部群組，讓團隊可以用這些報告來檢視服務的穩定度並進行改善

文章後半部分包含
1. SLICK 用法介紹，包含 UI 的呈現樣子，定期的報告內容以及相關的 CLI 介紹
2. SLICK 的架構，團隊是如何設計 SLICK 這個服務，用到哪些元件以及這些元件之間個溝通流向
3. 兩個使用 SLICK 來改善穩定度的案例，這兩個案例都有簡單的去識別化，主要是介紹這些團隊發生什麼問題，如何透過 SLICK 來改善以及改善後的效能。

標題: 「透過 Kubefarm 來自動化幫實體機器打造基於 Kubernetes in Kubernetes 的 Kubernetes 環境」
類別: Kubernetes
連結: https://kubernetes.io/blog/2021/12/22/kubernetes-in-kubernetes-and-pxe-bootable-server-farm/

摘要:
本篇文章要介紹 Kubefarm 這個專案，該專案的目的是希望能夠於大量的實體機器上去創建各式各樣的 Kubernetes 叢集供不同團隊使用
為了讓整體的運作更加自動化，作者先行介紹何謂 Kubernetes in Kubernetes 這個專案，如何透過 Kubeadm 的方式於一個現存的 Kubernetes 專案
去部署 control-plane 並且透過這個 control-plane 去控管其他的 kubernetes 叢集，基本上達到的效果就如同各種 kubernetes service 服務一樣，使用者完全看不到 control-plane 的元件。

雖然透過這個方式可以很輕鬆地去創建新的 Kubernetes 叢集來使用，但是使用上覺得還是不夠方便，特別是這些實體機器還是會有不少手動的過程要處理，
為了讓整體流程更加自動化，作者團隊又基於 Kubernetes in Kubernetes 這個專案為基礎再開發更上層的專案，稱為 Kubefarm，一個如農場般可以快速於實體機器創建各式各樣 kubernetes 叢集的解決方案

Kubefarm 由三個專案組成，分別是
Kubernetes in Kubernetes, LTSP (PXE-Server) 以及 Dnsmasq-Controller
透過這三者專案的結合，實體機器會自動取得 DHCP 的 IP 地址並且透過 PXE 系統自動化安裝 OS，待一切都安裝完畢後又會自動地加入到現存的 Kubernetes 叢集中

整篇文章滿長的，是一過非常有趣的用法與研究，如果團隊是大量實體非虛擬化機器的讀者可以研究看看別人遇到什麼問題以及透過何種思路去解決的。