Original address: Reviewing my microservice journey
Write in front:
The content in this article is suitable for repeated reading, and has practical guiding significance in system construction for enterprises that need rapid trial and error, or enterprises that need rapid changes in business models.
They are all lessons and summaries that the original author got in actual development, and are very valuable.
text:
introduction
On New Year's Day in 2015, I joined Weicai , and what I experienced in the next two years is very worth recording today.
The whole process seemed a bit like an unplanned adventure, most of which were made by myself and my partners with experience and intuition.
Now, I call it the "microservices journey", and I will detail it here, in order to make it a supplementary case of the article Microservices for others to learn from and reflect on.
Dropwizard , opportunity
Frankly speaking, in 2015, microservices have been a hot topic in the architecture circle, but I am still in the stage of understanding SOA . My past experience has taught me that trendy words are used for coercion, and there are real problems waiting for me to solve.
A few months into the job, the handling of several online failures drove me to take a hard look at the existing system architecture. It is a very mainstream Java Monolithic Application Spring + Mybatis, which is more than enough to meet the business scenarios at that time, but some details of engineering implementation have buried hidden dangers for failures:
- Various miscellaneous configuration files (Bean description, SQL template, Properties), spelling mistakes if you are not careful, especially the rough update of the online environment
- If there is no time to reserve monitoring indicators, there is no way to clearly reflect the operating status of the system.
- WAR-based Web containerized deployment, adding an application instance, human flesh operation for half a day
The above may not be a problem for a team with good professionalism, but an excellent development framework can improve the basic ability of a young team.
In 2012, I used Dropwizard to independently develop the operation and maintenance support application of internal middleware. The overall feeling is "fast, more, better and less".
Immediately, I shared and promoted Dropwizard to the team and the whole company, and also took the lead in piloting the non-core system of the credit business line.
(The picture comes from the value of spring-boot in the unified architecture system )
Inspired by this move, Wang Fuqiang ( Teacher Fuqiang), who is implementing service-oriented services in the company , also fired the first shot for using SpringBoot to build a microservice system in the future.
Why choose SpringBoot over Dropwizard? The wall teacher explained in the article Spring Boot Rock'n'Roll .
service split
Mr. Fuqiang, Hong Jiang and I have all experienced servitization in Alibaba, and are well aware of the positive role of system architecture servitization in the rapid development of Internet companies.
The P2P market was booming in 2015, and the competition that followed was fierce, especially in the credit business line. In order to seize the traffic, the business continues to expand various loan models to cover as many different consumer groups as possible. At this time, the requirement for the technical team is to make every effort to rapidly iterative development to support the rapid trial and error of the business.
Faced with such a situation, the architectural style of the monolithic application is obviously unable to cope with:
- Branches of the same code base are often merged into conflict, and the efficiency of multi-person collaborative development encounters a bottleneck. On the contrary, the more people, the lower the efficiency;
- There are many types of loans and there are conflicting business rules, and various
if-elsetemporary solutions for codes make testing and troubleshooting extremely time-consuming; - Application upgrades must be restarted. In order to reduce the impact of system unavailability on business, we had to choose to release in the early morning, and nightmares continued.
Demolition, must be demolished, the sooner the better!
Front and rear separation
In traditional Java Web development, the page is mainly rendered statically, and a small amount of JavaScript is used for dynamic form interaction. However, after the mobile Internet became the mainstream, the more demanding Web user experience requires that interactions be completed on the device as much as possible, forcing application services to provide Web APIs for front-end application logic.
In the second half of 2014, Dubbo has been introduced into the wealth management business line of Wacai for service transformation. Considering the general trend of separation of front and back ends, Web API is indispensable. For this reason, whether Dubbo for service is the most suitable, we have had a fierce debate internally.
Extract core services
Even if it is a single application, it is actually possible to develop multiple types of loans in parallel, which is nothing more than a single application for one type of loan. However, the public logic, such as order, data, contract, card binding, payment, anti-fraud, etc., must be developed repeatedly? Regardless of whether it is elegant or not, it is also unacceptable in terms of R&D efficiency.
Naturally, these public logics should be transformed into reusable core services for the orchestration and use of various loan business services.
Sub-library and sub-table
The sub-database sub-table here does not refer to horizontal partitioning based on a field value in order to improve the parallelism of data access.
Unfortunately, the separation and separation of services is not as simple as imagined. In the previous monolithic application style, the large-width table (more than 50 fields) of an order in the database coupled all the core logic, that is, the implementation of their logic needs to operate on the same table, and the huge DAO allows all Logic has no clear boundaries. Even the independent credit middle and back-end systems (another monolithic application) will directly access this table, which means that once the business logic changes involving this table, the two major systems must change accordingly. Even if the core services can be split, the disaster will only get worse in the future.
+---------+ +----------+
| 贷前系统 | ---> [订单表] <--- | 中后台系统 |
+---------+ +----------+
A single point of dependence on data like this is often accompanied by serious performance problems or hidden dangers. For example, the middle and back-end systems will have batch-scanning scheduled tasks or data analysis reports, which is a fatal blow to the front-end system that requires high real-time response.
Therefore, service points, data points. The data of the database table should be re-organized and modeled according to the abstraction of the service logic, and the database table with high cohesion with the corresponding service should be created. Data access across services should not be directly connected to the database, but should be completed through the service interface to ensure that there is no The internal details of the data structure create hidden coupling associations.
autonomy and collaboration
At the beginning of service splitting, each core service abstraction implementation will assign a core R&D person to be responsible for completion, but this does not mean that his R&D task is over once the service is launched. In principle, he will be responsible for the daily operation and maintenance and future changes .
You may have noticed that I used the word "in principle" to qualify. Yes, in reality, the team members are always tense and frequent. It is a bit difficult for one or two people to be responsible for one service or multiple services, and it is easy to form a collaboration bottleneck.
To this end, I implement Github's PR (Pull Request) collaboration model in the team. Suppose that the new loan A service expects core service B to provide new interface support, and the person in charge of core service B has a higher priority year-end promotion project on hand . The code of core service B , so as to provide a new interface implementation as a PR request the person in charge of core service B to review and merge the code, so as to alleviate or avoid the blocking situation. Over time, the more research and development that provides PR, the ability to take over core service B gradually becomes available .
For details of the actual operation, see:
In order to make the participation of collaborators smoother, the person in charge of the core service is obliged to provide the necessary README documents to help collaborators quickly familiarize themselves with the project code, such as:
- How to quickly run and debug code
- Core logic design ideas
- Test Case Guidelines
In addition, in order to ensure that the corresponding person in charge cannot diagnose and deal with the service failure in time, the person in charge shall also provide the OPS operation key document to facilitate the guidance of others to deal with it temporarily, including but not limited to:
- Key Configuration Notes
- start stop method
- Common fault handling
R & D support
To enjoy the dividends brought by service, the above part is just the tip of the iceberg, and more construction on the basic platform cannot be ignored. In this part of the content, Mr. Fuqiang has written a book called "SpringBoot Revealing: Rapidly Building a Microservice System" . I will not repeat it here. It is recommended to read.
The book does not discuss how the most popular Docker containerization technology is applied in the microservice architecture, just because when Mr. Fuqiang left Wacai, Wacai had not officially started Docker. But at the end of 2016, Docker and Kubernetes were already digging for money to carry out the implementation, codenamed K2 .
Epilogue
Going back in history, the industry gods first used "microservices" to collectively refer to a new type of software architecture model at the seminar. Since then, it has been so popular that it has misled some people to blindly follow concepts and metaphysics.
In contrast to the above content, if you look at the common characteristics of "microservices", you will find that there is an amazing similarity between them.
The concept of "microservices" is worth advocating, but what is more important is the causal relationship behind the concept. I hope that every practitioner who embarks on the road of microservices can explore a microservice architecture suitable for their current environment.