14 posts
In Spring Boot we commonly use @RestControllerAdvice and @ControllerAdvice to catch exceptions globally and handle them gracefully — but it can't really catch everything. A case I ran into: a custom filter extending OncePerRequestFilter validates the token, and when the token expires it throws an ExpiredJwtException that never gets caught.
If you have followed me from the first section to create the project and tried running my code (https://github.com/NeilRen/SpringCloudDemo), I believe you can now build a basic microservices architecture. Since this is a beginner tutorial, many things are not covered in depth or detail — the goal was simply to get a microservices architecture up and running. If I have time later, I will try to write an advanced tutorial covering Spring Security, message queues, database distributed master-slave setups, distributed log collection, and so on.
After the previous section on service tracking and link monitoring, the basic microservices framework is nearly complete. Deployment in a microservices setup inevitably involves Docker, so how do we build a Docker image? In this section we'll cover packaging the code into an image file and uploading it to an image repository.
In the previous section we covered circuit breaking and degradation, and we can basically build a fairly complete microservices architecture now. But a microservices architecture is distributed — each service runs independently while depending on others — so if a problem occurs, it's hard to trace where it is. We need a service-tracing solution, and Spring Cloud Sleuth provides service tracing and link monitoring.
In the previous section we covered the API gateway, which lets multiple services be published uniformly through the gateway. Before publishing, we also need to understand a mechanism in microservices — circuit breaking and service degradation, called Hystrix in Spring Cloud. This section integrates Hystrix to implement circuit breaking and degradation. Hystrix has many features; we only cover the most commonly used circuit breaking and degradation mechanisms.
In the previous section we covered Spring Cloud's API gateway Zuul. As service interfaces grow, we also need a tool to manage the interface documentation, so in this section I introduce Swagger. It is not part of the microservices architecture, but it is very practical, so I included it in the beginner tutorial. Swagger can not only visualize interfaces as documentation, but also test online and generate SDKs. This section mainly covers integrating Swagger; we won't go into Swagger usage in detail — I'll write a dedicated tutorial on that later.
In the previous section we covered asynchronous communication between microservices via message queues. This section introduces the API gateway in microservices, Spring Cloud Zuul, which can centrally manage numerous interfaces and provide load balancing, among other functions.
The previous section, 'Spring Cloud Microservices Beginner Tutorial (6): Spring Cloud BUS Message Bus for Dynamic Config Refresh,' already installed the RabbitMQ message queue and implemented the Spring Cloud Bus message bus. This section introduces Spring Cloud Stream message-driven microservices. You can use RabbitMQ, Apache Kafka, etc., for asynchronous message passing and receiving between microservices.
The previous section, 'Spring Cloud Microservices Beginner Tutorial (5): Centralized Config — ConfigService,' implemented unified config management. At the end I mentioned that config is only pulled automatically after a restart, so this section explains using the Spring Cloud BUS message bus to automatically update config files, which lets the application hot-reload config without a restart.
In the previous section, 'Spring Cloud Microservices Beginner Tutorial (4): Inter-service Invocation — FeignClient,' we covered creating microservices and consuming between them. As the number of microservices grows, so do the many Spring Boot programs, and modifying their config files becomes a terrifying workload. So the microservices architecture also provides a config center, which lets us conveniently manage our service config files centrally. At the same time, the production environment config is not open to developers, so only operations staff need to maintain the online config center.
