Skip to content

Commit 9e63c80

Browse files
klc407073648klc407073648
committed
apollo,cat,consul,kong,logstash 中间件md笔记合入
1 parent b664f14 commit 9e63c80

31 files changed

Lines changed: 2679 additions & 1 deletion

‎md/micro-services/middleware/apollo/apollo-basic.md‎

Lines changed: 181 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,181 @@
1+
2+
3+
# Apollo - 简介
4+
5+
[[toc]]
6+
7+
# 内容
8+
9+
![Apollo](/_images/micro-services/middleware/apollo/Apollo.png)
10+
11+
**Apollo - A reliable configuration management system**
12+
13+
https://github.com/ctripcorp/apollo
14+
15+
Apollo（阿波罗）是携程框架部门研发的分布式配置中心，<font color='red'>能够集中化管理应用的不同环境、不同集群的配置，配置修改后能够实时推送到应用端</font>，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
16+
17+
Apollo包括服务端和客户端两部分：
18+
19+
服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。
20+
21+
Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。
22+
23+
## 什么是配置
24+
25+
**既然Apollo定位于配置中心，那么在这里有必要先简单介绍一下什么是配置。**
26+
27+
应用程序在<font color='red'>启动和运行的时候往往需要读取一些配置信息</font>，配置基本上伴随着应用程序的整个生命周期，比如：数据库连接参数、启动参数等。
28+
29+
配置主要有以下几个特点：
30+
31+
- **配置是独立于程序的只读变量**
32+
- 配置首先是独立于程序的，同一份程序在不同的配置下会有不同的行为；
33+
- 其次，配置对于程序是只读的，程序通过读取配置来改变自己的行为，但是程序不应该去改变配置；
34+
- 常见的配置有：DB Connection Str、Thread Pool Size、Buffer Size、Request Timeout、Feature Switch、Server Urls等。
35+
- **配置伴随应用的整个生命周期**
36+
- 配置贯穿于应用的整个生命周期，应用在启动时通过读取配置来初始化，在运行时根据配置调整行为。比如：启动时需要读取服务的端口号、系统在运行过程中需要读取定时策略执行定时任务等。
37+
- **配置可以有多种加载方式**
38+
- 常见的有程序<font color='red'>内部硬编码，配置文件，环境变量，启动参数，基于数据库</font>等
39+
- **配置需要治理**
40+
- 权限控制
41+
- 由于配置能改变程序的行为，不正确的配置甚至能引起灾难，所以对配置的修改必须有比较完善的权限控制
42+
- 不同环境、集群配置管理：
43+
- <font color='red'>同一份程序在不同的环境（开发，测试，生产）、不同的集群（如不同的数据中心）经常需要有不同的配置</font>，所以需要有完善的环境、集群配置管理
44+
- 框架类组件配置管理
45+
- 还有一类比较特殊的配置 - 框架类组件配置，比如CAT客户端的配置。
46+
- 虽然这类框架类组件是由其他团队开发、维护，但是运行时是在业务实际应用内的，所以本质上可以认为框架类组件也是应用的一部分。
47+
- 这类组件对应的配置也需要有比较完善的管理方式。
48+
49+
## 什么是配置中心
50+
51+
传统单体应用存在一些潜在缺陷：
52+
53+
* 随着规模的扩大，部署效率降低，团队协作效率差，系统可靠性变差，维护困难，新功能上线周期长等。
54+
55+
56+
因此，迫切需要一种新的架构去解决这些问题，而微服务（ microservices ）架构正是当下一种流行的解法。
57+
58+
* 不过，解决一个问题的同时，往往会诞生出很多新的问题，所以微服务化的过程中伴随着很多的挑战，其中一个挑战就是有关服务（应用）配置的。
59+
* 当系统从一个单体应用，<font color='red'>被拆分成分布式系统上一个个服务节点后，配置文件也必须跟着迁移（分割），这样配置就分散了，不仅如此，分散中还包含着冗余</font>，如下图：
60+
61+
![配置文件冗余](/_images/micro-services/middleware/apollo/配置文件冗余.png)
62+
63+
配置中心<font color='red'>将配置从应用中剥离出来，统一管理，优雅的解决了配置的动态变更、持久化、运维成本等问题</font>。
64+
65+
* 应用自身既不需要去添加管理配置接口，也不需要自己去实现配置的持久化，更不需要引入“定时任务”以便降低运维成本。
66+
* 总得来说，配置中心就是一种统一管理各种应用配置的基础服务组件。
67+
68+
在系统架构中，配置中心是整个微服务基础架构体系中的一个组件，如下图，它的功能看上去并不起眼，无非就是配置的管理和存取，但它是整个微服务架构中不可或缺的一环。
69+
70+
![配置中心](/_images/micro-services/middleware/apollo/配置中心.png)
71+
72+
集中管理配置，那么就要将应用的配置作为一个单独的服务抽离出来了，同理也需要解决新的问题，比如：版本管理（为了支持回滚），权限管理等。
73+
74+
总结一下，在传统巨型单体应用纷纷转向细粒度微服务架构的历史进程中，配置中心是微服务化不可缺少的一个系统组件，在这种背景下中心化的配置服务即配置中心应运而生，一个合格的配置中心需要满足：
75+
76+
- 配置项容易读取和修改
77+
- 添加新配置简单直接
78+
- 支持对配置的修改的检视以把控风险
79+
- 可以查看配置修改的历史记录
80+
- 不同部署环境支持隔离
81+
82+
## 主流配置中心
83+
84+
目前市面上用的比较多的配置中心有：
85+
86+
1. [Disconf](https://github.com/knightliao/disconf)
87+
88+
2014年7月百度开源的配置管理中心，专注于各种「分布式系统配置管理」的「通用组件」和「通用平台」, 提供统一的「配置管理服务」。目前已经不再维护更新。
89+
90+
2. [Spring Cloud Config](https://github.com/spring-cloud/spring-cloud-config)
91+
92+
2014年9月开源，Spring Cloud 生态组件，可以和Spring Cloud体系无缝整合。
93+
94+
3. [Apollo](https://github.com/ctripcorp/apollo)
95+
96+
2016年5月，携程开源的配置管理中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。
97+
98+
4. [Nacos](https://github.com/alibaba/nacos)
99+
100+
2018年6月，阿里开源的配置中心，也可以做DNS和RPC的服务发现。
101+
102+
## 功能特性对比
103+
104+
由于Disconf不再维护，下面主要对比一下Spring Cloud Config、Apollo和Nacos。
105+
106+
| 功能点 | Spring Cloud Config | Apollo | Nacos |
107+
| :----------- | :--------------------- | :----------------------- | :----------------------- |
108+
| 配置实时推送 | 支持(Spring Cloud Bus) | 支持(HTTP长轮询1s内) | 支持(HTTP长轮询1s内) |
109+
| 版本管理 | 支持(Git) | 支持 | 支持 |
110+
| 配置回滚 | 支持(Git) | 支持 | 支持 |
111+
| 灰度发布 | 支持 | 支持 | 不支持 |
112+
| 权限管理 | 支持(依赖Git) | 支持 | 不支持 |
113+
| 多集群 | 支持 | 支持 | 支持 |
114+
| 多环境 | 支持 | 支持 | 支持 |
115+
| 监听查询 | 支持 | 支持 | 支持 |
116+
| 多语言 | 只支持Java | 主流语言，提供了Open API | 主流语言，提供了Open API |
117+
| 配置格式校验 | 不支持 | 支持 | 支持 |
118+
| 单机读(QPS) | 7(限流所致) | 9000 | 15000 |
119+
| 单击写(QPS) | 5(限流所致) | 1100 | 1800 |
120+
| 3节点读(QPS) | 21(限流所致) | 27000 | 45000 |
121+
| 3节点写(QPS) | 5限流所致() | 3300 | 5600 |
122+
123+
## Apollo特性
124+
125+
Apollo作为一个有治理能力的配置发布平台，目前提供了以下的特性：
126+
127+
- **统一管理不同环境、不同集群的配置**
128+
- Apollo提供了一个统一界面集中式管理<font color='red'>不同环境（environment）、不同集群（cluster）、不同命名空间（namespace）的配置</font>。
129+
- 同一份代码部署在不同的集群，可以有不同的配置，比如zookeeper的地址等
130+
- 通过<font color='red'>命名空间（namespace）可以很方便地支持多个不同应用共享同一份配置，同时还允许应用对共享的配置进行覆盖</font>
131+
- **配置修改实时生效（热发布）**
132+
- 用户在Apollo修改完配置并发布后，客户端能实时（1秒）接收到最新的配置，并通知到应用程序
133+
- **版本发布管理**
134+
- 所有的配置发布都有版本概念，从而可以方便地支持配置的回滚
135+
- **灰度发布**
136+
- 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观察一段时间没问题后再推给所有应用实例
137+
- **权限管理、发布审核、操作审计**
138+
- 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了<font color='red'>编辑和发布</font>两个环节，从而减少人为的错误。
139+
- 所有的操作都有审计日志，可以方便地追踪问题
140+
- **客户端配置信息监控**
141+
- 可以在界面上方便地看到配置在被哪些实例使用
142+
- **提供Java和.Net原生客户端**
143+
- 提供了Java和.Net的原生客户端，方便应用集成
144+
- 支持Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，方便应用使用（需要Spring 3.1.1+）
145+
- 同时提供了Http接口，非Java和.Net应用也可以方便地使用
146+
- **提供开放平台API**
147+
- Apollo自身提供了比较完善的统一配置管理界面，支持多环境、多数据中心配置管理、权限、流程治理等特性。不过Apollo出于通用性考虑，不会对配置的修改做过多限制，只要符合基本的格式就能保存，不会针对不同的配置值进行针对性的校验，如数据库用户名、密码，Redis服务地址等
148+
- 对于这类应用配置，Apollo支持应用方通过开放平台API在Apollo进行配置的修改和发布，并且具备完善的授权和权限控制
149+
- **部署简单**
150+
- 配置中心作为基础服务，可用性要求非常高，这就要求Apollo对外部依赖尽可能地少
151+
- 目前唯一的外部依赖是MySQL，所以部署非常简单，只要安装好Java和MySQL就可以让Apollo跑起来
152+
- Apollo还提供了打包脚本，一键就可以生成所有需要的安装包，并且支持自定义运行时参数
153+
154+
## 核心概念
155+
156+
1. application (应用)
157+
158+
* 实际使用配置的应用，Apollo客户端在运行时需要知道当前应用是谁，从而可以去获取对应的配置。
159+
160+
* 关键字：appId
161+
162+
2. environment (环境)
163+
164+
* 配置对应的环境，Apollo客户端在运行时需要知道当前应用处于哪个环境，从而可以去获取应用的配置
165+
* 关键字：env
166+
167+
3. cluster (集群)
168+
169+
* 一个应用下不同实例的分组，比如典型的可以按照数据中心分，把上海机房的应用实例分为一个集群，把北京机房的应用实例分为另一个集群。
170+
171+
* 关键字：cluster
172+
173+
4. namespace (命名空间)
174+
175+
* 一个应用下不同配置的分组，可以简单地把namespace类比为文件，不同类型的配置存放在不同的文件中，如数据库配置文件，RPC配置文件，应用自身的配置文件等
176+
177+
* 关键字：namespaces
178+
179+
它们的关系如下图所示：
180+
181+
![关系图](/_images/micro-services/middleware/apollo/关系图.png)

‎md/micro-services/middleware/apollo/apollo-design.md‎

Lines changed: 131 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,131 @@
1+
2+
3+
# Apollo - 设计
4+
5+
[[toc]]
6+
7+
# 总体设计
8+
9+
如下即是Apollo的基础模型：
10+
11+
1. 用户在配置中心对配置进行修改并发布
12+
13+
2. 配置中心通知Apollo客户端有配置更新
14+
15+
3. Apollo客户端从配置中心拉取最新的配置、更新本地配置并通知到应用
16+
17+
![basic-architecture](/_images/micro-services/middleware/apollo/basic-architecture.png)
18+
19+
## Apollo工作原理
20+
21+
下图是Apollo架构模块的概览
22+
23+
![架构图](/_images/micro-services/middleware/apollo/架构图.png)
24+
25+
上图简要描述了Apollo的总体设计，我们可以从下往上看：
26+
27+
* Config Service提供配置的读取、推送等功能，服务对象是Apollo客户端
28+
29+
* Admin Service提供配置的修改、发布等功能，服务对象是Apollo Portal（管理界面）
30+
31+
* Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
32+
33+
* 在Eureka之上我们架了一层Meta Server用于封装Eureka的服务发现接口
34+
35+
* Client通过域名访问Meta Server获取Config Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Client侧会做load balance、错误重试
36+
37+
* Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port），而后直接通过IP+Port访问服务，同时在Portal侧会做load balance、错误重试
38+
39+
* 为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中
40+
41+
## 各模块概要介绍
42+
43+
### Config Service
44+
45+
* 提供配置的读取、推送等功能
46+
* 服务于Apollo客户端
47+
48+
### Admin Service
49+
50+
* 提供配置的修改、发布等功能
51+
* 服务于Apollo Portal（管理界面）
52+
53+
### Client
54+
55+
* 为应用获取配置，支持实时更新
56+
* 通过Meta Server获取Config Service的服务列表
57+
* 使用客户端软负载SLB方式调用Config Service
58+
59+
### Portal
60+
61+
* 配置管理界面
62+
通过Meta Server获取Admin Service的服务列表
63+
* 使用客户端软负载SLB方式调用AdminService
64+
65+
### Eureka
66+
67+
* 用于服务发现和注册
68+
* Config Service和Admin Service都是多实例、无状态部署，所以需要将自己注册到Eureka中并保持心跳
69+
* 与Config Service住在一起部署
70+
71+
### Meta Server
72+
73+
* Client通过域名访问Meta Server获取Config Service服务列表（IP+Port）
74+
* Portal通过域名访问Meta Server获取Admin Service服务列表（IP+Port）
75+
* 在Eureka之上架了一层Meta Server用于封装Eureka的服务发现接口，Meta Server相当于一个Eureka Proxy
76+
* 与Config Service住在一起部署
77+
78+
### NginxLB
79+
80+
* 通过与域名系统配合，完成以下功能
81+
* 协助Portal访问MetaServer获取Admin Service服务列表
82+
* 协助Client访问MetaServer获取Config Service服务列表
83+
* 协助用户访问Portal进行配置管理
84+
85+
## 分步执行流程
86+
87+
1. Apollo启动后，Config/Admin Service会自动注册到Eureka服务注册中心，并定期发送保活心跳；
88+
2. Apollo Client和Portal管理端通过配置的Meta Server的域名地址经由Software Load Balancer(软件负载均衡器)进行负载均衡后分配到某一个Meta Server；
89+
3. Meta Server从Eureka获取Config Service和Admin Service的服务信息，相当于是一个Eureka Client；
90+
4. Meta Server获取Config Service和Admin Service（IP+Port）失败后会进行重试；
91+
5. 获取到正确的Config Service和Admin Service的服务信息后，Apollo Client通过Config Service为应用提供配置获取、实时更新等功能；Apollo Portal管理端通过Admin Service提供配置新增、修改、发布等功能。
92+
93+
# 服务端设计
94+
95+
在配置中心中，一个重要的功能就是配置发布后实时推送到客户端。下面我们简要看一下这块是怎么设计实现的。
96+
97+
![release-message-notification-design](/_images/micro-services/middleware/apollo/release-message-notification-design.png)
98+
99+
上图简要描述了配置发布的大致过程：
100+
101+
1. 用户在Portal操作配置发布
102+
103+
2. Portal调用Admin Service的接口操作发布
104+
105+
3. Admin Service发布配置后，发送ReleaseMessage给各个Config Service
106+
107+
4. Config Service收到ReleaseMessage后，通知对应的客户端
108+
109+
# 客户端设计
110+
111+
![client-architecture](/_images/micro-services/middleware/apollo/client-architecture.png)
112+
113+
上图简要描述了Apollo客户端的实现原理：
114+
115+
1. 客户端和服务端保持了一个长连接，从而能第一时间获得配置更新的推送。（通过Http Long Polling实现）
116+
117+
2. 客户端还会定时从Apollo配置中心服务端拉取应用的最新配置。
118+
119+
* 这是一个fallback机制，为了防止推送机制失效导致配置不更新
120+
121+
* 客户端定时拉取会上报本地版本，所以一般情况下，对于定时拉取的操作，服务端都会返回304 - Not Modified
122+
123+
* 定时频率默认为每5分钟拉取一次，客户端也可以通过在运行时指定System Property: `apollo.refreshInterval`来覆盖，单位为分钟。
124+
125+
3. 客户端从Apollo配置中心服务端获取到应用的最新配置后，会保存在内存中
126+
127+
4. 客户端会把从服务端获取到的配置在本地文件系统缓存一份
128+
129+
* 在遇到服务不可用，或网络不通的时候，依然能从本地恢复配置
130+
131+
5. 应用程序可以从Apollo客户端获取最新的配置、订阅配置更新通知

0 commit comments

Comments
 (0)