メインコンテンツまでスキップ

go-lynxの設計思想

· 約6分
tanzhuo

github.com/go-lynx の設計目的は、企業がマイクロサービス体系を素早く構築できるようにするための基盤フレームワークを提供することです。リポジトリ全体(組織 go-lynx 配下の 29 個の repo を含む)を分割し、lynx アーキテクチャの基盤部分と、各種 lynx プラグインモジュールに分けています。

https://github.com/go-lynx

最大の特徴は Plug-and-Play(本当の意味でのすぐ使える体験)で、複雑なマイクロサービスアーキテクチャを「ブロック遊び」のように組み立てられることです。

ゼロから車輪を再発明するのではなく、巨人の肩の上に立っています。

  • コアランタイムは Kratos(bilibili のオープンソースフレームワーク)を利用
  • サービスディスカバリー/ガバナンスには Polaris(Tencent のクラウドネイティブサービスメッシュ)と Nacos(Alibaba のオープンソース) を採用
  • 分散トランザクションには Seata、DTM などを利用
  • その上に、自作のプラグイン管理システム + イベントバス + コントロールプレーンを追加し、本当のホットスワップを実現しています。

Kratos との比較:Kratos は「基盤フレームワーク」であり、Lynx は「Kratos のプロダクション強化版 + プラグイン体系 + ゼロコンフィグ」です。Kratos は好きだけれど設定が面倒、プラグインが統一されていないと感じているなら、このフレームワークはまさにそのペインポイントのために生まれたものです。

スキャフォールディング​

ゼロコンフィグ + CLI スキャフォールディングにより、コマンド 1 つで完全なプロジェクトを素早く生成できます。

# lynx コマンドラインツールをインストール
go install github.com/go-lynx/lynx/cmd/lynx@latest

# 完全なマイクロサービスプロジェクトの骨組みを生成
lynx new my-service

実装済みのプラグイン体系​

  • 既存のプラグイン:gRPC、HTTP、Redis、PostgreSQL、Redis 分散ロック、Swagger、Tracer、Seata など。
  • プラグイン間は組み込みの Event Bus で通信し、プラグイン同士の連携と制御を実現。
  • サービス登録・ディスカバリー + ヘルスチェック + マルチバージョン + ロードバランシング(Polaris)
  • トラフィックガバナンス:レートリミット、サーキットブレーカー、ブルーグリーン/カナリア、fallback
  • セキュリティ:TLS 相互認証、JWT、OAuth2、RBAC/ABAC
  • 分散トランザクション:Seata 完全自動化
  • オブザーバビリティ:Prometheus + OpenTelemetry + Zap(JSON ログ)
  • グレースフルシャットダウン、リトライ、デッドレターキュー、リカバリーマネージャー

設定駆動​

  • 各プラグインは固定の confPrefix(例:lynx.grpc.service、lynx.grpc.client)を持ち、設定は Lynx Runtime の rt.GetConfig().Value(confPrefix).Scan(...) から読み込まれます。
  • Configure(c) によるホットリロードをサポート:サーバー側では confMu で設定ポインタの差し替えを保護し、並行安全性を保証しつつ、再起動なしで一部の機能を更新できます。

lynx プロジェクトの設定例(YAML 形式)​

lynx:
  polaris: {namespace: default}   # サービス登録・ディスカバリー
  http: {addr: ":8080"}           # HTTP サービスのリッスンアドレス
  grpc: {addr: ":9090"}           # gRPC サービスのリッスンアドレス
  # metrics/tracing/logging/tls/rate_limit もすべて既成のテンプレートあり

全体的には Spring Boot に似ており、使いたいプラグインの分だけ設定を書けばよく、プラグインは完全にすぐ使える状態になっています。

プラグイン化アーキテクチャの設計​

  • 統一プラグインインターフェース:プラグインは Lynx の plugins.Plugin インターフェースを実装し、BasePlugin を埋め込むことで ID、名前、バージョン、設定プレフィックス、重みなどの共通機能を獲得します。
  • ファクトリー登録:クライアントプラグインは init() 内で factory.GlobalTypedFactory().RegisterPlugin(clientPluginName, "lynx.grpc.client", ...) によって登録され、フレームワークが設定プレフィックスに基づいて読み込み、ライフサイクルを管理します。
  • ライフサイクル:標準の 3 フェーズ——InitializeResources(設定の読み込み・検証)、StartupTasks(サービス起動・接続)、CleanupTasks(グレースフルシャットダウン・リソース解放)。
  • 依存性注入:サーバー側プラグインは SetDependencies を通じてアプリケーション名、Logger、証明書、コントロールプレーンなどが注入され、グローバルシングルトンを避けることで、テストやマルチインスタンス化が容易になります。

セキュリティモジュールの設計​

内部ネットワークのマイクロサービス間通信のセキュリティを確保するため、Lynx には TLS 証明書の自動管理とローテーション機能が組み込まれています。サービスの稼働中に証明書を更新しても再起動は不要で、新しく確立される接続は自動的に最新の証明書を使用するため、本当の意味でのゼロダウンタイム更新を実現しています。全体の設計としては、統一された証明書プロバイダー(CertificateProvider)で証明書を管理し、内部ネットワークの gRPC サーバーは TLS ハンドシェイク時に現在の証明書を動的に取得します。クライアント側も同じ仕組みで Root CA を取得し、クレデンシャルのリフレッシュをサポートするため、証明書の更新は自動的に反映されます。さらにこの仕組みはファイル監視、クラウド証明書サービス、鍵管理システムとの連携が可能で、証明書更新の自動化とエンタープライズレベルのセキュアな通信を実現し、システムのセキュリティを高めると同時に、運用コストも大幅に削減します。

まとめ​

go-lynx のコアとなる考え方は、車輪の再発明ではなく、Kratos の上にプロダクション環境で必要となるレイヤーを補完することです。統一されたプラグイン体系、設定駆動によるすぐ使える体験、そしてイベントバスとコントロールプレーンがもたらすホットスワップ機能。サービスガバナンス、分散トランザクション、オブザーバビリティ、TLS 自動ローテーションといった機能はすべてプラグインとして提供され、使いたいものだけ設定すればよい仕組みです。Kratos を使っていて設定やプラグインの不統一に悩まされたことがあるなら、ぜひ go-lynx を見て、この設計があなたのペインポイントを解決できるか確かめてみてください。

COMMENTS