Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the overall structure of go micro". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn how the overall architecture of go micro is.

In addition to the stability of the micro-service project, I am also concerned about several issues:

One: the efficiency and security of data transmission between services.

Second, the dynamic expansion of services, that is, service registration and discovery, service clustering.

Third: the customization of micro-service functions, because not all functions will meet your needs, so it is inevitable that you need to develop some functions according to your own needs.

Go-micro is a good RPC micro-service framework under the go language, the function is very complete, and several problems that I am concerned about have been solved very well:

One: the transmission format between services is protobuf, which is not efficient, very fast and secure.

Second: the service registration and discovery of go-micro are varied. Personally, I prefer etcdv3's service discovery and registration.

Third: the main functions have corresponding interfaces, as long as the implementation of the corresponding interface, you can customize plug-ins according to your own needs.

Server listens for calls from the client and processes the information pushed by Brocker. And the Server side needs to register its existence or demise with Register so that Client can know its status.

Discovery of the registration of the Register service.

The Client side gets the information of the Server from the Register, and then selects a Server to communicate according to the algorithm for each call. Of course, the communication has to go through a series of processes, such as encoding / decoding, selecting the transmission protocol and so on.

If necessary, notify all Server sides that you can use Brocker to push messages.

The Brocker information queue receives and publishes information.

The reason why go-micro can be highly customized is inseparable from his framework structure. Go-micro is composed of eight key interface, each of which can be reimplemented according to its own needs. These eight main inteface also constitute the framework structure of go-micro.

Transort

The interface for communication between services. The final implementation of sending and receiving services is customized by these interfaces.

Source code:

TypeSocketinterface {

Recv (* Message) error

Send (* Message) error

Close () error

}

TypeClientinterface {

Socket

}

TypeListenerinterface {

Addr () string

Close () error

Accept (func (Socket)) error

}

TypeTransportinterface {

Dial (addrstring,opts...DialOption) (Client,error)

Listen (addrstring,opts...ListenOption) (Listener,error)

String () string

}

The Listen method of Transport is usually called by the Server side. It listens on a port and waits for the client to call.

The Dial of Transport is how the client connects to the service. He returns a Client interface, which returns a Client interface, and the Client is embedded in the Socket interface, whose method is to send and receive communication messages.

Http transport is the default synchronous communication mechanism of go-micro. Of course, there are many other plug-ins: grpc,nats,tcp,udp,rabbitmq,nats, all of which have been implemented so far. You can find it all in go-plugins.

Codec

With the transmission mode, the next thing to solve is the problem of transmission encoding and decoding. Go-micro has many encoding and decoding methods, the default implementation is protobuf, of course, there are other implementation methods, such as json, protobuf, jsonrpc, mercury and so on.

Source code

TypeCodecinterface {

ReadHeader (* Message,MessageType) error

ReadBody (interface {}) error

Write (* Message,interface {}) error

Close () error

String () string

}

TypeMessagestruct {

Iduint64

TypeMessageType

Targetstring

Methodstring

Errorstring

Headermap[string] string

}

The Write method of the Codec interface is the encoding process, and the two Read is the decoding process.

Registry

Service registration and discovery, the current implementation of consul,mdns,etcd,etcdv3,zookeeper,kubernetes. Wait,

TypeRegistryinterface {

Register (* Service,...RegisterOption) error

Deregister (* Service) error

GetService (string) ([] * Service,error)

ListServices () ([] * Service,error)

Watch (... WatchOption) (Watcher,error)

String () string

Options () Options

}

To put it simply, Service Register to register, and Client uses the watch method to monitor. When a service is added or deleted, this method will be triggered to remind the client to update Service information.

The default is consul for service registration and discovery, but it is not recommended by individuals because you cannot use consul clusters directly

5.jpg

Personally, I prefer etcdv3 clusters. Everyone can choose according to their own preferences.

Selector

Based on Registry, Selector is a load balancer at the client level. When a client sends a request to the service, selector obtains the available Service nodes from the list of hosts in Registery according to different algorithms to communicate. At present, there are cyclic algorithm and random algorithm, and the default is random algorithm.

Source code:

TypeSelectorinterface {

Init (opts...Option) error

Options () Options

/ / Selectreturnsafunctionwhichshouldreturnthenextnode

Select (servicestring,opts...SelectOption) (Next,error)

/ / Marksetsthesuccess/erroragainstanode

Mark (servicestring,node*registry.Node,errerror)

/ / Resetreturnsstatebacktozeroforaservice

Reset (servicestring)

/ / Closerenderstheselectorunusable

Close () error

/ / Nameoftheselector

String () string

}

The default is that the implementation is local cache, the current implementation is blacklist,label,named and so on.

Broker

Broker is the interface for publishing and subscribing messages. A very simple example, because the node of the service is not fixed, if there is a need to modify the behavior of all services, you can make the service subscribe to a topic. When information is published, all monitoring services will receive the message and act accordingly according to your needs.

Source code

TypeBrokerinterface {

Options () Options

Address () string

Connect () error

Disconnect () error

Init (. Option) error

Publish (string,*Message,...PublishOption) error

Subscribe (string,Handler,...SubscribeOption) (Subscriber,error)

String () string

}

The default implementation of Broker is http, but this should not be used in a production environment. There are many mature message queue implementations in go-plugins, such as kafka, nsq, rabbitmq, redis, and so on.

Client

Client is the interface for requesting services. It encapsulates Transport and Codec to make rpc calls, and also encapsulates Brocker to publish information.

Source code

TypeClientinterface {

Init (. Option) error

Options () Options

NewMessage (topicstring,msginterface {}, opts...MessageOption) Message

NewRequest (service,methodstring,reqinterface {}, reqOpts...RequestOption) Request

Call (ctxcontext.Context,reqRequest,rspinterface {}, opts...CallOption) error

Stream (ctxcontext.Context,reqRequest,opts...CallOption) (Stream,error)

Publish (ctxcontext.Context,msgMessage,opts...PublishOption) error

String () string

}

Of course, he also supports the specific implementation and use of duplex communication Stream, which will be explained in detail later.

The default is rpc implementation, and it also has grpc and http, which can be found in go-plugins

Server

Server looks at the name and everyone knows what it does. Listen and wait for rpc requests. Monitor the subscription information of broker, wait for the push of the information queue, etc.

Source code

TypeServerinterface {

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

}

The default is rpc implementation, and it also has grpc and http, which can be found in go-plugins

Service

Service is an encapsulation of Client and Server. It includes a series of methods to initialize Service and Client with initial values, so that we can easily create a rpc service.

Source code:

TypeServiceinterface {

Init (. Option)

Options () Options

Client () client.Client

Server () server.Server

Run () error

String () string

}

Thank you for your reading, the above is the content of "what is the overall structure of go micro". After the study of this article, I believe you have a deeper understanding of how the overall structure of go micro is, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.