I came to realize microservices (3)-demand management

Unlimited merge

Recently work has received a demand module: The problem of automatic account merging. Simplified speaking, mobile phone 1 and 1 is an account, mobile phone 1 and Mailbox 2 request to create an account, due to the same mobile phone number, automatically merged into an account. Mobile phone 3 and mailbox 2 again come to request to create an account, because the same mailbox, automatically merged into an account. Mobile phone 3 and Mailbox 4 come over to request to create an account, and because the phone number is the same, again merged into an account ... If it is a large number of visits and such a coincidence, it is similar to the infinite merger. In fact, there may only be a few strokes, not so infinite loop. But I am a person who is apt to think much. Account merging, and associated with the transfer of data related to the account, from my personal point of view, so there is no need for border defense, my heart is rejected, but not a better way to do so, for the moment.

This topic Lenovo to micro-services, micro-services can solve this problem? Unfortunately, microservices are not as powerful as they might seem. Account merging is essentially a micro-service, but microservices do not solve this business problem.

I know the micro-service is for the convenience of horizontal expansion, easy to use experience heterogeneous technology, easy to quickly trial and error, easy to deploy, can eventually achieve high availability and high concurrency. You know a little more about microservices and are not used to solve such business problems.

For this kind of business problem, the general way is to judge whether the demand is reasonable ? Unreasonable demand can be properly rejected.

see who's mentioning it again? If you are a regular customer, try to replace it with other simpler and easier-to-maintain alternatives. If the gold master or the top leaders to distribute the demand, it is only in the summary of risk based on the step-by-step look ahead.

The third is whether the demand is universal, Universal solutions are generally easier to understand, more suitable for promotion. Customized requirements are time consuming and laborious.

Iv. Judging the scope of the impact , if it is a high risk, but also time-consuming and involve a lot of old business, do you dare to move? Cautious and cautious.

The need to determine the stage is complete, the following talk about risk avoidance

First, the clear labeling requirements affect the boundaries , the changes should be timely unit testing or manual testing. Any line of code you've changed could trigger a hidden green chicken.

Second, do not blindly move the knife, we must analyze the needs . In the case of vacant demand, blind code bricks, you will be very tired. What's more, the demand itself only shows the tip of the iceberg, as well as the vast unknown iceberg buried underneath. If you can't find out in advance, your time will be shorter and more and more things will be done. It's a runaway. Sometimes out of control is predictable but must be difficult to get on. Sometimes it is easy to throw a pot easily by a few words. This is also a kind of cultivation.

Thirdly, personnel distribution . To the cooperative project members should have the necessary understanding, good people do good things.

Four, minutes of the meeting. sometimes meetings are often unavoidable, and nutritious ideas should be documented to facilitate practice. There are questions that should be discussed in time, don't take it for granted. Taking for granted is the most time-consuming thing.

These things have nothing to do with microservices. But these features can eventually be called a microservices. This can be understood as how the micro-service development process identifies requirements and develops requirements.

Micro-service comes from life above life.

Starter Book: