夜莺V6.X架构介绍
夜莺 6.x 版本相比 5.x 在架构上做了巨大的调整，之前服务端有两个模块，n9e-webapi 和 n9e-server，6.x 之后合并成了一个，就是 n9e，这个模块既可以提供接口给前端调用，也可以提供告警引擎的能力。但是有的时候机房网络链路不好，或者有acl限制，很多 agent 没法连通服务端，此时就需要下沉部署方案。
中心汇聚式部署方案
这个方案的架构图如下：
夜莺只有一个模块了，就是 n9e，可以部署多个 n9e 实例组成集群，n9e 依赖 2 个存储，数据库、Redis，数据库可以使用 MySQL 或 Postgres，自己按需选用。
n9e 提供的是 HTTP 接口，前面负载均衡可以是 4 层的，也可以是 7 层的。一般就选用 Nginx 就可以了。
n9e 这个模块接收到数据之后，需要转发给后端的时序库，相关配置是：
[Pushgw]
LabelRewrite = true
[[Pushgw.Writers]]
Url = "http://127.0.0.1:9090/api/v1/write"
相当于是，虽然数据源可以在页面配置了，但是上报转发链路，还是需要在配置文件指定。
所有机房的 agent（ 比如 Categraf、Telegraf、 Grafana-agent、Datadog-agent ），都直接推数据给 n9e，这个架构最为简单，维护成本最低。当然，前提是要求机房之间网络链路比较好，一般有专线。如果网络链路不好，则要使用下面的部署方式了。
边缘下沉式混杂部署方案
还是先上架构图，一图胜千言：
这个图尝试解释 3 种不同的情形，比如 A 机房和中心网络链路很好，Categraf 可以直接汇报数据给中心 n9e 模块，另一个机房网络链路不好，就需要把时序库下沉部署，时序库下沉了，对应的告警引擎和转发网关也都要跟随下沉，这样数据不会跨机房传输，比较稳定。但是心跳还是需要往中心心跳，要不然在对象列表里看不到机器的 CPU、内存使用率。还有的时候，可能是接入的一个已有的 Prometheus，数据采集没有走 Categraf，那此时只需要把 Prometheus 作为数据源接入夜莺即可，可以在夜莺里看图、配告警规则，但是就是在对象列表里看不到，也不能使用告警自愈的功能，问题也不大，核心功能都不受影响。
边缘机房，下沉部署时序库、告警引擎、转发网关的时候，要注意，告警引擎需要依赖数据库，因为要同步告警规则，转发网关也要依赖数据库，因为要注册对象到数据库里去，需要打通相关网络，告警引擎和转发网关都不用Redis，所以无需为Redis打通网络。
小结
夜莺 v6.x 发布了 ga 版本，就是基本可用的版本，正式版还需要再稳定一段时间，预计 4.27 与大家见面，敬请期待。
