Introduction and theoretical basis of Go language micro-service

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

Introduction to the basic theory of Go micro-service

Blueprint Overview

Is the overall view of the system blueprint built in our entire series of articles. However, we will write our first go microservices from scratch, and then as we move along the sections of the blog series, we will be getting closer to the structure represented by the diagram below.

The legend is basically as follows:

• Dashed white box: A logical Docker swarm cluster that runs on one or more nodes.
• Blue Box: Support Services from the spring Cloud/netflix OSS stack or other services such as Zipkin.
• Sand/White box: the actual microservices.

It is more or less the same blueprint used in the Magnus Larssons microservices blog series, the main difference being that the actual microservices are implemented using Go embedding java. Qutoes-service is an exception, and it provides us with a JVM-based microservices that we can use to seamlessly integrate and test platforms with our go-based microservices.

Theoretical basis: operational information

Some people ask, why do we use go to write microservices? In addition to working with such fun and creative language, the main reason to use go to build microservices is to have a tiny memory footprint. Let's look at the following, we are running the go microservices under Docker swarm and the microservices based on spring bot and Spring cloud architecture.

Quotes-service is spring-initiated, while Compservice and Accountservice are based on go. Both are servers that use a large number of class library deployments and are integrated with the spring cloud infrastructure to handle HTTP.

Is 2017 really important? Looking at the amount of memory that Java implements for MicroServices and the microservices that go implements, it makes us feel surprised, dozens of times times the difference. Indeed, for large businesses, running dozens of services is small, and many companies run tens of thousands of microservices that are placed on cloud delivery. When we run a large number of containers, saving resources will save the company a lot of money.

Non-functional requirements for microservices

This article is not just about how to use the Go language to build microservices-it's also a good performance in the spring cloud environment and a quality that meets the needs of a production-ready microservices domain.

Consider the following (no special considerations in order):

• Centralized configurations: Centralized configuration.
• Services discovery: Service Discovery.
• LOG: Logging.
• Distributed tracking: Distributed tracing.
• Circuit breaker: Circuit breaking.
• Load balancing: balancing load.
• Boundary: Edge.
• Monitoring: monitoring.
• Safety: Security.

All of these things I think you need to think about when you decide to try MicroServices, instead of using the go language, the Java language, JS, Python, C #, or any other language you like to encode. This blog series reveals all these topics from the perspective of the go language.

Another perspective is something in your actual microservices implementation. No matter what language you come from, you may have a class library that provides the following functionality:

• Http/rpc/rest/soap/the API.
• Persistent API (DB client, JDBC, O/R mapping).
• Messaging APIs (MQTT, AMQP, JMS).
• Testability (unit test/Integration test/System test/Acceptance test).
• Build Tool (CI/CD)
• More...

I will not cover all of these topics. If I were to do this, I would write a book instead of a blog series. I will cover a small part of them.

Running in Docker swarm mode

The basic premise of the system areas in these article series is that our operating environment is Docker Swarm. This means that all services-support services (configuration servers, boundary services, and so on) or actual microservices implementations are deployed as Docker swarm services. When we get to the end of the article sequence, there are the following Docker commands:

Again, please note that the services listed above contain many of the services we will include when we set up our swarm array in part fifth.

Performance

Well-because go microservices consume very little memory information-but can they be executed? It is very difficult to have the intention to mark different programming languages. That is, if we look at sites such as Benchmarkgame, where people can submit implementations in various languages with explicit algorithms, and then perform performance comparisons with each other, the go language is slightly faster than Java 8, a little bit surprising. The go language is actually a little slower to compare with C + +, just based on some benchmark scenarios. That is, the go language performs well for general microservices workloads-service Http/rpc, serialization/deserialization of data structures, processing of network I/O, and so on.

Another particularly important attribute of the go language is its garbage collection mechanism. After the main rewrite of the Go 1.5 garbage collection, GC pauses typically take almost a few milliseconds. If you are from the JVM world (I am myself), the go language garbage collector may not be mature enough, but some of the changes introduced after go 1.2 make it seem very reliable. This is also a non-configurable miracle-there is also a spherical handle (GOGC), you can fine-tune the GC behavior in the Go language, you can control the relative reachable object of the total heap size.

However-tracking performance impact, because we will build our first microservices, and add things like circuit breakers, tracking, logs and so on inside, this can be very interesting, so we will use the Gatling test in a later article, to see we continue to add more functionality to microservices performance changes.

Start time

Another good feature of the Go app is that it starts very fast. A simple HTTP server with some routing, JSON serialization, and so on, typically starts up to 100 microseconds. When we run our go microservices in a Docker container, we can see that their healthy ready service is within the most seconds, and our related spring boot type of microservices typically takes at least 10 seconds to be ready. While this is not the most important feature, it is certainly useful when your environment needs to be quickly scaled to handle unpredictable large traffic.

Statically linked binary files

Another big benefit of the go-based Docker microservices is that we can get all the statically linked binary dependencies in an executable binary file. Although the file itself is not very compact (a microservices generally have a 10-20mb look), the biggest benefit is that we can get very simple dockerfile, and we can use very bare base docker images. I used a base image called Iron/base, which is probably only 6MB.

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

In other words-without the necessary components of the JVM or other runtimes, in addition to the standard C library (LIBC), it is included in the base image.

We'll dig deeper into how to build our binaries and-profile=test in the next article.

Summarize

In this article, we describe some of the key factors in using the go language to build microservices: such as less memory information, good performance, and convenient static link binaries.

Chinese and English control

• Run information: Runtime footprint, reference link: https://bbs.csdn.net/topics/4 ....
• Unit tests: Units test.
• Integration testing: Integration test.
• System tests: Systems Test.
• Acceptance test: Acceptance test.
• Continuous integration: continuous integration.
• Continuous deployment: Continuous Deployment.

Reference links

• Gatling the performance test of the Test:web application.
• Topic Home
• Build our first Go Language micro service