Apollo configuration center

Apollo (Apollo) is a distributed configuration center developed by ctrip framework department. It can centrally manage the configuration of different environments and clusters. After configuration modification, it can be pushed to the application end in real time. Details please refer to the official introduction: https://github.com/ctripcorp/apollo/wiki/Apollo%E9%85%8D%E7%BD%AE%E4%B8%AD%E5%BF%83%E4%BB%8B%E7%BB%8D

Apollo supports four dimensions to manage the key-value format configuration:

1. application (application)
2. environment (environment)
3. cluster (cluster)
4. namespace (namespace)
   

   feature

   based on the particularity of configuration, so the Apollo, from the beginning of the design was determined to become a governance configuration publishing platform, currently offers the following features:

   • unified management of different environments, different cluster configuration

     • Apollo provides a unified interface centralized management environment (environment), different cluster (cluster), the configuration of different namespaces (namespace)
     • the same code deployed in different clusters, can have different configurations, such as a zookeeper address such as
     • (namespace) can be easily through the namespace support multiple different applications to share the same configuration, It also allows applications to override Shared configurations

   • configuration changes in real time (hot publish)

     • user after Apollo modified the configuration and released, the client can receive the latest configuration in real time (1 second), and notify the application

   • version release management

     • all configuration releases have a version concept, which makes it easy to support configuration rollback

   • grayscale release

     • supports the grayscale publication of configuration. For example, after clicking the publication, it only takes effect on some application instances. After the observation is ok for a period of time, it will be pushed to all application instances

   • authority management, release audit, operation audit

     • application and configuration management has a sound authority management mechanism, the management of configuration is also divided into two links, editing and publishing, so as to reduce human error
     • all operations have audit logs, can easily track the problem

   client configuration information monitoring

   • can easily see the configuration used by which instances

   • provide. Java and.net native client

   • provides a native Java and.net client to facilitate application integration
   • supports Spring Placeholder, Annotation, and ConfigurationProperties of Spring Boot to facilitate application use (Spring 3.1.1+ is required)
   • also provides Http interface, Non-java and.net applications can also easily use

   • to provide open platform API

     • Apollo itself provides more perfect unified configuration management interface, support environment and data center configuration management, permissions, process governance features such as
     • though Apollo, for the sake of generality to configuration modifications do not too many restrictions, as long as you comply with the basic format can save
     • in our research, found that for some users, there may be more complex their configuration format, such as XML, json, need to make check in the format
     • if there are some use DAL, Not only have a specific format, but also to input the value of the need to calibrate the rear can save, such as check the database, the user name and password match
     • for such applications, Apollo application support party through an open interface configuration changes in the Apollo and release, and has perfect authorization and access control

     • simple deployment

       • configuration center as a basic service, availability requirements is very high, which requires the Apollo external dependence as far as possible little
       • the only external dependence is MySQL, so deployment is very simple, as long as the installed Java and MySQL can make Apollo run
       • Apollo also provides packaging script, a key can generate all the necessary installation package, and supports custom runtime parameters
         

         development guide

         once we have a basic understanding of Apollo, we will start its development. Apollo consists of two parts, the client side and the server side. Let’s first describe the server side of Apollo.

         • Apollo server
         • Apollo server is mainly composed of three parts, namely, configservice, adminservice, portal
         • configservice: provides the configuration reading, pushing and other functions, and the service object is Apollo client
         • adminservice: The Service object is Apollo Portal (management interface)
         • Portal: Portal management interface, intuitively view and publish project configuration messages
         • Config Service and Admin Service are multi-instance, stateless deployment. Therefore, we need to register ourselves in Eureka and keep the heartbeat
         • . On top of Eureka, we built a layer of Meta Server to encapsulate Eureka’s Service discovery interface.
         • Client accesses the Meta Server through the domain name to get the Config Service Service list (IP+Port), and then directly accesses the Service through IP+Port. At the same time, load balance will be performed on the Client side, and error retry
         • Portal accesses the Meta Server through the domain name to obtain the list of Admin Service services (IP+Port), and then access the Service directly through IP+Port. Meanwhile, load balance will be performed on the Portal side, and error retry
         • to simplify deployment. We will actually deploy the Config Service, Eureka, and Meta Server logical roles in the same JVM process

         

         • Eureka Registry

         • it provides a complete Service Registry and Service Discovery implementation, and has also withstood the test of Netflix’s own production environment. It is relatively easy to use

         • 0. At the same time, Spring Cloud also has a set of perfect open source code to integrate Eureka, so it is very convenient to use.

         • . In addition, Eureka also supports startup in the container of our application, that is to say, after our application is launched, it ACTS as Eureka and also serves as a service provider. In this way, the service availability is greatly improved

         last point is open source, because the code is open source, so it is very easy for us to understand its implementation principle and troubleshooting problems

         Apollo client

         • 0

           1 rely on import convenience, just need to integrate apolloClient

           2

         3

         4

         5 client and server maintained a long connection, In this way, the push

         client will pull the latest configuration of the application regularly from the server of Apollo configuration center. The default timing frequency is to pull the latest configuration of the application every 5 minutes. After the client gets the latest configuration of the application from the server of Apollo configuration center, The client caches the configuration obtained from the server in the local file system a

         • application gets the latest configuration and subscription configuration update notification from the Apollo client

         0