TOP10技术特性
本文主要介绍Nebula的10个最重要技术特性
- 支持SaaS多租户架构
- 支持微服务架构开发
- 支持 Linux+docker+K8S 的部署方式
- 强大且实时的在线可观测能力，超越各种流行APM
- 监控对象自动发现，可配置可扩展的监控指标
- 强大易用的消息管道开发模型
- 简单易用的后台任务开发模型
- 统一的全局帐号管理，解决帐号泄漏问题，所有配置可在线调整
- 全异步支持
- 更少的内存占用
SaaS多租户架构
SaaS架构，也称 “多租户” 架构。概念这里就不多说~~
数据库设计
- 主库：一个SaaS项目一个主库，存放一些全局数据。
- 租户库：为每租户创建一个租户数据库，存放与租户相关的数据，用于保证各租户之间的数据隔离。
应用站点
- 应用站点与服务的部署实例不区分租户（共享），可以接受所有租户的用户访问。
- 用户Token包含租户ID，用于区分租户
- 框架根据租户ID，在运行时动态切换到对应的租户数据库中，实现租户的数据库路由访问。
Linux+docker+K8S 的部署环境
支持以下部署技术：
微服务架构开发
微服务与单体应用程序有很大差别，主要表现在：
- 经常需要跨进程调用，而不是直接的方法调用
- 因此需要知道：调用的目标服务部署在哪里？
- 需要部署多个服务站点，又会带来新的问题：
- 参数在哪里配置？ 如何避免重复问题？
- 日志怎么统一收集，查看？
- 出现故障时，怎么排查问题？
Nebula对于微服务的支持可参考：微服务架构开发
强大的在线可观测能力
重点体现在：
细节内容包括：
- 各服务的实时调用情况统计（总量/延迟/异常/平均响应时间）
- 各服务的业务指标 实时采集与实时汇总统计
- 一些技术性指标：线程池线程数量，内存占用，TPS，错误数，警告数，打开的SQL连接数量，等等。
- 完善的日志记录（操作日志/异常日志/性能日志/框架性能日志)
- 性能日志 包含详细的执行过程及耗时，以及全链路展示，可快速定位性能根因
- 各种内部状态：运行环境参数，系统信息，各种计数器，程序集，线程及调用堆栈
- 应用进程/数据库/中间件服务的 可用性监控
监控对象自动发现，可配置可扩展的监控指标
Nebula自动识别的监控对象分为4大类：
- 配置服务中注册的：服务地址
- 配置服务中注册的：连接帐号，例如：RabbitMQ的连接帐号
- 配置服务中注册的：数据库连接，例如：某个MySQL数据库的连接参数
- 集群中微服务的运行实例
可监控指标包含3大类：
所有这些数据都可以配置为监控规则，点击引处查看文档。
有了这些监控对象和监控规则，Nebula就能产生告警通知。
- 服务/中间件的【可用性】告警
- 服务节点的 心跳/打卡 告警
- 基于 指标规则 的监控告警
- 应用程序启动失败的异常日志告警
以上4类告警通知都可以发送到指定的IM聊天群。
消息管道开发模型
为了方便消息订阅和消息处理，ClownFish提供了一种称为消息管道的开发模型，如下图所示：
此模型有以下优点：
- 规范代码：将消息处理划分为多个阶段，避免代码风格迥异
- 功能增强：提供完善的日志和监控，支持重试处理，支持异常处理
- 统一模型：支持一套消息处理代码，订阅不同的消息服务（消息来源），可理解为与消息服务解耦。
- 简化代码：隐藏所有技术差异：订阅模式差异，线程模型差异，订阅者数量管理，提交方式，序列化等等细节。
消息处理只负责实现业务逻辑即可。
后台任务开发模型
后台任务也是一种很常见的业务开发模式，例如：
- 每天晚上执行一次数据统计
- 每小时执行一次XXXX检查
虽然 Quartz和Hangfire 也能完成这类任务，但是它们没有提供完善的日志和监控功能，
没法与Nebula的日志和监控整合，因此，ClownFish直接内置了周期性后台任务的开发模型。
下表是ClownFish内置的 BackgroundTask 和 Hangfire 的差别对比
| 技术特性 | BackgroundTask | Hangfire |
|---|---|---|
| 依赖ASP.NET | 否 | 是 |
| 依赖数据库持久化 | 否 | 是 |
| 同一任务重叠执行 | 否 | 是 |
| 支持异步任务 | 是 | 否 |
| 支持秒级触发 | 是 | 否 |
| 支持性能日志 | 是 | 否 |
| 支持Venus监控 | 是 | 否 |
| 支持立即执行 | 是 | 延迟 |
| 支持临时任务 | 否 | 是 |
统一的全局帐号管理，解决帐号泄漏问题
许多开发框架和客户端类库虽然都提供了参数配置能力，
例如：
- 可以把 MySqlConnection 的连接字符串配置在 appsettings.json 中，
- ASP.NET甚至允许我们为不同环境指定不同的配置文件，
但是这种设计没有解决帐号泄漏的安全问题，因为：配置文件很容易通过源代码方式造成泄漏！
在Nebula框架中，采用了以下方式来解决帐号泄漏问题
- 配置服务：统一管理所有连接帐号，以及各种密码之类的敏感参数
- 封装各种客户端：强制从配置服务中获取必要的连接参数
- 最终结果：应用程序的代码不会包含帐号类的敏感内容
全异步支持
异步是一个非常有用的技术特性，它与同步调用相比，可以在相同的硬件资源下提供更高的系统吞吐量。
尤其是国内各种【互联网应用】和【信息化系统】，因为它们有以下特点：
- 大量的数据库CURD操作
- 大量的服务之间相互调用
这些都是【异步】最适合的使用场景。
Nebula和ClownFish中，几乎所有涉及远程调用的API都提供异步版本，例如：
- 所有数据库CURD操作
- 所有HTTP调用
- 各种中间件服务的客户端
更少的内存占用
Nebula在内存占用方面做了大量优化，主要包含4大类：
- 在框架内部的代码热点路径上涉及的大对象尽可能地使用对象缓存
- 提供许多参数开关用来控制不必要的对象分配
- 代码优化，尽量减少内存的占用
- 运行环境：GC参数的配置优化
例如下图是线上部分服务的真实运行情况，可以关注下 MEM 这个数据，
我们可以看到基于Nebula开发的服务，它们的内存占用都比较低，
