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

How to understand the Greenfield micro-service-oriented architecture, I believe that many inexperienced people do not know what to do, so this paper summarizes the causes of the problem and solutions, through this article I hope you can solve this problem.

Micro-service-oriented architecture is now popular all over the world. This is because a faster deployment pace and lower cost are the basic commitments of a micro-service-oriented architecture.

However, for most companies testing the water, development activities are more about transforming existing monolithic applications into a micro-service-oriented architecture, which may be a source of hindrance and conflict at many levels.

Although Greenfield's (undeveloped) micro-service-oriented architecture implementation can adhere to the strict interpretation-design principles of current micro-services. However, in the micro-service-oriented architecture, there is a gray shadow in the decomposed legacy applications, and budget and time constraints can only be met if there is no other reason.

Somewhere in the enterprise management chain, a business executive looks at the decomposition costs associated with these legacy applications in a micro-service-oriented architecture and compares them with the value already provided by the legacy code. Once the development cost exceeds the expected benefits, the business director is likely to exit and cancel the project.

This happens all the time.

As a result, development managers are under great pressure to output the code as soon as possible. "good enough" has become an ideal goal for transformation.

Now, this is not necessarily a bad thing. The ability to output working code is always better than waiting for dreams to come. However, the "gray shadow" is very difficult to manage, and the problem is how to define the boundaries of "good enough".

So the conflict began. One side wants to output what they want, while the other wants to make more improvements.

The challenge for you is not to let these different schools create an endless quarrel over views that are essentially supported by beliefs. If you do, it will create a situation where no code is provided at all. Now, conflict can synthesize the best ideas from many competing ideas. But when words degenerate into never-ending conflicts, they can be fatal.

1. What is the reason for the design?

When you evaluate the design of a microservice-oriented architecture, the challenge is to shift past ideas to theoretical analysis. Its creation mainly comes from the decomposition of a single application. Any design can be "good enough", as long as you can prove its benefits and value.

For example, one of the preferred styles of micro-service-oriented architecture design is to use an event-driven approach to communication between services. Specifically, this means that you use message nodes to pass messages between microservices asynchronously. However, in the long run, while asynchronous communication is more flexible and extensible, the messaging system implementation is much more complex than the design of using synchronous HTTP calls between "micro-service-oriented" API. Therefore, when market time is concerned, there is every reason to reconstruct the features in a single application into independent micro-services represented in HTTP API.

Compared with asynchronous services, the implementation of synchronous micro-services is usually less complex.

Synchronous communication is not necessarily the best choice in the long run, but synchronization is "good enough" for the first version, given all the other work required to extract stand-alone microservices from a single application. Therefore, this is a reasonable reason.

However, this is not to say that the synchronization method is risk-free. In fact, there are many risks. When it comes to reviewing microservice-oriented architecture design, justification alone is not the only factor. Risks must also be addressed.

two。 How risky is it?

All designs have inherent risks. In the synchronous design example described above, this method of inter-service communication may lead to the risk of type coupling between services, increasing latency due to the nature of synchronous HTTP and other communications.

It is important to make people aware of these risks so that they can be weighed against the reasonableness of the expected design. If the risk is huge, no amount of reason is enough. On the other hand, given current needs, some risks may be acceptable. The trick is to ensure that risks are clearly communicated during the review process. The known risk in the discussion is always preferable to the hidden risk, which can have an impact on the road. In addition, if you knew the risks before, as the micro-service-oriented architecture matures, you can plan how to better move forward in future releases. This is the reason for reducing risk.

3. What is the plan to reduce the risk?

One of the hallmarks of a wise application designer is the ability to identify their design risks, and once determined, he will have the foresight to clarify a way to mitigate these risks. Risk identification without proper mitigation technology is a sign of incomplete thinking.

If microservice-oriented architecture design is risky and has a marginal plan to solve these problems, then the design team needs to seriously consider its feasibility. In addition, if the mitigation plan is impractical-beyond the expertise and budget of the project-the feasibility of the design needs to be questioned. It's all a matter of balance.

A well-balanced micro-service-oriented architecture design is reasonable because the conditions it wants to meet are weighed against its inherent design risks and mitigation plans designed to address them.

4. Put them together.

Conflict is an important part of the creative process. Creative people tend to be tough on their own ideas. So tensions are bound to increase when you put them in a room and ask them to design a single design for micro-service-oriented buildings. That's what happened. But cheer up! Conflict is a good thing.

Fortunately, with a rational approach to reviewing microservice-oriented architecture design with the three issues I described earlier, you can facilitate objective discussion to generate software to meet your needs in a timely manner. No design is perfect, especially those that break down a single application. However, delivering a micro-service-oriented architecture has a big advantage, which is good enough to work effectively in the short term and flexible enough to continuously improve in the long term.

After reading the above, have you mastered how to understand Greenfield's micro-service-oriented architecture? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

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.