1984年、RobPikeとBrianW. Kernighanは、AT＆T Bell Laboratories Technical Journalに「Unix環境でのプログラム設計」という記事を公開しました。この記事では、BSDの cat -v <の例を使用して、Unix哲学について論じています。 / strong> 実装。一言で言えば、その哲学は次のとおりです。1つのことだけを実行し、このことをうまく実行し、 stdin を介して通信する、小規模で焦点を絞ったプログラムを（どの言語でも）構築します。 / stdout 、およびパイプを介して接続されています。
おなじみですか？
ええ、そう思いました。これは、JamesLewisとMartinFowlerが提供するマイクロサービスの定義とほぼ同じです。
つまり、マイクロサービスアーキテクチャスタイルは、単一のアプリケーションを小さなサービスのスイートとして開発するためのアプローチであり、それぞれが独自のプロセスで実行され、軽量のメカニズム（多くの場合HTTPリソースAPI）と通信します。
1つの*nixプログラムまたは1つのマイクロサービスは、それ自体では非常に制限されているか、あまり面白くないかもしれませんが、そのような独立して動作するユニットの組み合わせが、真のメリット、したがってそのパワーを明らかにします。
*nixvs.マイクロサービス
次の表では、プログラム（ cat など）を比較しています。 またはlsof ）マイクロサービス環境のプログラムに対する*nix環境。
| * nix | ||
|---|---|---|
| 実行単位 | stdinを使用したプログラム / stdout | HTTPまたはgRPCAPIを使用したサービス |
| データフロー | パイプ | ？ |
| 構成とパラメーター化 | コマンドライン引数、 環境変数、構成ファイル | JSON/YAMLドキュメント |
| 発見 | パッケージマネージャー、男性、作成 | DNS、環境変数、OpenAPI |
各行をもう少し詳しく見ていきましょう。
マイクロサービスの詳細
- マイクロサービスのチートシート
- マイクロサービスをCEOに説明する方法
- 無料の電子書籍：マイクロサービスとサービス指向アーキテクチャ
- 無料のオンラインコース：マイクロサービスアーキテクチャを使用したクラウドネイティブアプリケーションの開発
- 最新のマイクロサービス記事
* nix（Linuxなど）の実行単位は実行可能ファイル（バイナリまたは解釈されたスクリプト）であり、理想的には stdinからの入力を読み取ります。 出力をstdoutに書き込みます 。マイクロサービスのセットアップは、HTTPやgRPCAPIなどの1つ以上の通信インターフェースを公開するサービスを扱います。どちらの場合も、ステートレスの例（本質的に純粋関数型の動作）とステートフルの例があり、入力に加えて、内部の（永続的な）状態が何が起こるかを決定します。
従来、*nixプログラムはパイプを介して通信できました。言い換えると、Doug McIlroyのおかげで、渡すために一時ファイルを作成する必要がなく、それぞれがプロセス間で事実上無限のデータストリームを処理できます。私の知る限り、2017年のApache Kafkaベースの小さな実験以外に、マイクロサービスで標準化されたパイプに匹敵するものはありません。
プログラムまたはサービスを、永続的または呼び出しベースでどのように構成しますか？ * nixプログラムでは、基本的に3つのオプションがあります。コマンドライン引数、環境変数、または本格的な構成ファイルです。マイクロサービスでは、通常、YAML（またはさらに悪いことにJSON）ドキュメントを処理し、単一のマイクロサービスのレイアウトと構成、および依存関係と通信、ストレージ、およびランタイム設定を定義します。例としては、Kubernetesリソース定義、Nomadジョブ仕様、DockerComposeファイルなどがあります。これらはパラメータ化されている場合とされていない場合があります。つまり、KubernetesのHelmなどのテンプレート言語を使用しているか、非常に多くの sed -iを実行していることに気づきます。 コマンド。
どのようなプログラムやサービスが利用可能であり、それらがどのように使用されることになっているのかをどうやって知るのですか？ええと、* nixには、通常、パッケージマネージャーと古き良き人がいます。それらの間で、彼らはあなたが持っているかもしれないすべての質問に答えることができるはずです。マイクロサービスのセットアップでは、サービスの検索がもう少し自動化されます。 AirbnbのSmartStackやNetflixのEurekaのような特注のアプローチに加えて、通常、サービスを動的に検出できる環境変数ベースまたはDNSベースのアプローチがあります。同様に重要なのは、OpenAPIがHTTP APIのドキュメントと設計の事実上の標準を提供し、gRPCがより緊密に結合された高性能のケースに対して同じことを行うことです。最後になりましたが、開発者の経験（DX）を考慮に入れてください。まず、優れたMakefileを作成し、最後にスタイルを使用して（または？）ドキュメントを作成します。 。
長所と短所
* nixとマイクロサービスはどちらも、多くの課題と機会を提供します
はっきりとしたシャープなフォーカスを持ち、他の人とうまく遊ぶことができるものをデザインするのは難しいです。異なるバージョン間で正しく理解し、それぞれのエラーケース処理機能を導入することはさらに困難です。マイクロサービスでは、これは再試行ロジックとタイムアウトを意味する可能性があります。これらの機能をサービスメッシュにアウトソーシングする方がよいかもしれません。難しいですが、正しく理解すれば、その再利用性は非常に高くなる可能性があります。
モノリス（2018年）またはすべてを実行しようとする大規模なプログラム（1984年）では、事態が南下したときに犯人を見つけるのはかなり簡単です。しかし、
yes | tr \\n x | head -c 450m | grep nまたは、たとえば20のサービスを含むマイクロサービスセットアップのリクエストパス、どのように開始しますか どちらが悪い動作をしているのかを把握するには？幸いなことに、OpenCensusとOpenTracingなどの標準があります。マイクロサービスへの移行を検討している場合でも、可観測性が最大の単一ブロッカーになる可能性があります。
* nixプログラムにとってはそれほど大きな問題ではないかもしれませんが、マイクロサービスでは、グローバルな状態についてはまだ議論の余地があります。つまり、ローカル（永続的）状態を効果的に管理する方法と、グローバル状態を可能な限り少ない労力で一貫させる方法です。
結局のところ、疑問は残ります。特定のタスクに適切なツールを使用していますか？つまり、さまざまな機能を実装する特殊な* nixプログラムが特定のユースケースやフェーズに適しているのと同じように、組織やワークロードにはモノリスが最適なオプションである可能性があります。とにかく、この記事が、Unix哲学とマイクロサービスの間の多くの強力な類似点を理解するのに役立つことを願っています。おそらく、前者から何かを学び、後者に利益をもたらすことができるでしょう。