FTU(Feeder Terminal Unit)全称馈线终端装置，安装在10 kV馈电线路上,对柱上开关进行监控，完成遥测、遥控、遥信，故障检测功能，并与配电自动化主站通信，提供配电系统运行情况和各种参数即监测控制所需信息，包括开关状态、电能参数、相间故障、接地故障以及故障时的参数,并执行配电主站下发的命令，对配电设备进行调节和控制，实现故障定位、故障隔离和非故障区域快速恢复供电功能。
DTU (Data Transfer unit)，是专门用于将串口数据转换为IP数据或将IP数据转换为串口数据通过无线通信网络进行传送的无线终端设备。才茂通信DTU广泛应用于气象、水文水利、地质等行业。
DTU的升级版是RTU。
FTU与RTU有以下区别：FTU体积小、数量多，可安置在户外馈线上，设有变送器，直接交流采样，抗高温，耐严寒，适应户外恶劣的环境；而RTU安装在户内，对环境要求高；FTU采集的数据量小，通信速率要求较低，可靠性要求较高；而RTU采集的数据量大，通信速率较高，可靠性要求高，有专用通道。
电压时间型FTU和电流时间型FTU区别在于一个是电压开关，一个是电流开关
深入研究Cilium多集群
局域网常用的拓扑结构有以下几种：
1、总线型拓扑结构。网络中各个节点由一根总线相连，数据在总线上由一个节点传向另一个节点。优点是节点的加入和退出都很方便，可靠性高，而且结构简单，成本低，因此这种结构是局域网普遍采用的形式。缺点是故障检测比较困难。
2、星型拓扑结构。星型拓扑结构是最早的通用网络拓扑结构形式，在星型拓扑中，每个节点与中心点连接，中心节点控制全网的通信，任何两个节点之间的通信都要通过中心节点。因此，要求中心节点有很好的可靠性。优点是星型拓扑结构简单，易于实现和管理。缺点是由于其集中控制方式的结构，一旦中心节点出现故障，就会造成全网的瘫痪，可靠性较差。
3、环型拓扑结构。各个节点通过中继器连接到一个闭合的环路上，环中的数据沿着一个方向传输，由目的节点接收。优点是环型拓扑结构简单、成本低，是用于数据不需要在中心节点上处理而主要在各自节点上进行处理的情况。缺点是环中任意一个节点的故障都可能造成网络瘫痪，成为环型网络可靠性的瓶颈。
4、树型拓扑结构。节点按层次进行连接，像树一样，有分支、根节点、叶子节点等，信息交换主要在上、下节点之间进行，树型拓扑可以看作是星型拓扑的一种扩展，主要适用于汇集信息的应用要求。优点是易于扩展和故障隔离。缺点是对根节点依赖性太大。
5、网状型拓扑结构。网状型拓扑结构没有上述四种那么明显的规则，所以又成为无规则型。节点与节点之间的连接是任意的，没有规律。目前实际存在和使用的广域网基本上都是采用网状型拓扑结构。优点是系统可靠性高。缺点是由于结构复杂，就必须采用路由协议、流量控制等方法。
本文是对ClusterMesh（Cilium的多集群实现）的深入研究。简而言之，ClusterMesh 提供：
多集群功能以层为单位构建，您可以选择使用所有层，也可以仅选择和使用所需的层。
在深入研究实现细节之前，让我们回顾一下连接多个Kubernetes集群的一些用例。
对于大多数人来说，高可用性是最明显的用例。 此用例包括在多个区域（regions）或可用区（availability zones）中运行Kubernetes集群，并在每个集群中运行相同服务的副本。 一旦失败，请求可以故障转移到其他集群。 此用例中涵盖的故障情形主要不是整个区域或故障域的完全不可用。 更可能的情况是一个集群中资源暂时不可用或配置错误导致无法在一个集群中运行或扩展特定服务。
基于Kubernetes的平台的最初趋势是构建大型多租户Kubernetes集群。 为每个租户构建单个集群或为不同类别的服务构建集群越来越普遍，例如， 不同级别的安全敏感度。
但是，某些服务（如密钥管理，日志记录，监控或DNS）通常仍在所有集群之间共享。 这避免了在每个租户集群中维护这些服务的操作开销。
此模型的主要动机是租户集群之间的隔离，为了维持该目标，租户集群连接到共享服务集群但未连接到其他租户集群。
运行有状态或无状态服务的操作复杂性是非常不同的。 无状态服务易于扩展，迁移和升级。 完全使用无状态服务运行集群可使集群保持灵活和敏捷。 从一个云提供商迁移到另一个云提供商非常简单。
有状态服务可能会引入潜在的复杂依赖链。 迁移服务通常涉及存储迁移。
为无状态和有状态分别运行独立的集群允许将依赖复杂性隔离到较少数量的集群，并使无状态集群依赖性保持自由。
控制平面基于etcd并尽可能保持简约：
pod IP路由是多集群能力的基础。 它允许跨集群的pod通过其pod IP相互联系。 Cilium可以在多种模式下运行以执行pod IP路由。 所有这些模式都能够执行多集群pod IP路由。
隧道模式将pod中发出的所有网络数据包封装在所谓的封包头中。 封包头可以包含VXLAN或Geneve帧。 然后通过标准UDP包头传输该封装帧。 该概念类似于***隧道。
在直接路由模式中，所有网络数据包都直接路由到网络。 这要求网络能够路由pod IP。 可以使用多个选项实现跨节点传播pod IP路由信息：
当网络不再理解pod IP时，网络数据包地址需要伪装。
混合路由模式允许在可用时使用直接路由，这通常在本地集群或同一VPC中的其他集群中，而当跨越VPC或云提供商时可以回退到隧道模式。 这可以限制操作复杂性并且允许仅在需要时支付优化成本。
Cilium的多集群模型的服务发现是使用标准的Kubernetes services 构建的，旨在对现有的Kubernetes应用程序部署完全透明：
从 frontend-1 到ClusterIP 30.1.1.1 的所有流量将自动负载均衡到集群1 的后端pod IP [10.0.0.1,10.0.0.2] 以及集群2的后端pod IP [20.0.0.1,20.0.0.2] 。 每个集群将执行本地后端实例的运行状况检查，并在容器创建，销毁或变得不健康时通知其他集群。
Cilium 1.4 中引入的透明加密与多集群兼容。确保使用公共密钥配置所有集群中的所有节点，如此节点之间的所有通信都会自动加密。
简单版本是您从单个集群中熟悉的策略实施将简单地扩展并跨集群工作。 由于策略是使用pod标签指定的，因此允许 frontend 与 backend 通信的策略将应用于集群流量，就像流量跨越集群一样。
Cilium 不会 跨集群自动传播NetworkPolicy或CiliumNetworkPolicy。 用户有责任将策略导入所有集群。 这是有意为之，因为这意味着每个集群都可以决定是否允许集群接收来自远程集群的通信或者发出到远程集群的通信。
可以仅建立适用于特定集群中的pod的策略。 集群名称由Cilium表示为每个pod上的标签，允许匹配的集群名称可以是 endpointSelector 或者是由 toEndpoints 和 fromEndpoints 构造的 matchLabels 标签：
上面的示例策略将允许cluster1中的 x-wing 与cluster2中的 rebel-base 对话。 除非存在将通信列入白名单的附加策略，否则x-wing将无法与本地集群中的rebel-base通信。
这两个项目都是独立的，但可以很好地相互补充。 组合Cilium和Istio多集群的常用方法是使用Cilium的多集群Pod IP路由层来满足 Istio多集群指南 的以下要求：
此外，Cilium策略执行功能可用于保护与Istio控制平面之间的通信，以及通过不支持的协议（如UDP或IPV6）保护sidecar的旁路尝试，以及防止受损的sidecar代理。
还可以同时运行全局Istio服务和Cilium全局服务。 所有Istio托管服务都可以获得Cilium的全局服务，因为它们可以像常规服务一样通过DNS发现。
要开始使用，请按照手把手的 ClusterMesh教程 进行操作，该教程将指导您完成将集群连接在一起的过程。 请务必加入我们的 Slack频道 ，提出问题并展示您的设置。
