Foreword
With the development of architecture, micro-architecture service architecture can be said is the hottest area of the design concept. In the company, we have been serving in charge of design and development work in the system.
Today to talk about some of the problems landing micro-services practice. I hope not start micro-service design friends, play some role in the reference; in addition also hope to share out their point of view, we look forward to work with the exchange, be able to recognize deficiencies.
A service Split
Before landing micro-services, the first problem we encountered is: how to split the service?
As you know, about how to split the service, and not a completely general rule. But are the following elements, we can refer to.
1, operational independence
Under normal circumstances, the first time we will take this into account. The system service module, in accordance with identification functions out of each individual module is split into a separate service.
After this split, our service to meet a principle: high cohesion, low coupling.
For example, we have a system split into goods and services, order services, logistics services. Under normal circumstances, we modify the time of logistics services, and will not affect the goods and services, which is reflected in low coupling; service orders then inside the function and logic, revolves around this core business processes orders, you can say it is highly cohesive.
2, business stability
We can distinguish traffic in the system in accordance with stability. For example, user registration, login section, in our system, as long as this piece of code written, basically no change will happen, then I will tear them to customer service.
Similarly, there are logging services, monitoring services, these modules are basically very stable business, can be considered separately split.
3, service reliability
Here the emphasis is on the high reliability requirements of core services and low reliability of non-core services split open, and then focus to ensure the availability of core services.
Avoid non-core service failures, affecting core services.
4, business performance
Split based on service performance, it contemplated that the split performance of the pressure module. For this, I have two ideas:
- Avoid performance pressure service affect other services.
- The high-traffic business independent, the case could not carry, easy to scale horizontally.
For example, in a system I participated in, was through RocketMQthe docking large amounts of data from multiple vendors.
At that time, it is a independent news service, designed to consume messages. Then some processed locally, some by RPCforwarding to other service processing interface, some directly WebSocketpushed to the front end of the show.
In this case, even if the surge in traffic, consider increasing the machine to the message service, increase spending power just fine.
When these types of split learned that the above way, we can according to their own business and technical team size, consider splitting the service of their own system.
But here, it is particularly noteworthy that, micro meticulous service should not split, it must be combined with the size scale of business and technical teams.
I encountered a previous project, in the process of doing service in the then technical director in accordance with operational independence to split the service, the result of the demolition of the 10 months service; then Genghen, and each business service the Servicelayers and Controllerlayers split off, each business methods require long-distance calls. According to the parties it describes, do so in order to facilitate post enhance scalability.
But to be honest, some systems and not so much traffic, blindly cater to the micro-micro-word service, no doubt to increase the difficulty of their own, undermine the stability of the overall system. So, after the business process re-sort, the author of this system has been restructured, reducing the number of services.
Here, I would like to point out. ServiceLayer and the Controllerlayer can be split into multiple modules, this does not matter. However, it only should be separate modules rather than split the service. For example, we can put them in the development phase split into multiple modules, then through Maven modulespolymerization to an, in the deployment phase of operation, they are a service.
Second, technology selection
After the completion of the split service, the choice of what framework to develop it, you should choose Dubbo 还是 SpringCloud ？
I simply do not want to discuss at their strengths and weaknesses, where you can on the issue of sharing the mentality of the author under the.
When the initial selection, I chose SpringCloud, after all, it is known as micro-service one-stop solution. And then build the framework, integration of various components, completed some demo of development and testing.
However, after the completion of this part of the work, re-examine the entire system, we see SpringCloud, the involved Eureka、Ribbon、Feign、Hystrix、Zuul、Configcomponents.
At this time, I will have two questions:
- These components are not non unavailable? Is there a more portable system solution?
- So many things, either part of the problem, whether we can hold live?
For the author 一站式there are two layers of understanding of the word. First, it simplifies the development of distributed systems infrastructure, ease of development; second, simplifying the same time, it must be shielded complex configuration and implementation principle, it is not easy to understand in depth principle.
As an architect or team technical director, we must own system involves technical point do know too much, or that, at least to know their principles. In this way, even with the problem, Baidu / Googlewhen the results do not come out, do not panic.
Based on such an idea, he turned to look up Dubbo. For the author, for the Dubbomore familiar, and it is from its frame itself, has achieved the load balancing and fault-tolerant cluster, call the way is also based interface. Compared SpringCloudterms, do not need to like the introduction of additional Ribbon/Feigncomponents such.
Another point, Dubbothanks to a powerful SPImechanism, we can very easily extend it. If you have a business need, in many places it can be extended, such as RPC protocol, cluster registry, serialization, thread pools.
But having said that, Dubbojust a high-performance RPC framework, and carries it SpringCloudcompared to more quite REST和RPC. But on this point, in general projects only, this performance difference is not enough final word up just icing on the cake.
As for the other components, such as Hystrix/Zuul/Config/zipkinsuch as the author's point of view, or to see the scale of business. Micro service is just a design, architecture concept, rather than that used in many distributed service framework called micro. These frameworks are produced, but in order to solve problems encountered in the micro-services system.
Know a bite to eat a fat man, in doing technology selection, remember direct benchmarking like Ali, Jingdong, manufacturers experience the beauty of this group, the one, maybe we never quite that kind of business scenarios; In addition, general corporate there is no talent pool people like that. After all, if the line is a problem, it is no one to share the loss with you.
In general, or in conjunction with their actual situation, the most secure technical solutions to meet requirement on business.
Third, complications
Split the service, and also completed the selection of the technical solution, then all is well, start line and the code yet? If it simply as a developer, it is indeed open line and on the line. If you are the person in charge of a system, content with a strategically advantageous position, regardless of the details, it is bound to complicate the issue.
1, overtime and fault tolerance
After the service of calls between different services is remote calls. There is a remote call most basic settings, namely timeout.
For example, in Dubbothe default timeout of 1 second. We can not simply use the default value or unified set to another value, to Dubboset the timeout is best targeted.
Some, like the short, relatively simple business that can be set; but for complex business, you need to lengthen the appropriate time. Because, there is also the problem of a fault-tolerant cluster.
In Dubbo, the default policy is fault-tolerant cluster failure retry, the number is 2. If some business itself takes a long time to execute, because the timeout is too short will trigger fault tolerance mechanisms to try again. A large number of concurrent retry the request is likely to fill up Dubbothe thread pool, and even affect the back-end database systems, result in connections being depleted.
2, fault tolerance and idempotent
We said above, if the timeout is set too short, it may lead to a large number of requests will continue to retry, and causes an exception.
There are also hiding other details, that read and write requests. If it is a read request, then retry does not matter; if it is a write request, if our interface also supports automatic retry it? This will involve issues such as power interfaces.
If the write request interfaces do not support idempotency, then the fault-tolerant clusters have changed failfastthat quickly failed.
3, distributed transactions
I feel, a distributed transaction in the industry is not completely solve the technical problems. There is no universal solution, nor is both efficient and simple means.
Nevertheless, we have to take this into account in advance, otherwise the data will certainly become dirty and messy.
Before considering solutions, we need to look at their system is not really the pursuit of strong consistency; in accordance with the BASEtheory, in a distributed system, allowing different nodes there is a delay in the process of synchronization, but restored after a period of time , to achieve the ultimate data consistency.
Based on these two ideas, we go to develop their own programs distributed transactions.
For a scene requires strong consistency, may consider XA protocol, submitted a three-stage or two-stage submission is guaranteed by.
For consistency requirements of the final scene, it can be considered TCC mode, compensation mode, or mode based on the message queue.
For example based on the message queue mode, you may be employed RocketMQ. It supports transaction message, this time the whole process is probably this:
- By
RocketMQqueue to send a transaction message to the message; - Message sent successfully perform local affairs;
- If the local transaction is successful, then submit
RocketMQthe transaction messages after submitting visible to the consumer; - If the local transaction fails, the delete
RocketMQtransaction messages, consumers will not see this message.
In addition, here at Amway Ali open source Seata. The latest version is 1.1.0, support for multiple transaction mode, such as AT, TCC, SAGA and XA transaction mode.
I have the article is based on the Seata 0.7version written by friends who are interested can learn under.
SpringBoot + Dubbo + Seata distributed transaction combat
4, the message queue
In a distributed system architecture, in order to decouple and asynchronous processing between systems to cope with high concurrency and high flow, message queues it is definitely a big weapon.
Before using this weapon, probably because we have to have a message queue annoyance under consideration.
First to consider is the availability, if the message queue is unavailable, the system itself will not cause a large number of unavailable;
Then, the message will not lose it? How to ensure the reliability of transmission of the message it? For example, to consider the brush disc itself, the message queue mechanism, the synchronization mechanism; submitted after the confirmation of data transmission time and consumption;
Then is repeated consumption, to ensure that if the message is not lost, the problem may be more or less the message will be repeated, this time we should consider repeating the consumer has no problem with that message idempotency;
Also, message sequence problems, your business scene, whether there is a message sequence problems, if you have this problem, either avoid it at design time, either at the time of order to ensure its consumption.
5, unified log
With micro-services split, logging system may also evolve into separate modules. To view the log, we may need to log in to different servers one by one to see.
Therefore, to build a unified log processing platform is inevitable. We can use ELKsolutions for log aggregation.
Here, we also need a link to track the problem. In the complex chain of micro-service calls, it will be more difficult to locate and track problems than single application.
For this problem, we consider the introduction of distributed call chain, generate a globally unique TraceID, through which the entire series up call chain. Combined Dubbo framework, we realize their own Filter, to pass through this TraceID.
You can refer to specific ideas: SpringBoot ELK + Dubbo integrated combat
Of course, we can also use a number of mature open source framework to solve.
to sum up
This article briefly summarizes some of the problems micro-service design and development process, it may be involved.
These views just one of the words, just summarize my experience in the past years.
If it helps you, please praise to encourage ~ If you have a different point of view, please actively speak and share their ~