Apollo配置中心的安装_apollo配置中心使用

1.k8s cronjob 启动顺序

2.微服务注册中心Consul转Nacos实践

3.开发阿波罗有python版本么

在服务器与客户端进行信息传输的时候，是客户端从服务器拉去消息，还是服务器往客户端推送消息，这是在设计一个需要网络通讯系统需要考虑的问题。

本文将介绍推与拉这两种交互方式的优缺点，和一些案例经典的框架是如何选择推和拉的形式的。

推和拉都有各自的优缺点，先说推、拉的实现。推一般情况下是服务端与客户端维护了长连接，服务端使用这个长连接进行的消息推送。而拉则是客户端采用轮询的方式定期查看服务端是否有消息变更，如果有就拉去下来。

这就是简单的推和拉的实现，他们的优缺点也比较明显。推的优势在于实时性很高，当服务端发送信息变更之后由服务端主动推送这样的实时性是非常高的。而缺点在于消息都是由服务端主动推送，当服务端很频繁的推送消息的时候，由于客户端的处理速度是不同的，由服务端去推送消息目的是为了让信息及时发送给客户端提高客户端的消费速率，但是当客户端的处理速度低于服务端的推送速度，客户端往往会不堪重负。

而拉的优点在于，由客户端按照自身的处理情况按照一定的周期去服务器拉去信息，这样就不会出现服务端压客户端的情况。但是拉的形式有一个问题是你拉去的周期是多少？周期太长，服务端与客户端的消息延迟最坏情况就是一个周期，周期太短，当服务端没有信息的时候会导致长期的空轮训。基于这个问题我们可以采用长轮询去解决，客户端会一直阻塞直到服务端有数据才返回。

上面介绍了推和拉的实现和各自的优缺点，这里将列举一些经典框架，看它们是如何选择的，这样也会加深对推和拉的认识。

kafak作为消息队列，采用的是生产者往broker推消息，消费者往broker拉消息。为什么消费者采用的是拉的形式？上面分析过，如果采用推的形式，各个消费者的消费速率是不同的很可能将客户端压垮。而且采用推在消息系统中还有另外一个不好的点，因为kafak为了提高吞吐量，消息都是批量发送和批量消费，当服务端不知道下游的消费速率的时候，将系统调整为低延迟状态，这就会导致一次只发送一条消息，以至于传输的数据不再被缓冲，这种方式是极度浪费的。 因为 消费者 总是将所有可用的（或者达到配置的最大长度）消息 pull 到 log 当前位置的后面，从而使得数据能够得到最佳的处理而不会引入不必要的延迟。

apollo作为配置中心，当我们更改了配置之后，服务端能够及时的将变动通知给客户端，apollo采用的就是拉的形式，下面是apollo客户端获取变更的步骤：

不同于传统的pull，apollo采用的是 long pull，简单来说传统的pull当服务端没有消息的时候会立即返回，而long pull在服务端没有变动的时候会将请求挂起，直到有数据或者请求超时才返回请求。这有点类似于jdk中的阻塞队列 BlockingQueue 调用poll方法会一直阻塞当前线程直到有数据返回，只不过这个是跨进程的。

配置中心对于变更的实时性要求不是很高，所以apollo采用了拉的形式，而且为了避免客户端的空轮训采用长轮询的方式。

zookeeper作为分布式协调框架，提供丰富的功能，其中一个就是watcher机制。Watcher是zookeeper中很重要的功能。客户端通过对znode创建watcher当节点发生变化的时候(节点删除、数据更改、子节点变化等)，ZooKeeper将会通知注册Watcher的客户端节点已经变更。

zookeeper实现watcher采用的是推和拉结合的方式，节点的变化是需要实时通知的所以采用推的模式，但是zookeeper这里推送的信息只是节点的变化事情，告诉客户端这个节点发生了变动，而非推送这次变动的信息。具体的变动信息是客户端按照自己的需要去从服务端拉去变动的信息。采用这样方式每次变动只需要传输少量数据，减少变动通知的IO传输。

经过分析了kafka、apollo、zookeeper三个案例之后，发现推和拉并没有什么绝对的使用场景，还是需要在自己特定的创建选择合适的方法，必要时候两个也可以同时存在，适合自己才是最好的。

k8s cronjob 启动顺序

Nacos是以服务为主要服务对象的中间件，Nacos支持所有主流的服务发现、配置和管理。

Nacos主要提供以下四大功能：

Nacos支持加权路由，使您可以更轻松地在数据中心的生产环境中实施中间层负载平衡，灵活的路由策略，流量控制和简单的DNS解析服务。它可以帮助您轻松实现基于DNS的服务发现，并防止应用程序耦合到特定于供应商的服务发现API。

Nacos提供易于使用的服务仪表板，可帮助您管理服务元数据，配置，kubernetes DNS，服务运行状况和指标统计。

nacos具有Apollo大部分功能，最重要的是配置中心与注册中心打通，可以省去我们在微服务治理方面 的一些投入（比如通过动态配置来启停线程池等操作）。

初步结论为：使用Nacos代替Eureka和apollo，主要理由为：

相比与Eureka：

(1)Nacos具备服务优雅上下线和流量管理（API+后台管理页面），而Eureka的后台页面仅供展示，需要使用api操作上下线且不具备流量管理功能。

(2)从部署来看，Nacos整合了注册中心、配置中心功能，把原来两套集群整合成一套，简化了部署维护

(3)从长远来看，Eureka开源工作已停止，后续不再有更新和维护，而Nacos在以后的版本会支持SpringCLoud+Kubernetes的组合，填补 2 者的鸿沟，在两套体系下可以采用同一套服务发现和配置管理的解决方案，这将大大的简化使用和维护的成本。同时来说,Nacos 计划实现 Service Mesh，是未来微服务的趋势

(4)从伸缩性和扩展性来看Nacos支持跨注册中心同步，而Eureka不支持，且在伸缩扩容方面，Nacos比Eureka更优（nacos支持大数量级的集群）。

(5)Nacos具有分组隔离功能，一套Nacos集群可以支撑多项目、多环境。

相比于apollo

(1) Nacos部署简化，Nacos整合了注册中心、配置中心功能，且部署相比apollo简单，方便管理和监控。

(2) apollo容器化较困难，Nacos有官网的镜像可以直接部署，总体来说，Nacos比apollo更符合KISS原则

(3)性能方面，Nacos读写tps比apollo稍强一些

结论：使用Nacos代替Eureka和apollo

系统模块架构

Nacos提供DNS-F功能

DNS-F落地的技术价值

阿里巴巴、虎牙直播、中国工商银行、爱奇艺、中国平安、平安科技、浙江农信、贝壳、丰巢、百世快递、汽车之家等

完整列表：

微服务注册中心Consul转Nacos实践

k8s cronjob 启动顺序如下：

在K8S部署中，有时候容器启动顺序因为我们业务需要是有要求的，比如业务服务可能需要在 配置中心、注册的中心 启动后才启动。

通过 initContainer 来阻塞启动，如下以业务服务需要在apollo配置中心启动后才启动需求为例：

my-namespace为配置中心所在命名空间的名称。svc.cluster.local为固定写法。6166为我的配置中心的端口号。

/info为配置中心启动后可以正常访问的一个URL地址，这个根据你自己实际需求填写，比如 /actuator/metrics 等等。

开发阿波罗有python版本么

先说下为什么要从Consul 换到Nacos？

当然最主要的原因是需要使用Nacos的配置和管理微服务的能力，配置中心之前用过携程开源的Apollo，个人感觉环境搭建起来比较复杂。

下面开始：

具体可以看下 这个是Nacos的官方文档网址，里面有Nacos功能的详细介绍和集成教程。

3.修改项目原来的配置文件 ，将原来的application.yml 改成 bootstrap.yml配置内容大致如下

common.yaml 内容如下

到这里改造就基本完成了，如有问题可以在评论区讨论。

有。Apollo（阿波罗）是携程框架部门研发的开源配置管理中心，能够集中化管理应用不同的配置，修改后能够实时推送到应用端，根据查询结果显示，apollo的官方开发文档中显示是有python的客户端接入方式的，用户可以自行阅读。