Spring Boot is a suite based on the Java Spring framework that comes preloaded with Spring components, allowing developers to create standalone applications with minimal configuration. In a cloud native environment, there are a number of platforms that can run Spring Boot applications, such as virtual machines, containers, and so on. One of the most attractive, however, is to run Spring Boot applications Serverless.
Author: Xiliu
SpringBoot is a suite based on the Java Spring framework that comes preloaded with Spring components, allowing developers to create standalone applications with minimal configuration. In the cloud-native world, there are a number of platforms that can run SpringBoot applications, such as virtual machines, containers, and so on. But one of the most attractive is to run SpringBoot applications Serverless.
I will analyze the merits and demerits of SpringBoot application running on Serverless platform from five aspects, including architecture, deployment, monitoring, performance and security, through a series of articles. To make the analysis more representative, I chose Mall, an e-commerce app with more than 50K stars on Github, as an example. Through the article “SpringBoot Serverless actual combat – deployment”, I believe that we have felt the Serverless application online convenience. This is the third article in a series that shows you how to monitor and debug Serverless applications.
Real time log
For applications running on remote cloud platforms, logs are the main means of debugging. In distributed applications with multiple instances, log collection and analysis can be challenging. There are plenty of mature open source products out there, but it’s expensive to build and maintain them. Function computation has full support for log collection/analysis built in. Users only need to output logs in the application logic, these days are automatically collected, and can be viewed in real time, through a variety of ways of aggregation, query.
In previous articles, we have created a log repository for application automatic creation using the Serverless Devs tool, which allows viewing requests, application-level logging on the function computing console, and advanced queries using SQL. In addition, the Serverless Devs tool provides real-time logging capabilities that can be very helpful for application debugging.
In the project root directory, where S.aml resides, execute the following command to log all the services defined in S.AML.
sudo -E s logs
Users can also view logs of a specified service.
sudo -E s mall-admin logs
Using the -t parameter, you can enter the observation mode to view logs in real time.
sudo -E s mall-admin logs -t
In this case, the Serverless Devs tool listens to the logs of all instances under the mall-admin application in real time and displays the newly generated logs in real time. After that, when we send a request to the mall admin application using a browser or curl, we can see the corresponding request processing log output.
Serverless Devs also supports querying logs by keyword. For example, we can run the following command to view the ERROR level log of the mall-admin application.
s mall-admin logs -t –keyword=ERROR
Multi-dimensional query and display of indicators
In addition to Serverless Devs’s command-line tools, users can view logs from multiple dimensions, including function, instance, request, and more, on the function calculation console.
For example, on the left navigation bar of the function computing console, click Services and Functions, select the mall-admin service, and then the function of the same name under the service. The details page of the mall-admin function is displayed. Click the Monitoring indicators TAB.
As shown below, the request list shows the execution of the request, including success/failure, which version of the function it was executed on, how long it was executed, how much memory it used, which instance it was executed on, and so on. You can also easily query the log related to the request.
The following figure shows the instance dimension information. In addition to indicators, users can also scroll to the bottom of the page to view the instance list and log in to the instance to perform related operations.
Note: the measured instances of the function are completely managed by the system and are reclaimed by the system after being idle for a period of time. The reclaimed instance is no longer in use and cannot be logged in. It is shown in gray in the figure below.
User development flows are seamlessly linked through the log collection and query capabilities provided by the functional computing platform. Modifying the code, deploying the application using the Serverless Devs tool, viewing the logs, and the process is silky smooth.
Local debugging
Before deploying an application to the cloud, we usually want to be able to deploy the application locally and debug it. The Serverless Devs tool provides the ability to run applications locally.
In the project root directory (s.aml directory), run the command to start the corresponding service. The auto parameter indicates that the test domain name that is compatible with the Web framework is automatically generated for the instance. For example, run the following command:
sudo -E s mall-admin local start auto
The tool launches the function instance locally and provides a URL to call. In this way, we can debug Web applications locally and improve efficiency.
Note: Listen ports are generated randomly each time a local instance is started.
The cloud alignment
Many times, the microservices/functions that make up the application need to call each other with other services. In addition to simple unit testing locally, syndication or integration testing must deploy code to the cloud. In this way, the development and debugging process is longer, and the complex cloud environment also increases the difficulty of problem diagnosis. Such as:
- In order to migrate the original application, the function instance needs to access other services in the cloud environment. If the instance cannot be started, how can I troubleshoot the cause?
- The application uses a microservice architecture and involves multiple services. Can end-to-end testing be done quickly after native code development is complete?
- Event-driven applications, triggered by event sources, have multiple links and long links. Can you quickly test the entire link locally?
- …
To solve the above problems, Serverless Devs provides the end-to-end cloud tuning function. Developers can start instances locally through end-to-end cloud tuning, and seamlessly connect with the cloud environment for rapid testing and problem debugging. End-to-end cloud integration can help developers:
- Code changes, real-time view results, debugging iteration of the shortest loop.
- Able to reuse local rich development and debugging tools, the highest efficiency.
End-to-end cloud interworking establishes a secure tunnel connection between the local development machine and the VPC of cloud applications. Traffic to cloud applications will be automatically forwarded to the local developer; In addition, the network traffic accessed by the local instance is automatically forwarded to the CLOUD application’s VPC. For example, when accessing a cloud RDS database instance from a local instance, traditional developers can only access the RDS instance from the public network. With endcloud, RDS instances can be accessed directly from the Intranet without any configuration changes.
Take the mall application as an example. The entire application consists of multiple services, such as mall-admin-Web, mall-admin, mall-portal, and mall-search. There are upstream and downstream dependencies between services, such as mall-admin-Web that sends requests to the downstream mall-admin service. Suppose that we have deployed a whole set of mall application services in the test environment, and now want to debug the mall-Admin service in the whole link of the development machine, we need to deploy the whole set of mall-admin-Web services and databases on the development machine, or interact with the services and databases in the cloud VPC through the public network. This is very cumbersome and even unrealistic. End-to-end cloud integration enables us to start the instance of the mall- Admin service in the local development machine environment and securely interact seamlessly with other services and databases in the cloud VPC environment. The user doesn’t need to do anything.
First, run the following command in the directory where S. aml resides to start the end-to-end cloud mediation for the mall-admin service.
sudo -E s mall-admin proxied setup
Then access the mall-admin-Web application from the console and you can see that the relevant request has been forwarded to the local instance of the mall-admin function. In addition, local instances can seamlessly access databases and other services in the cloud VPC.
Note: When end-to-end cloud mediation is used, all traffic is sent to the local instance. To restore the traffic to the instance on the function calculation, execute s deploy redeploy the relevant function.
conclusion
From the two reports below, we can see that debugging and observability have been the two biggest pain points for Serverless development practitioners in the Serverless world.
The Serverless product always practices the concept of developer first, exploring and landing ahead of all cloud vendors in terms of debugging and observability. In terms of debugging, Serverless Devs tool supports local debugging, end-to-end cloud debugging and even remote debugging. In terms of observability, it has launched second level monitoring, instance index and instance login that other manufacturers do not have, which greatly improves the working efficiency and happiness of Serverless developers. Server Less, Value More!
The original link
This article is the original content of Aliyun and shall not be reproduced without permission.