*nix程式 vs 微服務

1984 年，Rob Pike 和 Brian W. Kernighan 在 AT&T 貝爾實驗室技術期刊上發表了名為 “Unix 環境程式設計” 的文章，其中他們使用 BSD 的cat -v例子來認證 Unix 哲學。簡而言之，Unix 哲學是：構建小型、單一的應用程式 —— 不管用什麼語言 —— 只做一件小而美的事情，用stdin /stdout進行通訊，並透過管道進行連線。

這就是 James Lewis 和 Martin Fowler 給出的微服務的定義 。
簡單來說，微服務架構的風格是將單個 應用程式開發為一套小型服務的方法，每個服務都執行在它的程式中，並用輕量級機制進行通訊，通常是 HTTP 資源 API 。
雖然一個 *nix 程式或者是一個微服務本身可能非常侷限甚至不是很有用，但是當這些獨立工作的單元組合在一起的時候就顯示出了它們真正的好處和強大。

下面的表格對比了 *nix 環境中的程式（例如 cat 或 lsof）與微服務環境中的程式。

	*nix 程式	微服務
執行單元	程式使用 stdin/stdout	使用 HTTP 或 gRPC API
資料流	管道	？
可配置和引數化	命令列引數、環境變數和配置檔案	JSON/YAML 文件
發現	包管理器、man、make	DNS、環境變數、OpenAPI

讓我們詳細的看看每一行。

*nix 系統（如  ）中的執行單元是一個可執行的檔案（二進位制或者是指令碼），理想情況下，它們從 stdin 讀取輸入並將輸出寫入stdout 。而微服務透過暴露一個或多個通訊介面來提供服務，比如 HTTP 和 gRPC API。在這兩種情況下，你都會發現無狀態示例（本質上是純函式行為）和有狀態示例，除了輸入之外，還有一些內部（持久）狀態決定發生了什麼。

傳統的，*nix 程式能夠透過管道進行通訊。換句話說，我們要感謝 Doug McIlroy，你不需要建立臨時檔案來傳遞，而可以在每個程式之間處理無窮無盡的資料流。據我所知，除了我在 2017 年做的基於 Apache Kafka 小實驗，沒有什麼能比得上管道化的微服務了。

你是如何配置程式或者服務的，無論是永久性的服務還是即時的服務？是的，在 *nix 系統上，你通常有三種方法：命令列引數、環境變數，或全面的配置檔案。在微服務架構中，典型的做法是用 YAML（或者甚至是 JSON）文件，定製好一個服務的佈局和配置以及依賴的元件和通訊、儲存和執行時配置。例如 Kubernetes 資源定義、Nomad 工作規範 或 Docker 編排 文件。這些可能引數化也可能不引數化；也就是說，除非你知道一些模板語言，像 Kubernetes 中的 Helm，否則你會發現你使用了很多sed -i 這樣的命令。

你怎麼知道有哪些程式和服務可用，以及如何使用它們？在 *nix 系統中通常都有一個包管理器和一個很好用的 man 頁面；使用它們，應該能夠回答你所有的問題。在微服務的設定中，在尋找一個服務的時候會相對更自動化一些。除了像 Airbnb 的 SmartStack 或 Netflix 的 Eureka 等可以定製以外，通常還有基於環境變數或基於 DNS 的方法，允許您動態的發現服務。同樣重要的是，事實上 OpenAPI 為 HTTP API 提供了一套標準文件和設計模式，gRPC 為一些耦合性強的高效能專案也做了同樣的事情。最後非常重要的一點是，考慮到開發者經驗（DX），應該從寫一份好的 Makefile 開始，並以編寫符合 風格 的文件結束。

*nix 系統和微服務都提供了許多挑戰和機遇。

要設計一個簡潔、有清晰的目的，並且能夠很好地和其它模組配合的某個東西是很困難的。甚至是在不同版本中實現並引入相應的異常處理流程都很困難的。在微服務中，這意味著重試邏輯和超時機制，或者將這些功能外包到服務網格service mesh是不是一個更好的選擇呢？這確實比較難，可如果你做好了，那它的可重用性是巨大的。

在一個獨石（2018 年）或是一個試圖做任何事情的大型程式（1984 年），當情況惡化的時候，應當能夠直接的找到問題的根源。但是在一個

yes | tr \\n x | head -c 450m | grep n

或者在一個微服務設定中請求一個路徑，例如，涉及 20 個服務，你怎麼弄清楚是哪個服務的問題？幸運的是，我們有很多標準，特別是 OpenCensus 和 OpenTracing。如果您希望轉向微服務，可預測性仍然可能是最大的問題。

對於 *nix 程式來說可能不是一個大問題，但在微服務中，全域性狀態仍然是一個需要討論的問題。也就是說，如何確保有效的管理本地化（永續性）的狀態以及儘可能在少做變更的情況下使全域性保持一致。

最後，問題仍然是：你是否在使用合適的工具來完成特定的工作？也就是說，以同樣的方式實現一個特定的 *nix 程式在某些時候或者階段會是一個更好的選擇，它是可能在你的組織或工作過程中的一個最好的選擇。無論如何，我希望這篇文章可以讓你看到 Unix 哲學和微服務之間許多強有力的相似之處。也許我們可以從前者那裡學到一些東西使後者受益。