51CTO旗下网站
如何解决分布式系统可管理性问题?
分布式系统是一个由很多进程组成的整体，这个整体中每个成员部分，都会具备一些状态，比如自己的负责模块，自己的负载情况，对某些数据的掌握等等。
作者：韩伟来源：| 09:21
上期我们邀请腾讯互娱研发部高级工程师韩伟给大家分享了关于分布式系统的一些基础知识，了解了分布式系统产生的背景以及它是如何提高系统承载量的。回顾往期请看《分布式系统，你真的了解吗?》
今天我们将继续跟随韩伟的分享，来进一步学习解决分布式系统可管理性有哪些基本手段。
韩伟现就职于腾讯互娱研发部，在公共技术研发中心担任产品的架构设计和开发。多年来一直从事技术开发，擅长开发高性能系统，对于软件架构设计也有丰富的经验。曾任网易无线事业部技术总监。
解决分布式系统可管理性的基本手段
目录服务(ZooKeeper)
分布式系统是一个由很多进程组成的整体，这个整体中每个成员部分，都会具备一些状态，比如自己的负责模块，自己的负载情况，对某些数据的掌握等等。而这些和其他进程相关的数据，在故障恢复、扩容缩容的时候变得非常重要。
简单的分布式系统，可以通过静态的配置文件，来记录这些数据：进程之间的连接对应关系，他们的IP地址和端口，等等。然而一个自动化程度高的分布式系统，必然要求这些状态数据都是动态保存的。这样才能让程序自己去做容灾和负载均衡的工作。
一些程序员会专门自己编写一个DIR服务(目录服务)，来记录集群中进程的运行状态。集群中进程会和这个DIR服务产生自动关联，这样在容灾、扩容、负载均衡的时候，就可以自动根据这些DIR服务里的数据，来调整请求的发送目地，从而达到绕开故障机器、或连接到新的服务器的操作。
然而，如果我们只是用一个进程来充当这个工作。那么这个进程就成为了这个集群的&单点&&&意思就是，如果这个进程故障了，那么整个集群可能都无法运行的。所以存放集群状态的目录服务，也需要是分布式的。幸好我们有ZooKeeper这个优秀的开源软件，它正是一个分布式的目录服务区。
ZooKeeper可以简单启动奇数个进程，来形成一个小的目录服务集群。这个集群会提供给所有其他进程，进行读写其巨大的&配置树&的能力。这些数据不仅仅会存放在一个ZooKeeper进程中，而是会根据一套非常安全的算法，让多个进程来承载。这让ZooKeeper成为一个优秀的分布式数据保存系统。
由于ZooKeeper的数据存储结构，是一个类似文件目录的树状系统，所以我们常常会利用它的功能，把每个进程都绑定到其中一个&分枝&上，然后通过检查这些&分支&，来进行服务器请求的转发，就能简单的解决请求路由(由谁去做)的问题。另外还可以在这些&分支&上标记进程的负载的状态，这样负载均衡也很容易做了。
目录服务是分布式系统中最关键的组件之一。而ZooKeeper是一个很好的开源软件，正好是用来完成这个任务。
消息队列服务(ActiveMQ、ZeroMQ、Jgroups)
两个进程间如果要跨机器通讯，我们几乎都会用TCP/UDP这些协议。但是直接使用网络API去编写跨进程通讯，是一件非常麻烦的事情。除了要编写大量的底层socket代码外，我们还要处理诸如：如何找到要交互数据的进程，如何保障数据包的完整性不至于丢失，如果通讯的对方进程挂掉了，或者进程需要重启应该怎样等等这一系列问题。这些问题包含了容灾扩容、负载均衡等一系列的需求。
为了解决分布式系统进程间通讯的问题，人们总结出了一个有效的模型，就是&消息队列&模型。消息队列模型，就是把进程间的交互，抽象成对一个个消息的处理，而对于这些消息，我们都有一些&队列&，也就是管道，来对消息进行暂存。每个进程都可以访问一个或者多个队列，从里面读取消息(消费)或写入消息(生产)。由于有一个缓存的管道，我们可以放心的对进程状态进行变化。当进程起来的时候，它会自动去消费消息就可以了。而消息本身的路由，也是由存放的队列决定的，这样就把复杂的路由问题，变成了如何管理静态的队列的问题。
一般的消息队列服务，都是提供简单的&投递&和&收取&两个接口，但是消息队列本身的管理方式却比较复杂，一般来说有两种。一部分的消息队列服务，提倡点对点的队列管理方式：每对通信节点之间，都有一个单独的消息队列。这种做法的好处是不同来源的消息，可以互不影响，不会因为某个队列的消息过多，挤占了其他队列的消息缓存空间。而且处理消息的程序也可以自己来定义处理的优先级&&先收取、多处理某个队列，而少处理另外一些队列。
但是这种点对点的消息队列，会随着集群的增长而增加大量的队列，这对于内存占用和运维管理都是一个复杂的事情。因此更高级的消息队列服务，开始可以让不同的队列共享内存空间，而消息队列的地址信息、建立和删除，都采用自动化的手段。&&这些自动化往往需要依赖上文所述的&目录服务&，来登记队列的ID对应的物理IP和端口等信息。比如很多开发者使用ZooKeeper来充当消息队列服务的中央节点;而类似Jgropus这类软件，则自己维护一个集群状态来存放各节点今昔。
另外一种消息队列，则类似一个公共的邮箱。一个消息队列服务就是一个进程，任何使用者都可以投递或收取这个进程中的消息。这样对于消息队列的使用更简便，运维管理也比较方便。不过这种用法下，任何一个消息从发出到处理，最少进过两次进程间通信，其延迟是相对比较高的。并且由于没有预定的投递、收取约束，所以也比较容易出BUG。
不管使用那种消息队列服务，在一个分布式服务器端系统中，进程间通讯都是必须要解决的问题，所以作为服务器端程序员，在编写分布式系统代码的时候，使用的最多的就是基于消息队列驱动的代码，这也直接导致了EJB3.0把&消息驱动的Bean&加入到规范之中。
在分布式的系统中，事务是最难解决的技术问题之一。由于一个处理可能分布在不同的处理进程上，任何一个进程都可能出现故障，而这个故障问题则需要导致一次回滚。这种回滚大部分又涉及多个其他的进程。这是一个扩散性的多进程通讯问题。要在分布式系统上解决事务问题，必须具备两个核心工具：一个是稳定的状态存储系统;另外一个是方便可靠的广播系统。
事务中任何一步的状态，都必须在整个集群中可见，并且还要有容灾的能力。这个需求，一般还是由集群的&目录服务&来承担。如果我们的目录服务足够健壮，那么我们可以把每步事务的处理状态，都同步写到目录服务上去。ZooKeeper再次在这个地方能发挥重要的作用。
如果事务发生了中断，需要回滚，那么这个过程会涉及到多个已经执行过的步骤。也许这个回滚只需要在入口处回滚即可(加入那里有保存回滚所需的数据)，也可能需要在各个处理节点上回滚。如果是后者，那么就需要集群中出现异常的节点，向其他所有相关的节点广播一个&回滚!事务ID是XXXX&这样的消息。这个广播的底层一般会由消息队列服务来承载，而类似Jgroups这样的软件，直接提供了广播服务。
虽然现在我们在讨论事务系统，但实际上分布式系统经常所需的&分布式锁&功能，也是这个系统可以同时完成的。所谓的&分布式锁&，也就是一种能让各个节点先检查后执行的限制条件。如果我们有高效而单子操作的目录服务，那么这个锁状态实际上就是一种&单步事务&的状态记录，而回滚操作则默认是&暂停操作，稍后再试&。这种&锁&的方式，比事务的处理更简单，因此可靠性更高，所以现在越来越多的开发人员，愿意使用这种&锁&服务，而不是去实现一个&事务系统&。
自动部署工具(Docker)
由于分布式系统最大的需求，是在运行时(有可能需要中断服务)来进行服务容量的变更：扩容或者缩容。而在分布式系统中某些节点故障的时候，也需要新的节点来恢复工作。这些如果还是像老式的服务器管理方式，通过填表、申报、进机房、装服务器、部署软件&&这一套做法，那效率肯定是不行。
在分布式系统的环境下，我们一般都是采用&池&的方式来管理服务。我们预先会申请一批机器，然后在某些机器上运行服务软件，另外一些则作为备份。显然我们这一批服务器不可能只为某一个业务服务，而是会提供多个不同的业务承载。那些备份的服务器，则会成为多个业务的通用备份&池&。随着业务需求的变化，一些服务器可能&退出&A服务而&加入&B服务。
这种频繁的服务变化，依赖高度自动的软件部署工具。我们的运维人员，应该掌握这开发人员提供的部署工具，而不是厚厚的手册，来进行这类运维操作。一些比较有经验的开发团队，会统一所有的业务底层框架，以期大部分的部署、配置工具，都能用一套通用的系统来进行管理。而开源界，也有类似的尝试，最广为人知的莫过于RPM安装包格式，然而RPM的打包方式还是太复杂，不太符合服务器端程序的部署需求。所以后来又出现了Chef为代表的，可编程的通用部署系统。
在虚拟机技术出现之后，PaaS平台为自动部署提供了强大的支持：如果我们是按某个PaaS平台的规范来编写的应用，可以完全把程序丢给平台去部署，其承载量计算、部署规划，都自动完成了。这方面的佼佼者是Google的AppEngine：我们可以直接用Eclipse开发一个本地的Web应用，然后上传到AppEngine里面，所有的部署就完成了!AppEngine会自动的根据对这个Web应用的访问量，来进行扩容、缩容、故障恢复。
然而，真正有革命性的工具，是Docker的出现。虽然虚拟机、沙箱技术早就不是什么新技术，但是真正使用这些技术来作为部署工具的时间却不长。Linux高效的轻量级容器技术，提供了部署上巨大的便利性&&我们可以在各种库、各种协作软件的环境下打包我们的应用程序，然后随意的部署在任何一个Linux系统上。
为了管理大量的分布式服务器端进程，我们确实需要花很多功夫，其优化其部署管理的工作。统一服务器端进程的运行规范，是实现自动化部署管理的基本条件。我们可以根据&操作系统&作为规范，采用Docker技术;也可以根据&Web应用&作为规范，采用某些PaaS平台技术;或者自己定义一些更具体的规范，自己开发完整的分布式计算平台。
日志服务(log4j)
服务器端的日志，一直是一个既重要又容易被忽视的问题。很多团队在刚开始的时候，仅仅把日志视为开发调试、排除BUG的辅助工具。但是很快会发现，在服务运营起来之后，日志几乎是服务器端系统，在运行时可以用来了解程序情况的唯一有效手段。
尽管我们有各种profile工具，但是这些工具大部分都不适合在正式运营的服务上开启，因为会严重降低其运行性能。所以我们更多的时候需要根据日志来分析。尽管日志从本质上，就是一行行的文本信息，但是由于其具有很大的灵活性，所以会很受开发和运维人员的重视。
日志本身从概念上，是一个很模糊的东西。你可以随便打开一个文件，然后写入一些信息。但是现代的服务器系统，一般都会对日志做一些标准化的需求规范：
日志必须是一行一行的，这样比较方便日后的统计分析;每行日志文本，都应该有一些统一的头部，比如日期时间就是基本的需求;
日志的输出应该是分等级的，比如fatal/error/warning/info/debug/trace等等，程序可以在运行时调整输出的等级，以便可以节省日志打印的消耗;日
志的头部一般还需要一些类似用户ID或者IP地址之类的头信息，用于快速查找定位过滤某一批日志记录，或者有一些其他的用于过滤缩小日志查看范围的字段，这叫做染色功能;日志文件还需要有&回滚&功能，也就是保持固定大小的多个文件，避免长期运行后，把硬盘写满。
由于有上述的各种需求，所以开源界提供了很多游戏的日志组件库，比如大名鼎鼎的log4j，以及成员众多的log4X家族库，这些都是应用广泛而饱受好评的工具。
不过对比日志的打印功能，日志的搜集和统计功能却往往比较容易被忽视。作为分布式系统的程序员，肯定是希望能从一个集中节点，能搜集统计到整个集群日志情况。而有一些日志的统计结果，甚至希望能在很短时间内反复获取，用来监控整个集群的健康情况。
要做到这一点，就必须有一个分布式的文件系统，用来存放源源不断到达的日志(这些日志往往通过UDP协议发送过来)。而在这个文件系统上，则需要有一个类似Map
Reduce架构的统计系统，这样才能对海量的日志信息，进行快速的统计以及报警。有一些开发者会直接使用Hadoop系统，有一些则用Kafka来作为日志存储系统，上面再搭建自己的统计程序。
日志服务是分布式运维的仪表盘、潜望镜。如果没有一个可靠的日志服务，整个系统的运行状况可能会是失控的。所以无论你的分布式系统节点是多还是少，必须花费重要的精力和专门的开发时间，去建立一个对日志进行自动化统计分析的系统。
【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
聚焦头条热点聚焦热点
24H热文一周话题本月最赞
讲师：126111人学习过
讲师：131978人学习过
讲师：51805人学习过
精选博文论坛热帖下载排行
本书按照人事部、信息产业部全国计算机技术与软件专业技术资格（水平）考试程序员考试大纲编写，是对2004版的修订版，内容包括计算机系统、...
订阅51CTO邮刊分布式服务框架：Zookeeper
来源：open开发经验库
Zookeeper是一个高性能，分布式的，开源分布式应用协调服务。它提供了简单原始的功能，分布式应用可以基于它实现更高级的服务，比如同步， 配置管理，集群管理，名空间。它被设计为易于编程，使用文件系统目录树作为数据模型。服务端跑在java上，提供java和C的客户端API。 Zookeeper是Google的Chubby一个开源的实现，是高有效和可靠的协同工作系统，Zookeeper能够用来leader选举，配置信息 维护等，在一个分布式的环境中，需要一个Master实例或存储一些配置信息，确保文件写入的一致性等。
Zookeeper总体结构
Zookeeper服务自身组成一个集群(2n+1个服务允许n个失效)。Zookeeper服务有两个角色，一个是leader，负责写服务和数据同步，剩下的是follower，提供读服务，leader失效后会在follower中重新选举新的leader。
Zookeeper逻辑图如下：
客户端可以连接到每个server，每个server的数据完全相同。
每个follower都和leader有连接，接受leader的数据更新操作。
Server记录事务日志和快照到持久存储。
大多数server可用，整体服务就可用。
ZooKeeper的基本运转流程：
选举Leader。
同步数据。
选举Leader过程中算法有很多，但要达到的选举标准是一致的。
Leader要具有最高的zxid。
集群中大多数的机器得到响应并follow选出的Leader。
Zookeeper表现为一个分层的文件系统目录树结构（不同于文件系统的是，节点可以有自己的数据，而文件系统中的目录节点只有子节点）。数据模型结构图如下：
圆形节点可以含有子节点，多边形节点不能含有子节点。一个节点对应一个应用，节点存储的数据就是应用需要的配置信息。
Zookeeper 特点
顺序一致性：按照客户端发送请求的顺序更新数据。
原子性：更新要么成功，要么失败，不会出现部分更新。
单一性 ：无论客户端连接哪个server，都会看到同一个视图。
可靠性：一旦数据更新成功，将一直保持，直到新的更新。
及时性：客户端会在一个确定的时间内得到最新的数据。
Zookeeper利于分布式系统开发，它能让分布式系统更加健壮和高效。它的主要优点有：
zookeeper是一个精简的文件系统。这点它和hadoop有点像，但是zookeeper这个文件系统是管理小文件的，而hadoop是管理超大文件的。
zookeeper提供了丰富的“构件”，这些构件可以实现很多协调数据结构和协议的操作。例如：分布式队列、分布式锁以及一组同级节点的“领导者选举”算法。
zookeeper是高可用的，它本身的稳定性是相当之好，分布式集群完全可以依赖zookeeper集群的管理，利用zookeeper避免分布式系统的单点故障的问题。
zookeeper采用了松耦合的交互模式。这点在zookeeper提供分布式锁上表现最为明显，zookeeper可以被用作一个约会机制， 让参入的进程不在了解其他进程的（或网络）的情况下能够彼此发现并进行交互，参入的各方甚至不必同时存在，只要在zookeeper留下一条消息，在该进 程结束后，另外一个进程还可以读取这条信息，从而解耦了各个节点之间的关系。
zookeeper为集群提供了一个共享存储库，集群可以从这里集中读写共享的信息，避免了每个节点的共享操作编程，减轻了分布式系统的开发难度。
zookeeper的设计采用的是观察者的设计模式，zookeeper主要是负责存储和管理大家关心的数据，然后接受观察者的注册，一旦这些数 据的状态发生变化，Zookeeper 就将负责通知已经在 Zookeeper 上注册的那些观察者做出相应的反应，从而实现集群中类似 Master/Slave 管理模式。
Zookeeper 会维护一个具有层次关系的数据结构，它非常类似于一个标准的文件系统，如图所示：
Zookeeper 这种数据结构有如下这些特点：
每个子目录项如 NameService 都被称作为 znode，这个 znode 是被它所在的路径唯一标识，如 Server1 这个 znode 的标识为 /NameService/Server1
znode 可以有子节点目录，并且每个 znode 可以存储数据，注意 EPHEMERAL 类型的目录节点不能有子节点目录
znode 是有版本的，每个 znode 中存储的数据可以有多个版本，也就是一个访问路径中可以存储多份数据
znode 可以是临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除，Zookeeper 的客户端和服务器通信采用长连接方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为 session，如果 znode 是临时节点，这个 session 失效，znode 也就删除了
znode 的目录名可以自动编号，如 App1 已经存在，再创建的话，将会自动命名为 App2
znode 可以被监控，包括这个目录节点中存储的数据的修改，子节点目录的变化等，一旦变化可以通知设置监控的客户端，这个是 Zookeeper 的核心特性，Zookeeper 的很多功能都是基于这个特性实现的，后面在典型的应用场景中会有实例介绍
四种类型的znode：
PERSISTENT-持久化目录节点。客户端与zookeeper断开连接后，该节点依旧存在
PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点。客户端与zookeeper断开连接后，该节点依旧存在，只是Zookeeper给该节点名称进行顺序编号
EPHEMERAL-临时目录节点。客户端与zookeeper断开连接后，该节点被删除
EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点。客户端与zookeeper断开连接后，该节点被删除，只是Zookeeper给该节点名称进行顺序编号
ZooKeeper Client Library提供了丰富直观的API供用户程序使用，下面是一些常用的API：
create(path, data, flags): 创建一个ZNode, path是其路径，data是要存储在该ZNode上的数据，flags常用的有: PERSISTEN, PERSISTENT_SEQUENTAIL, EPHEMERAL, EPHEMERAL_SEQUENTAIL
delete(path, version): 删除一个ZNode，可以通过version删除指定的版本, 如果version是-1的话，表示删除所有的版本
exists(path, watch): 判断指定ZNode是否存在，并设置是否Watch这个ZNode。这里如果要设置Watcher的话，Watcher是在创建ZooKeeper实例时 指定的，如果要设置特定的Watcher的话，可以调用另一个重载版本的exists(path, watcher)。以下几个带watch参数的API也都类似
getData(path, watch): 读取指定ZNode上的数据，并设置是否watch这个ZNode
setData(path, watch): 更新指定ZNode的数据，并设置是否Watch这个ZNode
getChildren(path, watch): 获取指定ZNode的所有子ZNode的名字，并设置是否Watch这个ZNode
sync(path): 把所有在sync之前的更新操作都进行同步，达到每个请求都在半数以上的ZooKeeper Server上生效。path参数目前没有用
setAcl(path, acl): 设置指定ZNode的Acl信息
getAcl(path): 获取指定ZNode的Acl信息
Zookeeper的应用场景：
1、命名服务
命名服务也是分布式系统中比较常见的一类场景。在分布式系统中，通过使用命名服务，客户端应用能够根据指定名字来获取资源或服务的地址，提供者等信 息。被命名的实体通常可以是集群中的机器，提供的服务地址，远程对象等等——这些我们都可以统称他们为名字（Name）。其中较为常见的就是一些分布式服 务框架中的服务地址列表。通过调用ZK提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。
2、配置管理
程序总是需要配置的，如果程序分散部署在多台机器上，要逐个改变配置就变得困难。现在把这些配置全部放到zookeeper上去，保存在 Zookeeper 的某个目录节点中，然后所有相关应用程序对这个目录节点进行监听，一旦配置信息发生变化，每个应用程序就会收到 Zookeeper 的通知，然后从 Zookeeper 获取新的配置信息应用到系统中就好。
3、集群管理
所谓集群管理无在乎两点：是否有机器退出和加入、选举master。
对于第一点，所有机器约定在父目录GroupMembers下创建临时目录节点，然后监听父目录节点的子节点变化消息。一旦有机器挂掉，该机器与 zookeeper的连接断开，其所创建的临时目录节点被删除，所有其他机器都收到通知：某个兄弟目录被删除，于是，所有人都知道：它上船了。新机器加入 也是类似，所有机器收到通知：新兄弟目录加入，highcount又有了。
对于第二点，我们稍微改变一下，所有机器创建临时顺序编号目录节点，每次选取编号最小的机器作为master就好。
4、分布式锁
有了zookeeper的一致性文件系统，锁的问题变得容易。锁服务可以分为两类，一个是保持独占，另一个是控制时序。
对于第一类，我们将zookeeper上的一个znode看作是一把锁，通过createznode的方式来实现。所有客户端都去创建 /distribute_lock 节点，最终成功创建的那个客户端也即拥有了这把锁。厕所有言：来也冲冲，去也冲冲，用完删除掉自己创建的distribute_lock 节点就释放出锁。
对于第二类， /distribute_lock 已经预先存在，所有客户端在它下面创建临时顺序编号目录节点，和选master一样，编号最小的获得锁，用完删除，依次方便。
5、队列管理
两种类型的队列：
1、同步队列，当一个队列的成员都聚齐时，这个队列才可用，否则一直等待所有成员到达。
2、队列按照 FIFO 方式进行入队和出队操作。
第一类，在约定目录下创建临时目录节点，监听节点数目是否是我们要求的数目。
第二类，和分布式锁服务中的控制时序场景基本原理一致，入列有编号，出列按编号。
6、负载均衡
这里说的负载均衡是指软负载均衡。在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑，其中比较典型的是消息中间件中的生产者，消费者负载均衡。
7、分布式通知/协调
ZooKeeper中特有watcher注册与异步通知机制，能够很好的实现分布式环境下不同系统之间的通知与协调，实现对数据变更的实时处理。使 用方法通常是不同系统都对ZK上同一个znode进行注册，监听znode的变化（包括znode本身内容及子节点的），其中一个系统update了 znode，那么另一个系统能够收到通知，并作出相应处理。
参考链接：
引用地址：http://www.biaodianfu.com/zookeeper.html
免责声明：本站部分内容、图片、文字、视频等来自于互联网，仅供大家学习与交流。相关内容如涉嫌侵犯您的知识产权或其他合法权益，请向本站发送有效通知，我们会及时处理。反馈邮箱&&&&。
学生服务号
在线咨询，奖学金返现，名师点评，等你来互动芯片制造工艺真的很难吗，自制芯片作为一个趋势存在，广……
进入中国三十一年以来，德州仪器（TI）在不断推出创新半……
2017德州仪器（TI）中国教育者年会上，TI与来自全国97所……
最近，博通收购高通的新闻引起了广泛的关注，您如何看待……
最近，博通收购高通的新闻引起了广泛的关注，您如何看待……
演讲人：刘烁时间： 10:00:00
演讲人：徐济炜时间： 10:00:00
演讲人：孙彬时间： 10:00:00
预算：￥25000预算：￥10000
广东省广东省
基于CAN总线的分布式热电阻智能节点的设计
现场总线技术是当今自动化领域发展的热点，德国bosch公司的can是为解决汽车内部的复杂硬信号接线提出的，而其应用范围正逐渐向过程控制、机器人、数控机床、医疗器械及传感器等领域发展。can总线以其独特
现场总线技术是当今自动化领域发展的热点，德国bosch公司的can是为解决汽车内部的复杂硬信号接线提出的，而其应用范围正逐渐向过程控制、机器人、数控机床、医疗器械及传感器等领域发展。can总线以其独特的设计、低成本、高可靠性、实时性、抗干扰能力强等特点得到了广泛的应用。本文选用can总线设计了分布式热电阻智能节点，利用can总线连接各个网络节点，可以直接与主控卡或上位机通信，组建成工业网络分布式测控系统。本文引用地址:
2& 热电阻智能节点硬件设计
2.1智能节点整体结构
本热电阻智能节点设有4路输入通道，支持3线制方式，支持热电阻类型有cu50、cu100和pt100，采用freescale mc9s12d64单片机作为微控制器，其内部有一个can通信模块（mscan），符合can2.0a/b标准，所以不需要扩展can通讯控制器。can接口收发器采用pca82c250作为can通信模块和物理传输线路之间的接口。节点通过24位a/d转换器ads1216对组态通道进行采样，由于热电阻的阻值与温度成正比关系，需将已知电流流过该电阻以得到与温度成正比的输出电压。本文使用ads1216的两个8位电流输出idac1和idac2作为恒流源，通过模拟开关max355选通相应的组态通道，然后ads1216对得到的电压信号进行采样并输出至微控制器，经校正后进行标度变换转化成相应的电阻值，查热电阻分度表即可得到所测温度。本节点也可通过rs485接口并严格按照modbus协议进行通信，rs-485收发器采用sn65lbc184。
本热电阻智能节点硬件结构框图如图1所示。
图1 热电阻智能节点硬件结构框图
2.2信号输入端电路与采样电路
信号输入端电路与采样电路原理图如图2和图3所示。
图2 热电阻信号输入端电路
图3& a/样电路
max355差动4通道模拟开关接4路热电阻信号转换电路，图中只画出第一路转换电路，接线方式为三线制，使能端en接高电平，使max355一直有效。a0、a1引脚接至mc9s12d64单片机的pp0和pp1端，用于选通某一路热电阻信号进行转换与测量。当max355选通某一通道后，该通道将与公共端接通，假设选通通道1，200ua恒定电流由no1a和no1b输出流经热电阻产生毫伏级电压信号，此信号在vin1和vin2处被ads1216采样。
ads1216组成4路全差分通道。单片机通过porta与ads1216通信，用于控制ads1216选通某一路模拟量输入通道并进行采样，每一个控制信号均通过光耦合器和两个施密特触发器进行数字隔离，这样做可有效抑制各种噪声干扰，提高传输通道上的信噪比。ads1216采样每一路通道之前均进行偏置与增益自校准。当/drdy变为低电平，标志着数据寄存器中数据已准备好，单片机便从24位数据输出寄存器（dor）读取转换结果。
2.3 can和rs-485通信电路
can和rs-485通信电路原理图如图4所示。
mc9s12d64单片机的can输入与输出引脚（rxcan0和txcan0）分别接至收发器pca82c250的txd和rxd引脚。pt2用来控制数据接收与发送，当pt2为低电平时，接收数据；当pt2为高电平时，发送数据。输入rs通过一电阻接地，使pca82c250工作在斜率控制模式下。sn65lbc184为具有瞬变电压抑制的rs485差分收发器，因此本智能节点可以接入采用canbus或rs485的测控系统，并方便的与各种组态软件进行通信。
图4& can和rs-485通信电路
3& 热电阻智能节点软件设计
单片机程序用mc9s12汇编语言编写。在主程序首先完成各寄存器和存储单元的初始化，再通过调用读取地址子程序，得到i/o板卡的地址和can通信波特率，再完成mscan模块和ads1216初始化。随后调用e2prom中组态信息，对每一路组态通道进行信号转换，数字滤波及温度查表计算等，其主程序流程图如图5所示。
& 图5 热电阻智能节点主程序流程图
由于现场的各种干扰很容易使信号失真，从而使a/d转换结果产生比较大的误差。因此在对信号进行有效的硬件滤波后还需进行软件滤波，本节点采用了数字中值滤波、算术平均、加权滤波等方式。
3.2 节点与上位机的can通信
智能节点与主控卡或上位机的通信主要基于can通信协议来完成，它的优点是能够实时处理数据、在恶劣环境下正常工作、成本低且拥有比较高的带宽。由于上位机内部无can网络适配器，因此需外接rs-232/can转接卡，实现上位机与智能节点的通信。通过节点上的跳线设置节点地址，当上位机发出命令时，节点进入can接收中断，对数据解包放入接收缓冲区并调用数据处理函数。当上位机发出组态命令时，单片机会将收到的组态通道信息和信号类型写入e2prom保存，并回送一帧数据通知上位机组态信息已成功接收。当接收到上传rtd值命令时，单片机会将内存中的4路rtd温度值以多帧形式发送给上位机。
3.3 rtd阻值变换算法
软件设计中关键算法在于rtd电压阻值的转化，刻度点间的线性化及标度变换。以pt100热电阻的温度刻度表为例，
pt100tab：fcb 04h,00h,07h,39h,08h,0e8h,0ah,94h,0ch,3ch,
& fcb 0dh,0e1h, 0fh,83h,11h,23h,12h,0c0h,14h,5bh,
& fcb 15h,0f3h,17h,89h,19h,1eh,1ah,0b1h,1ch,41h,
& fcb 91h,84h,92h,0afh,93h,0d8h,95h,01h,96h,28h,
& fcb 97h,4eh,98h,72h,9ah,0cah&
分度表由-210℃开始每间隔10℃作为一个刻度点，每一个刻度点的电阻值扩大100倍后转换为十六进制数即构成上表。考虑到表格的一致性，cu100和cu50热电阻的分度表也从-210℃开始计算。
当得到校正后的ad转换数值后，需要将采样到的电压信号转换为电阻值以便于查表。阻值计算公式如下：
r即为实际热电阻阻值，在这里将其扩大100倍以便于查表。
3.4 分段线性化查表
得到的对应阻值后，则从第0个刻度点开始比较，如果该采样值大于第0个刻度点，则再与下一个刻度点比较，同时记录小于该采样值的刻度点的个数n，如果采样值小于某一温度刻度点，则温度位于该刻度点b与前一个刻度点a之间，温度线性化在a、b两刻度点之间进行，线性化得到的温度加上a点对应的温度（n&10）即为采样温度。
以pt100热电阻为例，某一通道得到校正后的采样值为$9343，则前8个刻度点均小于$9343，第9个刻度点值大于$9343，记录小于该采样值的刻度点的个数n＝101，此时a点（第101个刻度点$92af）对应温度为10&101＝1010℃，b点（第9个刻度点$93d8）温度为1020℃，线性化在a、b两点间进行，具体公式为：
[（＄934-＄92af）/（＄93d8-＄92af）]&10=5℃
所以$9343对应的温度为：
a点（第101个刻度点）对应温度1010℃+线性化温度5℃-210℃=805℃
其中，各表均以-210℃作为起始，故计算温度时应减去210℃。
本智能测控节点主要完成对现场热电阻信号进行采集和处理。在实验室条件下，利用电阻计代替现场的热电阻信号，经过反复测试，温度测量值均正确，并且误差在&1%以内。另外在监控程序的控制下，节点能够有效配合上位机完成系统的组态、信号校正和上传等功能，具有可靠、实时、灵活等特点。
闫志红（1986-）女 在读硕士，现就读于山东大学控制科学与工程学院，研究方向为自动化装置的集成化与智能化。
[1]李正军．计算机测控系统设计与应用[m]．北京：机械工业出版社，2004．
[2]李正军．现场总线及其应用技术[m]．北京：机械工业出版社，2005．
[3]孙同景．freescale十六位单片机原理及嵌入式开发技术[m]．北京：机械工业出版社，2008．
[4]邵贝贝著．单片机嵌入式应用的在线开发方法[m]．北京：清华大学出版社，2004．
随着日元逐步走高，在日本本土生产产品变得愈来愈不划算。许多日商都在考虑（或已经）将大部份的生产移到海外，但一直有 MIJ 传统的 Canon 却选择用生产线自动化的方式，来对抗节节升高的成本。该公司发言人表示，在......关键字：
Apple 刚刚推出了在 15.4 加┠豢占淠谟涤 2,880 x 1,800 像素(220ppi)的新一代 MacBook Pro，应该有不少第三方软体开发商在忙着为旗下软体的像素升级了。想不到 Apple 的死敌 Google 旗下......关键字：
硬盘厂商之间的竞争颇大，偶有两厂整合或并购的情况发生，所以他们当然要来些新意，寻找新方向吧。Toshiba 刚刚发表旗下第一款与网络整合的个人云端装置 -- Canvio Personal Cloud。它有 2TB 和 3TB 的选择，不......关键字：
你有没有想过把超极本 7mm 厚的硬盘拿出来放进硬盘盒里做成移动硬盘?现在看来至少东芝是这么想的，而且他们还把这个想法变成了现实。东芝旗下的 Canvio 系列行动硬碟最近迎来了新成员 Canvio Slim，这款产品的厚度仅......关键字：
21ic讯，法国Mecanroc公司近日推出了一款单座四驱越野车E-Spider。什么什么?你说你没听过?这不是像路虎、jeep等等一样的越野汽车。这一款车并不附带很多高科技。它最大的特点是，它的四个轮毂连接着的支臂与它的悬挂......关键字：
Microchip Technology Inc.(美国微芯科技公司)日前宣布，开始提供业界第一款外部CAN灵活数据速率(CAN FD)控制器。采用MCP2517FD，设计人员能够很快从CAN 2.0升级到CAN FD，受益于CAN FD......关键字：
经过四年发展的检验，我国分布式光伏电站的发展出现了四大深层次矛盾。庆幸的是，解决这些深层次矛盾并非毫无办法，而是有章可循。......关键字：
我 要 评 论
热门关键词