Apollo configuration center
h3>
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 p>
Apollo supports four dimensions to manage the key-value format configuration:
- application (application) li>
- environment (environment) li>
- cluster (cluster) li>
- namespace (namespace) li> ol>
feature h3>
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: p>
-
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) li>
- the same code deployed in different clusters, can have different configurations, such as a zookeeper address such as li>
- (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
- can easily see the configuration used by which instances li> ul> li>
-
provide. Java and.net native client p>
- 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
client configuration information monitoring
-
-
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 li>
- 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 li>
- 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 li>
- 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 li>
- 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 li> ul> li>
-
p> simple deployment
- configuration center as a basic service, availability requirements is very high, which requires the Apollo external dependence as far as possible little li>
- the only external dependence is MySQL, so deployment is very simple, as long as the installed Java and MySQL can make Apollo run li>
- Apollo also provides packaging script, a key can generate all the necessary installation package, and supports custom runtime parameters li> ul> li> ul>
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 -
application gets the latest configuration and subscription configuration update notification from the Apollo client
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
0
Read More:
- Zuul gateway routing URL and service ID configuration
- Solve the java.net.connectexception: connection rejected: connect error
- mysql configuration supports SSL connection
- Problems in learning Aidl
- Nginx front end and back end separation + service cluster reverse proxy
- Eureka server startup error: cannot execute request on any known server
- [Solved] nested exception is com.alibaba.dubbo.rpc.RpcException: Failed t o invoke the method findPage
- Common errors reported by Eureka in spring cloud
- Several ways to view spark task log
- Simple understanding and basic operation of mongodb
- After Nacos started, the client worker log was printed all the time
- Eureka failed to register error: saw local status change event statuschangeevent
- The local program cannot access the test environment redis cluster through public IP_ compromise
- Synergy 1.4.12 “ipc connection error, connection refused” and other issues
- Docker starts the image and reports an error. Iptables failed: iptables — wait – t NAT – a docker – P TCP
- [Solved] Error in registering Eureka for spring cloud micro service: classnotfoundexception: org.apache.http.conn.scheme.schemeregistry
- After introducing security, the service cannot be registered with Eureka
- BO error Error: RWI 00200 FWM 01014
- JDBC connect to Sql Server to connect to the database–The TCP/IP connection to the host localhost, port 1433 has failed
- CHECK_NRPE: Error – Could not complete SSL handshake.