什么是mybatis框架

MyBatis 是一款优秀的持久层框架，它支持定制化 SQL、存储过程以及高级映射。MyBatis 避免了几乎所有的 JDBC 代码和手动设置参数以及获取结果集。MyBatis 可以使用简单的 XML 或注解来配置和映射原生信息，将接口和 Java 的 POJOs(Plain Ordinary Java Object,普通的 Java对象)映射成数据库中的记录。

背景

MyBatis 是支持普通 SQL查询，存储过程和高级映射的优秀持久层框架。MyBatis 消除了几乎所有的JDBC代码和参数的手工设置以及结果集的检索。MyBatis 使用简单的 XML或注解用于配置和原始映射，将接口和 Java 的POJOs（Plain Ordinary Java Objects，普通的 Java对象）映射成数据库中的记录。

每个MyBatis应用程序主要都是使用SqlSessionFactory实例的，一个SqlSessionFactory实例可以通过SqlSessionFactoryBuilder获得。SqlSessionFactoryBuilder可以从一个xml配置文件或者一个预定义的配置类的实例获得。

用xml文件构建SqlSessionFactory实例是非常简单的事情。推荐在这个配置中使用类路径资源（classpath resource)，但你可以使用任何Reader实例，包括用文件路径或file://开头的url创建的实例。MyBatis有一个实用类----Resources，它有很多方法，可以方便地从类路径及其它位置加载资源。

特点

简单易学：本身就很小且简单。没有任何第三方依赖，最简单安装只要两个jar文件+配置几个sql映射文件易于学习，易于使用，通过文档和源代码，可以比较完全的掌握它的设计思路和实现。

灵活：mybatis不会对应用程序或者数据库的现有设计强加任何影响。 sql写在xml里，便于统一管理和优化。通过sql语句可以满足 *** 作数据库的所有需求。

解除sql与程序代码的耦合：通过提供DAO层，将业务逻辑和数据访问逻辑分离，使系统的设计更清晰，更易维护，更易单元测试。sql和代码的分离，提高了可维护性。

提供映射标签，支持对象与数据库的orm字段关系映射

提供对象关系映射标签，支持对象关系组建维护

提供xml标签，支持编写动态sql。

ThingsBoard设计为：

扩展性：可水平扩展的平台使用领先的开源技术构建。

容错性：没有单点故障集群中的每个节点都是相同的。

健壮性：单个服务器节点可以根据使用情况处理以万级别的设备，集群可以处理数百万级别设备。

自定义：使用可自定义的部件和规则引擎节点可以轻松添加新功能。

持久化：永远不会丢失你的数据。

参见如下架构图及关键组件和相关接口。

通信

ThingsBoard提供了基于MQTT、HTTP、CoAP和LwM2M的基础API适用于你的设备应用程序/固件。

每个协议API都是由单独的服务器组件提供的并且是ThingsBoard“传输层”的一部分。

MQTT传输还提供网关API与多个设备建立连接获取传感器的数据。

传输从设备接收到消息后将被解析结果推送到持久的消息队列。

仅在消息队列确认了相应消息后才将消息传递给设备。

内核

ThingsBoard Core负责处理REST API调用和WebSocket订阅。

它还负责存储有关活动设备会话和监视设备连接状态。

ThingsBoard Core使用Actor来实现主要实体（租户和设备）的actor。

平台节点可以加入群集其中每个节点负责传入消息的某些分区。

规则引擎

ThingsBoard规则引擎是系统的心脏负责处理传入的消息。

规则引擎使用Actor来实现主要实体的actor：规则链和规则节点。

规则引擎节点可以加入集群，其中每个节点负责传入消息的某些分区。

规则引擎从队列中订阅传入的数据并且仅在处理完消息后才对其进行确认。

有多种策略可用于控制顺序或消息处理以及消息确认的标准， 请参阅提交策略和处理策略。

ThingsBoard规则引擎可能以两种模式运行：共享和隔离

在共享模式下规则引擎处理多个租户的消息。

在隔离模式下规则引擎处理特定租户的消息。

Web UI

ThingsBoard提供了一个使用Express.js框架编写的轻量级组件用于开发静态Web界页。

这些组件是完全无状态的，没有太多可用的配置。

静态Web界面包含应用程序加载后该应用程序将开始使用ThingsBoard核心提供的REST API和WebSockets API。

消息队列

ThingsBoard支持多种消息队列实现：Kafka、RabbitMQ、AWS SQS、Azure服务总线和Google发布订阅。

使用持久化和可伸缩的队列ThingsBoard可以实现积压和负载均衡。

我们在特定的队列实现上提供“抽象层”并维护两个主要概念：主题和主题分区。

一个主题可能具有可配置数量的分区由于大多数队列实现不支持分区因此我们使用topic + “.” + partition模式。

ThingsBoard消息生产者根据实体ID的哈希值确定使用哪个分区。

因此同一实体的所有消息总是被推送到同一分区。

ThingsBoard消息使用者使用Zookeeper进行协调，并使用一致性哈希算法确定每个使用者应订阅的分区列表。

在微服务模式下运行时每个服务还基于唯一的服务ID（只有一个分区）具有专用的“通知”主题。

ThingsBoard使用以下主题：

tb_transport.api.requests: 发送通用API调用以检查从Transport到ThingsBoard核心的设备凭据。

tb_transport.api.responses: 从ThingsBoard核心到Transport接收设备凭证验证结果。

tb_core: 将消息从传输或规则引擎推送到ThingsBoard核心。消息包括会话生命周期事件属性和RPC订阅等。

tb_rule_engine: 将消息从Transport或ThingsBoard核心推送到规则引擎。消息包括传入遥测、设备状态、实体生命周期事件等。

注意:所有主题属性（包括分区的名称和数量）都可以通过Thingsboard.yml或环境变量进行可配置从ThingsBoard3.4开始可以通过UI配置规则引擎队列请参阅文档。

注意:从2.5版开始我们已经从使用 gRPC切换到消息队列用于ThingsBoard组件之间的所有通信。

核心思想是牺牲少量的性能/延迟以支持持久可靠的消息传递和自动负载平衡。

部署

ThingsBoard支持本地部署和云部署并在AWS，Azure，GCE和私有数据中心运行超过5000台服务器用于生产环境同时完全可以在没有互联网访问的专用网络中良好运行。

模式

平台设计为可水平扩展并支持自动发现新的服务器（节点）集群中的所有节点都是相同的并且支持负载均衡所有请求都会被转发到所有的节点用来解决单点故障。

微服务

从ThingsBoard v2.2开始对平台进行了重构以支持微服务体系结构而且还能够以独立模式将其作为单体应用程序运行。

支持这两个选项都需要一些额外的编程工作，但是由于与各种现有安装的向后兼容性，这一点至关重要。

ThingsBoard始终被设计为可作为分布式应用程序运行但最初也被设计为单体应用程序。

这意味着在每个服务器节点上只有一个Java进程在运行该应用程序。

这些进程正在使用gRPC进行通信，并且服务发现是通过Zookeeper完成的。

该模型适用于许多安装，并且只需最少的支持工作，知识和硬件资源即可进行设置。

但是微服务架构还解决了一些挑战，这些挑战适用于更复杂的部署和使用场景。

例如运行一个多租户部署，其中需要更精细的隔离以防止：

如果需要高可用性或希望扩展到数百万台设备微服务是一种选择，适用于更复杂的部署和使用场景例如：运行多租户部署需要更加精细的数据隔离以防止：

不可预测的规则链配置错误；

不可预测的负载峰值；

由于固件错误，单个设备打开了数千个并发连接；

和许多其他情况。

请点击下面列出的链接以了解更多信息，然后选择合适的架构和部署选项：

单体：了解有关单体模式下部署、配置和运行ThingsBoard平台的更多信息。

微服务：了解有关微服务模式下部署、配置和运行ThingsBoard平台的更多信息。

数据库

ThingsBard使用数据库进行存储 实体设备，资产，客户，仪表板等）和遥测数据（属性，时间序列传感器读数，统计信息，事件）。 平台目前支持三种数据库选项：

SQL：将所有实体和遥测存储在SQL数据库中，建议使用PostgreSQL数据库HSQLDB可用于本地开发和测试不建议将HSQLDB用于任何其他用途。

NoSQL (已弃用)：将所有实体和遥测存储在NoSQL数据库中，建议使用Cassandra数据库。

混合：将所有实体存储在SQL数据库中，并将所有遥测存储在NoSQL数据库中。

混合 (PostgreSQL + Cassandra)：将所有实体存储在PostgreSQL数据库中，并将时间序列数据存储在Cassandra数据库中。

混合 (PostgreSQL + TimescaleDB)：将所有实体存储在PostgreSQL数据库中，并将时间序列数据存储在Timescale数据库中。

可以使用thingsboard.yml文件配置此选项有关更多详细信息，请参见数据库配置页面。

1

2

3

4

5

6

7

8

database:ts_max_intervals:"${DATABASE_TS_MAX_INTERVALS:700}"# Max number of DB queries generated by single API call to fetch telemetry recordsentities:type:"${DATABASE_ENTITIES_TYPE:sql}"# cassandra OR sqlts:type:"${DATABASE_TS_TYPE:sql}"# cassandra, sql, or timescale (for hybrid mode, DATABASE_TS_TYPE value should be cassandra, or timescale)# note: timescale works only with postgreSQL database for DATABASE_ENTITIES_TYPE.

登录后复制

中间件

ThingsBoard后端是用Java编写的但是我们也有一些基于Node.js的微服务。

ThingsBoard前端是基于Angular JS框架的SPA。

有关使用的第三方组件的更多详细信息请参见单体和微服务页面

2EE的三层结构是指表示层（Presentation），业务逻辑层（Business Logic）以及基础架构层（Infrastructure），这样的划分非常经典，但是在实际的项目开发法中，开发者通常对三层结构进行扩展来满足一些 项目的具体要求，一个最常用的扩展就是将三层体系扩展为五层体系，即表示层(Presentation),控制/中介层(Controller /Mediator)、领域层(Domain),数据持久层(Da

ta Persistence)和数据源层(Da

ta Source)。它其实是在三层架构中增加了两个中间层。控制/中介层位于表示层和领域层之间，数据持久层位于领域层和基础架构层之间。由于对象范例和关 系范例这两大领域之间存在阻抗不匹配，所以把数据持久层单独作为J2EE体系的一个层提出来的原因就是能够在对象－关系数据库之间提供一个成功的企业 级映射解决方案，尽最大可能弥补这两种范例之间的差异。

三种持久层主流解决方案1、JDBC许多开发者用JDBC进行数据库程序的开发。此中方式很多情况下都使用DAO模式，采用SQL进行查询。虽然用此方式可以使应用程序代码与具体的数 据库厂商和数据库位置无关，不过JDBC是低级别的数据库访问方式，JDBC并不支持面向对象的数据库表示。JDBC数据库表示完全围绕关系数据库模型。 在大型应用程序的DAO中书写这样的代码，维护量是非常大的。

2、EJB在J2EE的规范中，为EJB定义了两种持久化的解决方案：一种是BMP，另一种是CMP。其中CMP不需要将SQL语句加入到代码中。目前，在采 用J2EE的应用中，EJB CMP方式得到了广泛应用。更加引人注意的是，随着EJB规范的发展，CMP也包含了一些高级关系的内容。但是，CMP的使用比较复杂，对很多开发人员来 说比较难以掌握。而且，不是在所有的情况下都适合在系统中采用EJB，而且想要非常清楚的了解EJB规范也是非常费时的。在用EJB编码前，先要让专家理 解API，然后需要了解每一个容器部署时所要关注的技术

。此外，许多情况下商用容器的性能和支持也不是很好。

3、JDOJDO是一个存储java对象的规范，JDO规范1.0的提出可以使你将精力集中在设计Java对象模型，然后在企业应用软件架构的不同层面中存储 传统的Java对象（Plain Old Java Objects，简称POJOs），采用JDOQL语言进行SQL *** 作。一些公司（包括sun）企图根据JDO规范进行设计并实现JDO产品，然而他们都 不能很好的进行实现，并且性能优化上比较差。

持久就是对数据的保持，即对程序状态的保持。通常通过数据库实现持久层是把数据库实现这块当作一个独立逻辑拿出来。

说白了，就是数据库程序是在内存中的，为了使程序运行结束后状态得以保存，就要保存到数据库使用ORM(对象关系数据库映射)技术可以避免代码直接 *** 作数据库，增加可移植性，可扩展性，可维护性。

持久层其目的是通过持久层的框架将数据库存储从服务层中分离出来是，持久层框架有两种方向：直接自己编写JDBC等SQL语句（如iBatis）；使用O/R Mapping技术实现的Hibernate和JDO技术；当然还有EJB中的实体Bean技术。

---