微服务实战架构：Apollo学习笔记

最新推荐文章于 2023-09-15 09:47:26 发布

Vigoss1996

最新推荐文章于 2023-09-15 09:47:26 发布

阅读量563

点赞数

分类专栏：学习笔记文章标签： java 后端微服务架构

本文链接：https://blog.csdn.net/weixin_46019495/article/details/107137343

版权

学习笔记专栏收录该内容

19 篇文章 0 订阅

订阅专栏

Apollo工作原理架构图：
在这里插入图片描述
最核心的四部分（每部分基本都是集群）：Client、Portal、ConfigService、AdminService。其中Portal、ConfigService、AdminService是apollo启动服务时启动的进程，如果有多个环境，则启动一个Portal进程，启动多个ConfigService、AdminService进程。
其中Portal是配置管理页面，当配置文件进行修改之后，通过AdminService将修改后的文件写入数据库。ConfigService把数据库更新的配置文件推送给Client客户端。

Portal通过软负载（SLB）的方式调用AdminService。
Client也通过软负载（SLB）的方式调用ConfigService。

Eureka是服务注册发现，通过心跳机制判断服务是否存活。由于服务实例的网络地址是动态分配的，而且，由于自动扩展，失败和更新，服务实例的配置也经常变化，所以需要服务发现机制（通过服务别名调用服务，当网络IP地址变更后，不需要服务调用端更改IP地址）。
Apollo的作者也考虑到开源到社区以后，很多客户应用是非Java的。但是Eureka(包括Ribbon软负载)原生仅支持Java客户端，如果要为多语言开发Eureka/Ribbon客户端，这个工作量很大也不可控。为此，Apollo的作者引入了MetaServer这个角色，它其实是一个Eureka的Proxy，将Eureka的服务发现接口以更简单明确的HTTP接口的形式暴露出来，方便Client/Protal通过简单的HTTPClient就可以查询到Config/AdminService的地址列表。获取到服务实例地址列表之后，再以简单的客户端软负载(Client SLB)策略路由定位到目标实例，并发起调用。
Software load balancer：携程采用的是扩展后的NginxLB（也称Software Load Balancer），由运维为MetaServer集群配置一个域名，指向NginxLB集群，NginxLB再对MetaServer进行负载均衡和流量转发。 Client/Portal通过域名+NginxLB间接访问MetaServer集群。

Apollo中由大到小的概念：application (应用、项目) environment (环境：开发、测试、生产) cluster (集群，每个环境中多个集群) namespace (命名空间，每个集群中有多个命名空间，同一命名空间可被多个应用共享)

读取Apollo配置文件信息：
启动类添加启动参数：
-Dapp.id=应用名称（项目名称） -Denv=环境名称
-Dapollo.cluster=集群名称 -D环境_meta=meta地址
在这里插入图片描述

Config appConfig = ConfigService.getAppConfig();//读取默认namespace下的配置信息
Config appConfig = ConfigService.getConfig("micro_service");//读取指定namespace下的配置信息
String value = appConfig.getProperty("keyName",null);//获取配置文件中指定key的值
System.out.printf(value);

添加新的环境。比如原本只有dev环境，添加pro生产环境：选择系统配置，key=apollo.portal.envs
在这里插入图片描述

配置发布的主要过程：
在这里插入图片描述 Admin Service向Config Service发送ReleaseMessage，通知其配置文件进行了修改，这一步过程可以通过MQ消息队列来实现。Apollo为了不使用第三方软件，减少外部依赖，所以没有采用外部的消息中间件，而是通过数据库实现了一个简单的消息队列。具体实现方式如下：

Admin Service在配置发布后会往ReleaseMessage表插入一条消息记录，内容就是配置发布的AppId+Cluster+Namespace。
Config Service有一个线程会每秒扫描一次ReleaseMessage表，看看是否有新的消息记录。消息扫描类：ReleaseMessageScanner。
Config Service如果发现有新的消息记录，那么就会通知到所有的消息监听器。然后调用消息监听类的handleMessage方法：
NotificationControllerV2。
NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，会通知对应的客户端。

NotificationControllerV2得到配置发布的AppId+Cluster+Namespace后，如何通知对应的客户端？

客户端会发起一个http请求（长连接）到ConfigService的notifications/v2接口NotificationControllerV2。
NotificationControllerV2不会立即返回结果，而是把请求挂起。考虑到会有数万客户端向服务端发起长连接请求，因此在服务端使用了asyncservlet（Spring DeferredResult）来服务Http Long Polling请求。
如果在60秒内没有该客户端关心的配置发布，那么会返回Http状态码403给客户端。
如果有该客户端关心的配置发布，NotificationControllerV2会调用DeferredResult的setResult方法，传入有配置变化的namespace信息，同时该请求会立刻返回，客户端从返回的结果中获取到配置变化的namespace后，会立即请求Config
Service获取该namespace的最新配置。
为防止长连接中断，客户端还会定时从服务端拉取最新配置，这是备用机制，定时频率为5分钟一次。

使用Apollo的好处（Apollo的特性）：

统一管理不同环境、不同集群的配置
- Apollo提供了一个统一界面集中式管理不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置。
- 同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
- 通过命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖
配置修改实时生效（热发布）
- 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序
版本发布管理
- 所有的配置发布都有版本概念，从而可以方便地支持配置的回滚
灰度发布
- 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例
权限管理、发布审核、操作审计
- 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而减少人为的错误。
- 所有的操作都有审计日志，可以方便地追踪问题
客户端配置信息监控
- 可以在界面上方便地看到配置在被哪些实例使用
提供Java和.Net原生客户端
- 提供了Java和.Net的原生客户端，方便应用集成
- 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
- 同时提供了Http接口，非Java和.Net应用也可以方便地使用
提供开放平台API
- Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等
- 对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制
部署简单
- 配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
- 目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来
- Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数

为什么我们采用Eureka作为服务注册中心，而不是使用传统的zk、etcd呢？有以下几方面的原因：

它提供了完整的Service Registry和Service Discovery实现
- 首先是提供了完整的实现，并且也经受住了Netflix自己的生产环境考验，相对使用起来会比较省心。
和Spring Cloud无缝集成我们的项目本身就使用了Spring Cloud和Spring Boot，同时Spring
- Cloud还有一套非常完善的开源代码来整合Eureka，所以使用起来非常方便。
- 另外，Eureka还支持在我们应用自身的容器中启动，也就是说我们的应用启动完之后，既充当了Eureka的角色，同时也是服务的提供者。这样就极大的提高了服务的可用性。
- 这一点是我们选择Eureka而不是zk、etcd等的主要原因，为了提高配置中心的可用性和降低部署复杂度，我们需要尽可能地减少外部依赖。

apollo配置中心介绍git网址：https://github.com/ctripcorp/apollo/wiki/Apollo配置中心介绍

Vigoss1996

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
微服务实战架构：Apollo学习笔记

Apollo工作原理架构图：最核心的四部分（每部分基本都是集群）：Client、Portal、ConfigService、AdminService。其中Portal、ConfigService、AdminService是apollo启动服务时启动的进程，如果有多个环境，则启动一个Portal进程，启动多个ConfigService、AdminService进程。其中Portal是配置管理页面，当配置文件进行修改之后，通过AdminService将修改后的文件写入数据库。ConfigService把数据
复制链接

扫一扫