When building micro services, we use the library

【Editor's Note】 When building micro-service, should not use the library, and those code suitable for writing library? Here are some of the author's experience.

As with other common solutions, the micro service architecture also has its own advantages and disadvantages; some things become more simple because of it, while others become more complex. When switching to micro services, the most common challenge is where to use shared code.

At first, it was nice to convert common code into an independent library. The reason is very simple, we generally have to use the same code in the two documents, it will write this code as a function, and write the library is at a higher level to achieve the same effect, why not The

But it is not as simple as we imagined. Shared libraries can result in strong dependencies between micro services, so you should consider this in advance to make decisions about the role of the service throughout the service group. I have experienced this kind of problem after joining Runnable.

For example, suppose you abstract the domain model into a library, and once you have made changes to the model, you must update all services that use the library at the same time. This includes updating the code, through review, testing, staging, and so on. As a result, the micro-service architecture becomes a rigid whole.

So, is not that micro service can not coexist with the library? It is not. Philipp Hauer in his article has explained some special cases of micro services and shared libraries.

On technical concerns, the use of libraries is okay (for example, log and monitoring), because business needs often have little impact on these issues.

this point is very important. Micro service can generally be divided into two types of code:

  1. Domain specific code. This type of code addresses the issues that the service needs to deal with. For example, all business logic and domain models are such code.
  2. Support code, that is, the technical issues mentioned by Philipp Hauer. In my own experience, a large part of the micro service code belongs to the support code, so we should take the time to think about how to organize the code better.

In Runnable, we used some libraries. Some of them are internally developed, some are third-party code. These libraries are the cornerstone of our new micro service.

Here are some technical issues related to some of our libraries:

  • Monitor dog – reports data to Datadog in a standardized way; for example, prefix the service name with each time.
  • Error cat – Provides an error hierarchy that inherits from all services and reports errors to Rollbar.
  • Configuration ( loadenv ) – to ensure that each micro-service in the same way to load the environment variable.
  • Worker server ( ponos ) – A regular worker server that contains standard monitoring and error reporting.
  • Docker / Swarm Client ( loki ) – Contains the standard monitored Docker / Swarm client library.
  • Correctness check ( joi ) – check the library for the correctness of the email address, date, etc.

in conclusion

It is important to correctly identify whether you need to use the library in your code.

Here are a few general rules of thumb:

  • If this code contains business logic or domain-specific code – that code should not be converted to a library.
  • If this code changes frequently due to new requirements – it is not suitable as a library.
  • If this code will cause the coupling between consumers – it is not suitable as a library.

If the above problems are not, then be assured to do it! Converting general code into a standalone library can speed up the development of new services, so that you can focus on the specific issues that the service needs to address. In addition, the use of library functions can also make all the module monitoring, error handling, and management configuration becomes standard.

Libraries We Use When Building Microservices (translation: Ma Yuanzheng)

Heads up! This alert needs your attention, but it's not super important.