IoT Application integration and CSE use based on Spring Boot 2.0

This article introduces the steps, benefits and problems of integrating IoT applications and using CSE based on Spring Boot 2.0. Using the CSE, a prototype system is equipped with micro-service governance and o&M capabilities, speeding up service rollout and reducing service operation risks.

Integrate and use the CSE in Spring Boot 2.0 through an IoT application. The IoT application was originally developed using Spring Boot 2.0 and integrates the CSE with a few steps. This article describes the new features that CSE integration brings to applications, the changes and problems that may be encountered during the transformation process. Through this example, we quickly transformed a prototype system of Spring Boot 2.0 into a microservice with general reliability and operation and maintenance capabilities, thus speeding up the construction of the business system. This document is updated based on the CSE JAVA SDK 2.3.52.

I. Integration steps

The basic integration process is divided into three steps.

1. Increase dependencies

Import the CSE dependencyManagement for spring boot 2 component packages and the CSE itself in dependencyManagement. You need to put spring Boot 2 dependency management first, because the CSE uses Spring Boot 1 by default. If the business needs to introduce a specific Version of Spring Boot or Spring Cloud, this mechanism can also be used to introduce Spring Boot or Spring Cloud dependencyManagement. [here] (http://servicecomb.apache.org/cn/docs/maven_dependency_management/) have a introduce dependencyManagement articles, DependencyManagement? Is a very useful skill to solve the three-party conflict. It helps developers to quickly locate and solve the common three-party conflict problem by mastering its principle correctly. [here] (https://huaweicse.github.io/cse-java-chassis-doc/using-cse-in-spring-boot/spring-boot-2.html) shows the CSE integrated spring boot 1. Principles and components of Spring Boot 2

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.huawei.paas.cse</groupId>
            <artifactId>cse-dependency-spring-boot2</artifactId>
            <version>${paas.cse.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>Copy the code

Then import the CSE support package for Spring Boot 2.

<dependencies>
    <dependency>
        <groupId>com.huawei.paas.cse</groupId>
        <artifactId>cse-solution-service-engine</artifactId>
        <exclusions>
            <exclusion>
                <groupId>org.slf4j</groupId>
                <artifactId>slf4j-log4j12</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    <dependency>
        <groupId>org.apache.servicecomb</groupId>
        <artifactId>spring-boot2-starter-servlet</artifactId>
    </dependency>
</dependencies>Copy the code

2. Modify running parameters

Use the @enableservicecomb tag to enable and load the CSE in Spring Boot 2. In Spring Boot 2, services are published as REST interfaces through DispatcherServlet. In Spring Boot 2, REST interfaces are published through DispatcherServlet. Services are published using the RestServlet provided by the CSE. After integration, the two servlets can coexist, and their contexts can be set to different prefixes to avoid conflicts. For details, see Step 3.

@EnableServiceComb public class Application { public static void main(String[] args) { SpringApplication.run(Application.class, args); }}Copy the code

3. Publish service interfaces

Like Spring Boot 2, the CSE scans the @RestContoller labelled classes and publishes them as REST interfaces. The interface information is also registered with the service center. You can specify the service center address in application.yml and provide simple microservice information. The service_description.name can use the name of the original project, and cs.rest. address is published using the Tomcat listening port server.port. The server. The servlet. Path = / MVC and servicecomb rest. Servlet. UrlPattern = / cse / *, respectively is Spring Boot DispatcherServlet and cse RestServlet prefix.

APPLICATION_ID: houseApp Service_description: name: ${spring.application.name} version: 0.0.1 CSE: Service: Registry: Address: http://localhost:30100 instance: watch: false rest: address: 0.0.0.0:9091 Servlet: urlPattern: / CSE /* server: servlet: path: /mvcCopy the code

Two, the integration effect

In the above example, it is very simple to convert the original Spring Boot 2.0 application runtime to CSE. However, transformation is not an end in itself. Here are some changes to illustrate the benefits brought to the business system after transformation, as well as the possible loss of functions and workload, so as to facilitate users to evaluate whether such integration is worth doing.

1. Runtime change

Runtime changes are a direct source of gains and losses. In the above transformation, neither the client code nor the server code has changed (or changed very little), the client still calls the server code using the RestTemplate, and the server still provides a REST interface that can be accessed using tools like Post Man. Runtime changes do not modify the external interface behavior of microservices, which is the basis of transformation.

Before the transformation, the Spring Boot 2 runtime schematic is shown below. On the client side, you can use the various MessageConverters provided by Spring RestTemplate to handle request message encoding and response message decoding, and on the server side, you can use the various functions provided by Spring MVC to validate user parameters.

After the transformation, the runtime diagram is as follows. The CSE client and server provide a unified processing chain. And the default implementation of load balancing (https://docs.servicecomb.io/java-chassis/zh_CN/references-handlers/loadbalance.html), [fusing fault-tolerant] ( (https://docs.servicecomb.io/java-chassis/zh_CN/build-provider/configuration/downgrade-strategy.html), [flow control] https://docs.servicecomb.io/java-chassis/zh_CN/build-provider/configuration/ratelimite-strategy.html), and other functions.

A core feature of runtime functionality is the rapid transformation of application microservitization. A basic feature of microservices is multi-instance communication through network interfaces. Therefore, solving the problems of service discovery and communication unreliability is a basic guarantee for microservitization. The CSE integration helps users quickly build these capabilities, reducing the cost of learning and developing other Spring Boot and Spring Cloud components.

The CSE itself offers a wealth of development and extension capabilities, From the [design] (https://bbs.huaweicloud.com/blogs/1fc9427c088611e89fc57ca23e93a89f) and [guide] ( https://docs.servicecomb.io/java-chassis/zh_CN/) for more information on CSE.

2. Change in development mode

With Spring Boot 2, developers can use RestTemplate or Feign to access the server interface. The CSE also supports RestTemplate and RPC. Compared with Feign, RPC of the CSE is more concise and does not need to define and use REST labels on the client.

This mode applies to access between microservices developed using the CSE framework. For accessing third parties, CSE provides a mechanism similar to Feign and provides more powerful load balancing management and governance capabilities (Consumer processing chain) than Feign. For an example, see ServiceComb code [Example]( https://github.com/apache/incubator-servicecomb-java-chassis/blob/master/integration-tests/it-consumer/src/main/java/org / apache/servicecomb/it/testcase thirdparty/Test3rdPartyInvocation. Java).

By integrating CSE, developers can easily use REST and RPC in their code at any time, which is very flexible and saves a lot of code writing time.

3. Changes of peripheral tools

The discussion above is limited to microservices themselves. In order to ensure the continuous and efficient operation and maintenance of business functions, it is also necessary to provide a powerful operating environment for microservices to realize the monitoring of microservices’ operating status and real-time adjustment of microservices’ functions (flow control, gray release, fuse fault tolerance, etc.). This can be implemented quickly with a commercial solution or built in-house with an open source solution.

L Business solutions

Huawei [micro service engine] micro (https://console.huaweicloud.com/cse/) provides one-stop service management capabilities. After the modified application is deployed to the micro-service engine, various functions such as viewing the micro-service catalog, interface management, and dynamic governance can be realized.

The core components of a microservice engine include a service center, a configuration center, and a governance center. In addition to deploying services to the cloud, developers can use these services locally, as long as they have an available network connection, register with huawei Cloud Micro service engine and obtain AK/SK identity information. ] [to buy a house system (https://github.com/huaweicse/HouseApp/tree/spring-boot-2.0-with-zipkin) provides an example of a local use huawei cloud service. You only need to configure AK/SK information and service center address information in application.yml.

L Open source solutions

Service center (https://github.com/apache/incubator-servicecomb-service-center). The service center provides registration discovery services, as well as front-end services for viewing service catalogs and interface testing.

[] configuration center (https://github.com/ctripcorp/apollo). This is the configuration center developed by Ctrip. The CSE supports the Netflix Archaius extension to use various configuration services.

[invocation chain zipkin] (https://github.com/openzipkin/zipkin). This standard Zipkin invokes the chain service. The CSE supports interconnection with the Zipkin call chain through the Hanlder extension.

[Skywalking]( https://github.com/apache/incubator-skywalking/tree/master/apm-sniffer/apm-sdk-plugin/servicecomb-plugin).

Can from [the] development guide (https://docs.servicecomb.io/java-chassis/zh_CN/) to understand how to integrate and use these open source components.

The CSE runs as a Servlet of Spring Boot 2.0. Therefore, users can use most components provided by Spring Boot and Spring Cloud. In the Spring Cloud scenario, eureka is selected as the service discovery service. The CSE uses the service center as the service discovery service. At present, there is no unified standard for the selection of service center, and the supporting SDK can only use the recommended service discovery tool.

4. Display load balancing and isolation capabilities

Here is an example to show the load balancing capability and isolation capability after the transformation. This [example] (https://bbs.huaweicloud.com/blogs/72a312f09c8911e89fc57ca23e93a89f) shows in multi-instance deployment situation, rolling upgrade zero interrupt.

[system] that buy a house (https://github.com/huaweicse/HouseApp/tree/spring-boot-2.0-with-zipkin) implements a complete spring cloud applications, you can use this system to carry on the experience.

5. Use Zikpin to call the chain tracking ability demonstration

This demonstrates the ability to quickly build call chain tracing in your system. The modified reference simply needs to import the call chain JAR package, add the processing chain configuration and zipkin server address to application.yml, and install the Zipkin server to use the call chain. [development steps] (https://docs.servicecomb.io/java-chassis/zh_CN/general-development/microservice-invocation-chain.html).

[system] that buy a house (https://github.com/huaweicse/HouseApp/tree/spring-boot-2.0-with-zipkin) to achieve the invocation chain.

6. Enable metrics monitoring

CSE provide powerful function of the metrics (https://docs.servicecomb.io/java-chassis/zh_CN/general-development/metrics.html), can help developers to analyze performance problems. The modified reference can be used only by importing the metrics jar package and adding a switch to enable metrics in application.yml. Metrics data can be captured in two ways.

Query through the interface

Output to a log file

Common problems

There are always problems when adapting a business with a new framework. [principle] (https://bbs.huaweicloud.com/blogs/ba7b62178cb811e89fc57ca23e93a89f) may encounter the problems in the process of transformation is introduced, and some common patterns, can read this article to evaluate the work of the renovation. The following lists some common problems encountered in modifying IoT systems and their solutions.

1. Tripartite conflict

Tripartite component conflicts are a common problem when introducing a new framework or component. The solution of three-party conflicts is based on compatibility between versions. The causes of conflicts can be many and there is no set way to resolve them, but with maven dependency management skills and an understanding of the causes of conflicts, it is often easier to analyze and resolve such problems. Recommended reading [maven management skills] (http://servicecomb.apache.org/cn/docs/maven_dependency_management/).

2. SpringMVC data type support

The CSE supports SpringMVC tags to define REST interfaces. In general, it is very easy to transform SpringMVC applications into CSE applications. However, the CSE and SpringMVC have different runtimes and design goals, so there are still some differences. The main difference here is that the REST interface is defined using CSE, which supports fewer annotations and data types than SpringMVC. Detailed reference [] (https://docs.servicecomb.io/java-chassis/zh_CN/using-java-chassis-in-spring-boot/diff-spring-mvc.html).

For example, the following REST interface definitions are not available or are restricted in the CSE.

When this interface is defined, Page is an interface. The CSE does not support the use of generics in interface definitions, such as interface and Abstract class. The CSE makes this restriction because the CSE must comply with the Open API specification, and the interface definition must have the corresponding Swagger description. If you use Interface and Abstract class, then you cannot describe this interface by Swagger.

When this interface is defined, Page is an interface. The CSE does not support the use of generics in interface definitions, such as interface and Abstract class. The CSE makes this restriction because the CSE must comply with the Open API specification, and the interface definition must have the corresponding Swagger description. If you use Interface and Abstract class, then you cannot describe this interface by Swagger.

CSE data type support [that] (https://docs.servicecomb.io/java-chassis/zh_CN/build-provider/interface-constraints.html)

L Solutions

The business code should be properly layered so that the code is flexible enough to migrate between different frameworks. If you use Spring for development, layered design can follow some of Spring’s recommendations. The business logic is implemented in @Service and the framework interface is published in the @Controller implementation. When publishing services in different frameworks (such as Servlets, Spring MVC, CSE, etc.), you simply tweak the @Controller code, not the @Service code. Take an example of the interface above.

@Service

Publish as the Endpoint of Spring MVC:

Published as Servlet:

Interfaces published for the CSE:

Class PageModel<T> { private int totalPages; private int totalElements; private int number; private int size; private int numberOfElements; private List<T> content; private boolean first; private boolean last; } Class Record { private long id; } @RestSchema(schemaId= "CSEEndpoint") @RequestMapping(value = "/cseEndpoint") public class CSEEndpoint { @Autowired private MyService service; @PostMapping(value = "/search") public ResponseEntity<PageModel<Record>> findAll(@RequestParam int pageNumber, @RequestParam int pageSize) { Page<Record> pages = service.findAll(example); // convert pages to PageModel PageModel<Page> result = ; return new ResponseEntity<List<T>>(result, HttpStatus.OK); }}Copy the code

3. Business logic that relies on Spring MVC specific mechanisms

In our transformation in step 2, remove the DispatcherServletAutoConfiguration, namely Spring MVC REST provides related features are removed. Some interfaces provided by Spring MVC rely on this functionality. If removed, this functionality will become unavailable. Such as:

import org.springframework.web.context.request.RequestContextHolder; import org.springframework.web.context.request.ServletRequestAttributes; @before ("webLog()") public void doBefore(JoinPoint JoinPoint) throws Throwable {// The request is received, Record the request content ServletRequestAttributes attributes = (ServletRequestAttributes) RequestContextHolder. GetRequestAttributes (); HttpServletRequest request = attributes.getRequest(); Log.info ("URL: "+ request.getrequesturl ().tostring ()); }Copy the code

The above code gets the Servlet request through the RequestContextHolder and gets some headers from the request to log. RequestContextHolder relies on Spring MVC REST to set the request context, and after rectification, the retrieved Attributes are empty, resulting in an NPE exception being thrown.

L Solutions

Depending on the specific functionality provided by the platform, the transformation needs to be combined with the platform to see if there is an alternative. This code is intended to implement logic such as audit logs or call chains. The CSE provides a Handler to obtain such information and has implemented call chains. Therefore, you can directly use or customize the Handler or HttpFilter mechanism to implement similar functions.

For more exciting content, please click on the top right corner to follow the small house

Source: Huawei Cloud community