Microservice で実現するココナラ新プロフィールページ機能

こんにちは。開発グループ・エンジニアの阿部です。
社内では abemotion って呼ばれたりもします。

前回の記事で紹介したのですが、

提案していたマイクロサービスの構成を初めて利用した

「新プロフィールページ機能」をついにリリースしました！！

f:id:coconalainc:20181030183148p:plain

設計期間も含めると約5ヶ月、、

長い戦いでした...

今回はそんな「新プロフィールページ機能」のシステム部分について、お話をさせて頂けたらと思います。

システム構成

私は apigateway(golang)の構築と profile Service の Rails 実装を担当しました。

マイクロサービス構成としてもそうですが、apigateway に至っては、本当に一から構築でした。

今回は golang での apigateway に焦点をあてたいと思います。

まずは設計方針からなのですが、

男は黙って標準パッケージ

フレームワーク（以下、WAF）を用いず、Goの標準パッケージを使って開発しました。

まだデファクトスタンダードのWAFがなく、
その段階でWAFを使うのは、今後負債化する恐れがあるためです。
※ もちろん使っている会社もある

ただ仕方なしの選定ではないです。

Goには機能豊富なパッケージが多く、
WAFの中には、標準パッケージをラッパーしているだけ的なのもあります。

次はパッケージ構成について、 Webアプリ内のレイヤ(ディレクトリ)構造をどうするかという話です。

そもそもGoでは、相互参照するとエラーになるので、
フレームワークを使わない以上、設計が重要になってきます。

他社さんの記事なども参考にさせて頂き、Lightweight DDDを採用しました。
(DDDライクなライトなパッケージ構成。レイヤアーキテクチャ)

interfaces：リクエストハンドラ
application：domain層を扱うビジネスロジック
domain：モデル。構造体定義（値と振る舞い）他構造体に付随する共通処理
- repository：infrastructure のインターフェース定義
- service：application のインターフェース定義
infrastructure：技術的機能
- persistence：domainで定義したデータアクセスの実装

「依存関係逆転の法則」を意識し、依存の方向や詳細ではなく抽象へ依存するよう考慮しました。

フロントエンド(Express)→ apigateway → Profile Service 間は、gRPCで通信しています。

前回の記事で、gRPCの概要・メリットは説明したので、ここでは使い方や運用方法について記します。

まずインターフェースの仕様となる .proto ファイルを Protocol Buffers 形式で記述し、
ファイル自体は専用のリポジトリを1つ用意し一元管理しています。

リポジトリからソースを取得し、 protoc コマンドを使うことで言語毎のモデルファイルが生成できます。

実装はサーバ/クライアント共に生成されたファイルを使って開発を行います。

gRPC では、エラーコードが独自に用意されており、 HTTP ステータスコードとのマッピングもコメント内に書かれています。