我們的行業傾向於迷戀Google，Netflix等公司的技術架構。他們已經構建了一些令人印象深刻的技術來解決罕見的擴充套件問題，所以這並不奇怪。但是，您的公司/系統是否需要類似的解決方案？可能不是...

對服務網格、K8S和其他原生技術的強烈抵制是合理的質疑，廠商供應商的營銷和強大技術思想領先導致較小的組織沒有看到森林，而只看到他們的樹木，並採用過於複雜的解決方案實現他們的實際需求。

如果你有一個新的/小的分散式系統，可從下面開始選擇：

 1. 單體Monolith SOA

 2. 沒有型別的語言/ API，比較狂野的

 3. 單一大程式碼庫Monorepo

 4. FaaS

 5. MongoDB？Web規模

 -1. 服務網格

 -2. K8S

專注於創造客戶價值，儘可能保持事物的簡單和無聊。但是，如果你有幸找到成功，你的開發團隊將會成長，你最終將轉向SOA。

無型別的語言和API將不再那麼高效。 - 那個monorepo？甚至我都不會從它開始， 今天最先進的FaaS不會在可靠性，視覺障礙，網路等方面問題，特別是當你開始感受SoA網路/視力障礙時。

此時，“服務網格”將以某種方式為您服務，因為必須解決障礙，負載平衡，服務發現，一致超時，重試等問題，或者您的SoA是DOA。

你全部使用Java嗎？Finagle或Hystrix是不錯的選擇。你是一個Go全棧嗎？試試像Micro這樣的東西。你是多語言嗎？您可以將資源投入到每種語言的自定義庫中，也可以使用邊車，必須找到解決方案。

如果你採取服務網格和K8s，你需要承擔的網路複雜性，因為無論供應商/會議告訴你什麼，都會有痛苦，沒有任何東西是免費的。

總是這樣嗎？我不這麼認為。我實際上認為我們正處於一個橋樑時期，普通工程師必須直接與Envoy和K8S等技術進行互動才能在SoA取得成功。

我堅信，在10年的時間內，FaaS是所有人都會與之互動的。如果我是開發人員，我想提供以下程式碼：

- 來自資料庫的讀寫R/W

- 呼叫API

- 佇列/deques作業

就是這樣。其他一切都是噪音。

在這種情況下，我認為在一個雲足以執行Google 的FaaS世界，K8S，Envoy，“服務網格”等技術將無處不在，但幾乎沒有人會知道它們在哪裡。這些都是管道。沒有人關心管道。