精华内容
下载资源
问答
  • 还记得我们在Why ZStack中说的,稳定性和灵活性是IaaS需要解决的两大问题。今天我们就来揭开ZStack超强灵活性的奥秘。 今天的内容非常的丰富,我们先来看一下什么是灵活性。所谓灵活性无非是三个方面:当需要添加新...

    在前面探秘一和探秘二中,我们已经分享了ZStack的拓扑结构和如何实现超高可伸缩性的能力。还记得我们在Why ZStack中说的,稳定性和灵活性是IaaS需要解决的两大问题。今天我们就来揭开ZStack超强灵活性的奥秘。

    今天的内容非常的丰富,我们先来看一下什么是灵活性。所谓灵活性无非是三个方面:当需要添加新功能的时候简单方便,不拖泥带水;系统升级轻巧无障碍;IaaS云配置想改就改,无需重头搭建,改动影响仅限于被影响的部分。让我们带着这三个方面的定义来读今天的内容。


    首先让我们看看通常一个自由生长出来的IaaS,它内部各个Components之间的消息传递或者说逻辑关系图吧。


    是不是看起来还行?熟悉IaaS的人应该可以理解。有没有想过当你再增加一个监控,一个计费,一个管理界面的时候,它可就不只是增加三个圈圈这么简单了,这图里的连接线怕是要多上好几倍。而当你需要修改一个圈圈的数据结构和输出结果的时候,你需要更改所有和当前圈圈有联系的其他功能模块的接口。为什么会是这样?这因为在自由生长的IaaS设计之初,功能比较单一,模块很少,所以模块之间的连线简单而清晰,直连的方法最容易实现而且有效。但是当等到项目越变越大,连线越连越多的时候,一切都晚了,到最后就变成就是一个令人恐怖的拓扑结构。


    多说无益,让我们直接来看看ZStack各个模块之间的关系图吧,星型拓扑结构


    每个微服务自然分离,又通过统一的Message Bus来连接。添加新的微服务,就增加一个星型节点和一条连线。是不是很清晰很简单?为什么会怎么简单呢?好像也没有为什么,这就是大自然在灵活性上的应该遵循的规则啊。


    在ZStack里面,微服务的架构又被称为进程内的微服务(In Process Micro Service中文翻译实在拗口啊)。它有如下的特点:

    • 每个服务之间相互独立,通过消息总线连接;

    • 所有的微服务都集合在同一个进程内,也就是我们说的管理节点(Management Node)

    • 因为通过消息总线连接,在不同管理节点上的微服务都可以相互通信(并且相互不知道是不是在相同的管理节点上)

    • 在多管理节点上存在相同的微服务(例如都有管理计算的微服务),最后由哪个管理节点上微服务来处理任务,是由Consistent Hashing Ring选择出来的(这点我们在《ZStack架构探秘二》中有阐述)


    接着让我们来看看ZStack是如何添加一个服务的。有了星型拓扑结构,添加新的微服务就变的简单起来。除了常规的微服务,IaaS的操作最终要落地在管理计算,存储和网络三大资源上。拿计算资源来举例,它有一个计算服务。在计算服务下面存在虚拟化和非虚拟化两种形式,其中虚拟化也可以分为KVM、VMWare、Xen、HyperV等。如果ZStack支持了KVM,也就是说要集成所有KVM的基本功能。另外,相比存储和网络,计算资源的种类是很少的。也就是一个可以工作的IaaS里面会集成很多的服务和具体的功能。面对可能多到数不清的微服务和具体功能,ZStack是怎么来支持的呢?可以用什么方法来保证新添加的功能既方便又不影响现有其他功能呢?ZStack采用了类似Eclipse的插件形式来实现不同的资源的管理。例如ZStack的主存储是存放虚拟机的各种Volume的,从实现上可以有NFS的主存储,iSCSI的主存储或者本地存储。那么就会去针对不同的类型实现对应的插件即可:

    L2的网络也是一样的道理,可以通过Vlan,OpenVSwitch,或者VxLan来实现隔离和连通:


    那具体来说,一个plugin是怎么实现的呢?ZStack的plugin根据所需要的功能可以采用不同的plugin策略:Strategy Plugin或者Oberserver Plugin。简而言之,策略插件会继承父类型的接口然后做具体的实现(例如实现NFS插件);观察者插件,会注册listener到提供注册的地方,当特别的事件发生的时候,注册的lisetener就会被调用,然后在调用中去实现插件的功能(例如在创建VM之前去登记计费。或者如下例所展示的SecurityGroup需要在不同的操作的时候去添加和删除对应的SG规则。)。


    需要指出的是,ZStack的插件非常灵活。它可以编译成独立的JAR文件,由ZStack加载(成为进程内in process的一部分)。删除后,也只是失去了该插件的功能本身,而不会影响其他功能。另外,由于ZStack的服务都是通过Rabbitmq来通信的,也就是我们也支持任何可以和Rabbitmq来通讯的进程外(out-of-process)插件。所以ZStack的插件功能是非常灵活的。用户可以选择任何语言来实现自己的插件。


    ZStack是如何处理错误的?能回滚错误造成的影响吗?由于IaaS管理的是非常复杂而庞大的系统,错误(由于网络,软件甚至硬件导致)发生频率一定不少。一个好的软件系统不仅仅能在一切正常的情况下能够稳定工作,更需要在不稳定的系统中能够提供稳定运行的能力。这就需要完善的容错和纠错的手段,在发生不可预见的系统的错误的时候,能够正确处理。事件回滚是处理由于出错导致的很多临时中间状态(有时候这些中间状态实际上就是系统垃圾)的有效手段。例如当创建VM的操作失败在最后一步,例如Host掉电。那么之前给VM分配的IP地址,根分区文件,数据库记录都应该通过回滚而清理掉。如果不回滚,那么系统中的就会留下很多垃圾,最终导致IaaS资源耗尽。

    ZStack设计了精巧的工作流引擎(Workflow Engine)既用来管理任务执行的顺序,而且不论任务在什么地方出错都会按照原先执行的路径回滚。


    ZStack 工作流引擎有如下特点:

    • 工作流可以用XML文件或者具体编程实现;

    • 每一个工作流都可以回滚错误;

    • 每个工作流还可以包含子工作流用于扩展业务逻辑


    让我们来看看如何通过XML文件来定义ZStack的一组工作流的:



    虽然利用插件系统可以添加新的功能,但是如果我们需要对原有功能进行扩展(这个不可避免,毕竟人的认知是有限的,不能保证原有功能可以支持未来更丰富的参数),可能会改变接口或者是改变原有数据结构中的表单。这种改变导致的问题是,基于原有数据库搭建的IaaS很难迁移和升级。我们可以看到在现有的IaaS系统里,这个方面的问题非常突出。为了解决这个问题,ZStack创造性的发明了一个Tag系统。通常大家认为的Tag系统只是用于给资源打标记做归类。ZStack的Tag系统除了最基本的打标签的功能外,它还可以实现System Tag。System Tag具有两个特殊的功能:

    1. 和插件一起合作可以改变原有系统的行为;

    2. 给资源添加一个新的属性;


    什么是改变原有系统行为。例如在ZStack中,一个Cluster可以挂载多个主存储。在启动VM的时候,用户通常只能选择VM的Zone,Cluster,Host等信息(如果不指定,ZStack会按照预先设计的策略自己选择)。如果用户希望VM被创建到一个特定的主存储,这个时候就可以利用系统System Tag来实现。例如我们可以实现一个特别的系统Tag,并且实现一个插件规定:当我们需要创建的VM被标注该系统Tag,那么这个VM的主存储就会在预先指定的一个主存储(该主存储也会被设置上相同的系统Tag)上创建。在ZStack中,VM可以设定DHCP Hostname。也就是在VM在获取DHCP IP地址的时候,同时也会获取一个系统分配的Hostname。但是由于这个DHCP HOSTNAM 并不是VM网卡的固定属性(因为从物理资源角度,VM NIC的确不应该具有一个Hostname的属性),最后在ZStack中,Hostname的功能也是通过系统Tag来实现的。



    最后我们来谈谈IaaS部署后,满足客户需求变更的问题。前面我们基本上都是在讲怎么能够给IaaS更容易的添加功能的问题。不过判断IaaS是否灵活,还有一个非常非常关键的问题,就是IaaS根据用户的要求配置完成后运行了一段时间,用户发现原有的资源配置需要更改,IaaS能否根据用户的要求改变?这个改变是不是可以通过一两个命令就完成,还是需要重头搭建整个IaaS系统?对于ZStack来说,我们的一大杀手锏就是配置灵活易变。我们暴露了非常全面的API,既有Add/Create Resource的,也有Delete/Destroy Resource的API,还有大量的resource的挂载和卸载的API。可以说用户想改变网络拓扑,如把eth0的设备去掉,或是替换主存储的设备对ZStack来说都是小菜一碟。添加的操作其实影响还好,但是删除的操作可是会造成大面积的影响。比如删除一个host,它的影响只限于这个host上,该host上的VM会被暂时stop掉;而删除一个Cluster,会导致删除这个Cluster上所有的Hosts,卸载主存储,以及相关的VM被删除。而删除L2 Network,则会导致正在使用该L2网络的VM(可能会跨很多的Cluster)被Stop掉。在ZStack中,我们有专门计算和处理由于删除架构中的某个资源而会波及到做哪些操作的Cascade Framework。这个架构说起来其实也很轻巧,你需要构建一个大大的地图,把资源按照相互关系梳理出来。不过很可惜的是,我们没有在别的IaaS系统中发现有如此轻巧的设计,恐怕它们以后也没有办法推出类似的设计了。


    有了这个资源相互影响地图后,当卸载或者删除一个资源的时候,我们就可以轻松的把受影响的资源的处理方法安装顺序调用一遍。


    今天,我们一口气介绍了ZStack的五项独门秘籍,它们可都是为实现超灵活性和可扩展性而量身定做的。他们既独立发挥着作用,又有相互关联。可以说是构成ZStack架构中非常重要的5个环节。通过他们,希望大家对我们的超灵活性有了进一步的了解。我们可是绝不忽悠,是骡子是马大家拉出来遛遛。另外由于微信里的内容都是点到为止,详细内容还请大家移步我们的官网,上面详细阐述了五大秘籍的来龙去脉:


    • In-Process Microservice Architecture: http://zstack.org/blog/microservices.html

    • Plugin System: http://zstack.org/blog/plugin.html

    • WorkFlow Engine: http://zstack.org/blog/workflow.html

    • Tag System: http://zstack.org/blog/tag.html

    • Cascade Framework: http://zstack.org/blog/cascade.html


    展开全文
  • 统一配置数据源:蓝鲸配置平台

    千次阅读 2018-09-07 18:12:48
    3、蓝鲸配置平台设计理念 4、CMDB实施中需要解决的核心问题   蓝鲸简介   蓝鲸智云,简称蓝鲸,是腾讯游戏运营部“腾讯智营”下的子品牌。它是一套基于 PaaS 的企业研发运营一体化技术解决方案,提供了一个...

    关注嘉为科技,获取运维新知

     

    目录

    1、蓝鲸简介

    2、传统CMDB建设的问题

    3、蓝鲸配置平台设计理念

    4、CMDB实施中需要解决的核心问题

     

    蓝鲸简介

     

    蓝鲸智云,简称蓝鲸,是腾讯游戏运营部“腾讯智营”下的子品牌。它是一套基于 PaaS 的企业研发运营一体化技术解决方案,提供了一个完整的研发、运维、运营的PaaS技术平台。平台提供了完善的前后台开发框架、调度引擎、公共组件等模块,帮助业务的产品和技术人员快速构建低成本、免运维的支撑工具和运营系统;是腾讯游戏运营部沉淀多年的技术运营支撑体系,承担着数百款业务线上运营的使命。

    对于蓝鲸不太了解和熟悉的同学可以移步这里:

    http://bk.tencent.com/index/,

    还有这里:

    http://docs.bk.tencent.com/product_white_paper/introduction/。

    请相信,你打开的不是两个链接,而是运维的新世界和新天地。

     

    传统CMDB建设的问题

     

    我们知道CMDB最早来自于ITIL,后来逐渐被各种IT管理工具吸纳,成为管理工具的一部分。例如ITSM中有CMDB,网管工具有中有CMDB,监控工具中有CMDB……

     

    这么多工具中都可以有CMDB,会导致很多问题:各个工具的CMDB诸侯割据,互不相通,数据不一致,需要维护多份数据等等。

     

    我们将传统CMDB建设存在的问题总结一下:

     

    1、自动化管理弱

    • 手动管理为主

    • 事后管理为主

    • 自动采集较弱

    • 管理成本高昂

    2、不以应用为中心

    • 更多是对象和属性罗列

    • 缺乏应用视角配置管理

    • 更多面向资产和流程

    • 应用与下层资源脱节

    3、数据流动性差

    • 缺乏自动化平台支撑

    • 外部对接扩展性差

    • 外部消费扩展性差

    • 跨云管理扩展性差

    4、数据一致性&准确性差

    • 缺乏自动发现校验

    • 缺乏数据扫描监控

    • 缺乏数据规则校验

    • 缺乏外部系统同步

    5、未对接自动化

    • 任务编排消费

    • 资源交付消费

    • 运维操作消费

    • 运营分析消费

    6、未对接流程

    • 未对接ITSM流程平台

    • 不支持配置数据读取与回写

    • 不支配置异常推送工单

    • 未构建配置管理同步和闭环

    7、未对接监控

    • 未对接企业监控系统

    • 不支持面向监控数据消费

    • 不支持故障影响范围分析

    • 不支持配置和监控可视化展示

    8、不可审计

    • 未实现所有变更均记录

    • 未实现任何更改可审计

     

    蓝鲸配置平台设计理念

     

    1、以业务与应用为中心的开放、开源的CMDB整体架构

    IT运维管理本身是以应用为中心进行的管理,因此合情合理的CMDB建设应该是以业务和应用为中心建设的CMDB,如此两者才能匹配起来。

    蓝鲸的CMDB设计正是以此为设计的基础。

    以应用为中心,理解起来是这样的:配置数据的入库和存储是以应用为中心的,配置数据的展示和查询是以应用为中心的,配置数据的消费和数据回写也是以应用为中心的。

     

     

    2、面向自动化场景、ITSM流程场景、监控&自愈场景的CMDB一体化数据消费

    应用运维和IT管理中针对CMDB配置数据的消费总体来说包括三种类型:自动化运维、ITSM流程、监控&故障自愈。

    这就要求CMDB具备对接和集成这三种工具的能力。蓝鲸CMDB原生集成蓝鲸的自动化运维平台和蓝鲸监控,并开放标准的接口能够对接企业自身的ITSM系统以及监控系统。

    这样一来,在企业中,只需要维护一套核心的CMDB数据源,就能在几乎所有场景中消费并维护数据。

     

     

     

     

    3、统一的、流转的、“活”起来的、闭环的CMDB数据源泉

    在上述任意一种运维场景中,配置数据本身都包含消费和回写等两个链路,整体构建成一个数据消费的闭环;确保配置数据在流转中始终是准确的,一致的。

     

    4、全方位、可视化、够灵活的CMDB自动管理和展示

    配置管理除了面向运维管理员之外,很多时候还需要将相关数据展示给其他人,比如领导。这就要求配置管理本身需要具备良好的可视化展示能力。

    嘉维蓝鲸研发的数据可视化工具,可以完美解决这一需求。不仅可以展示配置数据,还能接入各种监控数据、容量数据、自动化运维数据等,做集中展示和查询。

     

    CMDB实施中需要解决的核心问题

    结合上述CMDB的设计理念,在以业务和应用为中心的CMDB建设中,需要解决几个核心的问题。

    1. 如何设计业务(应用)层级

    2. 如何设计各层级模型和关联关系

    3. 如何入库各层级配置信息

    4. 如何实现数据消费闭环,并确保数据的一致性、准确性

    5. 如何进行CMDB可视化管理和安全管理

     

    1、如何设计业务(应用)层级

    应用的层级设计是在CMDB建设中第一需要考虑的问题,不同的企业相同应用或同一个企业的不同应用,层级拓扑和应用下属各个模块都是不同的。这就需要CMDB本身具备很强的灵活性,能够因地制宜,针对不同的应用或者业务需求,设计不同的应用层级拓扑。

    蓝鲸CMDB由于是一个非常开放的平台,并且本身完全开源,因此很容易能够满足上述要求。

     

     

    2、如何设计模型蓝图

     

    这一部分要解决的核心问题是:我们应该将哪些对象的哪些属性入库CMDB,这些对象之间应该具有怎样的关联关系。

    答案是:用到什么,就放什么。我们需要根据实际的运维场景的需求,来决定放什么数据,不放什么数据。不要为了数据而数据,而应该为了使用而放数据。大而无当的CMDB只会成为运维的累赘和后腿。

    作为企业而言,这个过程需要紧密配合服务商,一起参与进来。只有我们自己是最清楚自己需要什么数据的,不能指望有一个产品部署上来就能自动解决所有的数据需求。我们需要细细梳理各种各样的场景中大致需要怎样的数据,然后使用不同的手段将这些数据填充到CMDB中。

    这个过程非常关键和重要,决定了CMDB在之后是否真正的用起来和用好。因此,需要服务商本身具备深厚的IT运维和服务经验,对于企业中特别是传统企业中的日常运维非常清楚,并且积累了标准的CI、CI属性和关联关系的标准库和模板。仅仅靠理论推演和臆测,这个过程是绝难做好的。

     

    总结起来,这个部分要做好,需要服务商具备几个能力:懂企业的运维、懂企业使用的产品和技术、有相应技术人员和力量。

     

    嘉为作为一家立足北上广深,辐射全国的IT综合服务商,历经18年的发展与沉淀,形成了成熟的服务能力、服务体系和能力沉淀;常年技术服务合作客户超500家,各行业龙头企业均选择嘉为作为战略性合作伙伴。

     

    嘉为与Microsoft、阿里云、腾讯、RedHat、Oracle、VMware、Vertas、Citrix、EMC等国内外主流IT厂商合作,是这些IT大厂的重要合作伙伴。

     

    嘉为技术人员超300名,多为211/985院校毕业,基本素质高、学习能力强;内部员工离职率低,上述各技术领域均有10年以上的资深专家深度支持。

     

    结合蓝鲸强大的配置平台,轻松实现CMDB在企业的落地。

     

    3、如何入库各层级配置信息

    在将配置信息入库CMDB的过程中,需要结合多种手段实现。

    针对不同的数据,这些手段包括:与外部系统同步、自动发现和自动采集、手动批量导入。

     

     

     

    4、如何实现数据消费闭环,并确保数据的一致性、准确性

    这一部分一半靠技术和工具,另一半靠管理、制度和习惯。尽量按照企业内部规范的配置变更流程执行配置的变更,即便偶尔来不及,变更之后也需要补充相应的流程。可以是ITSM流程,也可以是相对简单的工单流。

    在这一点上,蓝鲸具有天然的优势。由于蓝鲸CMDB与蓝鲸自动化运维平台原生集成,因此通过自动化运维平台执行的任何变更操作,都会自动同步到CMDB中。如果需要其他系统也能及时获取最新的配置数据,比如ITSM系统,就需要将ITSM系统与蓝鲸的CMDB集成。这方面,在蓝鲸层面实现也是比较容易的。

     

     

     

    除此之外,服务商在交付CMDB建设项目的时候,除了项目交付和普通文档交付之外,还能够针对企业的实际运维环境,交付一套《CMDB配置维护流程规范》和《CMDB配置维护流程细则》;并且确保规范和细则是符合企业实际环境需求,并能持续运转的。

    如此,就是既授之以鱼,又授之以渔。

     

    5、如何进行CMDB可视化管理和安全管理

    数据可视化越来越成为很多中大型企业IT管理的刚性需求。由于业务系统众多,IT环境复杂,领导层迫切需要在一个集中的大屏中能够看到企业整体的业务运维情况和IT环境情况。

    对此,嘉为专门开发了数据可视化的工具,支撑上述需求。不仅可以将CMDB数据,还可以自定义将监控数据、容量数据、健康巡检数据等做集中展示。

     

    总结一下:蓝鲸配置平台是一款面向应用的 CMDB。在 ITIL 体系里,CMDB 是构建其它流程的基石,而在蓝鲸智云体系里,配置平台就扮演着基石的角色,为应用提供了各种运维场景的配置数据服务。

     

    嘉维蓝鲸凭借自身丰富的IT服务经验、规模化的人才梯队和对于CMDB的深刻理解,结合蓝鲸CMDB强大的能力,为企业提供切实可落地、可扩展、可消费、有质量、闭环的CMDB配置数据平台。

     

    欲了解更多关于蓝鲸CMDB的具体内容,可浏览蓝鲸官网:

    http://docs.bk.tencent.com/product_white_paper/cmdb/

     

    本文首发于微信公众号:嘉为科技,转载请注明出处。​​​​

    展开全文
  • 数据接口标准规范

    万次阅读 2019-08-09 16:24:21
    接口规范定义了与其他系统进行数据交换的数据规范报文规范。 2 规范引用文件 下列文件中的条款通过本标准的引用而成为本部分的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均...

    1 范围
    接口规范定义了与其他系统进行数据交换的数据规范和报文规范。
    2 规范性引用文件
    下列文件中的条款通过本标准的引用而成为本部分的条款。凡是注日期的引用文件,其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本部分,然而,鼓励根据本部分达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件,其最新版本适用于本部分。
    GB/T 1.1 标准化工作导则 第1 部分:标准的结构和编写
    GB/T 35778—2017 企业标准化工作 指南
    GB/T 5271.8-2001 信息技术 词汇 第8部分:安全
    GB/T 18811-2002 电子商务基本术语
    DL/T 485—2018 电力企业标准体系表编制导则
    DL/T 800—2018 电力企业标准编写导则
    DL/T 1004 电力企业管理体系整合导则
    3 接口服务描述规范
    3.1 概述
    接口服务描述是业务服务的集中描述,包含其提供的功能以及如何进行调用;是在电力安全系统发布的服务提供方和服务调用方之间的规约。接口服务描述必须包含对各个方面的人员有意义并可理解的信息,接口服务描述要包含概要和详细服务信息,使用平台/技术实现无关的语言进行描述以业务为导向。
    接口服务描述主要由2部分组成:接口服务属性和接口服务规约。
    3.2 接口服务属性
    接口服务属性是业务接口服务的描述,它提供组织和性能相关要求,是接口服务提供方和接口服务消费方之间服务协议的依据。定义一个接口服务应该包含的属性如下所示:
     服务编码(必选):能体现出接口服务的业务含义的唯一识别编码,应遵循统一的编码规则,具体定义请参考交易服务代码规范;
     接口服务中文名称(必选):能体现接口服务的意义,简单概括,应少于30个汉字;
     接口服务描述(必选):清晰描述接口服务的业务功能;
     服务提供方(必选):提供此接口服务的业务系统;
     服务消费方(可选):可能会使用到此接口服务的业务系统;
     服务等级(必选):分为紧急、普通和低级;
     报文XSD文件名:指请求报文XSD文件名和响应报文XSD文件名;
     数据量(必选):运行期间单次访问的数据量均值和范围,比如均值为200K,范围:100K-300K;
     运行效率(可选):单次访问的响应时间均值和范围;
     支持并发(可选):此接口可支持的并发访问量;
     是否可重(可选):接口是否能被多次重试调用;
     超时说明(必选):提供超时时间及其说明。
     返回码说明(必选):业务上需提供返回码和返回信息给服务消费方。
     技术方式(必选):明确此接口的技术方式,其技术方式必须为《电力安全系统接入规范》中规定的技术方式;
     调用说明(必选):提供调用此接口服务的必要条件。根据《应用平台接入规范》中定义的接入技术方式:
    (1)Web Service:WSDL文件或者WSDL地址;
    (2)EJB:EJB访问地址,链接用户名/密码,JNDI名称,EJB的jar文件;
    (3)JMS:请求和返回结构的定义文件,JMS链接地址,Queue或者Topic的JNDI 名字。例如:jms//hostname:port/ConnectFactory/ObjectJNDI。
     安全要求(必选):描述此接口服务的安全要求。
    按照接口服务定义规范生成的《接口服务列表模板》文档,各系统可参考此文档定义并提交接口。
     接口服务调用权限(必选):描述此接口服务的调用权限。
     描述该接口可以被哪些系统调用,即服务的调用权限。
    3.3 接口服务规约
    接口服务规约是接口及参数的技术描述,定义所有绑定和传输信息,以及所有支持的操作及相关输入、输出的格式,EJB或JMS等以XSD格式描述;而Web service协议通常以WSDL形式存在,被称为服务WSDL。接口服务规约包含:详细接口服务操作描述、数据类型、消息格式和结构、绑定的传输协议和服务的位置。
    4 接口服务实现规范
    4.1 设计规范
     接口服务命名要遵循一致的服务命名规范,参见下一章;
     接口服务应该遵守统一的报文规范,参见下一章;
     接口服务为了重用可以适当提高接口的颗粒度;
     接口服务的设计和定义应该与接口的实现分阶段进行;
     接口服务中传输的报文要求都是经过校验的,符合业务规则的,否则不符合报文会被返回;
     接口服务应充分考虑到扩展性,例如-在定义数据结构时多个字段封装为一个可扩展的对象;
     接口服务应尽可能通用,对于同一业务对象,应避免为不同系统开发不同接口服务。
    4.2 检查规范
    接口服务抽取后要对服务的交互进行检查,通过此检查来发现该接口服务是否合理。以下列出的是对接口服务进行检查的指导性原则,这些原则在运用的时候可以根据具体的项目情况进行裁减和选择。
     业务服务能否可以被一个以上的流程使用;
     业务服务是否是灵活和完整的;
     业务服务是否是与业务相关、有业务含义并被业务人员所能理解的;
     该服务在多大程度上依赖于其它业务服务;
     该服务是否是无状态的服务;
     该服务的描述是否和其它服务的描述相冲突;
     是否没有类似或重复的服务存在。
    5 报文规范
    5.1 报文组织格式
    报文在组织形式上划分为技术报文和业务报文两个部分,目的是将一些技术控制信息与业务信息分离开来,一方面可使逻辑上更加清晰,一方面可以提高系统处理的效率。
    根据应用集成标准的要求,为使不同应用系统能够直接有效的进行集成,电力安全系统主要使用XML格式报文。无论在何种传输协议上,如EJB、Web Service、JMS、MQ、FTP等,不同系统之间面对的报文格式需要尽量统一,提高处理的效率。同时为了保障EJB集成的高效,电力安全系统同时提供EJB协议下的标准开放的JavaBean对象格式报文。无论是XML格式还是JavaBean对象格式,只是报文数据的表现形式不同,要求这2者在语义上必须等价。
    5.2 业务报文
    业务报文表达了业务服务的业务语义,包含业务逻辑所需要的业务属性。
    业务报文包括业务请求报文和业务响应报文,对应业务服务的输入参数和输出参数。电力安全系统需要能够根据要求配置这些服务参数是否进行业务语义上的校验,需要能够按照标准通用开放的形式定义业务报文格式及其效验格式。具体定义分别参见下面的XML报文和JavaBean报文中的业务报文规范。
    5.3 XML报文规范
    采用XML方式来传输接口数据,XML报文满足通用性和扩展性原则,能满足业务的各种需要,而且方便开发人员应对不断变化的业务需求,方便新交易的开发。

    1. XML报文结构
      XML从报文结构上体现技术报文和业务报文,如下图:

     service为技术报文根节点;
     head为技术报文头信息;
     body节点为报文体,业务报文填写在此节点中。
    XML的结构是以XSD形式定义,需配套提供技术报文和业务报文的XSD定义,具体见下面2个章节。
    2. 技术报文及XSD
    技术报文的定义结构如下:

    技术报文对应的XSD格式定义如下:

    <?xml version="1.0" encoding="UTF-8"?>

    <xs:schema xmlns:xs=“http://www.w3.org/2001/XMLSchema” xmlns=“http://www.chinatax.gov.cn/spec/” targetNamespace=“http://www.chinatax.gov.cn/spec/” elementFormDefault=“qualified” attributeFormDefault=“unqualified”>
    <xs:complexType name=“headType”>
    xs:sequence
    <xs:element name=“tran_id” nillable=“false”>
    xs:annotation
    xs:documentation交易服务ID</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”/>
    </xs:simpleType>
    </xs:element>
    <xs:element name=“channel_id”>
    xs:annotation
    xs:documentation渠道ID</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”>
    <xs:length value=“100”/>
    </xs:restriction>
    </xs:simpleType>
    </xs:element>
    <xs:element name=“tran_seq”>
    xs:annotation
    xs:documentation交易流水号</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”>
    <xs:length value=“32”/>
    </xs:restriction>
    </xs:simpleType>
    </xs:element>
    <xs:element name=“tran_date”>
    xs:annotation
    xs:documentation交易日期</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”>
    <xs:length value=“8”/>
    </xs:restriction>
    </xs:simpleType>
    </xs:element>
    <xs:element name=“tran_time”>
    xs:annotation
    xs:documentation交易时间</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”>
    <xs:length value=“9”/>
    </xs:restriction>
    </xs:simpleType>
    </xs:element>
    <xs:element name=“rtn_code” minOccurs=“0”>
    xs:annotation
    xs:documentation交易返回代码</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”>
    <xs:length value=“1”/>
    </xs:restriction>
    </xs:simpleType>
    </xs:element>
    <xs:element name=“rtn_msg” type=“RtnMsg” minOccurs=“0”/>
    <xs:element name=“file_path” minOccurs=“0”>
    xs:annotation
    xs:documentation文件路径</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”>
    <xs:maxLength value=“512”/>
    </xs:restriction>
    </xs:simpleType>
    </xs:element>
    <xs:element name=“serv_version” minOccurs=“0”>
    xs:annotation
    xs:documentation服务版本号</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”>
    <xs:maxLength value=“10”/>
    </xs:restriction>
    </xs:simpleType>
    </xs:element>
    <xs:element name=“expand” type=“paramListType” minOccurs=“0” maxOccurs=“unbounded”/>
    </xs:sequence>
    </xs:complexType>
    <xs:complexType name=“paramListType”>
    xs:annotation
    xs:documentation参数列表类型</xs:documentation>
    </xs:annotation>
    <xs:sequence minOccurs=“0”>
    <xs:element name=“name”>
    xs:annotation
    xs:documentation参数属性名</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”/>
    </xs:simpleType>
    </xs:element>
    <xs:element name=“value”>
    xs:annotation
    xs:documentation参数值</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”/>
    </xs:simpleType>
    </xs:element>
    </xs:sequence>
    </xs:complexType>
    <xs:complexType name=“RtnMsg”>
    xs:annotation
    xs:documentation返回信息</xs:documentation>
    </xs:annotation>
    xs:sequence
    <xs:element name=“Code”>
    xs:annotation
    xs:documentation返回码小类代码</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”>
    <xs:length value=“3”/>
    </xs:restriction>
    </xs:simpleType>
    </xs:element>
    <xs:element name=“Message”>
    xs:annotation
    xs:documentation返回信息</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”/>
    </xs:simpleType>
    </xs:element>
    <xs:element name=“Reason”>
    xs:annotation
    xs:documentation原因及处理办法</xs:documentation>
    </xs:annotation>
    xs:simpleType
    <xs:restriction base=“xs:string”/>
    </xs:simpleType>
    </xs:element>
    </xs:sequence>
    </xs:complexType>
    <xs:element name=“service”>
    xs:annotation
    xs:documentation根节点</xs:documentation>
    </xs:annotation>
    xs:complexType
    xs:sequence
    <xs:element name=“head” type=“headType”/>
    <xs:element name=“body” type=“xs:string”>
    xs:annotation
    xs:documentation报文体</xs:documentation>
    </xs:annotation>
    </xs:element>
    </xs:sequence>
    </xs:complexType>
    </xs:element>
    </xs:schema>
    3. 业务报文及XSD
    业务报文包含请求报文和响应报文,是描述业务服务输入输出的关键结构,在语义描述上必须明确唯一,这是服务数据描述的业务关键内容。请求报文XSD和响应报文XSD定义将会在电力安全系统上进行管理,可以根据需要对传输的报文进行XSD格式的业务语义效验。其定义规范要求及XSD定义请参考下一章的业务报文定义规范。
    在对XML内容传输时,对于统一入口参数的,将技术报文和业务报文组装成一个报文进行传递,为了避免电力安全系统或某些场景对业务报文的不必要解释处理,把业务报文内容放置在“body”节点的<![CDATA[]]>内包裹以提高系统效率,根据W3C组织标准,CDATA关键字内部的XML报文是不会被XML解析器解析。例如:<![CDATA[业务报文内容]]>。
    而对于EJB或Web Service的多入口访问,技术报文和业务报文是分别2个参数传递,则业务报文内容不使用<![CDATA[]]>包裹,直接将技术报文XML和业务报文XML进行传递。
    4. 扩展报文编写方法
    扩展属性放在技术报文的expand节点中,每增加一个扩展属性,则需要增加一个expand节点,如下身份密码、人员和机关有3个扩展expand节点并行编写。

    identityType
    4432b7c8a61243f0a62813f01e47a1bb


    sjry
    24406060733


    sjjg
    14406820018

    5. XML报文示例

    <?xml version="1.0" encoding="UTF-8"?> SWZJ.HXZG.SB.CXSPHM GDGS.ZJNB.HXQD eea4ff11269045068f421dd3d654804e 20120416 083231475 identityType 4432b7c8a61243f0a62813f01e47a1bb sjry 24406060733 sjjg 24406820018 <![CDATA[<?xml version="1.0" encoding="UTF-8"?>aaaaaaaaaaaStringStringString]]>

    5.4 JavaBean对象报文规范

    1. JavaBean对象定义要求
      JavaBean对象报文是XML格式的对象表达形式,包括技术报文对象和业务报文对象。其在语义上等价于XML报文,使用Java平台语言定义,是POJO对象,不能依赖于某个私有框架,应具有通用性和开放性。
      对象报文包含涉及到的所有对象(技术报文对象和业务报文对象)及其子对象都必须实现序列化接口Serializable,同时都需要显示的定义serialVersionUID以解决序列化兼容问题。这些对象的定义应只包含与本业务服务相关的属性,不能包含与后台处理相关的属性。
    2. 技术报文对象定义
      技术报文对象包含报文根对象、报文头对象、报文体对象,等价于XML报文的技术报文XSD定义。
      报文根对象包含2个对象属性即报文头对象和报文体对象。
      报文头对象包含交易服务、渠道系统、交易流水、交易日期和时间等简单属性;如果有扩展属性,则需要有扩展对象集合,以key/value形式展现;对于交易服务的返回,则还需要包含返回对象,包含交易返回码以及交易失败时的错误原因信息。
      报文体对象则是业务报文对象的展现形式,需要通过序列化二进制形式作为报文体对象的属性,这是为了避免电力安全系统对其中的业务报文对象的序列化反序列化,提高系统的处理效率和避免业务报文对象依赖的部署发布影响。业务报文对象定义则具体参见下一节。
    3. 业务报文对象定义
      业务报文对象是业务服务的输入输出参数对象,包含请求报文对象和响应报文对象,分别等价于业务请求报文XSD定义和响应报文XSD定义,XSD定义规范要求请参考下一章的业务报文XSD定义规范。
      考虑到业务报文对象及其结构关系和数据类型的多样性及复杂性,以及对象与XSD之间和XML之间转换以及语义效验的通用标准性,建议业务报文对象遵守业界公开普及的JSR 222标准规范,该规范已经作为Java6内置标准OXM规范,采用Java6内置的JAXB工具即可实现XSD/XML和对象之间的正向反向转换映射。
      6 业务报文XSD定义规范
      6.1 元数据和数据元的要求
      元数据规范要求,同一个业务含义的字段在各个系统中命名要保持一致。数据元需要遵循的数据元规范,数据元公共报文名为TaxMLpublic.xsd,供所有业务报文引用。
      6.2 业务报文分类
      业务报文从不同角度存在多种分类方式:
    4. 从交易过程分:请求报文、响应报文和非交易报文(消息类报文)。
    5. 从交易类型分:提交类报文和查询类报文和校验类报文。
    6. 从报文内容分:表单类报文和非表单类报文。
      6.3 业务报文XSD文件命名
      电力安全系统业务报文XSD文件命名定义为多级字符串,总层级结构为六级,可包括大写字母和数字,各级间通过“_”进行相连。对于统一的业务服务,业务报文XSD文件命名由统一制定;对于其他自行增加的非统一的业务报文,可按照下述规范制定文件命名规范,,但总层级结构不能超过六级,总长度不能超过100位字符。
    7. 业务报文XSD命名规范第一级
      1、所有业务报文文件均以“TaxMLBw”作为命名前缀,其中TaxML做为行业标准要求,Bw为报文的简称。
      2、表单类业务报文编制时,每一张表单对应一个表单类业务报文,如果是依附于主表存在的附表报文,定义报文时要与主表业务报文放在同一目录下,其命名规范如下:
      TaxMLBd_表证单书编号_版本号
      3、表证单书编号详见GxB政务信息系统建设项目工程《代码集》。
    8. 业务报文XSD命名规范第二级(系统标识)
      参见本文5.2.2.2章节 服务命名规范(系统标识)
    9. 业务报文XSD命名规范第三级(主题类型)
      参见本文5.2.2.3章节 服务命名规范(主题类型)
    10. 业务报文XSD命名规范第四级(服务序号)
      服务序号采用5位数值型标识,初始值为00001,顺序累加1,服务序号一经使用,不得更改。
    11. 业务报文XSD命名规范第五级
      所有请求报文都以“Request”作为标识;所有响应报文都以“Response”作为标识;
    12. 业务报文XSD命名规范第六级(版本号)
      所有版本号前缀采用大写字母“V”标识,版本号采用两位数值型,中间使用字符串“.”进行连接,初始值为1.0,数序,如XSD报文有版本变更或升级,版本号顺序累加0.1。
    13. 业务报文XSD命名示例
      以GxB政务信息系统建设项目核心征管系统消费申报事前监控及获取期初数据业务报文为例,其XSD业务报文命名为:
      请求报文:TaxMLBw_HXZG_SB_00001_Request_V1.0.xsd
      响应报文:TaxMLBw_HXZG_SB_00001_Response_V1.0.xsd
      6.4 业务报文XSD编制
    14. 基本原则
       业务报文编制时,对于已存在数据元或聚合数据元的部分,应该引用数据元或聚合数据元;
       在满足交换需求的前提下,尽可能利用已有的数据集合或业务报文,避免重复编制;
       所有业务报文都需要包含(include)TaxMLpublic.xsd文件,从中引用数据元;
       业务报文的第一层结构中,只能使用“复杂类型”(complexType),不得使用“element”、“group”等其他类型;
       所有数据集合之下只能存在一层结构,若需要嵌套多层结构,必须抽象成多个数据集合(complexType),再进行引用。
    15. 业务报文的前导说明
    16. 字符集:encoding属性值为“UTF-8”。
    17. 命名空间:依据SW/T XX—201X《基于XML的数据交换格式设计规则》,
      XML的命名空间定义为:http://www.chinatax.gov.cn/dataspec/。
    18. 前导说明示例:参照《SW/T XX—201X基于XML的数据交换格式设计规则》,如:
    <?xml version=”1.0” encoding=”UTF-8”?>

    <xs:schema xmlns:xs=”http://www.W3C.org/2001/XMLSchema”
    targetNamespace=”http://www.chinatax.gov.cn/dataspec/”
    xmlns=”http://www.chinatax.gov.cn/dataspec/”>
    应在前导说明部分以注释的形式说明以下内容:
    ——数据交换格式的名称;
    ——数据交换格式的版本;
    ——XML模式编写单位或编写人;
    ——XML模式完成时间。
    3. 表单类业务报文
    按照通常的表单样式,表单类业务报文通常存在几个数据集合:
     “xx表单业务报文”:这是表单类业务报文的根元素数据集合,命名通常为“表单名称”+“Ywbw”,此集合下只添加一个元素,这个元素引用“xx表单”集合;
     “xx表单”:这是实际的业务表单内容,包括表头和表体集合;
     表头:对应表单上除表体具体内容外的通用类信息,例如编制方、时间等等;
     表体:对应表单上各行、列等具体内容。
    表单中业务含义明确的集合可以抽取为数据集合。
    例如,所有申报表业务报文的“表头”中都应使用聚合数据元中的“申报表公共表头”(SBBHead),若在该集合之外表单上还有其他的表头信息,应将其他的表头信息组成一个“私有表头”集合,与“公共表头”组合成为该申报表的“表头”集合。
    申报表业务报文中的“xx申报表”集合中,除表头和表体之外,可增加一个可空的“预留:附属表体”(BodyAffix)元素,类型设置为“xs:anySimpleType”。
    申报表表体的编制依据表样可横向抽取明细信息或纵向抽取表列信息。
    一般来说,在编制申报表的标准时,也会同时编制申报表提交和申报表明细查询的接口,这两类接口都有固定的请求、响应报文模式,申报表提交的请求报文和申报表明细查询的响应报文都应直接引用申报表表单业务报文进行编制。
    4. 非表单类业务报文
    非表单类业务报文可根据实际的数据交换需求内容编制,其中存在多行重复的内容可抽取为数据集合。编制中应尽量使用聚合数据元。

    展开全文
  • 软件系统的可扩展性设计

    万次阅读 2020-01-16 14:33:50
    系统的可扩展性一、可扩展性的设计1.可扩展性设计的优势2.可扩展性设计的目的3.可扩展性设计的两种方法二、可扩展性设计的形式1.分层架构2.消息队列3.远程调用4.开放平台三、企业级系统的平台化设计1.分层设计2.模块...

    一、可扩展性的设计关注点

    通常网站的可扩展性架构设计,能够在对现有系统影响最小的情况下,同时能保持可持续扩展和稳定提升的能力。
    按照可扩展性的定义,一个具备良好可扩展性的架构设计应当符合开闭原则:对扩展开发,对修改关闭。
    衡量一个软件系统具备良好可扩展性主要表现但不限于:

    • 软件内部方面:在软件系统实现新增业务时,对现有系统功能影响较少,即不需要对先用功能做任何改动或很少改动。
    • 软件外部方面:软件系统本身与其他存在协同关系的外部系统之间存在松耦合关系,软件系统的变化对其他软件系统无影响,其他软件系统和功能不需要进行改动。反之,则是一个扩展性不好的软件系统。

    开闭原则明确的告诉我们:软件实现应该对扩展开放,对修改关闭,其含义是说一个软件实体应该通过扩展来实现变化,而不是通过修改已有的代码来实现变化的。

    1.可扩展性设计的优势

    其表现为基础设置不需要经常变更,应用之间较少依赖或耦合,可以对需求变更快速响应。

    它对扩展开放,对修改关闭。架构设计会考虑到未来功能的可扩展性,所以当系统增加新功能时,不需要对现有系统的结构和代码进行修改。
    度量一个开发框架、设计模式或者编程语言优劣的一个重要尺度就是他是否能够让软件开发过程和软件产品更加低耦合。
    因为低耦合的系统更容易扩展,也更容易被复用,而且也会让开发过程和维护变得更加容易。但如何分解系统的各个模块、如何定义各个模块的接口,如何复用、组合不同模块构造一个完整的系统,这是软件设计中最具挑战性的部分。
    架构设计的最大价值,就在于把一个大系统分解为多个低耦合的子模块的能力,这些子模块包含横向的业务模块和纵向的基础技术模块。这种能力来源于专业能力与经验、业务场景的理解、对人性的把握以及对世界认知。
    构建可扩展的网站架构的核心思想是模块化,并在此基础上,降低模块之间的耦合,提高模块的复用性。
    可以利用分层与分割的方式,把软件分割为若干个低耦合、独立的组件模块,然后这些组件模块之间以消息传递或依赖调用的方式聚合在一起合成一个完整的系统。这些模块可以通过分布式部署的方式,部署在独立的服务器上。这种从物理上分离模块之间的耦合关系,可以进一步降低耦合性。

    2.可扩展性设计的目的

    可扩展性设计的目的在于为了处理更大规模的业务。
    在项目初期,硬件的成本会非常高,但随着时间的推移,软件成本变得昂贵得多。因此,构建应用程序时,应该想法让他不需要或者很少需要软件就能扩展;买更多的硬件,使用更多硬件来扩展要好一些。为了处理更大规模的业务,同时保证性能提升,还要搞清楚如何向外扩展。垂直扩展和水平扩展是其中两个重要的方法。

    3.可扩展性设计的两种方法

    • “垂直扩展”:
      在同一个逻辑单位添加资源以增加容量。开始的设置非常基础,可能就是一台web服务器和一台数据库服务器。当机器性能不足时,用更大的机器替换它。新机器能力不足时,用另外一台机器替换它。这台机器能力也不足时,就买一台更加强大的机器。如此反复。
    • “水平扩展”
      水平扩展内在原则上和垂直扩展相似,不断添加更多的硬件。不同于垂直扩展的地方在于,增长时不需要超级强劲的机器,而只需要很多常规的机器。从一台常规的机器开始,其能力不足后添加第二台。然后第三台,第四台等。增加多个逻辑单元资源并且使他们作为一个整体在工作。大多数的集群解决方案,比如分布式文件系统,负载均衡都是通过横向扩展技术来进行的。

    二、扩展方式

    设计具备良好可扩展性的系统,有两个思考角度:从业务维度,对业务深入理解,对可预计的业务变化进行预测;从技术维度,利用扩展性好的技术,实现对变化的封装。

    • 在业务维度

    对业务深入理解,对业务的发展方向进行预判,也就是不能完全不考虑可扩展性;但是变化无处不在,对业务看得远一点的同时,需要注意的是,要警惕过度设计;不能每个设计点都考虑可扩展性;所有的预测都存在不正确的可能。

    • 在技术维度

    预测变化是一回事,采取什么方案来应对变化,优势另外一个复杂的事情。及时预测很准确,如果方案不合适,则系统扩展性很麻烦。第一种应对变化的常见方案是将“变化”封装在一个“变化层”,将不变的部分封装在一个独立的“稳定层”。第二种常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”。

    1.分层架构

    三层架构通常意义上的三层架构就是将整个业务应用划分为:界面层、业务逻辑层、数据访问层。区分层次的目的即为了“高内聚低耦合”的思想。在软件体系架构设计中,分层式结构是最常见,也是最重要的一种结构。
    在早期的单体应用中,通过系统分层,每层可以独立的变化,降低的系统内部的耦合程度。分层的思想也是模块化的体现。

    2.消息队列

    如果模块之间不存在直接调用关系,那么新增或修改对其他部分的影响最小,这样的扩展性自然更好。通过在低耦合的模块之间传输事件消息,保持模块之间的松散耦合。不同系统之间,通过消息传递的方式,实现了系统之间的解耦。采用消息的方式,通常还是异步操作的,能够提升系统的性能。

    3.远程调用

    随着网站功能日益复杂,系统会逐渐发展成为一个巨无霸,里面聚合了大量的应用和服务组件,这样的一个系统会给开发,维护,部署带来巨大的麻烦。所以我们要做拆分,把模块独立部署,降低系统的耦合性。
    复用的业务分出来,独立开发部署为分布式服务,新增的业务只需要远程调用这些分布式的服务,就可以快速搭建出一个应用系统,技术模块内的业务逻辑发生变化,只要保持接口一致,就不会影响其他模块。
    目前,采用Dubbo,以及SpringCloud可以轻松的完成系统的构建任务。

    4.开放平台

    放平台是网站内部和外部交互的接口。外部会面对众多的第三方开发者。内部面对的是网站内众多的业务服务。下面是开放平台的常用架构:

    • API接口:暴露给开发者的一组API,可以使Restful,RPC等。
      协议转换:把各种API的输入转换为内部服务可识别的形式,并把内部服务的返回封装为API格式。
    • 安全:除了身份识别,权限控制等手段之外,还要对访问带宽进行分级限制,保证平台资源被第三方应用合理公平的使用,也能保证网站自身的内部服务不被外部应用拖垮。
    • 审计:监控第三方应用的访问情况并计费。
    • 路由:把开放平台的各种访问路由映射到具体的内部服务。
    • 流程:把一组松散的服务组织成一个上下文相关的新服务,对外提供接口供开发者使用。

    三、企业级系统的平台化设计

    一个高度平台化的系统,对高扩展性和灵活性是非常关注的,作为企业管理信息系统,最大的挑战是如何满足不同企业通用需求的同事快速满足企业个性化需求,除了企业战略、组织架构、流程体系等紧密相关外,软件的平台化水平,可扩展性和灵活性至关重要。一个高度平台化的系统对高扩展性是非常关注的。

    1.分层设计

    高可扩展性和灵活性的系统一版是分层架构,这里说的分层是指将客户的需求按照需求的通用性分层。根据自己平台所应用的目标客户群,分析客户的共性需求,将共性部分的需求按需求的通用性分层。根据自己平台所应用的目标客户群,分析客户的共性需求,将共性部分的需求放在平台的最底层实现,所有的客户共用,不要有分支版本,个性的需求放在高层实现。
    不同的客户可以完全定制。至于整个架构的层次数量没有绝对的标准,可参考的方法分为4层,

    • 公共平台层
    • 产品平台层
    • 行业扩展层
    • 个性扩展层

    这里的分层与软件架构中的表示层,中间层,持久层的分发属于不同的维度,是没有冲突的。

    2.模块化

    高可扩展性的系统一般都是模块化的。
    系统最好提供统一的基础组件,通过二次开发的手段提供上层扩展,做项目多了一版都会形成组件库,应该对这些组件进行分类分级管理。一旦有了新的项目,一般从现有的组件库中挑选进行配置,部分不满足要求的可以进行修改后满足,其他个性化很强的完全定制。

    3.数据建模

    提供图形化的数据建模模块,可以自动生成数据库的表结构,同事将数据的结构也保存为元数据,不依硬编码。

    4.流程建模

    采用图形化的方式,定义企业的业务流程,依赖业务流程的驱动完成流程的自动化。流程一般需要人的参与,所以与任务管理紧密相关,可能会涉及集成Email,手机短信实现自动通知。

    5.状态建模

    一般数据对象有多个状态,比如订单就有未发货,已发货,已到货等状态,不同状态下可执行的操作也是不同的,不同的状态下权限也会有差异。一般按照数据类型定义状态图,不同的状态有不同的操作和权限,一般依赖于各个操作或流程改变对象的状态。

    6.权限建模

    不同的数据类型通常由一些功能的权限项,比如浏览、修改等。应该支持自定义的权限项,不同的类型授权时权限项不同。权限的授予一般也有粒度要求,最小的按单个个体授权,最大的按类型授权。

    7.报表系统

    不同的角色可以看到不同的报表,最好建立报表的框架,开发一个新的报表后,通过简单的配置,不依赖修改代码,就可以通过系统访问到报表。报表的各种操作,也可以通过配置实现。

    8.界面建模

    企业中不同角色都希望看到与自己工作相关的功能,这就需要可以按角色自定义菜单和主页,主页的自定义用户可以选择自己需要的部分,添加到主页上。

    四、总结

    总体来说,可扩展作为软件非功能性设计的一个关注指标,其外在表现是多方面的,包括了分层结构、模块化、数据建模,流程建模等。甚至还包括权限体系的扩展等方面,当然真的要构建高扩展性的系统难度是很大的,也是系统复杂性的重要来源,通常都会遇到诸如性能问题,在各种复杂要求下寻求最好的平衡,大部分问题是可以解决的。

    展开全文
  • spring+druid多数据配置

    千次阅读 2019-02-18 10:01:37
    博客引用处(以下内容在原有博客基础上进行补充或更改,谢谢这些大牛的博客指导): spring+druid多数据配置 ...Druid是目前最好的数据库连接池,在功能、性能、扩展性方面,都超过其他数据库连接...
  • 以前写过一篇教程,Springboot AOP...网上大多流传的springboot系列的切换多数据源都是以上那种写死在配置文件里的方式,这样如果我需要切换的数据源有10个,那么这种方式会不会显得稍微有点繁琐了。 现在这篇介绍...
  • 华为设备的各种接口模式应用场景及配置。 一、什么是vlan? vlan就是虚拟局域网,是在二层交换机上将一个物理的LAN在逻辑上划分成多个广播域(多个vlan)的通信技术。同一个vlan内的主机可以直接通信,而不同vlan...
  • 背景 在美团的价值观中,“以客户为中心”被放在一个非常重要的...在这种背景下,我们必须对服务进行一次全方位的“体检”,从而来保障美团多个业务服务的稳定,提供优质的用户服务体验。真正通过以下技术手段...
  • 数据湖是较新的技术,拥有不断演变的架构。
  • 通过配置数据的Json化实现业务字段的可扩展性。通过设计的数据模型来介绍满足多语言情况下的各类运营配置数据方法。通过提供SDK内部实现本地缓存,MQ监听,异步更新的机制解决了服务中心化的大流量问题缓存导致的...
  • 关于POS接口配置的几个注意事项

    万次阅读 2016-01-27 10:53:30
    POS接口配置的几个注意事项 POS接口配置的几个注意事项  POS接口在与对端路由器,特别是CISCO路由器对接的过程中,需要注意以下一些事项,否则可能导致我司路由器不能与对方互通。    1.我们的NE路由器...
  • 尤其适合大学生 初级程序员掌握的体系内容,资深程序员也可夯实基础
  • 文章目录代码可扩展性的几种实施方式基于接口的设计插件架构状态机 代码可扩展性的几种实施方式 《ThePragmaticProgrammer》(Addison-Wesley,1999)一书的作者DaveThomasAndyHunt曾经说过,所有编程工作都是维护...
  • 数据可视化平台理论与实践

    万次阅读 2017-08-02 09:32:26
    前面说完了大数据开发平台的核心组件,作业调度系统,接下来讨论一下大数据开发平台的脸面之一,数据可视化平台。
  • 基于PowerPC UPM 接口扩展数据采集卡

    千次阅读 2011-12-16 19:38:01
    作者简介:吴日海(1986-),男,学生,主要研究方向:嵌入式系统 E-mail...为确保系统高效、安全、可靠地运行,需要在系统接口扩展数据采集功能,实现某些状态量的检测。设计一套数据采集卡,并通过通信控制系统
  • 数据中台怎么选型?终于有人讲明白了

    万次阅读 多人点赞 2022-01-07 14:07:21
    数据中台怎么选型?终于有人讲明白了
  • 数据应用到各个角落,除了之前可以支撑的决策分析以外,大数据与线上事务系统(OLTP)的联动场景非常多,比如我们在电商平台查询个人所有历史订单,再比如一些刷单、反作弊的实时拦截,以及一些实时推荐等,这些都是...
  • 浅谈元数据管理之AtlasMetacat

    千次阅读 2020-05-27 15:51:30
    数据管理、血统采集、血统生命周期、数据地图、图数据库
  • 案例上手 Python 数据可视化

    万次阅读 多人点赞 2019-02-27 23:30:05
    课程亮点 ...数据可视化是数据分析机器学习的重要环节,比如数据清洗、特征工程、机器学习、数据分析(特别是报告)、评估等环节都会用到“数据可视化”技术。 数据可视化同时还广泛存在于各...
  • 接口类型 信号线 极限速率 最大速率 抗干扰能力 适用摄像头像素   PCB laypuit MIPI CSI-2 串口 CLKP/N、DATAP/N 最大支持4-lane 一般2-lane可以搞定   Gbps...
  • 我们可以通过配置CacheManneg来配置默认的过期时间针对每个缓存容器(value)单独配置过期时间,但是总是感觉不太灵活。下面是一个示例: @Bean public CacheManager cacheManager(RedisTemplate redisTemplate) ...
  • 虽然很多时候一个api接口的业务,数据逻辑是后端提供的,但真正使用这个接口的是客户端,一个前端功能的实现流程与逻辑,有时候只有客户端的RD才清楚,从某种意义来说,客户端算是接口的需求方。所以建议在前期接口...
  • 本文出自 ... 高级配置与电源接口 ...高级配置与电源接口(Advanced Configuration and Power Interface),简称ACPI,1997年由Intel、Microsoft、Toshiba 所共同制定提供操作系统应用
  • SDN南向接口和北向接口

    千次阅读 2017-05-02 18:34:32
    因此随着SDN技术的部署推广,将会有越来越多的业务应用被研发,这类应用将能够便捷地通过SDN北向接口调用底层网络能力,按需使用网络资源。 SDN推动业务创新已经是业界不争的事实,它可以被广泛地应用在云数据...
  • 今天技术小伙伴占卫同学分享了Apache Atlas元数据管理实践,被atlas的强大的血缘关系管理能力震撼,以下为本次分享内容: •Apache Atlas简介 •Apache Atlas架构 •Titan图数据库介绍 •ApachAtlas配置 •Apache ...
  • 研究数据的方法有很多,比如利用统计方法计算数据的平均值标准差、使用模型拟合数据数据通常是大量的,人脑难以直接把握其中的信息。研究数据的最终目的是减少海量数据的信息量,将数据中的信息客观地展示
  • ATA(Advanced Technology Attachment, 高级技术附加装置)起源于 IBM,是一个单纯的磁盘驱动器接口,不支持其他的接口设备,适配的是 IDE(Integrated Drive Electronics,电子集成驱动器)磁盘驱动器。IDE 接口,...
  • TMS320F2812外部接口分析与存储器扩展

    千次阅读 2011-03-30 22:10:00
     哈尔滨工业大学 袁帅 佟为明 李中伟  ...相对于TMS320LF2407只能寻址192 KB地址空间,该芯片的外部接口最多可寻址4 MB的空间;有3个独立的片选信号,并且读/写时序可编程,兼容不同速率的外设扩展

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 160,070
精华内容 64,028
关键字:

数据接口灵活配置和扩展性