Microservice architecture debate between radical technologists vs Project conservatives

Preface

In recent years, more and more enterprises have begun to build their own micro service system , In the process of model selection, there will inevitably be disputes over routes . Radical technocrats often insist on the idea of buying the new rather than the old , Stand firmly on the side of the service grid . The relatively conservative project faction will pay more attention to the stability and ease of use of Technology , Thus, it advocates to give priority to the traditional micro service scheme . If it's you , What would you choose ？

Before answering , Let's try to answer a few questions first ：

• What is microservice ？

• What is the purpose of your enterprise trying to build a micro service system ？ Have you encountered any challenges ？

• Do you know about service grid ？ Do you know what kind of mission it was born with ？

If you can answer the above questions quickly , I believe your conclusion on the selection of micro services should be considered . If the above questions confuse you , Why don't you sort out the logic of micro services with me .

01  When we talk about micro Services , What do you think ？

When it comes to microservices, the first thing most people think of is  Spring Cloud、Dubbo  perhaps  Istio. in fact , This understanding has certain limitations . Strictly speaking, microservice means literally , Refers to micro services . And what we often say  Spring Cloud、Dubbo  and  Istio  It is the specific practice of the idea of micro service architecture . Of course , Knowing only this is nonsense literature , What we want to know more is why we need microservices ？ What benefits can microservice bring ？

It should be said

The evolution of any architecture will clearly point to the core pain point of the previous generation architecture , The initial pain point of microservices is centralization and tight coupling

. I'm afraid that all programmers who have experienced the previous era will be interested in the system code “ Pull one hair and move the whole body ” impressive .

Microservices can be divided into relatively simple and interconnected micro modules , Realize the full decoupling of business , The more independent service splitting method also makes microservices more in line with the needs of distributed deployment . Microservice system also brings other advantages , such as ： Improve fault isolation capability 、 Scalability enhancements 、 Reduce code complexity, etc . Since then, the great gods of technology have been highly cohesive 、 Low coupling has a more people-friendly implementation , And the burgeoning distribution also has more uses .

Of course, like all things , Microservices are not perfect . Completely fragmented services reduce code complexity , But it greatly increases the complexity of the architecture , This makes it difficult for services to find each other and track quality problems . meanwhile , The transaction problems caused by distribution are also highlighted . For the designers of the project , How to reasonably plan the functions of each microservice , It has also become a thorny problem that needs to be tangled repeatedly .

02  Service grid is a micro service 2.0 Do you ？

I often hear people say that service grid （Service Mesh） It is the next generation of microservice Technology ,Service Mesh  Will replace with  Spring Cloud  The first generation of microservice architecture technology represented by . The author has different views on this .

With  Spring Cloud  For the microservice architecture and service grid

The biggest difference is actually the intrusiveness of the code

. Usually  Spring Cloud  The program of the architecture needs to be comprehensively considered with the business logic when designing , Although it will not invade the business , But active in every corner of the business code .

The service grid technology completely adopts a non-invasive processing method ,sidecar  Become the only spokesperson for business services . Service discovery that previously required business systems to complete 、 Traffic management and other work , Now turn to the control surface and  sidecar  Formed a professional team to take care of .

thus it can be seen , In solving the problems encountered by micro Services , Service grid technology and  Spring Cloud  There is no essential difference between the basic ideas of microservice architecture technology represented by , There are only obvious differences in the specific implementation path .

It should be acknowledged that the emergence of service grid technology is based on the demand of technicians for further separation of business and governance capabilities , But from this point of view, the service grid is a micro service 2.0 Time , It's too early . In my opinion ,

At this stage, service grid technology is more like a half generation upgrade of microservice Technology

.

03  Let's solve the problem of how to choose

Mountain impermanence , The water is impermanent , There is no fixed rule about what kind of technical architecture to choose in the project . As we mentioned above , The old architecture inevitably has many disadvantages in the process of use , And the new architecture will also bring new problems . It cannot be said that the most advanced architecture is the best , Similarly, the oldest architecture is not without value .

All choices should be based on the reality of the enterprise and the project .

So what factors should we consider ？

1.  The purpose of the project or the development stage of the product

. If the purpose of the project is to verify a technical or business solution , Or the product is still in  MVP  Validation phase , Please remove your attention from the myth of micro service architecture , For the sake of rapid development, monomer architecture is your best choice .

2.  Business scale and market expectations .

Of course, microservices have enough advantages to make people yearn , But we should never choose technology for Technology . A daily life is high enough  2C  Of course, the scenario requires microservices , A transaction volume is large enough  2B  The scenario is also inseparable from the guarantee of micro Services . However, small and beautiful vertical fields do not necessarily need the blessing of micro Services .

3.  Technical personnel reserve .

The core value of technology lies in people , For enterprises, it is best to inventory the human resources at hand before carrying out micro service transformation .Java  The language has more developers , Labor costs are relatively low ,Spring Cloud  and  Dubbo  It's very suitable for  Java  Enterprises with more programmers .Kubernetes And container technology is an important foundation of the current popular cloud native technology , The salaries of relevant operation and maintenance personnel and developers have also risen , If the accumulation of such personnel in the enterprise is good , Use one that has stronger affinity with the cloud Service Mesh  The plan is also very good .

4.  Project resources .

The project is always to complete the work of determining the scope with limited resources . A project that will only run in a virtual machine environment , In fact, there is no need to use it forcibly  Service Mesh. A non  Java  Language development system , There is no need to use  Spring Cloud  And forcibly restructure into  Java  System .

5.  Tolerance for request delays .

Sidecar  While bringing convenience , It also brings additional delay . With  Istio  The use of  Envoy  For example , The official test conclusion is that every time  sidecar  It will produce  3ms  Left right delay , For general application systems  3ms  Is a completely acceptable number . But for complex business systems with deep call links , On the link  sidecar  The accumulated delay will be a large number . In a scene that is very sensitive to delay ,3ms  Whether it is an acceptable number also needs to be fully considered .

With limited space, the author cannot and cannot exhaust all the situations , The above content is just a guide .

Technology is ultimately just a means to achieve our practical goals , Making good use of bricks is also a powerful weapon of a generation .