Service Mesh 這幾年的話題沒有停過，不論是 Linkerd, istio 或是其他解決方案都有各自的支持者。今天這篇文章是 Linkerd 官方文章，來跟大家解釋說明為什麼 Linkerd 沒有像其他解決方案一樣直接採用 Enovy 做為底層 proxy，而是要自行開發一個名為 Linkerd2-proxy 的取代方案
# 前提
1. Linkerd 是一個由工程團隊打造給工程團隊使用的產品，所有的決定都是基於工程方面的考量，而不是市場壓力
2. Envoy 很棒，但是對於 Linkerd 來說並沒有辦法透過 Envoy 打造一個簡單，輕量且安全的 Service Mesh 解決方案
3. 透過重新打造 Linkerd2-proxy，針對自己的需求重新設計才有機會讓 Linkerd 變得簡單且好用
# 想法
1. Linkerd2-proxy 是一個完全不考慮使用者面向的 Proxy 實作，跟 Envoy, Nginx 以及 Apache 這類型的實作是完全不同考慮。 Linkerd2-proxy 就是一個專門給 Linkerd 內部使用的
2. Envoy 超級彈性，同時是一個多用途的 Proxy，這種框架導致 Envoy 非常熱門，但帶來的就是其底層複雜。對於 Linked 來說需要的功能沒有這麼多。簡單來說就是殺雞焉用牛刀
3. 根據 Linkerd 內部的效能壓測，於 4,000 RPS(Request Per Second) 的前提下， Istio's Envoy 使用的 CPU 量相對於 Linkerd2-proxy 是 50% ~ 1000% 的增長，而 Memory 則是 1000%
4. Linkerd2-proxy 採用 Rust 開發，相對於 C++ 來說再安全性方面的開發會比較輕鬆一點，這個並不代表 Envoy 不安全，因為 Enovy 的社群龐大，CVE跟 bug 的修復也是很快。
# 其他
1. 相對於重新開發一個類似 Linkerd2-proxy 的專案，直接使用 Envoy 做為底層的 proxy 是非常簡單且省時的。並不是所有的 Service Mesh 解決方案都有足夠的能力與時間去開發屬於自己的 Proxy，因此整合 Enovy 並非錯誤
2. 目前使用 Linkerd 解決方案的使用者，其底層都是使用 Linkerd2-proxy
3. 其他的 Service Mesh 並不太能直接改採用 Linkerd2-proxy，畢竟其本身的設計就不是一個市場與使用者面向的專案。作者建議可以考慮使用 Rust 的 network library 來打造一個自己的方案
這篇文章並不是教你如何使用 Service Mesh，反而是分享更多一些設計上的哲學思考，個人覺得非常有趣，有興趣的可以點選下列連結觀看全文
https://linkerd.io/2020/12/03/why-linkerd-doesnt-use-envoy/
rust效能 在 Re: [問題] 請問關於Rust 跟C 的速度比較- 看板C_and_CPP 的推薦與評價
※ 引述《os653 ()》之銘言：
: 最近在練習 Rust，聽說執行速度可以跟 C 相當
: 但看了下面網頁的執行速度比較，似乎 Rust 還是略輸一截
: https://benchmarksgame.alioth.debian.org/u64q/rust.html
: 請問這是為什麼？
: 在我的粗略理解上，Rust 的很多東西都是在編譯期就處理掉了
: 而且因為變數的定義較為嚴格，還有可能編出較短的機械碼
: 那理論上應該會比 C 快才對呀？
Hi, 在開始說明前，建議你可以先看一下 benchmarks game 針對效能比較的說明
https://benchmarksgame.alioth.debian.org/dont-jump-to-conclusions.html
他們開宗明義就講：每個程式語言設計時要達成的目標不一樣
單純地實作相同演算法並比較它們的效能，其實是LP比雞腿
Rust 在設計上的首要目標是 memory safe 與 thread safe
並且在提供高階抽象化的同時，儘可能維持良好的執行效能
而 C 的目標是取代當時 (1973) 雖然效能好但不易跨平台的組合語言
因此它允許 undefined behavior，而且提供許多低階的操作
確實 Rust 在 compile time 就做了許多 safety check 來提高 runtime 效率
但有些與 memory safety 相關的檢查確實很難在 compile time 實現
而 C compiler 根本就不管 memory safety 的
這種時候，Rust 的執行效率確實會比 C 還要慢
最簡單最常見的例子就是陣列存取
像這樣的程式碼：
array[i] = x;
Rust 的效率會明顯低於 C
因為 compiler 無法在 compile time 確認 i 是否落在 array 的長度限制內
為了不引發 undefined behavior，它必需在 runtime 幫你做邊界檢查。
事實上，所有 memory safe 的語言，在這樣的陣列存取時都會做邊界檢查。
大家會說 Rust 的效能很好，多半是與其它 memory safe 的語言比較
比如說 C# / Java / Go，而不是和 C 比較。
* * *
所以 Rust 一定比 C 還要慢嗎？那也不一定。
你可以看看 C 與 C++ 在 benchmarks game 上面的比較，
幾乎所有的測試中 C 都比 C++ 還要快。
但是，如果你比較 C++ 的 std::sort 與 C 的 qsort
那麼 C++ 肯定是壓倒性的勝利
當然，如果要比排序，你還是可以用 C 手刻一個與 C++ sort 相同的版本
但，當你使用某個語言寫程式，而標準函式庫提供了 qsort
你還會手刻一個自己的 sort 出來嗎？
「使用某語言」在一定程度上，包含了「使用某語言的library」
這也算是 benchmarks game 的一項規則
上面的測試程式碼會儘可能使用該語言提供的函式庫
以符合使用該語言寫程式的普遍情況
因此，benchmarks game 上面某個語言的效能，應該要被理解為它的「平均表現」
而不是該語言的「極限」
以 C 與 Rust 的比較中，其中 C 表現得比較好的測試像是 mandelbrot 或 n-body
C 都使用了 SIMD 指令以提昇效率
但是目前 Rust 的 SIMD 尚未成為標準功能，因此範例碼中也未使用 SIMD 加速
這是否表示 Rust 不能用 SIMD 呢？並不是
你真的想做，還是可以用 unsafe block 與 inline asm 做到
但這不會是 Rust programming 的常態
畢竟如果你那麼在意效能，覺得效能比 memory safe 或易讀易寫更重要
那 C 還是比較適合的選擇
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 125.227.5.133
※ 文章網址: https://www.ptt.cc/bbs/C_and_CPP/M.1502645537.A.264.html
... <看更多>