1, Application of apollo in project

1. pom introduces dependency (here is the company's internal api)

        <dependency>
        <groupId>com.bestpay.framework.apollo</groupId>
        <artifactId>apollo-client</artifactId>
        <version>1.3.0.6</version>
        </dependency>

2. Configuration file

aplollo-context.xml

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:apollo="http://www.ctrip.com/schema/apollo"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.ctrip.com/schema/apollo http://www.ctrip.com/schema/apollo.xsd">

    <apollo:config namespaces="application, technology.dubbo-sh, technology.redis, technology.rf-mpersonal_fin, business.config,
    technology.kafka-hx, technology.elasticjob-ls, technology.hikaricp.config "/>
</beans>

 

<import resource="classpath:apollo-context.xml"/>

 application.properties

app.id=clp-pay-center
apollo.env=func
apollo.meta=http://172.17.46.16:20880

3. Test

public class Test extends BaseTest {
    @Value("${privateTradeType}")
    private String merchantNo;
    @org.junit.Test
    public void test(){
        System.out.println(merchantNo);
    }

You can see that after the @ Value annotation is used, you can get the Value configured by apollo

You can also read the configuration of apollo in the configuration file

For example:

 4.apollo configured listening

@Slf4j
@Service
public class ApolloChangeListener {
    /**
     * Spring LoggingSystem for
     */
    @Autowired
    private LoggingSystem loggingSystem;


    private void onAppChange(ConfigChangeEvent changeEvent) {
        Set<String> changedKeys = changeEvent.changedKeys();
        for (String key : changedKeys) {
            ConfigChange change = changeEvent.getChange(key);
            String oldValue = change.getOldValue();
            String newValue = change.getNewValue();
            log.info("Apollo The configuration has been updated, namespace=[{}], key=[{}], oldValue=[{}], newValue=[{}]",
                    changeEvent.getNamespace(), key, oldValue, newValue);
            System.out.println("Apollo The configuration has been updated"+"namespace="+changeEvent.getNamespace()+"key="+key+"oldValue="+oldValue+"newValue="+newValue);
            // Log level change
            if ("loggingLevelRoot".equals(key)) {
                log.info("Apply log level updates, key=[{}], old=[{}], new=[{}]", key, oldValue, newValue);
                loggingSystem.setLogLevel("root", LogLevel.valueOf(newValue.toUpperCase()));
            }
        }
    }

2, Introduction to apollo

Apollo (Apollo) is a distributed configuration center developed by Ctrip framework department. It can centrally manage the configuration of different application environments and clusters. After the configuration is modified, it can be pushed to the application end in real time. It also has standardized permissions, process governance and other characteristics. It is suitable for micro service configuration management scenarios. The server is developed based on Spring Boot and Spring Cloud. After packaging, it can run directly without installing additional application containers such as Tomcat. The Java client does not rely on any framework and can run in all Java runtime environments. At the same time, it also has good support for Spring/Spring Boot environment.

Apollo (Apollo) is a distributed configuration center developed by Ctrip framework department. It can centrally manage the configuration of different application environments and clusters. After the configuration is modified, it can be pushed to the application end in real time. It also has standardized permissions, process governance and other characteristics. It is suitable for micro service configuration management scenarios.

 

characteristic

• Uniformly manage the configuration of different environments and clusters
• Configuration modification takes effect in real time (hot release)
• Version release management
• Grayscale Publishing
• Authority management, release audit, operation audit
• Client configuration information monitoring
• Provides Java and Net Native Client
• Provide open platform API

• Config Service provides functions such as reading and pushing configuration, and the service object is the Apollo client
• Admin Service provides configuration modification, publishing and other functions. The service object is Apollo Portal (Management Interface)
• Config Service and Admin Service are both multi instance and stateless deployments, so you need to register yourself in Eureka and keep heartbeat
• A layer of Meta Server is built on Eureka to encapsulate Eureka's service discovery interface
• The Client accesses the Meta Server through the domain name to obtain the Config Service service list (IP+Port), and then directly accesses the service through IP+Port. At the same time, the Client side will do load balance and error retry
• Portal accesses the Meta Server through the domain name to obtain the Admin Service list (IP+Port), and then directly accesses the service through IP+Port. At the same time, it will do load balance and error retry on the portal side
• In order to simplify deployment, we will actually deploy the three logical roles of Config Service, Eureka and Meta Server in the same JVM process

Implementation principle of Apollo client:

1. The client and the server maintain a long connection, so that the push of configuration updates can be obtained at the first time. (via Http Long Polling)
2. The client will also regularly pull the latest configuration of the application from the server of the Apollo configuration center.
   • This is a fallback mechanism to prevent the configuration from being updated due to the failure of the push mechanism
   • The client will report the local version for timed pull, so generally, the server will return 304 - Not Modified for timed pull
   • By default, the timing frequency is pulled every 5 minutes. The client can also specify System Property: Apollo Refreshinterval, in minutes.
3. After the client obtains the latest configuration of the application from the server of Apollo configuration center, it will be saved in memory
4. The client will cache a copy of the configuration obtained from the server in the local file system
   • When the service is unavailable or the network is unavailable, the configuration can still be restored locally
5. The application can obtain the latest configuration and subscribe to configuration update notifications from the Apollo client

https://www.cnblogs.com/dalianpai/p/14311014.html