精华内容
下载资源
问答
  • 本视频教程以新的信息系统项目管理师教程(第三版)为蓝本,结合小任老师多年高校教学经验和软考培训经验录制。参加工作后,我们没有太多的时间投入到信息系统项目管理师的备考中,教程太厚、真题太难,怎样花少的...
  • 2017年上半年(5月份)软考 信息系统项目管理师下午案例分析真题及答案解析,全网最清晰,答案最正确的真题资料。小任老师出品,必属精品。
  • 本课程套餐包括信息系统项目管理师基础知识上、下、上午真题解析、案例分析解析和论文写作五部分内容,涵盖了信息系统项目管理师考试的所有内容,通过该视频学习,有效缩短备考时间,提高效率。购买本套餐,讲师提供...
  • 消息系统介绍及选型依据

    千次阅读 2017-12-04 16:10:57
    消息系统目前已经广泛使用于互联网企业,各类业务系统都有它的身影,一方面是其传统的功能特点:系统间调用的异步解耦,减低系统的复杂度、流量的削峰填谷,便于业务弹性伸缩、易于实现最终一致性系统,避免分布式...

     

    消息系统介绍及选型依据

    消息系统目前已经广泛使用于互联网企业,各类业务系统都有它的身影,一方面是其传统的功能特点:系统间调用的异步解耦,减低系统的复杂度、流量的削峰填谷,便于业务弹性伸缩、易于实现最终一致性系统,避免分布式事务对性能的影响、支持P2P(点对点的调用)和pub/sub模式减少RPC的多次调用(广播通知机制)等。另外随着业务的快速增长,企业内部需要大量数据的同步传输,流式计算等应用都需要非常稳定高效的传输通道给予支持,消息系统在其中充当了重要的角色。

    目前使用较为广泛的消息中间件(MOM)主要有:rabbitmq、kafka、RocketMQ(MetaQ)、ActiveMQ或ZeorMQ等产品;

     

    1.        系统功能介绍

     

    n  消息系统对企业异构系统集成有着重要的使用场景,各系统遵循协商的数据规范进行生成和消费消息,系统间通讯从传统RPC服务接口调用方式转换到数据协议的通讯方式,使得系统耦合度降低,责任边界更明确,同时有利于系统升级发布,可持续集成部署;

    n  消息通知机制使得系统异步处理变得简单,同步调用需要阻塞当前线程等待结果返回,会影响系统的并发能力;而消息通知方式是由上游业务将请求转化为消息的形式发往消息中间件(MOM)即可返回,无需等待后续业务处理,下游获取消息后异步的处理后续逻辑。

    n  业务流量的削峰填谷;传统RPC同步调用(PUSH模型)在应对突增性流量时,一般采用扩容/降级/熔断等机制来保护下游核心服务的正常运行; 而消息系统在调用中间层增加了一道缓冲机制,暴增流量发生时,通过消息积压的方式存储在broker中,下游服务根据自身处理能力,量力而行的拉取消息进行消费,不会给后续服务带来毁灭性冲击;

    n  消息系统易于业务实现最终一致性场景;传统的强一致性的事务,一般通过二阶段或三阶段提交方式来实现,但是性能较差容易造成性能瓶颈;通过消息系统的消息通知机制和补偿手段来达到分布式系统的数据一致,很大程度上改善了系统性能和吞吐能力;

    n  支持P2P和pub/sub模型;点到点的调用类似RPC的行为;另外一种是广播机制,比如缓存通知,需要更新所有本地缓存;RPC的方式实现,每接入一个新业务方需要调一次方法,难以动态接入和灵活性较差;消息系统绝大多数支持广播的方式,极大简化业务逻辑处理和提供灵活接入的能力;

    n  快速数据传输,为在线流式计算提供可靠的数据通道。分布式环境中各类异构数据源分散杂糅,高效快速的归集数据,并为实时数据分析模型高效地传导数据,对现代互联网企业有着至关重要的作用。

     

    2.        核心技术剖析

    1.        消息协议支持

    消息协议分为即时通信协议和延迟通讯协议;

    Ø  即时通信协议常用于RPC通信系统,端到端的进行传输采用push的方式,发送方需立即得到消费方的响应;如RMI,Thrift,Avro等协议;

    Ø  延迟类通讯协议,消息一般经由中间层broker存储后,当条件满足时再分发至消费端;常见通信协议如:xmpp, stomp, mqtt, amqp或 binary私有协议;消息中间件采用的便属于此类延迟性协议;

    xmpp, stomp, mqtt, amqp属于标准化通讯协议,被广泛使用在消息中间件设计之中,这类标准协议通常基于消息的状态机模型而设计,消息投递过程中的各种状态都从协议层面进行了精心设计和可靠性处理,有的协议在可靠性方面设计过于复杂,冗余信息也多,交互频率高,性能上会有大量损耗;因此在追求高性能大并发的消息系统中,也常见采用私有协议来进行交互,尽管在扩展性和灵活性上有所下降,但协议设计更紧凑,通信负载更轻量级;比如kafka或rocketmq等消息系统均采用自定义协议来进行设计;

    2.        通信系统设计

    消息系统处于星型调用关系的中间节点,起着承上启下的关键作用;如何支持单节点达到高的连接数(cps)和高的吞吐量(qps)对通讯层的设计有很高的要求;常常从以下角度来进行考虑:

    Ø  建立TCP长链接,减少频繁握手的开销;

    Ø  链路空闲(idle)和检活(heartbeat)处理, 回收空闲和非活的链接资源;

    Ø  多路复用及非阻塞IO方式提高单链接多通道的通讯方式;

    Ø  io线程池隔离机制,io线程只负责req/resp的读写,各类业务线程池进行隔离避免重业务逻辑的资源池复用;

    Ø  通讯协议设计,比如选用protocolbuf或者私有协议以降低包体大小;

    Ø  对请求进行合并和批量发送的方式;

    Ø  基于jvm的设计时,减少堆内存回收对网络io的影响,比如采用zero-copy的方式避免堆内存的申请;

    Ø  具体实现上可选择netty框架(java语言)降低开发的复杂度。

    3.        存储系统设计

    存储系统需要考虑:

    Ø  消息物理存储格式设计

    优秀的存储格式的设计,一方面节省存储资源,比如利用位域存储来实现字节的复用,利用族群分块和相对位移/增量存储降低存储开销;另一方面,存储格式的边界对齐考虑也有利于高效的读写性能;

    同时要考虑数据的完整性检查,各类索引的创建以及如何快速检索定位消息;

    Ø  消息存储介质选择

    n  日志文件存储方式

    选择日志文件来持久化消息,需要考虑:

    1.      如何保证高效的读写性能:比如写时采用AOF方式进行记录;利用os的pagecache来改善磁盘访问性能和安全性;

    2.      日志文件的保留策略,磁盘是有限资源如何管理和制定妥善的清除策略对存储系统尤为关键;

    3.      异常退出,通过日志的如何快速恢复系统;

    4.      队列一般是无限长度的空间,需设计好与有限的存储文件之间的映射;

    5.      不同业务队列采用单一的事务日志进行存储,还是不同业务采用物理隔离的日志进行存储;两种存储方式在不同的业务场景下各有优势,在不同的开源产品中也都有采用;

    n  数据库存储的方式

    采用数据库存储一般源于多维度查询的需求和长久保存消息方便消息审计的目的,利用数据库自身的索引机制给消息的检索带来便利;但需要解决数据库性能吞吐,数据库具有强事务性特点,系统开销会比较大;

     

    4.        路由策略机制

    消息路由是消息系统的核心内容,包括路由元数据管理和消息数据分发策略的实现;

    l  元数据管理:用以描述消息队列的物理存储地址,容量大小,分片情况;

    l  消息分发策略:根据消息的路由键和系统的路由元数据,通过不同的路由策略算法计算获取落盘的具体物理地址;发送和消费可以共用相同的路由元数据,采用不同的路由算法机制,以达到各类消费的目的;

    具体实现方式:有的路由策略放在server端实现;有的通过客户端来实现;

    例如:

    rabbitmq的路由逻辑放在服务端来实现;通过声明exchange和queue的绑定关系来确定路由情况,支持比较丰富的路由策略,direct/topic/fanout/header等方式以满足不同的业务需求,可以满足绝大部分的应用场景,不支持用户自定义策略;

             kafka的路由逻辑在客户端实现;客户端会定时和特定情形下主动拉取路由元数据,通过客户端的路由算法来确定消息的存储地址并创建tcp链接与存储broker进行通信;路由算法在客户端有缺省实现同时支持用户实现接口的方式进行自定义,提供灵活的配置方案和动态调节能力;

     

    5.        负载均衡策略

    负载均衡对分布式应用的稳定运行有极其重要的意义,如何防范流量不均衡导致集群雪崩效应的发生,又或是负载的不平衡造成系统的瓶颈,不能发挥最大的效能;请求负载能否自动化调节或是人工管理的方式进行灵活的分配调整,对系统健康度有着积极的作用,同样负载均衡对消息系统设计亦是如此。

     

    负载均衡的设计,可以从客户端和服务端两方面来考虑:

    如4中所言的路由策略,在一定意义上可以实现负载的平衡调节,不同的路由策略可以让流量进入到不同的集群节点进行处理;客户端通过调节路由算法来达到系统负载平衡;

    随着集群不断的扩容,资源分布不均衡性逐步显现,资源分布如何动态进行迁移显的尤为关键, 服务端提供出灵活的监控和管理策略来调节节点资源分配就很有必要;比如多副本资源如何协调好leader节点在集群中的分配,对系统吞吐能力有很大的影响。

    负载均衡策略在各个子系统中都需要进行细致设计和考虑,以充分发挥单节点和集群的整体性能。

     

    6.        HA高可用设计

    系统高可用从技术和业务层面都需要进行考量;

    比如:日志副本的复制/同步管理,采用怎样的同步机制能保证节点失效时能快速切换到新的副本节点继续提供服务;同时保证数据在多副本之间的一致性,以保障消息不丢;这里涉及到两个方面的问题:

    1. Leader节点的选举机制;

    2. 副本的同步机制,如何保证副本的一致性;

    针对以上问题,目前有多种一致性协议来处理,如paxos,raft,pacificA以及私有同步协议来解决副本的一致性问题;协议目的是要解决以上2个重要问题,实现时有很多安全机制需要考虑去解决各类异常情形,比如网络分区,出现慢设备,网络抖动,反复选举,日志回滚安全机制等等问题;

     

    同时业务层面采用ack机制去保证业务正常被处理;发送时如何保证消息安全被传输和存储;消费时如何保证业务正确被执行,失败时如何进行重试,并最终提供安全的ack方式;这些都需要在设计上提供友好的处理方式。

     

    7.        流量控制设计

    消息系统承载着众多的业务数据,各业务重要程度不同,业务流量各异,遇到突增流量,对集群造成风险时;集群需在流量管理上进行流控处理以防止服务宕机,常采用阈值判断的方式来禁止请求进入;

    比如:在网络io层或者业务reqest分发层来进行控制,采用blockingqueue的rejected策略,当内部业务线程处理延迟时,请求队列已经塞满的情况下,采取拒绝外部新请求来保证核心逻辑处理;

    另外针对不同链接做细粒度的流量控制,对不同的业务流量采取有区别的控制方式,例如kafka根据clientid来区分具体客户端实例进行流量的细粒度控制;

    除了server端的流量控制之外,也可在客户端进行流量监控和并发流量控制;客户端的流量在大促期间很容易出现流量尖刺,控制这些流量峰值对系统稳定性非常有价值,如何消除尖峰平稳流量,常常通过拥塞窗口的方式来进行控制,比如利用信号量来控制并发线程的网络io等等方式。

     

    8.        安全认证和传输安全设计

    作为企业级消息总线,安全接入和信息传输的安全性至关重要;

    接入认证对管理各类应用接入意义匪浅,例如通过Oauth认证来实现平台级管理客户端实例的功能;

    信息的传输安全和系统性能常常不能兼得,信息加/解密操作会影响系统的吞吐,因此设计时根据具体场景来考虑;

     

    9.        消息索引机制

    在提供平台级消息服务时,业务方常常需要对发送或者消费完的消息进行检索服务,进行快速定位、排查问题或是后期补偿措施;

    消息队列通常数据量比较大,同时大部分场景使用完消息即可丢弃等特点,如何提供高效的创建索引机制、快速查询方案,以及索引的删除机制都有很大的挑战;

             对于吞吐不大的业务需求,底层通过数据库进行存储,依赖数据进行索引创建来支持多维度的查询需求,是非常适合的场景,数据库的索引建立在B+tree结构上,查询性能logm(N),同时btree是动态平衡树,记录的插入都会造成tree的调整都会带来较大的系统开销,性能欠佳;

             另外一种如rocketmq的索引方案通过预分配hash文件的方式来创建文件hash表,利用文件系统的pagecache来达到内存级别的O(1)访问速度;对于hash键碰撞问题未能提供re-hash的处理机制,预分配时是已经确定了最大hash槽位,检索碰撞键值时退化到链表的查找性能,需业务上精心设计查询键值;

             也可接入外部索引方案如ES系统,通过消费的方式对所有集群的消息进行索引创建,可以只考虑索引的存储,避免索引过大,带来系统的开销和检索性能的下降。

     

    10.     消息的幂等处理

    幂等处理是业务层面考虑的重要议题,如何在消息技术层面降低重复消息的影响,通常需要从上下游综合考虑;

    1.      发送端发出的消息如何保证在broker端进行唯一存储,这是上游发送需要考虑的幂等问题;由于网络不稳定或丢包造成发送ack包丢失,业务层面采取重试后就易造成消息的重复存储;在server端进行消息去重,要求server端能缓存和识别消息的标识码,进而实施去重操作;这种标识需要在集群层面全局唯一,最有效的处理方式,是集群server能提供生成唯一标示码的服务,发送端发送之前需要首先从server端获取标识消息的标识码,进而发送,server端通过预申请的标识来过滤重复消息;

    2.      消费端去重处理,消息系统在投递消息时一般支持at-least-once的投递保证;当消费客户端发生rebalance或是集群元数据异动后都有可能造成消息重新投递至客户端;客户端如何识别重复消息并进行去重处理,一般做法采用缓存某个时间窗口的消息标识,继而来过滤短时间内的大量重复情形;这依赖本地缓存或是中心化缓存的大小,本地缓存问题在于发送客户端rebalance之后,缓存失效问题,中心化缓存会引入第三方存储的复杂度;不引入第三方缓存服务亦可基于消息系统本身来实现中心化缓存的目的;以上考虑只能去除短时期内的重复问题,因为内存大小的限制;要彻底解决幂等性问题还需要业务上配合进行更严格的幂等判断,比如实现业务上的状态机,避免相同状态反复处理问题;

     

    11.     事务性消息支持

    事务性消息有两个层面的含义:

    1.      业务操作和消息发送的同步成功或同时失败;例如:数据库的修改事务完成后,消息才能同步投递消费端;这种情况为什么采用事务消息来处理,事务消息在实现时一般采用2阶段commit方式来完成;pre-commit阶段消息已经发送至server端并持久化存储,该阶段有较重的业务逻辑,第二阶段进行commit或rollback来判定消息是否对外发布,处理逻辑相对轻量级,出问题的概率小很多;如果不采用事务消息的方式发送,有可能数据库修改完成了,但是发送消息逻辑一直处于失败之中,造成业务逻辑处理的不一致;而采用事务消息发送时,消息先进行了存储,之后进行数据库的操作,根据数据库操作的成败来决定消息的提交或回滚;

    2.      事务性消息需要保证在单事务内所有消息的原子性和顺序性;意味着事务开始后,所有该事务内发送的消息,在提交完成后,消息同时对外进行发布及消费者能够消费该批消息,如果回滚该事务,则此类消息对外不可见;并且事务内的消息顺序需要保证;

    事务性消息设计需要考虑,消息的二阶段提交过程,在此过程中需要考虑第二阶段过程出现异常后,比如commit/rollback丢包或这阶段发送实例crash,本地事务并未完成时,server端如何进行远程回查并完结该事务;另外该事务内的批量消息的顺序如何保证。

    12.     顺序性消息支持

             顺序消息一般通过队列来实现,依赖队列先进先出的机制来保证消息投递的顺序性;

             单队列的吞吐有限,如何提升性能,自然想到的一个方式增加队列数,支持更多并发线程来处理多个队列消息;

             队列之间并不能保证顺序,消息的全局顺序性是无法保证的;通常结合业务特征,对顺序消息进行细分,将顺序消息负载到不同的队列上支持更好的并发度;

             多个队列提供顺序服务时,需要考虑消费端的rebalance机制,例如缺省的负载分配方式,会造成rebalance阶段出现短暂的消息混乱;因此需要精心设计该部分逻辑。

     

    13.     消息优先级

             消息队列实现排序一般通过额外索引来实现,基于数据库存储支持排序实现相对简单,数据库自身的索引机制就能支持,但随着吞吐量的增高和消息量的增加,动态索引创建会给系统带了很大的负荷;

             基于文件存储的消息队列做优先级排序实现更为困难,即便使用额外索引文件做排序方案,随着消息量的增加,索引文件排序必然导致文件外排序,索引项的不断调整会引起频繁的io,性能会产生瓶颈;

             另外的方式,对消息设定有限的优先级别比如最大128个优先级;通过桶排序的方式,将不同优先等级的消息存储到不同级别的桶中,投递消息时按照桶的优先级进行顺序投递;基于这种思想,消息队列并非需要支持优先级排序功能,也可从业务使用的场景上出发,通过申请多个消息队列,队列有优先级顺序,在发送消费时做好优先级别分配也能达到同样的效果。

     

    14.     消息回溯

             消息回溯在各项业务中都有广泛的应用,比如索引恢复/本地缓存重建,有些业务补偿方案也可采用回溯的方式来实现;

             消息回溯需要解决的是查找回溯的基点,通常按时间维度和绝对位点来进行消息起点的定位;消息队列如果实现了多维度查询亦可按照查询维度定位消息的位点后再重置回溯起点;

             在PUSH消费模式下,除更新server端存储的消费进度外,同时也需通知所有对应的消费端重置pull消息的位置信息,重新进行消息拉取动作;

     

    15.     消息广播

             大部分消息系统支持pub/sub的订阅方式,不同的消费group能全量消费订阅队列的所有消息,组内实例间采用并行互斥的方式消费消息;组间的广播常常会造成业务部署时的苦恼,每个环境下需要申请不同的group名来进行配置,遗漏或错误配置都会引起生产事故;在这种场景下,实现组内的广播机制,对业务会有很大的帮助,在设计客户端rebalance机制和位点持久化方面需要精心考虑。

     

    3.        常见消息系统对比

             本文主要从几种常见的消息系统来进行比较目前主要使用几种消息系统:kafka和rabbitmq,和阿里开源消息系统RocketMQ各自的不同特性:

     

     

            消息系统

    特征比较

    Kafka

    RabbitMQ

    RocketMQ

    Server

     

     

     

    消息协议支持

    1.        支持kafka私有协议(参考kafka协议

    1.        支持比较丰富的消息协议,通过插件的方式进行添加;

    2.        支持AMQP, mqtt, stomp等等协议

    1.        支持rocketmq私有协议

    2.        支持mqtt协议

    数据一致性保证

    3.        支持类pacificA协议的副本复制方式; 通过ISR来保证副本之间的同步性;

    4.        支持数据强一致性语义;

    5.        leader节点由集群的controller角色决策,支持动态调节leader分布情况以调节负载平衡;

    6.        支持大规模集群的部署,分区容错性非常好;

    7.        元数据管理依赖zookeeper集群来存储

    8.        Leader/follower是队列级别,主备切换只影响该队列;

    9.        读/写只发生在leader节点上;

     

    1.        基于erlang语言级通讯同步框架 的方式;

    2.        支持数据强一致性语义;

    3.        对网络延迟和稳定性较为敏感,易产生集群脑裂;

    4.        跨机房大规模部署时依赖于第三方插件如federation插件等,但分区容错性不足;

    5.        Leader/follower同样是队列级别,主备切换只影响该队列

    6.        读/写只发生在leader节点

    1.        通过私有协议来进行主备同步;

    2.        不支持在线的主备切换,通过配置方式决定主备实例;

    3.        主备角色是实例级别的,切换时会引起节点上所有的队列不可用;

    4.        写事件发生在leader节点,读事件可以从follower节点执行;

    路由策略支持

    1.        支持topic路由方式;

    2.        Server端保存和维护topic所有分区partition的存储信息;

    3.        路由算法由客户端实现,默认情况采用hash的算法来计算存储地址,客户端会定时拉取server端路由表通过路由算法来确定存储地址;

    1.        支持exchange的多种路由策略,如direct/topic/fanout/head等;

    2.        元数据存在于server端,路由策略由server执行,仅支持有限的路由方式;

    3.        客户端无法灵活制定不同的路由策略来满足各类需求。

    同kafka 的topic路由方式

    日志保留策略

    1.        支持按时间清除日志的方式,根据保留时间阈值扫描日志的最后修改时间进行清除动作,批量清理处理效率极高;不考虑消费方的目前进度,设置不合理容易引起客户端重置进度和丢失数据;

    2.        支持compact压缩的日志清除策略,按K-V来存储最新版本的消息,永久保留内存中的全量数据

    1.        RabbitMQ清除策略有些类似jvm垃圾回收,采用标记清除方式定时清除标记为已消费的消息并进行清理;清除逻辑比较复杂。

    1.        同kafka按时间清除的策略

    消息索引机制

     

     

     

     

    1.        支持按offset的查询方式;

    2.        支持按时间timestamp的查询方式;

    3.        每个partition目录会产生2个独立索引文件用于支持按offset和按时间的检索方式;

    不支持消息的检索

    1.     支持按offset的查询方式;

    2.     支持按时间timestamp的查询方式;

    3.     支持按业务设置的key进行检索消息方式;

    4.     系统按业务设置的key创建hash索引文件,检索时通过hash方式检索消息;

    延时队列支持

    1.     kafka服务并未从系统内部支持延时队列的实现;

    2.     每个消息都携带时间属性,可按发送时间或存储时间进行选择;

    3.     通过外部服务的方式,结合队列延时要求,实现延时队列的支持,存在一定的开发工作量

    1.        RabbitMQ支持队列设置消息expired时间,结合DLX的路由策略来实现延时队列的投递;

    2.        客户端通过声明相关exchange和queue及相应绑定关系便能实现延时队列的功能

    1.        内部支持18个等级的延时队列;

    2.        用户发送延时消息时,指定消息的延时等级,server会按延时等级先存储至不同的内部延时队列;

    3.        在延时到期时,从内部队列发布到实际用户队列中;

    事务性消息

    1.     0.11之后的kafka版本支持事务性消息

    2.     Producer在存活阶段可以保证本地事务的执行情况但是如果在commit或rollback阶段出现crash,暂时不支持远程事务回查机制

    1.        支持事务性消息

    2.        Producer在存活阶段可以保证本地事务的执行情况但是如果在commit或rollback阶段出现crash,暂时不支持远程事务回查机制

    1.        支持事务消息;

    2.        支持本地事务完成

    3.        同时支持远程事务回查机制,开源版本只在接口层面支持,并未具体实现

    队列的幂等处理

    支持在producer生命周期内发送消息的幂等性;server端会按事务id进行去重处理。

    不支持发送消息的幂等处理

    不支持发送消息的幂等

    租户管理

    1.     支持用户实例级别的访问权限管理;

    2.     支持用户实际级别设置流量控制;

    1.     支持用户级别的访问权限管理;

    2.     流量控制只能在集群层面设置对每个链接按类似信号量的方式(credit)进行限制流量

    3.     另外按照内存容量或磁盘容量设定阈值来进行限流;

    4.     支持vhost的资源隔离级别,在能在资源的命名空间上做隔离,并未在物理资源分配上做到隔离

    1.     系统不支持用户权限和限流处理

    2.     可以接入第三方系统来实现

    集群扩容能力

    1.        Kafka水平扩容能力较为突出,基本能够到达线性容量提升的水平; 在linkedin实践中也有部署超过千台设备的kafka集群;

    2.        Topic的设计极易于业务容量扩容,topic是逻辑层概念,物理层面上关联了一系列分散在不同设备上的partition资源信息,而partition是实际数据传输通道;因此当扩容时只需增加partition数目,客户端可无感知的将数据分散到新的分区partition上进行服务,增加了带宽。

    1.     RabbitMQ对网络延迟和稳定性较为敏感,易发生脑裂情况,尽管通过federation或shovel插件能降低脑裂发生的情况;但在实际生产上,并未见rabbitmq部署在大规模集群中使用;

    2.     RabbitMQ针对单业务容量扩容,从设计上是有一定欠缺,客户实例容易扩容,依靠rabbitmq内部负载均衡机制便能达到;但是受限于单queue通道的容量大小,该queue在原生系统中很难简单的扩展上去;

    1.     RocketMQ的设计理念和kafka类似,也采取了topic的路由策略,通过partition分区极易扩展容量;

    2.     在实际生产上,并未见大规模部署集群的案例;通过有限的扩容实验来看,其水平扩容也能达到线性增长的程度。

    版本兼容性

    1.        Kafka设计上充分考虑了生产环境中不同版本的兼容问题,从协议层面进行很好的设计以支持跨版本的访问情况;

    2.        集群升级时也提供了不同版本升级方案,以无损无感知的方式继续提供消息服务;

    1.     RabbitMQ采用的标准协议,协议保持不变的情况下server端和客户端并没有版本的耦合,因此极少考虑兼容性的问题;

    2.     Server端升级也提供比较完善的升级方案,以支持版本的不断迭代。

    1.     RocketMQ在兼容性方面相对薄弱,底层交互的协议变化会对应用方造成比较麻烦的处理;

    2.     基于mqtt协议的客户端相对影响比较小

    监控运维

    1.        Kafka监控和运维工具较多,每个工具专注方向不同如kafka manager, kafka web console,kafka offset monito,Cruise Control r等;

    2.        Kafka服务自身提供了metrics的各类指标,方便用户通过jmx的方式去拉取指标去做平台级的监控服务;在运维管理方面也可通过admin-api进行集群的运维和管理,为达到更高层次的监控和治理能力可以集成开源产品的服务功能;

    1.     RabbitMQ主要基于rabbitmq-management插件进行集群的监控和管理;

    2.     该插件提供丰富的rest-api,方便集成至公司的消息平台来实现各项管理能力,提高公司消息平台的服务能力;

     

    3.     RocketMQ监控和运维平台主要是rocketmq-console,通过rocketmq的admin-tools工具可以获取rocketmq内部的各类状态,同时提供管理的api可方便的对集群和客户端进行监控和运维管理

    队列数量对性能的影响

    1.        Kafka每个partition都有独立的日志和索引文件;当数据剧增的情况下,AOF的写文件方式并不能带来很好的性能,原因文件数过多在磁盘io层形成了随机写请求,对性能有较大影响;

    2.        连续读写单一partition的性能会比较优越,数据文件缓存命中率会比较高;

    1.     Queue的数目增加引起io层问题对rabbitmq的性能影响并不很明显,在压力测试中rabbitmq的性能瓶颈很少由文件io引起。

    1.     RocketMQ内的所有partition数据共享同一个日志文件,因此partition数量的增长并不会给系统带来明显的退化;

    2.     所有partition共享一个事务日志,当不同partition在竞争读取各自数据时,如果内存不充足情况下会引起频繁的页中断,造成io瓶颈

    开源产品社区活跃度

    1.        最近Kafka版本更新很快,提交频率非常高,不断的推出新的特性,生态环境也越来越完善,流计算,数据同步等都有很好的支持;

    2.        Kafka后期的改进规划(KIP事项)非常清晰,针对可靠性,可用性和一致性提高方面都有很好的讨论和时间规划;

    3.        Kafka各类文档资源丰富,任何问题很容易在wik或各论坛邮件都能得到快速回复。

    4.        围绕kafka的各类开源项目繁多,大家容易参考和借鉴相关经验。

    1.     Rabbitmq官方文档比较丰富和完善,因其erlang语言开发,对大多数开发者而言不太容易深入学习,出现线上bug自己修复的可能性很低;

    2.     论坛社区针对各类问题的回答相对欠缺,基本依赖官方解答或者bug修复;

    3.     生态产品基本是官方出品,第三方提供的相关产品比较少见;

    1.     RocketMQ今年刚升级为apache顶级项目,但是其文档和问答内容还是十分欠缺;出现问题时比较难找到解决方案;

    2.     相比其他产品属于比较新的系统,因为其对业务支持相对完善,越来越多的业界开始尝试使用;和阿里内部使用版本的还是有一定差距也是外界诟病的地方;

    3.     围绕rocketmq的生态产品目前还不太多。

    客户端

     

     

     

    顺序性消息发送

    1.        支持顺序性消息发送,可自定义路由策略来指定partition进行发送;

    不支持顺序消息

    同kafka顺序发送模型

    批量发送

    1.        支持按时间和条数进行批量打包发送

    2.        同时客户端内部支持压缩或未压缩方式进行发送,解压缩对用户透明

    1.     消息不支持打包方式发送,但是支持批量ack以减少堵塞的时间

    2.     客户端不支持压缩方式,业务层面考虑是否压缩。

    1.     只支持单条消息发送,在server端会对每个消息建立索引及消息id生成。

    2.     客户端不支持默认压缩方式,由业务层面考虑

    事务性消息发送

    支持

    支持

    1.     支持事务

    2.     同时支持本地事务失败后,server端回查机制

    发送端幂等

    支持

    不支持

    不支持

    客户端路由策略

    支持自定义路由策略;

    路由策略在server端实现,客户端设置routekey发送;服务端通过消息key进行路由的计算;

    同kafka方式

    延时消息发送

    1.        原生kafka不支持延时消息;

    2.        基于kafka原有功能可实现延时消息功能,需要一定的开发工作

    基于rabbitmq队列消息过期设置和DLX来实现延时队列的支持

    原生客户端api和server端服务支持延时消息的投递

    资源命名空间隔离机制

    1.        Kafka原生不支持资源的命名空间隔离;

    2.        可参照rocketmq机制来实现命名空间的资源隔离

    支持vhost的资源命名隔离;相同资源名在不同的命名空间里属于不同的物理资源;针对不同环境复用或有灰度使用场景的需求极为有用

    Rocketmq支持virtual的命名空间隔离资源功能(类似rabbitmq的vhost),此功能在客户端进行了封装,通过环境变量作为前缀命名的方式来区分物理资源;同样可以达到rabbitmq对资源隔离的效果

    消费rebalance机制

    1.        支持默认的平均分配机制

    2.        支持自定义负载均衡机制;

    比如:a.保证严格顺序对partition的严格分配策略,消费实例固定在partition上;

    b.按idc机房的分配策略以支持多机房多活的处理逻辑

    1.        仅Roundrobin的负载分配机制,缺乏灵活性;

    2.        但是通过客户端比较复杂的逻辑,并结合 rabbitmq服务端exchange的路由策略可以定义丰富的负载机制,但是实现逻辑负载。

     

    与kafka的rebalance机制类似;

    但在网络分区情况下,会造成一定的分配故障,kafka分配策略在这种情况下会比rocketmq更严格。

    Push模式下消费ack机制

    1.        提供手动和自动ack机制

    2.        自动ack机制情况下,按kafka投递消息的语义,并不能完全可靠的保证消息是否成功消费;

    1.        支持手动和自动提交

    1.        自动提交方式,能保证可靠的投递和消费,根据消费状态来进行消息的ack机制;

     

    消费的重试机制

    1.        Kafka客户端不提供消费重试,业务自己考虑本地重试方式;在故障或异常情况发生时,不能很好地解决消息失败后的处理逻辑;

    1.        原生客户端不支持重试

    1.        客户端支持重试投递的机制,用户可根据时延等级来制定下次消费的时间间隔;

    2.        重试并不会阻塞原生队列的消费,而是通过内部重试队列来充分解决并发问题。

    消费模式支持

    1.        支持P2P的消费方式;

    2.        支持组间广播消费,组内实例间互斥消费模式;

    1.        同kafka的方式

    1.        支持kafka的消费模式;

    2.        同时支持组内的广播方式,每个实例亦能消费全量消息;

    消息回溯

    1.        支持按消息offset进行回溯

    2.        按消息时间戳进行回溯

    3.        回溯只在单实例内进行,并不能通知所有实例统一进行;

    1.        不支持回溯

    1.        支持按offset方式回溯

    2.        支持按时间戳方式回溯

    3.        支持按业务设置的key进行消息回溯;

    4.        回溯能通知到所有组内实例进行

    事务性消息消费模式隔离级别

    1.        支持提交的读

    2.        支持未提交的读

    1.        只支持提交的读

    1.        只支持提交的读

    单队列并发消费能力

    1.        默认kafka客户端不支持单队列的并行消费,自身的线程分配模型决定;

    2.        提供缺省的并发能力依赖分区partition数量的增加和消费实例数的扩容;

    1.        支持单队列并发能力,所有实例处于平等地位;

    1.        支持kafka的默认的并发模型;

    2.        同时支持单队列的并行消费,降低单队列堵塞情况;

     

     

    1.        选型参考依据

             如何构建企业级消息总线,是基于现有开源引擎还是自力开发消息系统去满足企业内部需求;从开发周期、技术力量、人力资源以及功能特征上去分析,一般采用已有的开源产品来构建企业的消息总线收益更大;具体选择哪种消息引擎,可以从以下角度进行判断:

             选择条件:

    l  开源产品的活跃度,学习资源和各类问题解答获取的途径;

    l  开源产品开发语言的学习成本;

    l  消息引擎支持的功能特性:

    n  数据可靠性,一致性保证;

    n  集群水平扩容能力,分区有效性;

    n  集群兼容性和平滑升级的能力;

    n  消息路由策略的灵活性;

    n  消息日志的持久化方案;

    n  消息支持高级特性方面,顺序消息,延迟消息,事务消息,幂等性处理,索引机制等;

    n  运维治理能力,接入认证,流量控制,日志清除方案;

    n  压力性能测试结果。

    l  客户端功能支持:

    n  客户端发送消费可靠性机制,比如并发ack机制,重试消费等能力;

    n  客户端实例水平扩展能力及负载均衡机制

    n  客户端多线程并发能力;

    n  实例级别治理管控能力;

    n  Push和pull客户端的支持能力;

    n  消息高级特征的支持情况;

    n  灰度及资源隔离情况支持;

    n  消息回溯或补偿方式;

    从kafka,rabbitmq和rocketmq的各类特性比较来看,kafka在以上条件对比中,都有比较好的支持和功能实现,有些功能特性原生kafka还未能支持,但是在其之上进行功能二次开发,能够很好的满足现有的业务需求;同时从性能测试角度考量,kafka批量压缩异步等特性使得kafka能支持单机10w之上的吞吐,优于其他消息引擎;从管理运维角度,kafka大规模部署场景下,运维治理能力也十分优秀;

     

    Kafka引擎之上可实现的功能特性之总结:

     

    基于kafka引擎功能

    特征支持情况

    kafka_V0.8.x

    kafka_v1.0.0

    原生kafka基础上

    新增和优化

    (默认支持原生态)

    顺序消息发送

    支持

    支持

    同上

    批量压缩模式

    支持

    支持

    同上

    Ack机制

    -1,0,1

    -1 代表副本全同步,

    0 代表请求送达,

       1 代表leader持久化

    同上

    同上

    异步发送回调机制

    不支持

    支持

    同v1.0.0

    发送限流控制

    不支持

    支持按客户端实例方式

    同v1.0.0

    发送路由策略

    缺省支持:

    hash(key)取模

     

    缺省支持:

    hash和roundrobin方式

    丰富的路由策略:

    读配置方式路由,按机房路由,按权重方式等

    支持扩展header信息

    不支持

    支持

    同v1.0.0

    发送幂等性

    不支持

    支持

    同v1.0.0

    发送事务性消息

    不支持

    支持

    同v1.0.0

    延迟消息

    不支持

    不支持

    通过内部队列的转发机制实现延时功能,需开发;

    重试队列

    不支持

    不支持

    基于java客户端可实现重试队列;

    可提升消费的并发度和降低消费阻塞情况;

    死信队列

    不支持

    不支持

    开发实现;方便用户审计以及消息的补偿

    支持push和pull模式

    两种模式均支持

    支持pull模式

    基于v1.0.0版本增加支持push模式

    Push模式下消费ack的高可靠机制

    不支持

    不支持

    采用滑动窗口的方式来保证单queue下并发消费的offset覆盖问题,确保单消息的安全性;

    支持多线程并发消费单queue的能力

    不支持

    不支持

    在原生支持线程模型之上,增加单queue对多线程的支持

    消费端负载均衡策略

    Sdk仅支持RangeAssignor方式

    支持Range/RoundRobin/Sticky的分配模式

    支持v1.0.0所有负载模式;

    实现丰富分配策略,比如idc机房的分配策略,走配置文件的分配方式等

    消息的广播模式

    支持组间广播,带来组管理的复杂性以及客户端配置问题的繁琐

    同v0.8.x模式

    在原有广播模式基础上,改进组内广播模式,解决组间广播的痛点问题

    灰度发送和消费

    不支持

    不支持

    实现vhost的资源隔离机制,满足业务同资源的分流问题和解决发布灰度问题;

    消息回溯机制

    Push模式下不支持

    Pull模式下支持offset回溯

    Push模式下不支持

    支持offset和time的回溯

    可实现push模式下的按offset和time以及业务埋点信息的回溯方式

    消息查询

    offset查询

    offset查询

    timestamp的查询

    同v1.0.0 依赖外部索引系统,提供更多元化的查询功能

    发送和消费审计信息埋点

    不支持

    不支持

    基于v1.0.0进行埋点信息收集并进行线下准实时计算可对消息按业务维度审计。增强消息的可靠性。

    单实例指定链接补偿机制

    不支持

    不支持

    需开发,对于指向性的消息补偿

    状态汇报,运维治理

    监控告警平台级支持

    不支持

    不支持

    可封装并结合企业内部监控或告警平台进行配合治理

    客户端配置平台化管理

    客户度自配置

    客户度自配置

    结合消息平台统一管理能力,可统一业务的所有实例级参数和集中化变更

     

    2.        总结

                       通过分析消息系统关键技术及对比不同消息系统的功能特征;结合目前公司内部各业务团队的功能需求,综合考虑各个选型依据,选择kafka引擎来实现公司内部的消息总线是十分经济,基于已有消息功能并结合新业务需求也易于开发新的功能点,未来基于kafka的服务在可靠性,扩展性和可用性上都会有更好的发展。

             

    展开全文
  • 软考信息系统项目管理师论文视频培训课程:分别对十大领域各领域论文进行讲解,教你如果书写摘要、正文、总结,用短的时间,让你学会论文的写作,高分通过。
  • 信息系统项目管理师考试辅导教程(第3版)

    千次下载 热门讨论 2013-01-29 20:12:39
    《全国计算机技术与软件专业技术资格(水平)考试用书:信息系统项目管理师考试辅导教程(第3版)》由希赛教育软考学院组织编写,作为计算机技术与软件专业资格(水平)考试中的信息系统项目管理师级别的考试辅导指定教程...
  • 信息系统分析与设计课程心得

    万次阅读 2017-02-28 13:41:39
    信息系统分析与设计课程心得此博客为信息系统分析与设计课程的学习心得记录。一、绪论1概念1.1信息要了解信息系统,首先要了解信息的概念。信息是我们理解世界的重要概念,我对它的定义是:信息是对客观事物及其相互...

    信息系统分析与设计课程心得

    此博客为信息系统分析与设计课程的学习心得记录。

    原文出自http://blog.csdn.net/qq_31456593/article/details/58593089


    第1、2、3章:
    1、信息定义与基本属性?
    信息是经过加工后的数据,它对接收者有用,对决策或行为有现实或潜在的价值。具有以下基本属性:
    事实性、扩散性、传输性、共享性、增值性、不完全性、等级性、滞后性

    2、系统的特性
    系统的整体性、系统的层次性、系统的目的性、系统的稳定性
    系统的突变性、系统的自组织性、系统的相似性

    3、管理的层次
    一个企业可以分为三个层次:高层管理(战略管理)、中层管理(战术管理)、基层管理(作业管理)。
    战略性决策指有关重大方向性问题的决策
    战术性决策指为了保证战略性决策所需要的人、财、物的准备而进行的决策
    日常业务活动决策往往有经常性和重复性,有规律可循,可以事先安排

    4、信息系统定义与对企业管理的影响
    信息系统就是输入数据,通过加工处理,产生信息的系统
    以计算机为基础的信息系统定义为:结合管理理论和方法,应用信息技术解决管理问题,为管理决策提供支持的系统。特点是面向管理。
    对企业管理的影响(企业过程重组BPR):
    1)帮助企业高层领导规划、控制企业的运作,获得整个企业内部和外部信息,以辅助他们决策
    2)支持企业中层管理,辅助管理控制
    3)帮助企业基层有效地应用信息技术,减少重复劳动,提高工作效率

    第4章:
    1、复杂性的理解
    信息系统建设周期长、投资大、风险大,比一般技术工程有更大的困哪和复杂性,这是因为:
    1)技术手段复杂
    2)内容复杂,目标多样
    3)投资密度大,效益难以计算
    4)环境复杂多变

    2、信息系统开发是一个社会过程
    1)将信息系统建设与一般技术工程相比较,信息系统建设的困难不仅来自技术方面,还来自企业内部环境。
    2)影响信息系统成败的有体制、政策、法规、观念、技术鞥多种因素。技术不是唯一因素,甚至不是主要因素。
    3)信息系统是人机交互系统,其开发、维护都离不开人的参与。从社会行动观点看,信息系统系统开发是人类活动协调序列,是多种参与者的协作过程。
    4)信息系统不只是单纯的计算机系统,而是辅助企业管理的人机系统

    3、信息系统的生命周期

    系统规划、系统分析、系统设计、系统实现、系统运行和维护
    系统规划阶段:系统规划阶段的任务是对企业的环境、目标及线性系统的状况进行初步调查,根据企业目标和发展战略,确定信息系统的发展战略,对建设新系统的需求做出分析和预测,同时考虑建设新系统所受的各种约束,研究建设新系统的必要性和可能性。根据需要与可能,给出拟建系统的备选方案。对这些方案进行可行性分析,写出可行性分析报告。可行性分析报告审议通过后,将新系统建设方案及实施计划编写成系统设计说明任务书。

    系统分析阶段:系统分析阶段的任务是根据系统设计任务书所确定的范围,对现行系统进行详细调查,描述现行系统的业务流程,指出线性系统的局限性和不足之处,确定新系统的基本目标和逻辑功能要求,即提出新系统的逻辑模型。这个阶段又称为逻辑设计阶段。这个阶段是整个系统建设的关键阶段,也是信息系统建设与一般工程项目的重要区别所在。
    系统分析阶段的工作成果体现在系统说明书中,这是系统建设的必备文件。他既是给用户看的,也是下一阶段的工作依据。因此,系统说明书既要通俗,又要准确。用户用过系统说明书可以了解未来系统的功能,判断是不是奇说要求的系统。系统说明书一旦讨论通过,就是系统设计的依据,也是奖励来验收系统的依据。
    系统设计阶段:简单的讲,系统分析阶段的任务是回答系统“做什么”的问题,而系统设计阶段要回答的问题是“怎么做”。该阶段的任务是根据系统说明书中规定的功能要求,考虑实际条件,具体设计实现逻辑模型的技术方案,也即设计新系统的物理模型。这个阶段又称为无力设计阶段。这个阶段又可分为总体设计和详细设计两个阶段。这个阶段的技术文档是“系统设计说明书”。

    系统实施阶段:系统实施阶段是将设计的系统辅助实施的阶段。这一阶段的任务包括计算机等设备的购置、安装和陶氏,程序的编写和调试,人员培训,数据文件转换,系统调试与转换等。这个阶段的特点是几个互相联系、互相制约的任务同时展开,必须精心安排、合理组织。
    系统实施是按实施计划分阶段完成的,每个阶段应写出实施进度报告。系统测试之后写出系统测试分析报告。

    系统运行和维护阶段:系统投入运行后,需要经常进行维护和评价,记录系统运行的情况,根据一定的规格对系统进行必要的修改,评价系统的工作质量和经济效益。

    4、信息系统开发方法
    生命周期是指导性方针,很抽象,具体的信息
    系统开发方法有很多,主要研究方向有两类:
    针对开发过程: 不同的信息系统开发过程模型。关注整个开发采取哪些步骤,每个步骤包含哪些任务,由什么人完成,任务的成果如何体现等,也称为不同的生存周期模型
    针对开发技术: 不同的建模方法,从不同的观点来反映系统的全貌,并采用不同技术手段予以实现
    瀑布开发方法

    强调阶段的划分和阶段严格的顺序
    各阶段工作任务明确,要求文档完备性
    是一种严格线性的按阶段顺序的、逐步细化的开发模式,消除了软件开发的随意性

    特点:
    1) 简单易用,容易理解
    2) 开发的进程一个顺着一个,没有反馈过程,需要严密控制
    3) 允许基线和配置早期接收控制
    4) 一个新的项目不适合这种模型
    5) 用户直到项目结束才能看到质量如何
    6) 不允许或者严格限制变更
    不足:
    需求:客户常常难以表达真正的需求,而这种模型却要求严格的阶段性成果,返工困难,变 更代价很大
    风险:客户要等到开发周期的晚期才能看到程序运行的测试版本,这时若发现大的错误,可 能引起客户的惊慌,其后果也可能是灾难性的
    效率:因为前后任务的依赖关系,成员不能并行工作,有可能花在等待的时间比开发的时间 要长,即所谓的“堵塞状态”
    (适用于一些需求已明确并且变化较少的信息系统)

    原型开发方法

    特点:
    用户积极参与
    原型的开发没有严密的阶段性
    短期获得测试版本,降低风险

    应用于以下场合:
    需求含糊,用户不能标识出详细的输入、处理和输出需求
    设计方案不明确,开发人员不能确定算法的有效性、操作系统的适应性或人机交互的有效性

    不足:
    1. 用户随意无止境的需求变化,因为用户容易产生误解,认为系统很容易被构造和修改
    2. 如果采用原型基础上继续构造,由于修补过度,软件质量不易于保证
    3. 开发人员为了快速构造原型,可能会采用不合适的操作系统、语言、算法等,造成后期风险,如系统适应性差、维护困难等

    增量开发方法
    一条直线一次性到达目的总是困难的。
    紧迫的市场期限使得难以完成一个完善的软件产品,缓解压力的方式是先提交一个有限的版本,细节部分逐步增加。
    增量模型——融合了瀑布模型的基本成分和原型的迭代特征。采用随着日程时间的进展而交错的线性序列。 搭积木的方式,如按子系统划分增量

    特点:
     以功能递增的方式进行软件开发
     能较快地产生可操作的系统
     在每一步递增中,都可以把用户/开发者的经验结合到不断求精的产品中
     可改善测试效果和降低软件开发总成本
    应用场合:
     项目开始,明确了需求的大部分,但是需求可能会发生变化
     对于市场和用户把握不是很准,需要逐步了解
     对于有庞大和复杂功能的系统进行功能改进,本身就需要一步一步实施的。

    螺旋开发方法
    把软件开发过程定义成不断上升的螺旋周期,每个周期划分为计划、风险分析、实施和评价四个方面。沿螺线自内向外每旋转一圈便开发出更为完善的一个新的软件版本

    特点:
     风险驱动,可以在生命周期早期强制性的确定项目中存在的风险
     需要开发人员具有相当丰富的风险评估经验和专门知识
     要求用户参与阶段评价,对用户要求较高
    适用于:
     单位内部开发的大规模软件项目
     风险是项目的主要制约因素
     可能会发生重大变更
     采用新技术

    5、基于技术的开发方法(一个简答题10’)
    信息系统建模方法:
     面向过程的建模方法,也称结构化方法
     面向对象的建模方法

    1)结构化方法,也称为 面向功能/面向过程/面向数据流 的软件开发方法
    结构化分析(SA)对软件进行需求分析,以数据流图表示
    结构化设计(SD)进行总体设计,以模块结构图表示
    结构化程序设计(SP),以程序流程图表示
    结构化方法的基本思想:从系统功能出发,自顶向下,按照层次逐步分解求精

    2)面向对象的分析方法,以对象的观点来观察世界。
    它认为一个系统可以被看成一系列相互作用的对象组成,每个对象拥有自己的数据结构和行为方式,以及能触发对象的某种操作(行为)而改变其状态(数据结构)的事件。
    面向对象分析(OOA)、设计(OOD)和程序设计(OOP)最重要的模型图是对象图/类图。

    3)两者比较
     结构化方法
    容易理解和交流,对于大系统可以从全局逐步展开到局部,整体性较好。

     面向对象
    稳定可靠,有利于维护和重用,并容易实现多层分布式结构,技术先进,但对前期分析设计人员要求较高,用户理解模型有困难。

    结构化技术的特点:把现实世界描绘为数据在信息系统中的流动,在数据流的过程中数据发生转化。
    通过自定向下的程序将复杂的程序分解为程序模块的层次图,概括为自顶向下、逐步求精
    、模块化设计、结构化编码的基本特点。

    面向对象的特点:面向对象技术将数据模型和处理模型二合为一,将属性和方法封装在一个对象当中。
    将信息系统看成是一起工作来完成某项任务的相互作用的对象集合:通过定义系统中所有对象类型并显示对象之间是如何通过相互作用来完成分析任务。
    面向对象就是既使用对象有试用类和继承等机制,而且对象之间仅能通过传递消息实现彼此通信。
    面向对象优点:1、稳定性好; 2、可重用性好; 3、较易开发大型软件产品; 4、可维护性好

    结构化方法就是将系统看成是过程的集合,过程与数据实体之间交互,过程接受输入并产生输出。

    面向对象方法则不再把程序看成工作在数据上的一系列过程或函数的集合,而是把程序看做是相互协作而又被彼此独立的对象的集合。

    1、从概念方面看
    结构化软件是功能的集合,通过模块以及模块和模块之间的分层调用关系实现
    面向对象软件是事物对象的集合,通过对象以及对象和对象之间的通讯联系实现

    2、从构成方面看
    结构化软件是过程和数据的集合,以过程为中心;
    面向对象软件是数据和相应操作的封装,以对象为中心

    3、从运行控制方面看
    结构化软件采用顺序处理方式,由过程驱动控制
    面向对象软件采用交互式,并行处理方式,由消息驱动控制

    4、从开发方面看
    结构化方法的工作重点是设计;面向对象的房的工作重点是分析
    在结构化方法中,分析阶段和设计阶段采用了不相吻合的表达方式,需要把在分析阶段采用的具有网络特征的数据流图转换为设计极端采用的具有分层特征的软件结构图;
    在面向对象方法中,设计阶段的内容是分析阶段的细化,则不存在这一转换问题

    第5章:
    1、信息系统规划的任务
     制定信息系统发展战略
     制定信息系统总体方案
     制定信息系统开发计划
     制定信息系统资源分配

    2、可行性分析是哪几个方面和主要工作
    是指在企业当前情况下,研制这个信息系统是否有必要,是否具备必要的条件。可能性、必要性、合理性
    1) 技术可行性:根据现有的技术条件,能否达到所提出的要求;所需要的物力资源是否具备,能否得到
    2) 经济可行性:估计项目的成本和效益,分析项目经济上是否合理。要解决两个问题:资金可得性和经济合理性。
    3) 社会可行性:组织内部的改革是否能够推行(体制变化、人员精简)
    领导和员工的素质、支持度/阻力
    上级单位的认同
    政策、法规

    第6章
    1、系统分析的主要任务
    系统分析员与用户在一起充分理解用户的要求,并把双方的理解用书面文档——系统分析说明书表达出来。

    2、收集的业务信息:
    管理目标、功能、业务管理、数据流程
    企业系统规划的四个步骤(P77):
    1)定义管理目标:确定各级管理的统一目标,各个部门的目标要服从总体目标
    2)定义管理功能组:即识别企业在管理过程中的主要活动
    3)定义数据分类:四种数据类型——文档型、事物型、计划型、统计型
    4)定义信息结构:划分子系统,确定信息系统各个部门及其相关数据之间的关系,确定子系统的先后顺序

    3、业务流程图和数据流图
    1)数据流图元素符号

    外部实体:
    指系统以外又与系统有联系的人或事物。它表达了该系统数据的外部来源和去处
    外部实体是数据的来源(谁提供了最初始的数据?)
    外部实体是数据的去处(数据对谁有价值?)

    处理:
    指对数据的逻辑处理功能,也就是对数据的变换功能。
    别名:功能、处理过程,数据加工

    数据流:
    指处理功能的输入或输出(箭头表示数据流向) 。

    数据存储:
    表示某种数据保存后的逻辑统称。不是指保存数据的物理地点或物理介质。
    流入数据存储的数据流: 将处理后的数据写入或修改到数据存储中
    流出数据存储的数据流: 从数据存储中查询获取数据,不改变原来的数据

    其他图形表示:
    数据流图中的图形元素有不同的画法,本书使用Gane-Sarson画法

    2)数据流图画法看书或者ppt,考试只用话2层,不需要过度分析

    3)数据流图和业务流程图的却别
    1、描述的对象不同
    业务流程图描述某一具体的业务,数据流图描述对象是数据流
    2、功能不同
    业务流程图是一本用图形方式来反映实际业务处理过程的“流水帐”。
    数据流程分析主要包括对信息的流动、传递、处理、存储等的分析。
    3、基本符号不同
    4、绘制过程不同
    业务流程图是用一些规定的符号及连线来表示某个具体业务处理过程
    数据流图是按照“自顶向下,逐层求精”的方法进行的

    4)DFD规范:
    1.数据守恒
    2.在一套数据流图中的任务和一个数据存储,必定有流入的数据流和流出的数据流,即写文件和读文件,缺少任何一种都意味着遗漏某些加工。
    3.父图中某一处理框的输入,输出数据流必须出现在对应的子图中,否则就会出现父图与子图的不平衡。
    4.任何一个数据流至少有一端是处理框。

    5)表达处理逻辑的工具
    1. 结构化语言
    三种基本语句:祈使语句、判断语句、循环语句
    2. 判定树
    如果一个动作的执行不只是依赖一个条件,而是与多个条件有关,那么这项策略的表达就比较复杂,就可以使用判定树来表示
    3. 判定表
    如果条件较多、每种条件的取值情况也较多的情况下,可以使用判定表。
    判定表的优点是可以把各种组合情况一个不漏地表示出来,还能帮助发现遗漏和矛盾的地方。
    4、适用范围
    决策树适合10~15种行动的一般复杂度的决策,有时也可把决策表转换成决策树,便于用户检查。
    判定表适合于多个条件的复杂组合。
    如果一个判断包含了一般顺序的动作或循环执行的动作,则用结构化语言。

    第7:用例建模
    1、用例的意义
    1) 用例是对系统需求(主要是功能需求)的规范化的描述。
    2) 用例图及用例的事件流描述集中体现了系统责任,
    3) 通过用例建立交互图。交互图就是用例的具体实现,即系统中的对象以及对象间协作是如何完成一个用例的全部过程。
    4) 用例驱动的开发过程,从用例模型到分析模型和设计模型之间有一致性和可追踪性。

    2、用例图的构建(具体看书或ppt)
    1)确定参与者
    参与者是系统之外与系统进行交互的任何事物,只有在执行系统功能时与信息系统进行实时交互的人员才能被当作参与者
    1.使用系统的个人
    2.系统所连接的外部硬件。
    3.与该系统进行通信的其他信息系统。
    2)确定用例
    用例就是功能性需求。
    每个用例至少和一个参与者相关,用例名称要体现参与者希望系统提供的功能。
    3)描述每个用例
    至少包括以下内容:用例名、参与者、目标、前置条件、事件流、后置条件

    双列格式:

    顺序图:
    纯文本的用例描述直观性较差
    使用UML中的顺序图可以图形化地表现出参与者和系统之间的交互

    3、用例关系
    1) 包含关系:经过封装后可以在各种不同的基本用例中复用的行为称为包含用例。
     基本用例可以控制包含用例,并依赖于(使用)包含用例所得到的结果。
     包含用例是基本用例存在的必要条件
     一个基本用例可以有多个包含用例,一个包含用例可以包含在若干基本用例中。包含关系可以嵌套,但超过三层的嵌套是难于理解的。

    2) 扩展关系:表达某些可选或只在特定条件下才执行的系统行为的用例,它们是对基本用例的扩展。称为扩展用例。
     扩展用例是可选的,它是否执行取决于在执行基本用例时所发生的事件(存在扩展点)。
     扩展用例的缺失不影响对基本用例的理解。

    3) 泛化关系(不推荐):如果两个或更多用例在行为、结构和目的方面存在共性,可以使用泛化关系。父用例描述这些共有部分,子用例继承父用例并特殊化。
     用一个新的、通常也是抽象的用例来描述多个用例的共有部分(父用例),子用例继承父用例的所有结构、行为和关系,并含有自己特殊的部分。
     父用例通常是抽象的,如果两个子用例都对同一父用例进行特殊化,则两个子用例是相互独立而且完整的,这一点与包含关系扩展关系不同。

    4)三者区别(百度的):
    1.扩展不属于依赖,是用在用例和用例之间,扩展是指扩展用例与基用例之间的关系,说明如何将扩展用例定义的行为插入基用例定义的行为序列。比如发布博客用例和暂存博客用例之间就可以是扩展关系。
    2.包含属于依赖的一种,也是用在用例和用例之间,比如写博客用例,应包含了插入图片用例。
    3.泛化是集成,用在角色和角色之间,比如管理员和系统管理员可以是泛化关系。

    第8:类图
    1、面向对象的特点与优势(参见上面的比较。基本:封装继承多态)
    2、类与类的关系(考试结合图判断关系)
    1)关联
    关联表示不同类的对象之间的结构关系,它在一段时间内将多个类的实例连接在一起。可以使用关联表示对象了解其他对象的程度。
    要素:关联名称、对象在关联中的角色、多重性、导向性

    多重性:

    2)类的泛化
    泛化(Generalization)是在多个概念之间识别共性,定义超类(一般概念)和子类(特定概念)关系的活动。

    3)聚合
    描述整体-部分的关系,部分可能同时属于多个整体对象。
    关联路径的末端有一个空心菱形,用来表示聚集关系。

    4)组合
    组合聚集具有很强的归属关系,部分只能是一个组合对象的成员,而且部分对象的存在是依赖于整体对象,与整体同生共死。
    整体端的重数不会超过 1(即它无法被多个整体对象共享),关系建立后是不可变更。
    关联路径的末端有一个实心菱形,用来表示组合关系。

    5)依赖

    3、类图(具体看书或ppt,考试一切以业务描述为主,用名字短语来画图)
    类图(class diagram):描述了构成一类对象特征的状态和行为(描述软件架构)
    定义领域类属性的原则
    1.仅定义与系统责任和系统目标有关的属性。
    2.使用简单数据类型来定义属性。如数字、字符串、日期、布尔、文本等。还包含多种特征或规则的数据,可考虑作为独立的对象类。
    3.一般不使用可导出的属性。
    4.不为对象关联定义属性。属性只用于体现对象本身的内在性质,关联属性来实现,但那是设计阶段的问题,应推迟考虑。
    5.如毕业设计题目与教师和学生存在关联,但题目中不应定义“教师姓名”、“学号”之类的属性。

    第9:系统设计
    1、经典的三层架构
    表现层:处理用户和信息系统之间的交互。
    可以是简单的命令行窗口,也可以功能完善的图形用户界面(胖客户端程序),如基于HTML的浏览器界面(瘦客户端程序)。

    业务逻辑层:也称为领域层或应用层,是信息系统所有和领域相关的工作。
    如根据输入数据或已有数据进行计算,依赖于数据访问层获取数据或保存数据,类库形式。

    数据访问层:一般指与数据库的交互,主要责任是数据库记录的存取。

    简化的层次结构:
    表现层
    业务层+数据访问层

    甚至简化成没有分层:
    窗口程序=表现+业务逻辑+数据存储
    程序几乎不能重用

    2、模型视图控制器架构MVC
    模型: 即相关的数据,它是对象的内在属性
    视图: 是模型的外在表现形式,一个模型可以对应一个或者多个视图,视图还具有与外界 交互的功能
    控制器:是模型与视图的联系纽带,控制器提取通过视图传输进来的外部信息转化成相应事 件,然后由对应的控制器对模型进行更新; 相应的,模型的更新与修改将通过控 制器通知视图,保持视图与模型的一致性

    3、顺序图(具体看书或ppt)
    1) 从用例描述中选择主要actor和发起事件。
    2) 选择实现用例所需的基本显示屏幕,即边界对象。
    3) 选择一个用例控制者(基本控制对象)来处理边界对象和领域对象之间的通信,从而实现模型-视图分离
    4) 选择出所有参与到用例中的领域类(实体对象)。
    5) 以上过程可以动态创建所需要的类
    6) 若用例涉及到任何的包含或扩展用例,则可根据需要为它们创建次级控制对象。
    7) 确定实现用例所需的窗口数目,可根据需要为每个主要窗口创建一个次级边界对象。
    8) 在顺序图中按如下次序列出这些对象: 边界类对象、用例控制者、实体对象(以访问次序列出) ,以及按访问次序为准的次级控制对象和次级边界对象。
    9) 根据如下类别来识别所有解决问题的操作:
    实例创建和析构
    关联形成
    属性修改:计算、改变状态、显示或报表需求
    与外部对象或系统的接口
    10) 尽可能地根据任何已经存在的设计模式,来重新排列对象类之间消息的序列。
    11) 命名每个消息并为其提供可选参数。
    举例:
    一个用户登录的用例:
    系统中有多个用户
    每个用户属于一个用户组
    每个用户组有不同的授权
    权限有多种,如数据查询、数据添加、数据删除、数据修改等

    登录用例:
    界面对象接受输入的用户名和密码
    用例控制对象根据用户名和密码进行权限验证
    用户对象确认用户是合法用户
    通过用户的用户组对象获得有关权限
    界面对象显示登录成功/不成功结果

    分析阶段顺序图

    设计阶段顺序图

    第10:系统测试(了解)
    目前,检验软件有三种手段:动态检查、静态检查和正确性证明。

     程序正确性证明技术目前还处于初级阶段,
     静态检查指人工评审软件文档或程序,发现其中的错误(代码审查、代码走查、同行评审)。
     动态检查就是测试。测试是为了发现错误而执行程序的过程。测试只能证明程序有错误,而不可能证明程序没有错误。

    测试技术:
    1、黑箱测试/黑盒测试
    这种方法是把测试对象看做一个黑盒子,测试人员完全不考虑程序内部的逻辑结构和内部特性,只依据程序模块的详细说明,检查程序的功能是否符合它的功能说明。
    黑盒测试又叫做功能测试或数据驱动测试

    2、白箱测试/白盒测试
    此方法把测试对象看做一个透明的盒子,它允许测试人员利用程序内部的逻辑结构及有关信息,设计或选择测试用例,对程序所有逻辑结构进行测试。
    通过在不同点检查程序的状态,确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。

    展开全文
  • 信息系统项目管理师历年真题

    热门讨论 2013-11-07 19:44:27
    2005-2012年软考信息系统项目管理师真题,带答案版
  • 一、背景介绍基础集成平台是信息系统的基础设施环境,为各应用系统提供公共基础设施(如ESB、消息中间件等),将各系统的通用基础服务功能(如用户管理、授权管理、配置管理等)从业务系统剥离出来,使得业务系统...

    一、背景介绍

    基础集成平台是信息系统的基础设施环境,为各应用系统提供公共基础设施(如ESB、消息中间件等),将各系统的通用基础服务功能(如用户管理、授权管理、配置管理等)从业务系统剥离出来,使得业务系统聚焦于业务流程和业务功能,实现更好的可管理性和用户体验。

    在新一代医院信息系统(NGHIS)中,基础集成平台是医院内部各业务系统赖以运行的基础环境,没有基础集成平台,应用系统将无法完成用户身份认证和资源访问控制。基础集成平台向应用系统开放用户认证、资源访问授权等服务接口,也可以通过医院服务总线与各业务系统之间保持松耦合关系;健康医疗云平台也需要通过基础集成平台实现统一用户认证、统一授权管理和统一配置管理。

    二、系统结构设计

    (一)NGHIS总体结构

    基础集成平台是医院基础信息平台和健康医疗云平台的重要基础设施,无论是医院端的应用系统还是云端的互联网平台,都需要基础集成平台提供用户认证、授权管理等基础服务。医院端应用主要存在三种形态:第一种是在院内安装部署数据库的松耦合系统(NGHIS,Next Generation HIS),完全基于院内局域网处理所有业务;第二种采用云+端结合的方式,在医院内部部署的简洁型HIS(CHIS,Compact HIS)作为应急系统,与云端服务协同配合使用,当广域网故障无法访问云端时,应急系统仍然可以满足医院的应急业务应用需要(包括挂号、收费、发药、医嘱处方处理、病历书写打印等);第三种是完全使用瘦客户端访问云端应用服务及数据的轻便型HIS(PHIS,PortableHIS),云端不可访问时暂停所有系统操作。


    图1 新一代医院信息系统总体结构

    (二)基础集成平台架构

    基础集成平台是不区分行业特性的通用应用软件基础设施,主要包括统一认证授权(UAA)、统一配置管理(UCM)、统一消息管理(UMM)、统一用户中心(UCM)和单点登录(SSO),基础集成平台单点登录推荐使用耶鲁大学的开源CAS,也可以使用其他第三方SSO系统。基于统一认证的用户账户信息,对外提供符合OpenID规范的用户认证服务(OpenID Provider),并分别针对C/S和B/S应用封装用户认证及权限管理的开发库(AA-Lib),统一认证中心的用户账户信息,通过用户账户复制(UAR)系统实现与外部第三方用户数据库(包括微软AD域用户和LDAP用户)的用户数据同步。社会组织模型管理提供一个简约的社会组织关系数据维护,主要包括法人及其组织架构、自然人、网格化社会组织结构等基础数据的管理与维护。


    图2 基础集成平台系统结构

    三、系统功能设计

    (一)统一认证授权(UAA)

    统一认证授权系统负责企业信息化应用的组织架构、用户账户、应用系统、用户授权等基础管理功能。

    统一认证授权系统设置系统管理员、机构管理员、应用管理员、授权管理员、客服员等用户角色。系统管理员负责平台全局性的基础数据维护,包括岗位信息维护、应用信息维护、顶级机构创建等。机构管理员负责下级机构创建、机构岗位设置(包括机构岗位目录、岗位员额编制、岗位权限等)、机构用户管理(包括用户创建、用户冻结、用户权限设置)等。应用管理员负责其所管辖应用系统的数据初始化(资源维护、角色维护、角色可访问资源设置等)、应用权限分配(机构应用角色、机构岗位角色、用户组角色)、应用授权查询(查询特定应用资源的权限分配情况,包括什么角色能够访问该资源、哪些机构具有该资源的访问权限、哪些机构岗位拥有该资源的访问权限、哪些用户拥有该资源的访问权限)等。授权管理员负责其所辖机构的权限分配管理工作,包括为机构岗位分配应用角色和对机构所属用户进行权限管理。客服员负责系统日常使用的用户授权运维,包括重置用户密码、用户权限查询、用户账户冻结及冻结用户重新激活等操作。

    1、系统管理

    系统管理是系统管理员用于维护平台公共基础信息的功能,主要包括岗位维护、机构维护和应用维护。

    图3 系统管理功能结构

    (1)岗位维护

    岗位是全系统共享的全局岗位,各机构只能从全局岗位中选取本机构启用的岗位,不能自行增加岗位名称,以保持岗位名称的一致性。

    岗位维护功能包括岗位的新增、修改,岗位名称一旦增加,就不允许删除,可以设置为禁用状态,禁用状态的岗位,不能被机构选取,但不影响已经启用该岗位的机构正常使用。

    (2)机构维护

    系统管理员的机构及机构岗位维护功能,包括新增顶级机构、机构信息修改和机构岗位设置,子机构的创建一般由机构管理员负责,系统管理员也可以通过组织管理功能创建子机构。

    创建顶级机构时,需要同步创建或指定一个机构管理员,由该机构管理员通过使用组织管理功能维护该顶级机构的下属机构维护和用户管理。

    (3)应用维护

    维护各应用系统的基本信息及其对应的应用管理员,应用管理员负责其所管理应用的基础数据维护和应用授权管理。

    2、组织管理

    组织管理是机构管理员用于对其所属机构的组织机构和用户进行管理的主要界面,功能包括子机构创建、机构信息修改、机构岗位设置以及用户管理。机构管理员只能管理其所属机构及下属机构的机构信息及用户信息。

    图4 组织管理功能结构

    (1)机构维护

    机构维护包括子机构新增、机构信息修改以及机构岗位管理。机构管理员只能维护其所属机构及下属机构的机构信息。

    l  子机构新增:机构管理员可以其所属机构的任意节点创建子机构,机构信息原则上不允许删除,不再启用的机构可以设置为禁用状态。

    l  机构信息修改:修改机构的基本信息。

    l  机构岗位设置:设置管辖机构启用哪些岗位,启用岗位的编制数量等,并维护各岗位的权限,当用户启用企业级授权体系时,用户所拥有的应用操作权限,将取决于该用户所处的岗位,用户的权限将随着岗位的变动而自然变动,减轻IT运维的权限管理工作。需要特别授予或特别限制的权限,由授权管理员针对用户进行个别设置。

    (2)用户管理

    用户管理功能主要用于管理用户账户及其权限,包括创建用户、用户冻结、用户激活、重置密码、用户权限设置等。

    l  用户账户新增:为尚未创建用户的员工创建用于身份认证的账户。机构管理员无权增加员工信息,员工信息需要统一用户中心或者人力资源管理系统进行维护。

    l  用户密码重置:重置某一用户的登录密码,用户密码被重置后,系统向用户发送一个随机的验证授权码,用户使用该验证授权码重新设置其登录密码。

    l  用户冻结:将正常的账号设置为冻结状态,被冻结的用户将不允许登录,冻结的用户被激活以后可以正常使用系统。

    l  用户激活:对被冻结的用户进行激活,以便该用户可以重新登录系统。

    l  用户权限设置:根据用户采用的授权体系,进入配套的界面对用户的权限进行维护设置。

    3、应用管理

    应用管理功能是应用管理员维护应用信息和分配应用权限的主要操作功能界面。当部署的应用系统数量较多时,一个应用管理员难以管理所有的应用系统,因此系统管理员在注册登记应用系统时,为应用系统指派了应用管理员。应用管理员通过应用管理功能,只能看到系统管理员为其分配的应用,并对这些应用系统的基础信息(包括应用资源、角色、角色可访问资源等)和应用权限分配进行管理。应用管理员无权注册应用,只能对系统管理员为其指派的应用进行管理。

    图5 应用管理功能结构

    (1)应用修改

    修改应用系统的基本信息(如版本信息、部署时间、运行状态等)。

    (2)资源维护

    维护应用系统的资源,包括新增、删除、修改等。

    (3)角色维护

    维护应用系统的角色信息,以及角色可访问的应用资源。

    (4)应用授权

    将应用系统的角色授予机构、机构岗位或用户组。应用管理员可以直接将应用角色授予各机构岗位及用户组,也可以只将应用角色分配到机构,再由机构管理员或授权管理员将机构所拥有的应用权限授权到岗位、用户组或用户。

    (5)授权查询

    对应用资源或角色的授权情况进行查询,便于了解应用是否存在授权安全风险,如敏感资源访问权限是否约束度不高的岗位、用户组或用户。

    4、授权管理

    授权管理是授权管理员日常授权管理工作的主要功能界面,包括设置或调整岗位权限和用户授权工作。授权管理员无权创建用户,只能对所属机构及其下属机构的用户进行权限管理。

    图6 授权管理功能结构

    (1)岗位权限管理

    维护授权管理员所属机构及其下属机构的岗位权限信息,为机构岗位增加授予应用角色,可供选择的应用角色来源于应用管理员给该机构授予的应用角色,或者撤销某一机构岗位已经拥有的应用角色。

    (2)用户授权管理

    根据用户账户信息中设定的授权体系,调出相应的授权管理功能,完成用户权限设定。

    l  企业授权体系:企业授权体系采用岗位授权方案,对机构岗位的权限进行统一设定以后,调入相关岗位的人员自然拥有相应岗位的权限,岗位变动时,权限亦随之变动。为了增加灵活性,可以对用户单独进行特例授权或特殊限权,被特例授权的用户,除了拥有岗位的所有权限外,还额外增加特例授权的权限;被特殊限权的用户,将失去指定限制的权限,哪怕其岗位拥有该权限或者特例授权该权限。当组织规模较大,或者组织比较健全时,适合采用企业授权体系。

    l  标准授权体系:标准授权体系采用用户组授权方案,对用户组统一进行授权后,将用户归入一个或多个用户组,让用户具有其所属用户组的所有操作权限。标准授权体系适用于能够将用户归类到数量不多的分组的应用场景,且只能有一个系统维护人员,若需要将系统管理任务逐级分解到不同的人员,也建议使用企业授权体系。当用户分类特别复杂时,建议采用企业授权体系。

    l  简易授权体系:简易授权体系直接对每个用户授予应用角色,适用于系统维护人员单一,用户数量较少的场合,如员工数量很少的组织。

    5、用户服务

    服务人员为了解答信息系统使用者日常操作过程中出现的与授权相关问题,需要使用该功能获取必要的数据支撑,并协助用户进行一些不影响系统安全的操作(如用户密码重置)。

    图7 用户服务功能结构

    (1)用户权限查询

    查询用户所拥有的权限,包括授权权限、委托权限、受托权限,以及当使用企业授权管理体系时的特例授权和特殊限权。

    (2)应用授权查询

    对应用资源或角色的授权情况进行查询,便于了解应用是否存在授权安全风险,如敏感资源访问权限是否约束度不高的岗位、用户组或用户。

    (3)用户密码重置

    重置某一用户的登录密码,用户密码被重置后,系统向用户发送一个随机的验证授权码,用户使用该验证授权码重新设置其登录密码。

    (4)用户账户冻结

    将正常的账号设置为冻结状态,被冻结的用户将不允许登录,冻结的用户被激活以后可以正常使用系统。

    (5)冻结账户激活

    对被冻结的用户进行激活,以便该用户可以重新登录系统。

    6、个人中心

    个人中心是面向已经通过认证的登录人提供的针对其个人账户的信息维护及常用操作,包括重置密码、修改登录密码、个人外部账号维护、个人联系信息维护、值班签到签退、权限委托等。

    图8 个人中心功能结构

    (1)登录密码重置

    由于忘记密码,个人申请密码重置。系统向该账户的密码保护手机或邮箱发送验证码,用户通过特定的密码重置界面,输入新的登录密码和验证码,若验证码验证有效,则将该用户的登录密码设置为新密码。密码重置申请也可以由管理员或客服人员发起,由用户在有效期内进行重置。

    (2)修改登录密码

    为了提高账户的安全性,建议定期修改账户的登录密码。修改登录密码需要验证当前密码,只有当前登录密码验证通过后,才能将该用户的登录密码修改为新密码。

    (3)个人外部账户

    维护登录账户对应的员工的外部账户信息,如远程医疗账户、电视电话会议账户等。

    (4)个人联系信息

    维护登录账户对应的员工的联系信息。

    (5)值班签到

    签到到选定的轮值岗位,将个人设置为该岗位的在岗值班人员。

    (6)值班签退

    从在岗的轮值岗位签退。

    (7)权限委托

    将个人所拥有的部分或全部权限,委托给其他人员,在委托有效期内,受委托人将具有委托人授予的委托权限,以便在委托人不在岗时,受委托人可以处理本该由委托人处理的事务,避免业务因委托人的不在岗而受到耽误。

    (8)受托权限

    查询个人所拥有的受委托权限。

    (二)统一配置管理(UCM)

    统一配置管理系统用于统一对各应用系统的可配置参数进行集中管理,以便通过单一功能入口管理各类应用系统的可配置参数。应用的可配置参数项,采用键值对存储,同一配置参数项的值,可以在应用(全局)级、机构级和个人(用户)级进行设置,个人配置值优先于机构配置值,机构配置值优先于应用(全局)配置值。也就是说,如果某个配置参数在个人配置项下有定义,则优先取个人配置项的值,否则如果机构配置项下有定义,则取机构配置项的值,最后再取应用配置项下的值,如果都没有定义,则取默认值。

    应用可配置参数采用类似于Windows注册表的结构存储,具体实现可以采用网络文件、数据库、LDAP等多种形式。

    图9 统一配置管理需求用例

    1.配置服务管理

    设置应用系统存取配置参数的服务地址。应用系统启动时,或运行过程中,将从配置的服务地址存取配置参数。

    2.配置导入导出

    将配置服务中各配置项下的参数值导出到文件,或从文件导入到配置服务中。导出、导入时,应该让用户选择导入导出的机构及个人。

    3.应用配置详情

    显示应用的可配置参数列表详情,以及机构配置项、个人配置项下的各参数设定值。

    (三)统一用户中心(UUC)

    统一用户中心为基础集成平台的员工管理中心,通过统一用户中心集中管理组织架构和职员。一般作为尚未部署人力资源管理系统的机构进行人力资源管理的工具,主要功能包括员工管理和值班管理等。

    1.员工管理

    员工管理功能包括岗位编制维护、员工账户管理、员工信息维护、员工岗位设置和人事异动业务。

    图10 员工管理功能结构

     

    (1)岗位编制维护

    设置各机构岗位的编制数量,维护岗位职责和岗位技能要求。

    (2)员工账户管理

    为尚未创建用户账户的员工创建用于信息系统进行用户身份认证的用户账户,设置用户账户的基本信息(如用户授权体系、是否默认账户、是否自动同步岗位信息等),或者冻结用户账户、激活已冻结账户、重置用户密码等。

    (3)员工信息维护

    维护员工信息,包括从人力资源系统同步员工信息或者从外部文件导入员工信息、员工信息新增、基本信息修改、联系信息维护、外部账号维护等。

    l  人力资源同步:采用信息接口的方式,从人力资源系统获取用户信息,用户刷新本平台的用户信息,对于已从人力资源系统消失的员工,标志为禁用(离职)而不作删除。

    l  员工信息新增:手工录入新员工的信息,创建员工基本档案,以便为员工创建其认证账户,只有系统管理员和机构管理员才能通过组织管理凭空(即没有员工资料档案)创建认证用户账户,员工管理员创建的用户认证账户,前提是存着该账户对应的员工。

    l  基本信息修改:修改员工的基本信息,包括姓名、性别、身份证件信息等。

    l  联系信息维护:维护员工的各种方式的联系信息,如手机、座机、办公电话、电子邮箱、即时消息号码等。

    l  外部账号维护:维护员工使用的外部账户,如电视电话会议账号及其他第三方平台的账号。

    (4)员工岗位设置

    维护员工的工作岗位,当员工的工作岗位发生变化时,若其认证账户设置了自动同步岗位,则该认证账户的岗位将与员工的岗位保持同步。这样,如果该用户使用企业授权体系,那么其权限自然随着人事岗位的变动而自然变动,不再需要IT运维部门参与人事变动的信息维护,减少IT运维工作量。

    (5)人事异动业务

    人事异动业务实现简单的可追溯的员工信息动向,包括员工入职、员工离职和员工调岗等。通过人事异动业务驱动员工信息、员工状态的变化,避免直接使用系统维护功能维护员工岗位。人事异动业务建议采用制单-审核分离原则,形成相互监督制约的机制,防范员工授权错误的风险。

    2.值班管理

    在一些行业(尤其是医疗服务行业、安全保卫部门等)中,存在值班制度,在非工作时间及节假日安排人员轮流履行特定岗位职责。为了在外部业务协同中让对方更容易寻址、定位到相关岗位的值班人员(尤其使用网络视频呼叫、电话呼叫等方式),将值班岗位设置为特殊的人员,为其设置固定的呼叫联络方式,这样不管如何安排轮值,外部都可以轻易地与其取得联系。

    图11 值班管理功能结构

    (1)轮值岗位维护

    维护组织机构的值班岗位及其相关联系信息、外部账户信息等,功能类似员工信息维护。

    (2)值班签到签退

    当值班人员不通过个人中心进行值班签到、签退时,通过此功能集中设置组织机构各轮值岗位的人员在岗及离岗状态及时间。

    (3)值班岗位查询

    查询各轮值岗位的在岗情况及值班人员信息。

    (四)统一消息管理(UMM)

    统一消息管理为认证用户提供统一消息收发接口,支持手机短消息、即时消息、电子邮件等消息类型,并可以支持多个消息网关,系统根据消息接收人的目标地址,自动选择最优的目标消息网关发送。

    图12 统一消息系统需求用例

    1.消息系统控制台

    消息控制台是消息管理员用户配置消息系统、监控系统消息收发情况的主要功能界面。

    (1)消息接口配置

    配置消息系统的消息网关及其路由规则。

    (2)收发消息查询

    查询、监控消息系统的消息收发情况,能够根据特定条件(如发生人、接受人、时间段、内容等)查询消息收发记录。

    2.系统收发统计

    统计消息系统的消息收发情况,包括全系统和特定用户在指定时间段的统计数据。

    3.个人消息

    个人消息是登录人个人消息及消息业务的总入口,对个人消息进行归类,系统默认将已经编制但尚未发出的消息归入草稿箱,将收到的消息归入收件箱,将已经发出的消息归入发件箱,已经删除的消息归入垃圾箱(回收站),允许用户自行创建新的归类,并自由将消息在不同分类之间(草稿箱除外)移动。

    (1)草稿箱

    用户编写的消息,在尚未发送之前,默认存储在草稿箱中。通过草稿箱可以调出消息,继续修改,直至发送或删除。

    (2)收件箱

    用户收到的所有各类消息,自动保存到收件箱。

    (3)发件箱

    已经成功发送的消息,自动保存到发件箱。

    (4)垃圾箱

    删除的消息,保存在垃圾箱。系统在个人消息存储容量不足时,将自动清理垃圾箱,将消息彻底删除以便释放其占用的存储空间;系统也会定时清理垃圾箱,哪怕存储空间充足,消息在垃圾箱中存储一定时间后也被彻底删除以释放空间。

    (五)用户账户复制(UAR)

    为了更好地兼容多种应用环境,统一用户认证(UAA)中心的用户账户信息,可以与第三方账户数据库实施自动同步。在UAA和第三方账户数据系统分别安装部署账户同步器,将其中一边设置成源账户中心,另一边设置为目标账户中心。账户同步器将订阅源账户中心的账户变动事件,或者定期查询源账户中心的变动账户信息,并将这些账户变动事件发送给目标账户中心的同步器。目标账户中心的账户同步器收到源账户中心发送的消息后,将对本地的目标账户中心相关账户信息进行设置,保持目标账户中心的账户信息与源账户中心同步。目标账户中心同步器也可以主动向源账户中心的同步器发送账户查询请求,获取源账户中心的账户信息并同步到本地目标账户中心。

    第三方用户账户中心类型主要考虑支持常见的微软AD域用户数据库和LDAP用户数据库,其他类型的用户账户中心,根据需要进行定制化接口开发。

    图13 用户账户复制需求用例

    (六)单点登录系统(SSO)

    单点登录(SSO)系统允许用户只登录一次,就可以在不同的应用系统之间实现免重复登录的用户身份识别,基础集成平台使用耶鲁大学开发的中央认证系统CAS(Central Authentication System)作为单点登录系统。

    在CAS系统中,用户使用身份证明(Credential,比如用户名密码、个人数字证书等)在CAS登录,CAS生成用户总票据(TGT,TicketGranting Ticket),用户拥有这个TGT就可以证明其已经在CAS登录过。

    当用户访问某个受保护的应用资源时,在B/S应用中,这个访问请求被应用服务器的过滤器拦截,用来判断该Session是否有用户信息或者有CAS颁发的访问该资源的授权(即服务票据ST, Service Ticket)。如果Session中已经有用户信息,则表明用户已经通过该应用的身份认证而允许其访问;如果Session中没有用户信息,但是有服务票据ST,则拦截器(调用CAS Client)向CAS申请对ST进行验证,如果ST验证有效,就返回用户信息并记录在Session中,实现用户在该应用的身份认证。如果既没有用户信息,也没有服务票据ST,表明用户尚未登录,拦截器将浏览器重定向到CAS的登录页面进行用户登录,登录成功后,CAS生成用户总票据TGT,并使用TGT和原访问的目标应用生成针对目标应用的服务票据(ST),再将用户浏览器重定向到原访问的目标资源,同时将ST作为参数传递给应用服务,应用服务器的过滤器再次拦截请求,此时发现有了ST,即向CAS申请对ST进行验证,完成应用的用户认证,并在Session中记录用户信息。

    C/S应用系统的客户端由于无法像B/S应用的Web端那样嵌入拦截过滤器实现单点登录,这就要求C/S应用程序在启动时接收服务票据ST,并主动向CAS申请对ST进行验证,验证通过返回登录的用户信息,完成对用户的身份认证。

    如果C/S应用程序在启动时,没有接收到服务票据ST,应从命令行参数获取用户身份证明(用户名密码、数字证书等),或者打开用户身份证明输入窗口,通过用户身份证明向CAS申请认证,或者打开CAS的登录页面实现用户登录。C/S应用的用户登录完成后,应通过服务接口向CAS申请获取用户总票据TGT,以便能够让C/S应用程序使用TGT向CAS申请访问其他应用程序的服务票据ST,将ST作为参数传递给其他兼容CAS单点登录的应用,实现C/S应用程序之间以及C/S与B/S应用程序之间的单点登录。

    (七)统一认证授权编程接口(AA-Lib)

    为了方便应用程序身份认证的功能开发,需要向开发人员提供基础集成平台的用户认证编程接口。编程接口主要提供Windows环境的DLL和Java、Php等编程语言的开发包。编程接口主要包括用户认证、用户信息获取、用户角色获取、用户资源获取和用户权限判定等,同时也提供用于向基础集成平台更新应用资源及角色的工具类接口,包括更新应用资源、更新应用角色和更新角色资源。

    在统一认证授权管理方案中,应用程序要在一些对用户权限敏感的功能点,对当前用户是否拥有特定权限进行判定检查,检查当前用户是否有权访问特定资源,或者检查用户是否拥有特定角色,所需的资源或角色可以编码在用户程序代码或界面资源中,如果用户拥有相应的角色,或者被授予访问该资源,就允许用户继续访问,否则拒绝用户访问。

    1.身份认证

    根据用户身份证明向基础集成平台申请用户身份认证,认证成功则返回用户总票据(TGT)以及简要的用户信息(用户ID、用户名称、真实名称、员工ID、所属机构等),输入参数包括:用户身份证明、认证服务器地址、特殊附加信息等。

    2.票据验证

    验证TGT或者ST的有效性,如果验证有效,则返回用户授权Token以及简要的用户信息(用户ID、用户名称、真实名称、员工ID、机构ID等),输入参数包括:票据、AppID。

    3.用户信息

    根据用户授权Token获得用户信息(如机构信息、岗位信息等),或者查询一些不常使用的用户信息项,输入参数包括:Token、机构ID、选项。

    4.用户角色

    根据用户授权Token获得用户的角色列表,输入参数包括:Token、AppID。

    5.用户资源

    根据用户授权Token获得用户可访问的资源列表,输入参数包括:Token、机构ID、AppID。

    6.角色判定

    根据用户授权Token判定用户是否拥有某几种角色,输入参数包括:Token、机构ID、AppID、角色集合。

    7.资源判定

    根据用户授权Token判定用户是否拥有某几个资源的访问权限,输入参数包括:Token、机构ID、AppID、资源集合。

    8.应用资源更新

    更新应用系统在基础集成平台注册登记的资源,输入参数包括:AppID、AppSecret、资源列表。

    9.应用角色更新

    更新应用系统在基础集成平台注册登记的角色,输入参数包括:AppID、AppSecret、角色列表。

    10.角色资源更新

    更新应用系统在基础集成平台注册登记的角色授权,输入参数包括:AppID、AppSecret、角色资源关系列表。

    (八)OpenID认证服务

    基于OpenID的标准规范,实现OpenID Provider服务,使得基础集成平台的用户账户,可以被遵循OpenID标准的外部应用或网站用于用户认证。

    建议新开发的应用程序遵循OpenID的用户认证标准,这样即便不考虑单点登录,也更有利于实现多个系统之间的集中用户管理和授权,使得应用程序可以在用户部署环境下灵活选择不同的认证服务器(需要认证服务器支持OpenID)。

    (九)社会组织模型管理(SOM)

    社会组织模型管理主要为网格化社会管理提供基础数据维护功能,主要包括社会网格化属性(行政区划、乡镇街道、社区商圈、村屯组小区等)、社会基本单元(基本物业单元、家庭等)、社会资产资源(地表地貌地物、水系、交通道路、地下管网、空间轨道等)、自然人信息和法人信息等数据库。通过自然人信息库、法人信息库和社会资产资源信息库的建设,实现更好的社会资源信息共享,以便更好地支持跨政府部门、跨行业的基础数据资源共享。

    图14 社会组织模型需求用例

    1.自然人信息库

    自然人是家庭成员、法人机构员工和社会人群管理的基础数据。通过自然人信息数据库,建立贯穿个人一生的人员主索引。

    2.法人信息库

    管理法人机构的基本信息及其分支机构(部门)、员工等数据的维护。

    3.资产资源信息库

    各类社会资产资源的基本信息及空间信息,主要包括地表地貌地物、水系、交通道路、地下管网、建筑物、设施设备等。

    4.社会网格化信息

    社会网格化信息主要包括行政区划(县区级)、乡镇街道及社区商圈、村屯组小区(道路)等社会网格关系以及基本物业单元(栋、层、单元、门号)和家庭等社会基本单元信息。

    四、数据库设计

    在数据库模型中,背景为绿色的实体,表示表的数据一旦初始化后便极少新增或修改,如代码表;背景为粉色的实体,表示表的数据会因机构规模增长或时间流逝,缓慢增长的表,这类表的数据一般与业务量没有关系,数据增长缓慢,数据变更频率低;背景为黄色的实体,表示数据会随着业务量的增长而增长,此类表数据增长速度较快,需要定期进行重建索引、分区存储等优化;背景为蓝色的实体,表示表的数据为临时数据,其中的记录最终会被删除,因此存储容量基本不会太大,但由于频繁进行删除操作,也需要定期关注存储空间碎片问题。

    作者已经针对常用的Oracle、SQLServer、MySQL等数据库生成了数据库建表脚本,并提供数据字典文档,需要的同学请从下载资源处搜索“基础集成平台”下载或向作者索取

    (一)组织机构

    图15 组织机构实体关系模型

    组织机构采用树形结构表示,每个顶级机构形成一个独立的体系,具有类似租户的特性。机构的岗位从全局的岗位名称表中选取,并根据机构规模设定岗位的人员编制熟练。各机构岗位的权限(即角色)由本机构具有管理权限的人员(机构管理员、应用管理员、授权管理员等)进行管理。用户归属某一机构,该机构为其默认的机构,即用户信息表中的机构ID。用户登录系统后,默认使用其所属机构,但可以根据从其用户岗位表中选择其他机构,切换成当前应用系统的工作机构。

    (二)用户与职员信息

    图16 用户与职员实体关系模型

    基础集成平台进行身份认证的主体信息是用户,大部分用户指代某个职员,部分用户可能是指代某个系统或设备甚至指代特殊的人群(如超级用户)。当用户信息中具有职员ID,表明该用户代表该职员。由于用户认证已经独立于应用系统,应用系统不再维护用户信息,甚至用户信息对应用系统不可见,但是职员信息是对业务系统可见的,因此,当业务系统产生的业务数据需要记录相关责任人时,应当使用其对应的职员信息,而不是用户信息。

    用户账户可以绑定手机号码、电子邮件或登录名,通过手机号码、电子邮件或登录名对用户账户进行唯一索引(数据结构参见互联网注册用户)。

    员工在系统内部用员工ID唯一标识,在外部表现上一般采用工号,员工工号在一定时间内具有唯一性,但是工号可能会被回收重复使用,比如有些单位领导的工号,一直使用固定的001、002或者666、888等特殊工号,当领导更换时,新任领导继续沿用该特殊工号。

    职员信息表中,有一类特殊的“轮值人员”,其本身不是员工,而是需要排班轮值的岗位,该岗位具有固定的联系方式和外部账户信息。引入轮值人员的概念,是为了便于外部协同单位或人员联系到当班人员,不因排班或换班而受到影响。

    (三)互联网注册用户

    图17 互联网注册用户实体关系模型

    基础集成平台支持互联网用户的注册、认证和授权管理。互联网注册的用户不属于任何机构,因此不存在与之对应的员工信息,但通过组织机构员工创建的用户账户,依然以作为互联网用户登录互联网平台。

    第三方用户是指微信、支付宝、钉钉等第三方应用平台的用户,通过OAuth授权访问本平台,此时需要将第三方用户与本地用户账户进行绑定,使用本地账户的授权访问本地应用。

    新注册的互联网用户,默认使用标准权限体系,即基于用户组的权限分配。

    (四)应用信息

    图18 应用信息实体关系模型

    应用信息表的内容包含用于授权管理的应用和用于单点登录的应用,仅用于单点登录的应用不需要维护其资源和角色,只需要维护其访问入口、认证方式、启动方式等基本内容。

    (五)社会组织模型

    社会组织模型的数据结构及系统功能,放在医疗健康云平台中设计,目前基础集成平台暂不包含社会组织模型管理。

    (六)企业授权体系

    图19 企业授权体系实体关系模型

    企业授权体系下的用户权限,由用户岗位表关联到机构岗位角色表,得到用户岗位对应的角色,再加上用户受托权限表拥有的有效期内的角色和用户独立授权表的角色,最后排除用户独立限权表的角色,就是该用户所拥有的全部角色。

    给用户授权,主要通过设置用户岗位实现,若用户具有特殊性,可以通过用户独立授权表为用户额外增加授权,通过用户独立限权表为用户排除某些权限的应用。

    用户将其拥有的部分或全部权限委托给受委托人时,同时在用户委托权限表和用户受托权限表产生数据,其中用户委托权限表中的用户ID为委托人的ID,受托权限表中的用户ID为受托人的ID。

    用户所拥有的全部应用角色可以访问的应用资源,就是该用户有权访问的资源(开放授权的资源所用用户都可访问)。

    (七)标准及简易授权体系

    图20 标准及简易授权体系实体关系模型

    标准权限体系使用用户组权限,先对用户组设置该组具有的应用角色(即用户组应用角色表),然后再将用户组授予用户,用户便具有所属用户组的相应应用角色。一个用户可以隶属于多个用户组。

    简易授权体系不采用用户组,直接对用户授予应用角色(即用户授权角色表),判断用户权限时,直接从用户授权角色表中查询该用户的应用角色。

    用户所拥有的全部应用角色可以访问的应用资源,就是该用户有权访问的资源(开放授权的资源所用用户都可访问)。

    (八)用户单点登录配置

    图21 用户应用配置实体关系模型

    单点登录集成用户桌面环境(SSO-UIDE),使用用户应用配置表获取用户配置的常用应用及其认证方式和启动参数,实现集成用户桌面环境的配置漫游。用户应用配置表的应用信息,可以是应用信息表中注册的应用(即应用ID非空的记录),也可以是用户独立配置的应用(即在应用ID为空的记录),当应用ID非空时,应用类型、认证方式、网页启动URL、本地启动命令行、自动填表配置文件等字段内容,如果用户应用配置表中为空值,则取应用信息表中的相应字段值。

    五、其他说明

    本篇主要描述基础集成平台的总体架构及设计思路,重点对最基础的统一用户中心(UUC)和统一认证授权(UAA)进行详细的功能设计和数据库结构设计。基础集成平台其他模块的详细设计方案,将在后续推出。


    展开全文
  • 什么是涉密信息系统

    千次阅读 2019-12-11 13:09:56
    什么是涉密信息系统? 涉密信息系统,是指由计算机及其相关和配套设备、设施构成的,按照一定的应用目标和规则存储、处理、传输国家秘密信息的系统或者网络。 涉密信息系统主要指用于处理涉密信息的计算机设备或者...

    什么是涉密信息系统?
    涉密信息系统,是指由计算机及其相关和配套设备、设施构成的,按照一定的应用目标和规则存储、处理、传输国家秘密信息的系统或者网络。
    涉密信息系统主要指用于处理涉密信息的计算机设备或者用于实现内部办公自动化的涉密信息交换网络体系。通常情况下涉密信息系统是指有着一定安全保密需要和要求的计算机系统,按照国家强制性标准和规定,达到一定安全等级的计算机系统被称之为涉密信息系统。
    简而言之,一个计算机信息系统是否具备涉密属性,能够称之为涉密信息系统,主要是看这个计算机系统里面的信息是不是涉及到国家秘密,涉密信息的数量多与少不论,只要存储或者处理、传输了涉密信息,那么这个信息系统就应确定为涉密信息系统。从这个概念出发,可以看出并不是所有涉密信息系统都是较高安全等级的计算机信息系统,也不是所有安全等级的计算机信息系统都是涉密信息系统。随着商业竞争的越发激烈,目前,一些企业为保障其商业信息安全,采取了非常多的安全保密措施,引进了信息安全保密技术和设备,这些企业信息安全管理的等级非常高,但这些企业内部的信息系统,并不是涉密信息系统。通常的涉密信息系统都是党政机关内部使用的计算机系统,只要计算机系统当中运行或者存储、处理、传输了国家秘密信息,那么这个系统就是涉密信息系统,不论其信息等级高低,只要涉密,都应被称之为涉密信息系统,进而能够实现更为规范的管理,实现安全可控。
    在这里插入图片描述

    涉密信息系统与公共信息系统的区别,主要体现在四个方面:
    一是信息内容不同。涉密信息系统存储、处理和传输的信息涉及国家秘密和其他敏感信息,应严格控制知悉范围;公共信息系统存储、处理和传输的信息不能涉及国家秘密。
    二是设施、设备标准不同。涉密信息系统的安全保密设施、设备,必须符合国家保密标准;公共信息系统的安全保密设施、设备也应符合一定技术标准要求,但并不要求执行国家保密标准。
    三是检测审批要求不同。涉密信息系统必须满足安全保密要求,符合国家保密标准,投入使用前必须经安全保密检测评估和审查批准;公共信息系统投入使用前也需要进行相关检测,但检测的目的和要求不同。
    四是使用权限不同。涉密信息系统要严格控制使用权限;公共信息系统则是开放性的,只要具备一定访问条件就可以使用。

    展开全文
  • 消息系统设计与实现

    千次阅读 2018-12-07 11:44:51
    消息系统设计与实现
  • 1、计算机信息系统集成资质信息产业部从1999年开始建立计算机信息系统集成资质管理制度,制定并发布了《计算机信息系统集成资质管理办法》。 计算机信息系统集成资质等级分一、二、三、四级。一级:具有独立承担国家...
  • Apache Kafka:下一代分布式消息系统

    千次阅读 2017-08-16 09:23:45
    简介Apache Kafka是分布式发布-订阅消息系统。它最初由LinkedIn公司开发,之后成为Apache项目的一部分。Kafka是一种快速、可扩展的、设计内在就是分布式的,分区的和可复制的提交日志服务。Apache Kafka与传统消
  • 信息系统管理工程师教程高清版PDF

    千次下载 热门讨论 2011-12-10 10:58:56
    经过本人下载后整理成一个压缩包,希望方便各位朋友下载。
  • 信息系统项目管理师考试是否有必要考?证书有什么用处呢?对以后的工作有什么好处?2019年下半年的软考报名开始了要不要报?如果以后从事的工作不是it行业呢?相信有很多朋友都有存在这样或那样的疑问,那么今天在...
  • 一、前言我国的医院信息化建设,始于上世纪80年代中末期,经过90年代的自由繁荣(ye man)发展和本世纪初的政策扶持、引导规范与市场培育,历经30多年的发展,目前已经遇到瓶颈。其中最根本的原因是系统架构问题,...
  • 信息系统项目管理师考试辅导(针对上午考试和针对下午考试)
  • 消息系统数据库表设计

    千次阅读 2019-06-14 18:16:10
    初步设计消息系统,用户表的字段待完善;这里把分组和群组放一张表用类型区分
  • 卡夫卡是分布式发布 - 订阅消息系统它最初由LinkedIn公司开发,之后成为Apache的项目的一部分.Kafka是一个分布式的,可划分的,冗余备份的持久性的日志服务它主要用于处理。活跃的流式数据。 在大数据系统中,常常...
  • android设备在系统通知栏处提示有新消息,同时也有声音通知
  • Kafka(分布式发布-订阅消息系统)

    千次阅读 2018-04-20 12:57:08
    一、简介Apache Kafka是分布式发布-订阅消息系统,在 kafka官网上对 kafka 的定义:一个分布式发布-订阅消息传递系统。 它最初由LinkedIn公司开发,Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。Kafka...
  • 学生选课管理信息系统

    万次阅读 多人点赞 2019-01-04 11:55:23
    学生入校注册后需统一记录学生个人基本信息,对于面向学生开设的相关课程需要记录每门课程的基本信息,每个任课教师规定其可主讲三门课程,学生选课时系统将相应的选课信息记录入库,考试结束后需在相应的选课记录中...
  • 信息系统项目管理师 - 项目质量管理 规划质量管理 实施质量保证 控制质量 信息系统项目管理师 - 项目质量管理 规划质量管理 实施质量保证 控制质量 版权声明:转载必须注明本文转自 East196...
  • 信息系统项目管理师 - 项目沟通管理 规划沟通管理 管理沟通 控制沟通 信息系统项目管理师 - 项目沟通管理 规划沟通管理 管理沟通 控制沟通 版权声明:转载必须注明本文转自 East196 的博客:...
  • 主流消息系统框架「架构师必看」

    千次阅读 2018-05-03 14:22:24
    RabbitMQ 2007年发布,是一个在AMQP(高级消息队列协议)基础上完成的,可复用的企业消息系统,是当前最主流的消息中间件之一。,通常用于应用程序之间或者程序的不同组件之间通过消息来进行集成。RabbitMQ提供可靠的...
  • 信息系统项目管理师 - 项目风险管理 信息系统项目管理师 - 项目风险管理 版权声明:转载必须注明本文转自 East196 的博客:http://blog.csdn.net/east196 ...
  • 信息系统项目管理师 - 项目干系人管理 信息系统项目管理师 - 项目干系人管理 版权声明:转载必须注明本文转自 East196 的博客:http://blog.csdn.net/east196 ...
  • 信息系统项目管理师 - 项目人力资源管理 规划人力资源管理 组建项目团队 建设项目团队 管理项目团队 信息系统项目管理师 - 项目人力资源管理 规划人力资源管理 组建项目团队 建设项目团队 管理...
  • 信息系统项目管理师 - 项目立项管理 信息系统项目管理师 - 项目立项管理 立项管理并不属于项目管理十大知识域范围,但也是项目管理的基础。 版权声明:转载必须注明本文转自 East196 的博客:...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 5,561,887
精华内容 2,224,754
关键字:

消息系统