华为云物联网四年配置中心实践.docxVIP

华为云物联网四年配置中心实践 从场景分类 运维配置，即程序只读的配置 人工配置。通过人工在配置中心界面进行配置，而程序只进行读取，如数据库配置、邮箱服务器配置、网卡配置、子网地址配置等。这部安排置数据不要求代码动态写入。 业务配置，即程序可写的配置 我们是一个 SaaS 服务，每个用户在上面都有一些业务配置。如用户的证书配置、用户服务器的流控配置等，这些业务配置相对运维配置来说愈加简单，且可能会有独一性限制，如按用户 id 独一。这部安排置数据一般由用户操作触发，代码动态写入，并且通知到各个微服务实例。通常，我们期望这些配置能在界面呈现，且支持人为修改。上述规律假如由各微服务本人实现，会存在大量反复代码，并且质量无法保证。我们期望由一个公共组件来统一实现这个力量。 从配置能否会有列表可分为单值配置或多值配置 单值配置 整个配置下只是多对 key、value。value 不是很简单的格式，往往是整数或字符串。 多值配置 多值配置愈加简单，往往是单值配置在不同的 key 下，有不同的值。比如下面的配置，用户一和用户二的线程池大小和队列不同 第一阶段自研配置中心 在做云服务之前，我们的配置中心层级数较少。我们以软件的方式交付给客户，软件运转时分为管理面和业务面，配置中心管理着管理面和业务面的配置，最为简单的场景是多套业务面，这个时候需要保证不同集群、不同微服务下的配置不冲突，配置层级为集群、微服务、配置。 此时的配置中心是完全自研的，不包含蓝绿、灰度配置这些功能，它独具特色的地方有以下两点： 单配置单表 在存储模型上，每个配置对应一张数据表。 对多值配置比较友好，尤其是简单业务配置，可以支持各种主键约束。对单值配置，略微重型了一些。 配置的强 Schema 限制。这些限制包括类型、大小、长度、能否敏感等限制。这种限制既能为界面修改配置供应良好的体验（如：不同格式不同的输入框、敏感字段，前台输入明文，后台入库加密等），也能在通过接口写入配置时做充分的校验。 通过回调方式来确保配置的牢靠 举个例子，添加一个配置的流程是这样的 可能这里，有读者想要问了，这个流程能确保什么牢靠呢。这个流程通过调用微服务接口来校验配置能否牢靠，如 IP 地址能否合法、对端地址能否可达、配置数量能否超过规格等等，来保证配置基本可用。 总的来说，这个自研的配置中心在当时综合体验还是不错的。但是也有一些问题有待改进，比如单配置下配置项数量过多时，由于底层有部分接口单配置下全部数据都通过一个 http 恳求来承载，会导致响应超时等问题。 其次阶段 Apollo 开头其次阶段实践的缘由次要是，我们进行了组织切换，业务重心转向做云服务，同时团队进行 DevOps 转型。原先的老配置中心是由另一个团队维护的，组织切换完之后，假如还要使用，就要我们本人维护。所以我们需要在连续维护老配置中心和引入开源 Apollo 两头进行选择。除了上文中提到的运维配置和业务配置，这个时候我们的需求还有转变： 配置的层级愈发丰富了 要构建灰度发布微服务的力量 老配置中心一方面由于组织切换缘由不供应维护了，另一方面不能支撑丰富的配置层级，也不具备灰度发布的力量。这个时候，Apollo 的一些特性吸引了我们，这些特性正是老配置中心所缺乏的，例如（部分引用自 Apollogithub 主页） 丰富的层级，从 app_id 到 cluster,namespace,key-value 的层级能满足我们 region、集群、微服务的层级诉求； 支持配置的灰度发布，比如点了发布后，只对部分应用实例生效，等观看一段时间没问题后再推给全部应用实例； 全部的配置发布都有版本概念，从而可以便利的支持配置的回滚； 应用和配置的管理都有完善的权限管理机制，对配置的管理还分为了编辑和发布两个环节，从而削减人为的错误； 全部的操作都有审计日志，可以便利的追踪问题。 因而我们选型引入了 Apollo，我和我的主管，还有一个其他同事参与了这项工作。我们在 Apollo 开源代码的基础上做了比较大的改动，次要缘由有以下几点： 节省成本，将注册中心、数据库替换成我们当前正在使用的组件，由于这两个依靠不是 Apollo 的核心依靠 承继老配置中心强 Schema 的优点 保留回调确认配置的流程，提前拦截错误的配置，降低代码处理特别配置的简单度 通过 spi 或环境变量的方式兼容存量老局点使用老配置中心的场景 结合上述缘由，我们最终是这么实践的： 数据库切换为 postgre 数据库、注册中心切换到 servicecomb 在 namespace 上实现了 Schema，每个 namespace 都可以注册对应的 Schema，Schema 要求数据必需是 json 格式，且 json 内对应的 value 必需满足 Schema