A practical tutorial on Go Building microservices (i.)

This is a creation in Article, where the information may have evolved or changed.

Overview

The following diagram is an overview of the project we are going to build. We're going to start writing the first microservices and we'll do a little bit of everything in this picture.

Explain:
White dashed box inside: Docker swarm cluster, running on one or more nodes.
In the Blue box: The support system provided by Spring Cloud/netflix OSS, or other services such as Zipkin
Yellow box/White box: a micro service.

Run resource consumption

Why do we use go to write microservices? Besides being interesting and efficient, the other main reason is that go runs at a very small amount of memory. The following diagram compares the Spring boot,spring cloud and go. (all based on microservices running on Docker swarm)

Quotes-service is based on the spring Boot.compservice and Accountservice is based on go. Two are based on HTTP servers and have many libraries to integrate with spring cloud.

But does memory consumption have to be considered now? Are we not having GB-level RAM that can easily load a Java application?
You can say that, but for a big enterprise, they run more than dozens of microservices, hundreds of thousands of micro services. This can save a lot of money by reducing resource consumption.

Take a look at the Amazon host Price:

The second column is the number of CPUs, and the fourth column is RAM size.
We see that when RAM is increased by a factor, the price increases by a factor. If you have enough CPU, you don't have to spend a lot more money on missing memory, and later we'll see that the go service is even less than spring boot when it comes to processing requests.

Non-functional requirements of micro-service

This blog is not just about go-building microservices, but how to run and build a microservices product in the spring cloud environment that matches the real production environment. Including:

• Centralized configuration
• Service discovery
• Log
• Distributed search
• Fusing
• Load Balancing
• Edge
• Monitoring
• Safety

This should be done for the service, not just with go, other languages, such as Java,python, and when writing microservices products. In this blog I will try to cover this content from the go language perspective.

On the other hand, consider the implementation of microservices, which you may have heard:

• http/rpc/rest/soap/any form of APIs
• Persistent Data API (DB clients, JDBC, O/R mappers)
• Message Processing API (MQTT, AMQP, JMS)
• Test (unit test, integration, system, acceptance test)
• Compiler tool/CI/CD

I'll explain some of this.

Run on Docker swarm

In the overview we see that our services are running in Docker swarm, which means that all our services, including support services (server configuration, edge, etc.) and microservices, will run in Docker swarm. At the end of this project, we run:

docker service ls

We will see the following services

! [Image of the crossing ...]

Note: The above services are far more than the s we built in chapter fifth

Go microservices consume very little memory-but what about performance? It is difficult to make a meaningful base test of a programming language. From the algorithm submitted on the base survey website, go is faster than java8 most of the time. Most of the go is almost as fast as C + +, but it's much slower on some base measurements. That is, go can perform well for ordinary microservices-load http/rpc, serialization/deserialization data structures, and network throughput.

Another important feature is that go has a garbage collection feature, which only takes a few microseconds to pause in the Go 1.5GC garbage collection. The Go garbage collection may not be that mature, but after 1.2, he is very stable. Even more surprisingly, you can change the performance of garbage collection by changing the size of the entire stack relative to the class.

However, we will write our first micro-service while testing the performance, then we will add the functions of fuse, trace, log and so on. After we have added more and more functions, we will use Gatling to test our performance.

Start time

Another go feature is that it starts very fast. A normal HTTP server with some routing and JSON serialization services can be started in hundreds of milliseconds. When we run in Docker, we can run them within seconds. However, a spring boot micro-service takes at least 10 seconds. This doesn't seem to have any effect, but it can be very useful when you need to deal with large traffic quickly.

Statically linked binary

Another advantage of Go's statically linked binary contains all the dependencies in an executable binary, we can put this package in a Docker container. At the same time this file is not big, generally 10-20mb. So that we can get a very simple dokerfile. We can start with a very basic Docker image. I use Iron/base, this image is about 6MB.

FROM iron/baseEXPOSE 6868ADD eventservice-linux-amd64 \ENTRYPOINT ["./eventservice-linux-amd64", "-profile=test"]

In other words, no JVM or other running component is required, only the standard C library in this image
We will then explain how to compile binary files and what-profile=test means.

Summarize

In this blog, we explain why we use go to do microservices. The main reasons are:

• Small memory consumption
• Good performance
• The convenience of statically linking binary files

In the next article, we'll start writing the first microservices.