在现代微服务环境中，构建小型、单一的应用程序的旧策略又再一次流行了起来。
1984年，RobPike和BrianW.Kernighan在AT&T贝尔实验室技术期刊上发表了名为“Unix环境编程”的文章，其中他们使用BSD的cat-v例子来认证Unix哲学。简而言之，Unix哲学是：构建小型、单一的应用程序——不管用什么语言——只做一件小而美的事情，用stdin/stdout进行通信，并通过管道进行连接。
听起来是不是有点耳熟？
是的，我也这么认为。这就是JamesLewis和MartinFowler给出的微服务的定义。
简单来说，微服务架构的风格是将单个应用程序开发为一套小型服务的方法，每个服务都运行在它的进程中，并用轻量级机制进行通信，通常是HTTP资源API。
虽然一个*nix程序或者是一个微服务本身可能非常局限甚至不是很有用，但是当这些独立工作的单元组合在一起的时候就显示出了它们真正的好处和强大。
下面的表格对比了*nix环境中的程序（例如cat或lsof）与微服务环境中的程序。
*nix系统（如Linux）中的执行单元是一个可执行的文件（二进制或者是脚本），理想情况下，它们从stdin读取输入并将输出写入stdout。而微服务通过暴露一个或多个通信接口来提供服务，比如HTTP和gRPCAPI。在这两种情况下，你都会发现无状态示例（本质上是纯函数行为）和有状态示例，除了输入之外，还有一些内部（持久）状态决定发生了什么。
传统的，*nix程序能够通过管道进行通信。换句话说，我们要感谢DougMcIlroy，你不需要创建临时文件来传递，而可以在每个进程之间处理无穷无尽的数据流。据我所知，除了我在2017年做的基于ApacheKafka小实验，没有什么能比得上管道化的微服务了。
*nix系统和微服务都提供了许多挑战和机遇。
要设计一个简洁、有清晰的目的，并且能够很好地和其它模块配合的某个东西是很困难的。甚至是在不同版本中实现并引入相应的异常处理流程都很困难的。在微服务中，这意味着重试逻辑和超时机制，或者将这些功能外包到服务网格servicemesh是不是一个更好的选择呢？这确实比较难，可如果你做好了，那它的可重用性是巨大的。
或者在一个微服务设置中请求一个路径，例如，涉及20个服务，你怎么弄清楚是哪个服务的问题？幸运的是，我们有很多标准，特别是OpenCensus和OpenTracing。如果您希望转向微服务，可预测性仍然可能是最大的问题。
对于*nix程序来说可能不是一个大问题，但在微服务中，全局状态仍然是一个需要讨论的问题。也就是说，如何确保有效的管理本地化（持久性）的状态以及尽可能在少做变更的情况下使全局保持一致。
最后，问题仍然是：你是否在使用合适的工具来完成特定的工作？也就是说，以同样的方式实现一个特定的*nix程序在某些时候或者阶段会是一个更好的选择，它是可能在你的组织或工作过程中的一个最好的选择。无论如何，我希望这篇文章可以让你看到Unix哲学和微服务之间许多强有力的相似之处。也许我们可以从前者那里学到一些东西使后者受益。