23 Conclusion #
By now, I believe you have completed this course and have a more intuitive understanding of the Spring Cloud and Spring Cloud Alibaba open source projects. Through this practical operation, it may not be as difficult as you imagined. Once you have a systematic understanding of the entire development process, the concept of microservices can also be applied to your daily development work. In this section, let’s do a simple review and look back at the entire course.
Review #
This hands-on project focuses on a common scenario in a shopping mall parking lot. The goal is to gradually improve and iterate through the integration of microservice development technologies, in order to achieve our goal of learning and practicing microservice technology development. The content mainly focuses on technical development, with less emphasis on system operations. With the rise of DevOps, more and more companies are gradually blurring the boundaries between development and operations, integrating them completely.
When it comes to microservices, service decomposition is inevitable. However, there is no unified standard in the industry for the granularity of decomposition, and it varies depending on the team’s capabilities. If the granularity is too coarse, it won’t be effective. If it is too fine, it will be cumbersome and redundant to manage. After service decomposition, the underlying storage also involves the issue of decomposition. Even if microservices are not used, in cases of rapid business growth, it is common to split databases and tables horizontally. This involves vertical and horizontal decomposition.
Vertical decomposition involves dividing tables based on similar attributes and functions into different smaller databases. When the capacity of a single table in the database becomes too large, it needs to be horizontally split into different tables, distributed as A01, A02, A_03, etc. This case does not involve horizontal decomposition, but if the storage system remains unchanged, it will eventually encounter the issue of horizontal decomposition.
Review of Technical Points #
Technology serves the business, and the technology stack can only be useful in the appropriate business scenarios. Here is a table that maps business scenarios to technology applications.
| Business Scenarios | Technical Points |
|---|---|
| Bind mobile phone number and open monthly card for shopping mall users | Service invocation, RestTemplate, Feign, Ribbon |
| API management for various external interfaces of sub-services | Integration of Spring Boot and Swagger |
| Aggregation API for the shopping mall parking fee system | Integration of Spring Cloud Gateway and Swagger |
| How to manage the interfaces of multiple sub-service modules | Service management through Nacos |
| Give points for binding mobile phone numbers on special holidays | Use Nacos for distributed configuration, available to all services |
| Display available parking spaces and parking billing rules | Redis for distributed caching |
| Send marketing text messages to members on a regular basis | Distributed scheduling tasks, integration with Shedlock |
| Coupon redemption in the shopping mall | Redis for distributed locks, integration with Redisson |
| Data assembly for different terminals | Application of BFF architecture |
| Car wash service for coupon redemption | Integration with RPC framework Apache Dubbo |
| Shield internal interfaces and unify external routing control | Integration of Spring Cloud Gateway |
| Fast failure when the response of a service call is slow or the service is unavailable | Integration of Hystrix |
| Gateway traffic restriction to prevent overload | Setting specific rules with Sentinel |
| Gateway authentication and security protection | Integration of Spring Cloud Gateway with JWT |
| Integrity of billing data when leaving the parking lot and paying | Use distributed transactions, integration with the Seata component |
| Health status of each sub-service | Integration with Spring Boot Admin |
| Complete request chain when invoking services | Apache SkyWalking |
As the saying goes, practice makes perfect. In this short course of more than 20 sections, each aspect cannot be deeply explained. Therefore, you need to learn and explore while applying it in practice, steadily and step by step.
Is Microservices the Ultimate Solution? #
In recent years, microservices have been extremely popular and have become the silver bullet to save one’s own business. However, using microservices does not solve all the problems. It is closely related to the organization structure, technical reserves, business direction, and technical investment of the company, requiring collaboration among product, development, testing, and operations personnel. Without an open and agile mindset, both the initial implementation of microservice development and the microservice architecture refactoring based on existing business face significant challenges. At the same time, it places higher requirements on system testing and operations. Development is only a small part of the software life cycle. Most stages are in the operations phase.
Is it necessary to implement a microservice architecture? If the business is growing rapidly and the technical foundation is high with a mature application, you can directly start with a microservice architecture. Alternatively, if the system is already complex and maintenance becomes increasingly difficult, it is possible to refactor the architecture into a microservice one if time permits. However, it is not advisable to start from scratch. Instead, it should be done in a step-by-step manner, gradually replacing components. Otherwise, the cost of a complete rewrite is considerable.
Don’t underestimate monolithic applications. After in-depth exploration of their potential, they can fully meet normal business requirements. In general, it is recommended to start with a monolithic application and consider further steps after the business stabilizes. With appropriate design, cost waste can be avoided.
Microservices are More Than Just Development #
Microservices are not just about development; they also involve long-term operations and upgrades. This section only discusses the development part, but there is still a long way to go in terms of deploying and operating production systems in the future. The DevOps era requires developers to have more operational skills and even take on operational roles during the development phase. Containerized deployment, automated scaling, elastic scaling, and more are all part of the microservice architecture journey. I hope that everyone will continue to maintain the enthusiasm for learning and keep up the good work.