先看成果

配置文件(通过confd自动更新)

image.png

基础配置 and 业务配置(通过watch监听主动推送或是接口去pull)

image.png

技术选型

consul zookeeper etcd euerka对比

image.png

disconf apollo 对比

knightliao/disconf

部署极其简单：同一个上线包，无须改动配置，即可在 多个环境中(RD/QA/PRODUCTION) 上线
部署动态化：更改配置，无需重新打包或重启，即可 实时生效
统一管理：提供web平台，统一管理 多个环境(RD/QA/PRODUCTION)、多个产品 的所有配置
核心目标：一个jar包，到处运行

• 优: 成熟，开源即用
• 劣: 比较重，与现有的平台整合不方便，当前客户端支持比较好的是java

ctripcorp/apollo

Apollo（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。

服务端基于Spring Boot和Spring Cloud开发，打包后可以直接运行，不需要额外安装Tomcat等应用容器。

Java客户端不依赖任何框架，能够运行于所有Java运行时环境，同时对Spring/Spring Boot环境也有较好的支持。

.Net客户端不依赖任何框架，能够运行于所有.Net运行时环境。

• 优：比较成熟，开箱即用
• 劣：比较重，当前支持java,.net语言，与现有的平台或权限自定义，相对而言费时间。

工具型的salt, ansible提供的数据管理

服务器多些了，都会用到一些管理工具，目前比较优秀的是saltstack, ansible,而这些工具都提供以环境为分类的数据管理。salt在安全性做得挺好，采用salt，sha246等加密通信。

image.png

其它开源

如阿里早期开源的diamond, 近期开源的nacoa。
或基于zookeeper的，或是基于spring的config.....
有很多很多可供选择，根据业务选择合适的，即可。

造轮子

经过调研，测试，基于etcd+confd+自画页面，提供c/s或接口的pull/push调用方式。满足静态的配置文件或动态参数调用。

选用etcd的原因

• etcd是高可用的KV存储系统，他的Raft协议维护一个RSM(Replicated State Machine)，他的状态存储靠Snapshot和WAL（write ahead log）实现，为了保证数据的安全性（crash或者宕机下的恢复），每一个事务操作（即写操作），都会预先写到事务文件（WAL）中，当数据被破坏时，可以快速从最原始的数据恢复到数据损坏前的状态。还有一点是，需要undo或者redo的时候，只要反向或者正向执行日志中的操作即可。因此，etcd还提供了snapshot（快照）功能。snapshot定期把整个数据库保存成一个单独的快照文件，不但缩短了日志重放的时间，也减轻了WAL的存储量，etcd默认10000条记录做一次snapshot操作。etcd 底层默认使用的是开源的嵌入式键值存储数据库（https://github.com/etcd-io/bbolt），bolt是单机支持事务的KV数据库，通过COW (copy-on-write) 技术进行page管理，实现了无锁的读写，带来了很高的读性能，所以etcd V3不仅支持了数据的持久化，还提供了很高的读性能。

• MVCC（Multi-version Cocurrent Control）是etcd采用的乐观锁，不会阻塞大量的读操作，适合etcd这种读操作多的使用场景。etcd的revision就是MVCC中的版本，每次key-value的操作都会生成一个revision，他是全局递增并且唯一的，这些数据都放在keyIndex里的generation数组里，类似逻辑时钟，这个generation记录了key的生命周期。而所有这些generation和revision数据都被持久化到boltdb里，在内存中的btree维护key到keyindex的关系，从而加快keyindex的查找，通过内存btree在keyIndex.generations[0].revs中找到最后一条revision，就可从boltdb中读取对应的value。这样tangram完全可以利用了etcd的MVCC中的revision机制对key的历史记录的查询，再次摒弃了传统数据库对数据的历史信息的存储，因为传统数据库的MVCC不会直接暴露给用户使用，用户也很难了解一些细节。etcd把MVCC的信息暴露给用户。如果历史数据一直增加怎么办？可以通过compact操作来压缩历史版本，删除某个版本之前的所有历史版本，只保存这个版本以来的最近版本的数据。

• etcd事件通知机制就是基于MVCC实现的，它支持历史任意版本订阅事件，并且会推送对应的数据给客户端。客户端通过 Watch 结果监听某一个 Key 或者一个范围的变动，在每一次客户端调用服务端上述方式都会创建两个 Goroutine，这两个协程一个会从BoltDB 中后去当前版本范围内的数据变更并将它们转换成事件向监听者发送，通过一次性遍历，处理多个watcher，显然可以有效减少遍历的次数。另一个协程会负责处理客户端发来的事件。这样tangram客户端只要通过etcd的watch机制watch到key的更新事件，然后解析出value传入spring等框架中，把存储和事件通知都放在etcd中实现，减少了额外引入消息组件等成本。etcd V3的watch基于HTTP/2的TCP链接多路复用(multiple stream per tcp connection)，相比etcd V2或者目前业界其他的配置中心比如Nacos(https://nacos.io/zh-cn/)和Apollo(https://github.com/ctripcorp/apollo)基于http long polling有很大改进。Http long polling是当客户端发起long polling请求，如果此时服务端没有数据的话，会保持住这个http链接知道有数据推送或者超时，这样每个客户端需要一个http长连接去接受服务端推送的数据，对客户端可扩展性有很大限制。Http2的多路复用就是为了解决这个问题，在一个http2.0的连接中，可以存在多个流，并对他采取二进制编码，http header和body都以frame payload存在，每个流的数据通过帧的标识(frame header)区分数据属于哪个流，解决了请求阻塞的问题，提高了传输性能。这样同一个etcd client多个watcher共用一个http 2 stream达到多路复用的效果，通过watcher id区别。

• etcd采用的共识算法raft相比paxos协议更加容易理解和实现，提供了分布式系统中的选主(leader election)，日志复制(log replication)等特性，通过同步wal日志到各个节点来实现强一致性。raft会先选举出leader，leader完全负责replicated log的管理。leader负责接受所有客户端更新请求，然后复制到follower节点，并执行这些请求。如果leader故障，followers会重新选举出新的leader。传统数据库在这方面并不是天生的优势。

思考的功能点

• 权限控制。SSO或者LDAP可继承，或自定义的权限。

• 审计日志。燕过留痕，顶上的达摩克斯之剑。

• 环境管理。RD, QA, PROD配置肯定要做隔离，相同group内的配置可能大多相同，例如同一个IDC机房的应用也可以有namespace做区分

• 配置回滚。当发现配置错误，或者在该配置下程序发生异常可以立即回滚到之前的版本，这需要该系统能够有版本管理的功能

• 灰度发布，有时候我们新上线一个功能，想先通过少部分流量测试下，这个时候我们可以随机只修改部分应用的配置，当测试正常后在推送到所有的应用

• 高可用，配置中心需要高可用，所以最好能支持集群部署，同时配置中心系统挂了之后最好能不影响应用，应用能够继续使用本地缓存的配置

• Web配置中心, 主动push 或pull。

实现

python版（starlette/fastapi）

starlette 提供web服务，之所以选择这个，没选择django, flask， 是因为轻量级，异步
fastapi 提供api及文档，选择这个的原因是轻量级，性能快，有更好的文档展示。

go版

gin-gonic/gin 好用，性能强

之所以，用两个语言来实现，是应对不同量级的服务，如果是接口调用居多，又要求响应，稳定性高的，go语言方案就相对放心了。

参考

consul
https://www.jianshu.com/p/7d20dc58c9fc
etcd
https://juejin.im/post/5e02fb1f518825123b1aa341
https://www.jianshu.com/p/3189dd70a691
https://www.hi-linux.com/posts/40915.html

前端依赖
jstree
https://www.jianshu.com/p/168283e3c470
https://www.cnblogs.com/xiaohualu/p/9836528.html
highlight
https://highlightjs.org/usage/
quill
https://quilljs.com/docs/modules/syntax/
ace
https://github.com/ajaxorg/ace
bootstrap v4
bootstrap-table