Explain microservices splitting with an instance (in Springcloud+gradle)

Objective

Before, I have said a lot about the concept of micro-services, after all, many people will see after the idea of no meaning, because there is no practical thing to say, even if each concept is understood, it is difficult to give practice. So this time, let me illustrate with a practical example of how we will build our microservices in the actual project process.

PS: We just use the scene to simulate the entire process of our microservices construction or split, for the scenario itself in the actual problems we do not consider, it is plain that we do not consider the scene itself in real life is not the case.

Building with Springcloud+gradle

The purpose of this article: to let you experience the service splitting itself, causing you to think about service splitting.

Scene simulation

We first simulate such a business scenario where points are exchanged for physical goods. The process is generally as follows:
1. User Login
2. Select a product
3, the Order
4. Payment of Points
5. Delivery of goods
6. Order Completion

"Out of business" here in order to simplify our implementation, we remove the user login and product delivery Two steps, also is the default user login, the default order must be completed.
If we use a monolithic architecture, we should most likely do so in the end.
···
Users click Redeem
"Reduction of commodity inventories, operation of commodity tables"
"Generate order, operate order form"
"Reduce user points, operate user points table"
"Add user points record, Operation Integration Record table"

In the case of concurrency, you also need to use a transaction, which means that any one of these steps can cause problems with the entire redemption, that is, rolling back the data. This is the way we usually do in a single application.

How to split into micro services

Now, whether the boss says it or wants to do it, whatever it is, I want to make it a micro-service anyway. What to do?
So how do we split it into microservices, a business scenario that seems to be highly coupled?

The logic we need to master
1, if we want to split the business itself a high degree of coupling, then split the need to do is to dismantle the business, white is the need and product consulting business above need to make some changes.
2, if we split the business itself without coupling degree, then you dismantle??? No, need to consider two points, one is the granularity of too small cost will go up, one is the late expansion will have an impact

Specific split

Now I'm proposing a way of splitting it.
1, reduce the product inventory to create orders placed in a micro-service, the formation of a single service
2, reduce user points and operation of user points record in another micro-service, constitute a payment service

Post-split logic
Users click Redeem
"Reduction of commodity inventories, operation of commodity tables"
"Generate order, operate order form"

"Reduce user points, operate user points table"
"Add user points record, Operation Integration Record table"

Split to achieve the effect:
Even if user points are not properly deducted for various reasons, they can be paid later

Benefits of Splitting:
Later on, if the payment method is not just points, can use other, then only need to change the payment service, for the next order has no relationship

Split code

Github.com/linkinstars/microserviceexample

Analysis Summary

If you look at the code, you know that the split itself is not as complex as you think, although we have simplified some of the details, but actually if you need to split it, it's logically true. It's not as complicated as you think.
But!!!
The difficulty is not in the split code itself, before a blog I mentioned that, in fact, the split of micro-service is not as complex as the actual imagination, and the difficulty comes from the split will lead to a variety of problems, because in fact, for the business itself, many times we will encounter some coupling business, these business itself is difficult to break apart. So, as mentioned above, when some services are actually split, we will adjust the business, although for the user perception itself is the same, but the actual code is not the same.
Summarize the following points for reference:
1, if the experience is insufficient, first small demolition, after large demolition
2, assuming the exception, assuming that each service has an exception, what will affect the service you split
3, priority to ensure that the main line business stability
4, the principle of split is for the post-business expansion, then you need to prioritize the late expansion of the roughly how

Follow up

I've been stressing that this is just a simulation of a business scenario, what's actually going to be the problem?
1, when the user points are not enough to pay, for this order later how to deal with?
2, the needle for some large-scale projects, orders and products need to be split, then what impact on the current system?
3, reduce user points (later payment method), in fact, add records should not affect the payment, then how to decouple?
...
And so on some questions, I think you should all think about it, then try it and then find out the problem.
There will be a lot of interesting things in this area, such as MQ, Async, and so on, to stimulate
You're on the back!