Microservice at Golang

Find simplicity amid the confusion; find harmony among discord; in difficulty find an opportunity ...
(C) Albert Einstein

Articles about microservices, their strengths and weaknesses have been written a lot lately. However, somehow rarely anyone writes about the implementation of microservice architecture, and above all, about microservice, as if it were a brick, from which the building of such an application is built later. I tried to fill this gap, and share my experience in the development of http-microservice, which ultimately resulted in a small library under the name of no-doubt Microservice. The code is written in perfect for microservices, a simple and convenient programming language Golang.

Recently, I happened to work on the creation of microservices in the Golang language. It was an interesting experience. However, in many respects it turns out (at least for me) that every time a new microservice is created anew and from scratch. Of course, you can use the previous developments, but in this approach there is no certain kind of consistency, and I wanted to make a tool that would streamline such work (I sincerely hope so). No doubt, this is not the only idea in the development of microservices, but if you are interested in them, you may be interested in reading this article.

What is microservice, I think, in order to avoid holivar, there is no need to say. Also about the advantages and disadvantages of silent. I will only note that they exist, and it is precisely because of the presence of these that microservice architecture is in demand.
')
The architecture of microservice (here and below is about http microservice) in my library includes a handler, a tuner (configurator), a demo middleware. Everything works very simply: the application loads the configuration, taking into account the configuration file, the environment and the command line. Under the necessary routes it is formed from middleware and handler handler. Next, the server starts and, upon request, the application processes the necessary queues. In fact, it is suitable and can be used as a prototype of a typical http application, but perhaps for such an application I would use a slightly different architecture.

Tuner

An important point for microservice is loading the configuration. I tried to make this functionality as flexible as possible. By default, the configuration is loaded from the specified file (`config.toml`). The configuration file address can be changed from the command line, for example: yourservice -confile config.toml Thus, you can create several different configuration files and run microservice from one of the configurations of your choice.

Since the configuration of microservice involves not only the file, but also environment variables and command line parameters, I will clarify the order and priority of configuration. The lowest priority is given to the configuration from the file. If the environment is configured in the operating system, they have a higher priority than the variables from the configuration file. Command line parameters have the most important priority. To change a parameter in the command line, you need to specify its name in the form of the section name and the parameter name (with a capital letter!). Here is an example of changing the port - your service - Main / Port 85

A little more about configuration: in addition to the option of throwing the configuration into a pre-prepared structure, it would be quite possible to use the option of importing data into a regular map , and then calmly use the values ​​by key. This method has an undoubted advantage - it is not necessary to add data to the configuration file to duplicate it in the configuration structure. Those. easier and faster. The downside is that errors of incorrect key indication are transferred from the compilation stage to the execution stage, and besides, the IDE will no longer give us hints, which, by the way, is very good in terms of protection against typos and, as a result, errors.

Middleware

In order not to clutter up the handlers' space, microservice provides for the use of service functionality in the style of middleware (but not quite in the classic understanding of gopher middleware). Each such service has minimum requirements: it must take as an argument a function that accepts http.ResponseWriter, * http.Request and return the same function. The distribution demonstrates an example with connecting a metric to fix the request processing time ( duration ).

Depending on what tasks are solved by microservice and in what environment it does, you will almost certainly need other services, such as validation. Consider them connecting to the handler as middleware . And note that the demo metric is placed in a separate subdirectory to emphasize the distance between microservice and the middleware used in it.

Handler

In the distribution kit handler contains very little code. However, it is his methods that are those handlers that will process the incoming request, everything else is essentially a microservice kit. If this is so, then why not just make a bunch of autonomous functions that the router will call? There is a reason for this: thanks to the union through the structure, handlers can now have access (if required) to the fields of the structure (the general context of the application). In fact, it is very convenient for each public method (read handler) to create a separate file, for example, handle_hello_word.go , which, incidentally, does not interfere with organizing anything in any other way.

Creating a new handler

To do this, you simply need to create a new public method in the handler , which accepts http.ResponseWriter, * http.Request as input . See the HelloWorld method created for the demonstration.

Perfomance

For the general understanding that the speed of the microservice using the proposed architecture will be quite high, I will give the benchmark results that I received on my computer:

• BenchmarkMain-2 10,000,000 195 ns / op
• BenchmarkMainParallel-2 10000000 107 ns / op

Dependencies

• Logger github.com/Sirupsen/logrus
• Router github.com/claygod/Bxog
• Config github.com/BurntSushi/toml

Any of the listed libraries can be replaced or supplemented, in this case, they are rather intended to show in which direction to develop your microservice. It may also be useful for you to connect the logstesh and the influx.

Conclusion

The Microservice library does not claim the laurels of the only right decision, but on occasion, I hope, it will be able to help you build the architecture of your own http-microservice, becoming the prototype of the future application.

Links

• Library github.com/claygod/microservice
• Documentation godoc.org/github.com/claygod/temp/microservice-doc
• Report goreportcard.com/report/github.com/claygod/microservice

UPD

Taking comments into account, I changed the library a bit, removing the repository and correcting the organization method of the middleware (without queues), which, by the way, even slightly accelerated the application in the bench.