学习Apollo服务配置中心，与SpringBoot整合
通过spring-boot搭建的业务系统，可以通过Apollo提供远程的配置服务，以达到集群环境统一使用一套动态配置的目的。
1.关于NameSpace
1.1 namespace的使用场景
提供一份全公司默认的配置且可动态调整
RPC客户端项目可以自定义某些配置项且可动态调整
1.2 apollo的注解在java中配置
@EnableApolloConfig要和@Configuration一起使用。
想把日志配置也放阿波罗里，那么要把阿波罗的加载顺序提前，但是如此一来，阿波罗的启动就没日志了。
2. 注解
- 1.@ApolloConfig 自动注入Apollo对象
- 2.@ApolloConfigChangeListener 自动注册ConfigChangeListener事件
- 3.@ApolloJsonValue 转换配置的json字符串
3. 使用实践
3.1 单元测试
- 1.单元测试的时候用的是mockdata+{namespace}.properties
- 2.引用mockServer包进行环境模拟
3.2 实际连接Apollo环境
- 1.实际使用要连接Apollo的ConfigService，AdminService以及Portal
- 2.通过客户端API连接时：
- （1）在文件src/main/resources/META-INF/app.properties配置app.id=应用系统标识
例如： app.id=sales-platform - （2）在文件src/main/resources/META-INF/app.properties配置env=dev、fat、uat、pro等标识
例如： env=dev - （3）在文件src/main/resources/META-INF/apollo-env.properties配置
例如： dev.meta=http://apollo.dev.xxx.com fat.meta=http://apollo.fat.xxx.com uat.meta=http://apollo.uat.xxx.com pro.meta=http://apollo.xxx.com - （4）配置apollo.meta=http://config-service-url (这个地方还可以配置好之后，封装一个jar包，使用的时候引用即可)
-
（5）启动Apollo服务，需要mysql以及三个服务。
d:\baiduYun\Program_Files\mysql-advanced-5.6.25-winx64\startMySql.bat sh /c/Users/tf/app/apollo-configservice-1.2.0-github/scripts/startup.sh sh /c/Users/tf/app/apollo-adminservice-1.2.0-github/scripts/startup.sh sh /c/Users/tf/app/apollo-portal-1.2.0-github/scripts/startup.sh
4. 与Eureka和zookeeper的联系区别
能无缝的与SpringCloud、SpringBoot整合，Eureka还支持在我们应用中启动，降低了部署复杂度。
Zk不易与docker集成。
交互API通过Apollo客户端，配置用管理端。
ConfigService和AdminService都需要注册到Eureka上来保持心跳。
在Eureka之上架设了一层MetaServer用来管理元数据？不是，用来封装Eureka的服务发现接口，就是又套了一层。
Client通过MetaServer获得ConfigService服务配置。Portal通过MetaServer获得AdminService服务配置。
Config、Admin、Eureka同时部署在一个JVM中。
Eureka两大职能，Registry与Discovery。
5.存在疑惑
- （1）SpringBoot引用Apollo客户端，不是每次发布都能有效，偶尔也需要重启，这个是为什么？
- （2）apollo-env.properties好像没什么用但又有用，app.properties的env=dev确实没用，但是要怎么配置运行环境，这个待成功验证。
- （3）namespace暂时不支持与SpringBoot整合，这个要怎么结合？
- （4）cluster的概念还有些模糊，而且还没配置，陆续还需要迭代一两个版本加深理解。
6.题外话
提一句CAP理论，Consistency一致性、Availability可用性、Partition-tolerance分区可容忍性。BASE理论Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的缩写。BASE是对CAP中一致性和可用性权衡的结果。
写实时性要求高与读实时性要求不高的场景，所以允许最终一致性。
最终一致性是弱一致性的一个特例，是大型分布式系统推崇的一种模型。
分布式网络中的各种问题，成功、失败、超时三态。超时的原因有可能是节点故障，也有可能是网络原因。
由于这些不确定，所以，引进分布式事务概念。从单机ACID概念，原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability)，变为两段式提交，两阶段提交属于牺牲了一部分可用性来换取一致性。
题外话
| 侧重 | 说明 |
|---|---|
| CA | 放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择 |
| AP | 放弃强一致性，追求分区容错性和可用性，这是很多分布式系统设计时的选择，例如很多NoSQL系统就是如此 |
| CP | 基本不会选择，放弃可用性，追求一致性和分区容错性，网络问题会直接让整个系统不可用 |
来源：51CTO
作者：猎豹齐可
链接：https://blog.51cto.com/7680741/2347115