で、norpcというライブラリを紹介した。

https://tokio.rs/tokio/tutorial/channels

などでも語られているとおり、 リソースをサービスの中に閉じ込め、 そこに対するアクセスはすべてメッセージングで行うというデザインパターンが有効な場合がある。 一般のネットワークごしのマイクロサービスでも、データベースアクセスや、 外部からの or へのアクセスをサービスによって隠蔽したりする。

norpcは、プロセス内にサービスを立ち上げ、そこにRPCを定義することを容易にするライブラリだ。 素で行うとメッセージ定義など、煩雑なコードが必要になるところをすべて自動生成するだけだと考えれば、そう飛躍はない。

今現在おれが描く 非同期アプリケーション実装の ベストプラクティスは、プロセスの内部をnorpcによるメッセージパッシングで実現し、 プロセス間通信をgRPCで実現するというものだ。 そしておれの興味は、「本当にこれは正しいことなのだろうか？」だ。 実際のところ、正しいのか間違ってるのかよくわからずにやっている。 単純なメッセージパッシングをRPCに持ち上げただけなので、そう間違ってるとも思えないが、 本当にやっていいことなのかなど、謎が多い。

これを確かめる方法の一つは、理論的な証明をつけることだが、これはおれの能力ではどうにもならない。 もう１つの方法は、実践し、体験によって主観的な評価を行うことだ。

Sorockの開発は、この検証目的でもある。

norpcは実際には、社内のプロジェクトでも、それはSorockよりも巨大なソフトウェアであるが、使っている。 そこでの体験は確かに、norpcがなければ開発はより困難になっただろうというものだ。 実際に、ソフトウェアをマイクロサービスという非同期部品に分割し、それぞれを完成させ、 最終的に回路を組み立てるかのように部品を接続するという方法は、実装を簡単にしたと思う。 この場合はおれがすべてを一人で実装したが、他人に対して仕事を分割することも容易だったと思う。

そのため、社内での体験は非常に良いものなのであるが、何しろクローズドなものでありコードを見せることが出来ない。 そしておれは思う。コードがないものは何の証拠にもならず、コードも体験もすべて妄想だと言われても致し方がない。

分散ストレージは明らかにユーザからのリクエスト処理部分と、内部の安定化処理を全く非同期に行うことが出来る。 外部からのクラスタ情報の伝搬も、他の処理とは非同期に行われる。 また、ストレージというリソース、外部へのgRPCのためのコネクションというリソースの管理も行う必要がある。 そのため、norpcの格好の材料だった。 だから、norpc（と同時にlol）の パブリックな応用例として、Sorockを作ることにした。

Sorockの内部はこのようになっている。水色の部分がnorpcによるマイクロサービスだ。

例えば、IOFrontは以下のように定義している。

1
2
3
4
5
6

#[norpc::service]
trait IOFront {
    fn create(key: String, value: Bytes);
    fn read(key: String) -> Bytes;
    fn set_new_cluster(cluster: ClusterMap);
}

今回も、アーキテクチャに強引さは感じられず、実装はとても容易であった。 仮にあるサービスが他のサービスを新たに利用することになったとしても、変更量は少ない。 サービスを共有する場合でもクライアントをcloneするだけなので、 コストは低いし、所有権について考える必要はない。 また、依存しているサービスが明確になることも可読性の観点から優れてると考えられた。

ぜひ、norpcを使ってみてほしい。ゴミならゴミで構わないので批判があれば、ぜひ公開してほしい。

https://github.com/akiradeveloper/norpc