做网站每一步的是什么,怎么检测网站是否安全,网站页面改版,网站建设的新发展摘要#xff1a; 在上一篇文章中#xff0c;我们以MQ和ACM为例#xff0c;讨论了如何借助配置中心对消息进行限流管理的场景。在本文中#xff0c;我们继续以该场景为例#xff0c;讲述如何以规范的配置命名格式来进行限流设置。
点此查看原文#xff1a;http://click.al…摘要 在上一篇文章中我们以MQ和ACM为例讨论了如何借助配置中心对消息进行限流管理的场景。在本文中我们继续以该场景为例讲述如何以规范的配置命名格式来进行限流设置。
点此查看原文http://click.aliyun.com/m/41596/
配置规范问题的产生
对于单一应用的单一属性配置而言配置规范其实不是个问题。简单来讲以下配置文件即可解决该问题而不需要所谓配置规范问题。
//配置目录结构
--app|--src|--config|--application.properties//配置内容
RCV_INTERVAL_TIME20
然而当针对某一分布式PaaS服务编写分布式规则的时候作为PaaS服务提供方(而不是应用方)在设计配置时会存在不少问题。以MQ 限流场景为例将存在以下可能的问题
如何区分全局配置和局部应用配置比如PaaS服务方在统一管控平台提供服务时如何既有全局的规则配置又能针对某个应用进行特殊配置。 如何区分不同集群MQ服务比如MQ1 Cluster和MQ2 Cluster的配置在保证配置命名统一的情况下能有效被区分。 如何针对不同的环境如dev, test, staging, prod等基于同一套配置中心进行环境隔离。 以上MQ限流场景需求可由以下图例简述。显然不恰当的配置命名规范将影响以上的配置的易用性。
接下来本文基于配置中心介绍这一方面的最佳实践。为了说明配置的命名规范我们需要介绍一下这方面配置中心对应的配置结构组织的能力。
关于配置中心的一些配置结构功能说明
除了能对配置进行集中管理订阅推送等能力配置中心的配置结构化能力能帮助管理员大大简化不同应用复杂场景下的配置管理。
配置中心的配置结构能力说明 配置中心的配置结构能力可从以下几个场景进行说明
租户隔离配置中心针对不同用户或场景将配置进行隔离的能力。通过租户隔离不同的配置在不同的租户可以重名而且具有不同的鉴权机制。 最小配置集合配置中心如何将若干配置组合成一个配置集合。通过发布将不同配置放在一个最小配置集合来更改和发布配置可以以类似事物的形式统一发布应用这样可以统一处理。其中配置路径类似于一个文件路径或者网络域名的概念使得不同配置集合之间拥有层级关系。 具体配置的Key-Value形式用户如何具体在配置中心中设置具体配置内容。
配置中心配置结构能力产品比较
为了进一步具像化说明我们基于以下几个配置中心产品进行这方面的功能比较
阿里云 ACM: 阿里云应用配置管理前身为Diamond算是国内最早的配置中心产品。目前在Git上有不同开源版本在阿里云上有商业版供使用。 Spring Cloud Config: Spring Cloud官方用于做配置中心的工具主要是在Java Spring领域使用。 ZooKeeper: ZK其本身虽具备一部分配置中心能力但是由于本身定位于分布式协调信息管理因此只适合在应用规模不大的情况下做配置中心。鉴于其使用广大因此也在这里用于比较一下。 以下是对比详细情况
通过以上内容可见ACM在租户隔离和最小配置集合方面都有比较好的灵活性。以下内容我们介绍如何合理利用ACM的Namespace, Group, DataID等配置功能来设计一个合理配置结构来进行QoS限流策略。
基于配置中心的分布式服务的配置设计最佳实践 配置结构 为了满足MQ配置的功能性需求结合ACM的特点设计以下配置方法。
对于不同环境的MQ配置通过不同的Namespace进行隔离。如
ProdEnv 命名空间用于生产环境TestEnv, DevEnv分别用于测试和开发环境。 不同环境天然通过AK/SK来隔离安全得到进一步加强。 对于不同集群提供的MQ服务可通过Group来进行区分以进行配置隔离和简化访问形式。
例如对于专门为子部门核心交易部门服务的MQ集群和为子部门交易类目部门服务的MQ集群可通过Group来区分不同的全局配置。这样的好处在于对于生产系统所有应用采用同一(子)公司的AK/SK(或类似认证体系密钥)简化了部署的同时不同集群的配置得到有效的隔离简化了配置复杂性。DataID: mq.global.qosGroup: Trading DataID: mq.global.qosGroup: ProductCategory
全局配置用全局统一DataID命配置项存放
其中配置ID以mq开头global表示全局配置qos表示qos方面配置Group可使用默认。
DataID: mq.global.qosGroup: Default_Group
应用局部配置以相同前缀qos.*来命名ID
其中配置ID以mq开头app.[appname]表示需要重载的app配置项Group可使用默认。DataID: mq.app.app1.qosGroup: Default_Group DataID: mq.app.app2.qosGroup: Default_Group
配置具体KV的设置
在很多配置中心产品中如Appolo, ACM System Manager Parameter Store每一个具体的配置是一个配置中心中的最小粒度管理单元。用户需要挨个在某个粒度下去设置配置的KV。但是在ACM中并没有该限制。常用做法一般为两种
仿照以上配置中心将每个key存在一个独特的DataID上比如
mq.global.qos.RCV_INTERVAL_TIME 设置为 50 mq.global.qos.MAX_THREAD 设置为 20 将常用配置聚类成一个DataID编辑成一个配置文件(配置不限如PropertiesJsonXML等)
如 mq.global.qos 设置为如下
//MQ 限流 QoS设置RCV_INTERVAL_TIME 50MAX_THREAD 20
在实践中我们发现第二种方法为更高效的方法。除了更好的灵活性以外另外一个好处是多个配置同时在一次变更中发布降低了性能开销的同时理论上达到了变更批量变化的原子操作效果。
配置结构示意图 经过以上设计最终配置结构示意图如下方案有点总结如下 不同环境通过Namespace来进行隔离MQ配置项在不同Namespace可重复的同时不同Namespace通过管理人员程序AK/SK等权限设置得到隔离保护配置项能统一的同时各个环境间互不干扰。 相同环境不同集群之间通过Group做隔离既能保证不同集群下配置的统一性(如配置名不变等)代码更加简单又能在逻辑上将不同的集群配置做个里。 通过最小配置集DataID的规范命名设置各MQ客户端既可以方便的查找MQ Default全局配置又能查找到自己对应的应用特殊配置。同时管理员通过在ACM Portal上通过前缀通配查找能方便查找出所有MQ对应的所有规则使管理变得简单。示例如下
