Shulou(Shulou.com)06/02 Report--

This article launched Pangbo chat framework, Wechat official account: xiaobo2as

Summary of this article

Introduction

Four dimensions of micro-service split

How to maintain the version of microservice

How to make a smooth transition from a single architecture to a micro-service

Conclusion

I. introduction

The same micro-service has gone through two years from the establishment of the project to the implementation of promotion, from the initial simple and rough to today's fine improvement, the number of access services has also achieved an increase from 1 to 10 000 +.

The microservice development team stepped through numerous pitfalls with you, and finally built today's DSF2.0 platform. Review the crawl records, now sort out some crawl experience for your reference, but also dare to put forward some best practices to attract jade.

Here are some suggestions on how to split micro-services, version management and the transition from single to micro-services from the developer's point of view.

Second, the four dimensions of micro-service split.

From monolithic architecture to micro-services, split granularity is difficult to grasp. There are different theories and methods, and we recommend that the fast knife cut the hemp according to the following four dimensions:

Team organizational structure

Release upgrade frequency

Logic call frequency

Data read-write separation

1. Team organizational structure

According to Conway's law, the organizational structure must be reflected in the system architecture, and the same process is a tree structure + underlying network structure, so the architecture of each system must be obviously tree-shaped, but there will be multiple service visits between systems.

Microservice design should fully consider what are self-use (inner), external access (outer) and mixed (mix) services, and can migrate them to the corresponding service groups.

two。 Release upgrade frequency

Because the new and old projects are at different stages of the life cycle, the frequency of modification and release will be very different. We should try our best to divide the interfaces at different stages of the life cycle, avoid bundling high-frequency update services and low-frequency update services, and avoid adding new business interfaces to stable service groups, but should consider implementing them in new service groups.

3. Call frequency

The frequency of service calls in different service groups will vary greatly, and high-frequency calls will certainly occupy more resources, and individual interfaces will run out of resources, resulting in failure of the same group of interfaces (resource competition). It is necessary to set customized running policies for high-frequency access services, such as allocating more CPU cores and memory, adjusting deployment to make it as close to the data source as possible, and so on. However, if all service hosts are made into high configuration, it will cause a huge waste of resources, in fact, it is not necessary, so the services accessed by high and low frequency should be segmented so that they can be optimized for better performance and reliability.

4. Data read-write separation

The previous dimension actually covers part of the separation of reading and writing, but in order to highlight the need for the separation of reading and writing, it is listed separately here. The general data operation mode is divided into CQRS mode and CRUD mode, each of which has its own advantages and disadvantages.

From the point of view of whether the operation has an impact on the data itself, it can be roughly divided into two categories: read and write. Generally speaking, the frequency of write operation is much lower than that of read operation. Write operation often has more stringent authentication and authorization mechanism, usually internal (inner) calls. There are great differences between these and read operations, so it is recommended that services with high traffic or core services should be separated from reads and writes and released into two service groups.

Finally, share a tip for granularity control. In most cases, every noun that appears in the system will have a place at the storage level, corresponding to a separate data table or library. So the noun that appears in the system may be a potential micro-service.

Third, how to maintain the version of micro-service

Maintaining an orderly and intuitive version in micro-service governance will bring great convenience to the system development process and service dependency management, on the contrary, no version or chaotic version upgrade strategy confuses developers and designers and brings unexpected dependency problems. Good micro-service governance should include a complete set of version upgrade strategy. According to our long-term crawl practice, we recommend the following version strategy:

1. Use the standard semantic version

See semantic version 2.0.0 for details. The use of standard semantic versions can ensure a unified understanding of the version, and self-definition of version semantics should be avoided as far as possible. The SemVer convention is recommended for DSF version. The slight difference is that DSF recommends four-digit version number (1.2.3.4), the first two bits are used as major version (1.2), and the SemVer version is generally three digits (x.y.z corresponding: major version number. The second edition number. Revision number).

two。 Contract-oriented design

When a team chooses micro-service as a service-oriented implementation platform, it must be clear that micro-service has a high threshold and requires that the team itself is already a more mature operation system, such as a perfect architecture design before implementation. Team members have a clear division of responsibilities, and team members have a clear understanding of service cohesion and service coupling.

All of the above aspects will lead to a result: the service interface designed and developed will eventually have a good abstraction and reflect planning, and finally be able to deliver a service contract with good compatibility before the service implementation. In practice, any part that is added, modified or deleted in a version iteration is carefully considered and reflected in the service contract, and the actual development is not easy to modify and add service interfaces.

3. Version maintenance in parallel development

One of the major impacts of micro-services on the development system is the parallelization of development practices. Micro-services enable developers to get rid of the invocation jungle of a single architecture, so that developers can focus on one of the links in the call chain without paying too much attention to the implementation of upstream and downstream.

The cost is how to avoid repeated implementations and more frequent conflicts in code Merge. Having a good version management practice can solve most of the Merge conflicts.

We recommend to further extend the contract-oriented design, through communication within the team to determine who is responsible for the core part that is not exposed to the public and agree to implement it in a specific version, while other developers responsible for using the core module will increase the version on that version.

Kernel code that is relied on by other components and may be changed frequently occupies a specific version range (for example, v1.2.3.0kernel 1.2.3.10 as the exclusive version of the core module, the module that depends on this component must be greater than v1.2.3.10), it can well isolate the version conflict caused by parallel development.

Because the upper-level implementations that reference core components don't have much to do with each other, they can always handle conflicts caused by Merge.

4. Compatibility of version

Judging whether a service is backward compatible according to the version number is a very important aspect of service dependency management. Most of the time, it is difficult to make a decision that makes the service not backward compatible. But the result of continuous backward compatibility is often the uncontrollable growth of service volume and the non-linear increase of system complexity.

Developers need to think carefully and make a decision at the right time that the service is no longer backward compatible. A good version strategy can clearly state whether the service is backward compatible or not, explicitly telling the caller that this is an incompatible upgrade update. Please make sure that you read the new contract document carefully and do enough testing.

For DSF, incompatible upgrades are very eye-catching, as long as you need to observe whether the large version number of the service group (the first two digits of the version number, such as v1.2.3.4, the large version number is 1.2) is increased. Any service contract modification is considered to be an incompatible upgrade, including deleting the interface, modifying the interface name / parameters, etc., you must upgrade the major version number, and modify the minor version number (the last two digits of the version number). For example, v1.2.3.4, minor version 3.4) represents a compatibility upgrade, such as adding service interfaces, code logic optimization and Bug fix, but not modifying the service contract.

Fourth, how to make a smooth transition from a single architecture to a micro-service

Once it is decided to introduce the micro-service architecture into the development practice, it will be a great challenge to transform the huge giant system accumulated into the micro-service architecture silently.

It is not necessary to reverse the radical revolutionary route, and the part that architects most want to replace through micro-service is often the company's main profit core, which is as difficult as changing the engine in flight. Judging from the public information in the industry, no one has achieved a perfect upgrade, and there are more than two possibilities:

The first kind of transformation lingers on after transformation, and R & D is on the run.

The other is direct shock in the course of transformation.

Therefore, in order to ensure the smooth application of micro-services, architects should never fantasize about achieving it overnight. After hitting a brick wall countless times, we give the following suggestions for climbing holes:

1. Training comes first.

Job technicians are very good at turning the problems they face into technical problems and then solving them in their best areas. This creates a paradox: the problem that can be solved by technology is not the problem, the real problem cannot be solved by technology alone in limited situations, and the biggest obstacle to the implementation of micro-services is not technology itself.

From our practice, the biggest problem is not how to do a good micro-service, but to reach an agreement on what micro-service should be.

As the saying goes, there are all kinds of birds when the forest is big, and there may be 100 kinds of understanding of micro-service for 100 people. This does not mean that we can solve it with dubbo or spring boot.

Our recommended practice is to enable most people to agree on what microservices are and what microservices are not through large discussions and training attended by most people before implementation. Which scenarios are suitable and which scenarios are not suitable? As a result, just don't go too far, just like the naming convention in the coding specification, it doesn't matter which naming method you use, it's important that everyone uses the same naming method.

two。 Hanger mode

The hanger mode refers to the gradual stripping and reconfiguration of the system that can not be improved through the repairman mode by rebuilding new functions outside the system, and strangling the functional services one by one.

The advantage is that it does not affect the original environment and can be switched quickly once the conditions are ripe.

The downside is that it may take a period of time to maintain both systems at the same time, paying additional development and maintenance costs.

3. Prison model

There is also a practice called prison mode within the same journey, which allows some systems that can not be changed in the short term to access the micro-service platform through the prison window (MicroProxy) and entrust Proxy to expose it as a micro-service. The single architecture often has a large number of service interfaces, and often requires multiple prison windows.

Each prison window will be packaged and divided into micro-services, which can be easily replaced by native micro-services when the conditions are ripe, called prison release.

5. Conclusion

There are a lot of theories and discussions about micro-services in the market, among which there are many large articles, and in-depth reading, we often find that most of them are new bottles of old wine or cobbled together. It is characterized by a strong emphasis on theory in the retreat, a brief mention in practice, and nothing in careful exploration.

Therefore, if you find that some technical books are obscure and difficult to understand, they are full of height, and your mind is bloated after reading. It may not be that you are not good enough, but it is more likely that the author is mystifying. Recently, I have a feeling of reading. The book is here, and you will share it with me.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.