编写一份实用的工作分解标准的结构和编写应该注意哪些问题?

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

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

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

1.可扩展性设计的优势

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

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

2.可扩展性设计的目的

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  1. #{}将传入的数据都当成一个字符串会对自动传入的数据加一个双引号。如:order by #user_id#如果传入的值是111,那么解析成sql时的值为order by “111”, 如果传入的值是id,则解析成的sql为order by “id”
  2. ${}将传入的数據直接显示生成在sql中。如:order by
  3. ${}一般用于传入数据库对象例如表名
  4. 一般能用#{}就别用${}
 
  • resultType :语句返回值类型或别名。注意如果是集合,那么这里填寫的是集合的泛型而不是集合本身(resultType 与 resultMap 不能并用)

二:配置java对象属性与查询结果集中列名对应关系

  • 建立sql查询结果字段和实体属性的映射關系
  • 查询的结果集转换为java对象
  • 将结果集中的列和java对象中的属性对应起来并将值填充
 

我要回帖

更多关于 标准的结构和编写 的文章

 

随机推荐