Recently completed the company rental micro service project, due to the use of GO-Micro V3 encountered a lot of problems, here to use a real project to help everyone understand the use of GO-Micro V3

In addition, many articles on the web are out of date since Micro3.0 directly abandoned the maintenance of go-Micro.

The source address

  • The source address
  • Comprehensive micro service project of Airentals

Go Micro Introduction and design philosophy

Go Micro is a basic framework for building microservices based on the Go language. It provides the core components required for distributed development, including RPC and event-driven communication.

Its design philosophy is a “pluggable” plug-in architecture, with its core focus on providing underlying interface definitions and underlying tools that are compatible with various implementations. For example, Go Micro defaults to service discovery via Consul, communication via HTTP, codec via Protobuf and JSON so you can start quickly based on these components provided out of the box, but if needed, You can also replace the default component with another component that conforms to the underlying interface definition, such as service discovery via ETCD or ZooKeeper, which is the advantage of a plug-in architecture: you can replace the top component without changing any of the underlying code.

Go Micro Infrastructure

The Go Micro framework has the following infrastructure, consisting of eight core interfaces, each with a default implementation:

Its design philosophy is a “pluggable” plug-in architecture, with its core focus on providing underlying interface definitions and underlying tools that are compatible with various implementations. For example, Go Micro defaults to service discovery via Consul, communication via HTTP, codec via Protobuf and JSON so you can start quickly based on these components provided out of the box, but if needed, You can also replace the default component with another component that conforms to the underlying interface definition, such as service discovery via ETCD or ZooKeeper, which is the advantage of a plug-in architecture: you can replace the top component without changing any of the underlying code.

  • The top-level Service interface is the main component to build the Service. It encapsulates the interfaces needed to be realized by each package at the bottom level. It contains a series of methods for initializing the Service and Client, so that we can easily create an RPC Service.
  • Client is the interface that requests the service, obtains the Server information from Registry, and then encapsulates Transport and Codec for RPC call, and also encapsulates Brocker for message release. By default, it communicates through RPC protocol. It can also be based on HTTP or gRPC;
  • Server is the interface that listens to service invocation and will also receive messages pushed by the Broker. It needs to register its existence with Registry so that the Client can initiate a request. Like Client, it is based on RPC protocol by default and can also be replaced with HTTP or gRPC.
  • Broker is an interface to publish and subscribe messages. The default implementation is BASED on HTTP and can be replaced by Kafka, RabbitMQ and other components in production environments.
  • Codec is used for encoding and decoding during transmission. The default implementation is Protobuf, which can also be replaced with JSON, Mercury, etc.
  • Registry is used to implement Service registration and discovery. When a new Service is published, Registry needs to register with Registry and then Registry notifies the client to update. Go Micro implements Service registration and discovery based on Consul by default. It can also be replaced by etcd, Zookeeper, kubernetes, etc.
  • A Selector is a load balancer at the client level. When a client sends a request to a server, the Selector communicates with each other by retrieving the available Service nodes from the Registery’s host list according to a different algorithm. At present, the implementation of cyclic algorithm and random algorithm, the default use of random algorithm, in addition, Selector and cache mechanism, the default is local cache, but also support label, blacklist and other ways;
  • Transport is the communication interface between services, which is the final implementation of sending and receiving services. By default, HTTP is used for synchronous communication, and other modes such as TCP, UDP, NATS, and gRPC are supported.

Go Micro officially created a Plugins repository to maintain the Go Micro core interface support for the replacement of Plugins:

The relationship between the interfaces of each component can be connected in series as follows:

summary

Through the above introduction, you can see, the Go Micro light simple, easy-to-use, powerful functions, easy extension, is based on the language service architecture is recommended when a RPC framework, based on its core features and plug-ins, we can easily solve the discussion before the introduction of Micro service architecture needs to solve the problem:

  • Service interface definition: define communication protocol and data coding through Transport and Codec;
  • Service publishing and invocation: Implement service registration and subscription through Registry, and improve system availability based on Selector;
  • Service monitoring, service governance, and fault location are implemented using Plugins Wrapper middleware.

Next, we will demonstrate how to implement the Go Micro services architecture based on the Go Micro services framework.

Refer to the link

  • Micro doesn’t work? Some facts about the Go language microservices framework Micro
  • What exactly is go-Micro?