background
for RPC remote invocation, we are using Dubbo, Dubbox, and so on. We are ready to try new technology (and perhaps not a new technology at this time) because the community is suspending maintenance and responding to future developments, choosing to use the Spring cloud architecture. In the meantime, the Spring boot project was used to try development and the results were good. So you want to refactor the original spring project to Spring cloud step-by-step, so there are a variety of problems in development.
problem
Problems are always accompanied by the development of a step-by-step exposure, encountered problems always to solve:
Spring Cloud related issues:
1. Cross-system calls, the parameter object receives no problem
WORKAROUND: The service party can be @requestbody before the object parameter (Ps:public void Saveuser (@RequestBody user user)), and the data exists in the style of the report.
2. Inter-system retry problems, repeated calls are normal business data duplication, resulting in garbage data
The resolution is divided into 2 steps and all are in the caller configuration, and the first step is to add the class:
Return is the reference feign. Retryer, as to the method name arbitrarily.
@Configurationpublic class Feignconfig { @Bean public retryer Feignretryer () { return new Retryer.default (Seconds.tomillis (1), 0);} }
Step Two:
# Max number of next servers to retry (excluding the first server)
sample-client.ribbon.maxautoretriesnextserver=1 will randomly select the next service for the Cluster service, and may choose to access itself. Not having the cluster set to 1 accesses itself will cause 2 accesses.
Sample-client for multiple server ends, sample-client can be deleted.
To view configuration discovery, for the configuration section click here:
# Max number of retries on the same server (excluding the first try)
Sample-client.ribbon.maxautoretries=1 found useless.
3. Deploy the server, the registry service exists, but access to the data is not available, the service refused to connect
Solution: In fact, this is a point of attention, usually development is springapplication startup project, packaging Deployment Services when the Tomcat port and Server.port (Spring boot) configuration inconsistency caused. Guessing Spring cloud access gets the host and port from the registry, Access services based on host and Port but the service Tomcat settings port is inconsistent with the configuration, causing problems.
Spring Boot related issues:
1. The project uses springapplication to start normal, but cannot access the page
FIX: @ComponentScan only to scan the declaration in the package structure (including the child packages) of the current program
| -SRC
| | -Main
| | | -Java
| | | | -com
| | | | | -Controller/service/dao
| | | | -Springapplication.java
2. Request URL response problem, different suffix response different
Workaround: This scenario is because spring boot has multiple view parsers, Ajax requests can be directly used with A/b, page a/b.htm
Spring Related issues:
1.spring calling Spring Cloud project issues
Workaround: Use HttpClient to set the request header Content-type:application/json access to the Spring Cloud External System (gateway), as far as the intranet extranet access
Exception problem:
Spring Cloud has a hystrix, although the benefits of a lot, but access to each interface should be broken by the interface, if the processing logic is different okay, no difference I will not say. Since we are unified return, the use of global exceptions to intercept log returns failed for a problem, there is a disadvantage that access to the exception can be handled, as for timeouts these are not access to capture.
discussion
The Apprentice is not fine, some are indefinitely, hope the great God can guide pointing. It's a bit confusing that spring's visit to Spring Cloud finally hits the war pack deployment release, and the individual feels that spring should also be able to register with the registry, and hopefully know what to share.
Spring/spring Boot/spring Cloud Development Summary