go マイクロサービス フレームワーク go-micro の全体的なアーキテクチャの紹介

プロジェクトの設立から開発、発売に至るまでの、製品に関わる小さなプロジェクトは、時間と需要が急増するにつれてますます複雑になり、大規模なプロジェクトに変わります。初期のプロジェクト アーキテクチャが適切に設計されていない場合、コードはますます肥大化して保守が困難になり、その後の製品の反復ごとにシステム全体に影響を及ぼします。

マイクロサービスベースのプロジェクトとモジュール間の疎結合関係は良い選択であり、メンテナンスコストは増加しますが、それでも価値があります。

マイクロサービス プロジェクトの安定性に加えて、私はいくつかの問題についても個人的に懸念しています:

1: サービス間のデータ送信の効率とセキュリティ。

2: サービスの動的な拡張、つまりサービスの登録と検出、およびサービスのクラスタリング。

3: マイクロサービス機能はカスタマイズ可能ですが、すべての機能がニーズを満たすわけではないため、必要に応じていくつかの機能を開発する必要があります。

go-micro は、go 言語 での優れた RPC マイクロサービス フレームワークです。完璧な機能を備えており、私が懸念していたいくつかの問題も解決しています。

1:サービス間の送信形式は protobuf であり、非常に効率的で高速かつ安全です。

2: go-micro のサービスの登録と検出は多様です。個人的には etcdv3 のサービス検出と登録の方が好きです。

3: 主要な機能には対応するインターフェイスがあり、対応するインターフェイスが実装されていれば、必要に応じてプラグインをカスタマイズできます。

暇なときに go-micro のソースコードを体系的に読みましたが、読めば読むほどこのフレームワークはよくできていると感じ、多くのことを学びました。一連の投稿をまとめて、go-micro を学習した私の経験を皆さんと共有したいと思っています。

go-micro の通信プロセスは次のとおりです。

サーバーはクライアントの呼び出しを監視し、Brocker によってプッシュされた情報を処理します。そして、サーバーは、クライアントがそのステータスを知ることができるように、その存在または終了を Register に登録する必要があります。

サービス登録の検出を登録します。

クライアントはRegisterからServer情報を取得し、呼び出しごとのアルゴリズムに基づいて通信するServerを選択しますが、当然ながら通信にはエンコード/デコードや伝送プロトコルの選択などの一連の処理が必要です。

すべてのサーバーに通知する必要がある場合は、Brocker を使用して情報をプッシュできます。

ブロッカー情報キューは情報を受信して​​公開します。

go-micro が高度にカスタマイズできる理由は、そのフレームワーク構造と切り離すことができません。go-micro は 8 つの主要なインターフェイスで構成されています。各インターフェイスは、独自のニーズに応じて再実装できます。この 8 つの主要なインターフェイスgo-micro のフレームワーク構造も構成します。

これらのインターフェイス go-micir には独自のデフォルト実装があり、これらのインターフェイスの実装の代替となる go-plugins もあります。ニーズに応じて独自のプラグインを実装することもできます。

この記事では、主に go-micro の主な構造とこれらのインターフェイスの機能を紹介します。具体的な詳細については、今後の記事で説明します。

#Transort#サービス間の通信のためのインターフェイス。つまり、サービスの送受信の最終的な実装は、これらのインターフェイスによってカスタマイズされます。

ソース コード:

type Socket interface {
    Recv(*Message) error
    Send(*Message) error
    Close() error
}

type Client interface {
    Socket
}

type Listener interface {
    Addr() string
    Close() error
    Accept(func(Socket)) error
}

type Transport interface {
    Dial(addr string, opts ...DialOption) (Client, error)
    Listen(addr string, opts ...ListenOption) (Listener, error)
    String() string
}

Transport の Listen メソッドは通常、サーバーによって呼び出され、ポートをリッスンしてクライアントからの呼び出しを待ちます。

Transport の Dial は、クライアントがサービスに接続するために使用する方法です。これは、クライアント インターフェイスを返し、クライアント インターフェイスはクライアント インターフェイスを返します。このクライアントはソケット インターフェイスに組み込まれており、このインターフェイスのメソッドは、具体的には通信情報の送受信を行うためのものです。

http 送信は、go-micro のデフォルトの同期通信メカニズムです。もちろん、他にも grpc、nats、tcp、udp、rabbitmq、nats などのプラグインが多数あり、これらはすべてこれまでに実装されています。 go-plugins で見つけることができます。

Codec

送信方法に関して、次に解決すべきは送信のエンコードとデコードの問題です。go-micro には多くのエンコードとデコードの方法があります。デフォルトの実装もちろんprotobufですが、json、protobuf、jsonrpc、mercuryなど他の実装方法もあります。

ソース コード

type Codec interface {
    ReadHeader(*Message, MessageType) error
    ReadBody(interface{}) error
    Write(*Message, interface{}) error
    Close() error
    String() string
}

type Message struct {
    Id     uint64
    Type   MessageType
    Target string
    Method string
    Error  string
    Header map[string]string
}

Codec インターフェイスの Write メソッドはエンコード プロセスであり、2 つの Read はデコード プロセスです。

レジストリ

サービスの登録と検出、現在実装されている consul、mdns、etcd、etcdv3、zookeeper、kubernetes など、

type Registry interface {
    Register(*Service, ...RegisterOption) error
    Deregister(*Service) error
    GetService(string) ([]*Service, error)
    ListServices() ([]*Service, error)
    Watch(...WatchOption) (Watcher, error)
    String() string
    Options() Options
}

に簡単に言うと、サービスが登録され、クライアントは監視のために watch メソッドを使用します。サービスが追加または削除されると、このメソッドがトリガーされて、クライアントにサービス情報の更新を通知します。

デフォルトのサービス登録と検出は consul ですが、consul クラスターを直接使用できないため、個人的にはお勧めしません。

我个人比较喜欢etcdv3集群。大家可以根据自己的喜好选择。

Selector

以Registry为基础，Selector 是客户端级别的负载均衡，当有客户端向服务发送请求时， selector根据不同的算法从Registery中的主机列表，得到可用的Service节点，进行通信。目前实现的有循环算法和随机算法，默认的是随机算法。

源码：

type Selector interface {
    Init(opts ...Option) error
    Options() Options
    // Select returns a function which should return the next node
    Select(service string, opts ...SelectOption) (Next, error)
    // Mark sets the success/error against a node
    Mark(service string, node *registry.Node, err error)
    // Reset returns state back to zero for a service
    Reset(service string)
    // Close renders the selector unusable
    Close() error
    // Name of the selector
    String() string
}

默认的是实现是本地缓存，当前实现的有blacklist,label,named等方式。

 Broker

Broker是消息发布和订阅的接口。很简单的一个例子，因为服务的节点是不固定的，如果有需要修改所有服务行为的需求，可以使服务订阅某个主题，当有信息发布时，所有的监听服务都会收到信息，根据你的需要做相应的行为。

源码

type Broker interface {
    Options() Options
    Address() string
    Connect() error
    Disconnect() error
    Init(...Option) error
    Publish(string, *Message, ...PublishOption) error
    Subscribe(string, Handler, ...SubscribeOption) (Subscriber, error)
    String() string
}

Broker默认的实现方式是http方式，但是这种方式不要在生产环境用。go-plugins里有很多成熟的消息队列实现方式，有kafka、nsq、rabbitmq、redis，等等。

 Client

Client是请求服务的接口，他封装Transport和Codec进行rpc调用，也封装了Brocker进行信息的发布。

源码

type Client interface {
    Init(...Option) error
    Options() Options
    NewMessage(topic string, msg interface{}, opts ...MessageOption) Message
    NewRequest(service, method string, req interface{}, reqOpts ...RequestOption) Request
    Call(ctx context.Context, req Request, rsp interface{}, opts ...CallOption) error
    Stream(ctx context.Context, req Request, opts ...CallOption) (Stream, error)
    Publish(ctx context.Context, msg Message, opts ...PublishOption) error
    String() string
}

当然他也支持双工通信 Stream 这些具体的实现方式和使用方式，以后会详细解说。

默认的是rpc实现方式，他还有grpc和http方式，在go-plugins里可以找到

Server

Server看名字大家也知道是做什么的了。监听等待rpc请求。监听broker的订阅信息，等待信息队列的推送等。

源码 

type Server interface {
    Options() Options
    Init(...Option) error
    Handle(Handler) error
    NewHandler(interface{}, ...HandlerOption) Handler
    NewSubscriber(string, interface{}, ...SubscriberOption) Subscriber
    Subscribe(Subscriber) error
    Register() error
    Deregister() error
    Start() error
    Stop() error
    String() string
}

 默认的是rpc实现方式，他还有grpc和http方式，在go-plugins里可以找到

Service

Service是Client和Server的封装，他包含了一系列的方法使用初始值去初始化Service和Client，使我们可以很简单的创建一个rpc服务。

源码：

type Service interface {
    Init(...Option)
    Options() Options
    Client() client.Client
    Server() server.Server
    Run() error
    String() string
}

以上がgo マイクロサービス フレームワーク go-micro の全体的なアーキテクチャの紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。