Skip to content

Latest commit

 

History

History
107 lines (73 loc) · 5.85 KB

configuration.md

File metadata and controls

107 lines (73 loc) · 5.85 KB
Raw

配置管理

BFE配置文件的分布

配置文件都位于/conf目录下。为便于维护, 配置文件按功能分类存放在相应目录。

  • BFE主逻辑的主要配置文件如下：
功能类别 配置文件目录位置 配置文件 说明
服务基础配置 /conf/ bfe.conf 包括BFE的服务基础配置，如：服务端口、缺省超时配置、扩展模块加载等；还包括TLS的基础配置，如：HTTPS的加密套件，Session Cache的配置等。
接入协议配置 /conf/tls_conf/ server_cert_conf.data 服务端的证书和密钥配置。
接入协议配置 /conf/tls_conf/ session_ticket_key.data TLS Session Ticket Key配置。
接入协议配置 /conf/tls_conf/ tls_rule_conf.data 按照租户粒度区分的TLS协议参数。
流量路由配置 /conf/server_data_conf/ vip_rule.data 各租户的VIP列表。
流量路由配置 /conf/server_data_conf/ host_rule.data 各租户的域名列表。
流量路由配置 /conf/server_data_conf/ route_rule.data 各租户的分流转发规则信息。
流量路由配置 /conf/server_data_conf/ cluster_conf.data 各集群的转发配置，包括集群基础配置、GSLB基础配置、健康检查配置、后端基础配置等。
流量路由配置 /conf/server_data_conf/ name_conf.data 服务名字和服务实例的映射关系。
负载均衡配置 /conf/cluster_conf/ cluster_table.data 各后端集群包含的子集群，及各子集群中包含的实例信息。
负载均衡配置 /conf/cluster_conf/ gslb.data 用于配置各集群内的多个子集群之间分流比例。

  • BFE扩展模块的配置文件

    出于便于管理的目的，BFE各扩展模块的配置文件和BFE主逻辑的配置文件分开存放。对于每个扩展模块，有一个独立的配置文件目录，位于"/conf/mod_/"目录下。如：/conf/mod_block/目录下是mod_block的配置文件。

常规配置 vs 动态配置

在BFE中，将配置分为“常规配置”和“动态配置”：

  • 常规配置

    仅在程序启动时生效。在BFE中，常规配置一般基于INI格式，常规配置文件名一般使用".conf"的后缀。

  • 动态配置

    可在程序执行过程中动态加载。在BFE中，动态配置一般基于JSON格式，兼顾程序读取和人工阅读的需求。

    动态配置文件名一般使用“.data”的后缀。

动态配置的实现机制

BFE中动态配置的实现机制如下图所示，主要包括“配置加载”和“配置生效”两方面。

hot reload

配置加载

在“监控机制”中介绍过，在BFE程序中嵌入一个Web Server，用于外部读取BFE内部的状态信息。这个Web Server也用于触发配置的动态加载。

例如：通过访问 http://127.0.0.1:8421/reload/gslb_data_conf，可以触发gslb.data的重新加载。

出于安全的考虑，仅当从部署BFE程序的同服务器发起对这个接口的访问时，才会通过。这个限制位于Web Monitor的实现代码中：

// source ip address allowed to do reload
var RELOAD_SRC_ALLOWED = map[string]bool{
	"127.0.0.1": true,
	"::1":       true,
}

如果从这个范围外的地址发起访问，则会返回类似下面这样的错误

{
    "error": "reload is not allowed from [xxx.xxx.xxx.xxx:xxx]"
}

通过在嵌入Web Server中注册的回调函数，配置加载逻辑会执行以下逻辑：

  • 配置文件的读取
  • 配置文件的解析和正确性检查
  • 运行态配置信息的更新

配置生效

在BFE中，程序并行处理基于Go语言提供的"Go协程"（Go routine）。BFE使用的是“单进程内多协程”的机制，不需要考虑考虑多进程通信，只需要考虑协程间的共享数据。在多协程间的共享数据方面，和多线程机制类似，可以访问位于同一进程内的共享数据，并可以使用“锁”来做互斥访问。由于协程和线程实现机制的不同，“协程锁”的开销要远远小于“线程锁”。

在BFE中，从文件加载的配置信息会被保存在一个受到协程锁保护的临界区中。负责转发的协程在使用配置数据时，需要通过特定的接口来从临近区中读取；配置加载逻辑在更新配置信息时，也通过特定的接口来操作。

以mod_block为例，其中的ProductRuleTable用于保存各租户的配置信息。为了读取配置信息，提供了如下接口：

func (t *ProductRuleTable) Search(product string) (*blockRuleList, bool) {
	t.lock.RLock()
	productRules := t.productRules
	t.lock.RUnlock()

	rules, ok := productRules[product]
	return rules, ok
}

为了更新配置信息，提供了如下接口：

func (t *ProductRuleTable) Update(conf productRuleConf) {
	t.lock.Lock()
	t.version = conf.Version
	t.productRules = conf.Config
	t.lock.Unlock()
}

以上这两个接口，使用读写锁来保护。并且，在临界区中的操作都尽量简单，以降低对多个处理协程间并行度的影响。