软件开发的家园,编程爱好者的天地.

现在是:北京时间 2016/4/14 上午11:50:51 星期四

设为首页  |  加入收藏  |  网站地图

当前位置: 第八基地首页 > 软件工程 > SOA >
软件架构浅谈:问题域及其解决方法(2)
发布于:第八基地 来源:互联网 作者:天堂路上 时间:2016-04-24 点击:250

案例B:脚本的问题。产品在Web层提供了脚本支持,出于方便开发的目的。但是没有对脚本的环境限制,脚本可以做系统程序的大部分工作。导致开发人员偷懒,在web层混入了大量业务逻辑代码。最终造成业务逻辑分散而不可控制。

  2)组织结构对技术,开发效率和应变能力的影响。

  案例A.部门的分工问题。开发部门根据不同的职责,分成A,B和C等数个小组。大部分开发中互不相干。但也有时候,需要跨组的支持,比如B要实现某个需求,需要A在一定条件在记录一个或多个信息。因为每个开发人员各自负责一部分工作,导致跨组沟通的困难。同时由于整个开发部采取任务绩效,有时间压力,加上只是一个小的要求。于是在A人员的同意下,B人员直接在A代码中写入业务逻辑。每次都是这样的小改动,不断的发展后,代码开发变凌乱。

  案例B.开发的历史问题,当某个开发人员写下的代码,有是问题的,接手开发人员由于文档不全以及没有测试用例,不愿意承担变化的代价,选择小修小补,这个小修小补有可能和有问题的代码混杂,导致更大的代码。

  3)过程对开发效率和应变能力,以及组织的影响

  案例A.过程的问题。开发部门的上下游部门BA部门和ST部门的合作关系。ST部门的绩效考核,考核基于发现错误的数量,导致ST为了完成任务,提出一些非正常性要求。PM部门出于部门的方便通常提出一些实现难度比较大要求。开发部门本身又存在时间压力,导致一些需求的实现本应在低一层的代码中实现的,却在高层用蹩足的方式实现。

  案例B.帮助系统的问题。帮助系统一开始采用一个个单独分散的静态页面。出于性能的考虑和部门负责考虑。帮助系统不断改进中,过程缺乏组织性,文件的命名规则随意,存储位置随意,造成了管理的混乱。直接的后果是页面的入口混乱和各自引用关系混乱。

  在帮助系统的第二版,从静态页面转成动态页面。采取统一分类和命名规则,并统一了入口。同时采取分级管理引用关系,适度冗余。虽然减低了运行性能。但提高了开发效率和可维护性。

  二、架构的性能问题解决讨论

  性能问题——嗯,一个非常神圣而高深的问题的。从我刚刚开始工作的时候,至今依然是。然而我相信,一定存在一个基本的思路和方法,我以为解决性能问题的工作还是在于分解,通过分解来确定问题域。

  先介绍三个公式性能问题的公式:

  总处理单量=总处理时间/单笔请求处理时间*总并发数

  这个公式另一个写法为:

  总处理时间=单笔请求处理时间*总处理单量/总并发数

  不同的写法代表不同个关注点,适合不同类型的业务类型,一般说前一种写法代表在线请求的,后一种写法代表后台batch。

  也有客户给明确要求系统要支持xxx并发,这个就需要了解客户的这个并发数是如何计算得来,需要通过分析客户的业务,而通常是根据总处理单量来确定客户实际的并发数。

  但无论如如何,四个变量中,总处理单量和总处理时间是先被确定的,换句话说需要关注是单笔请求处理时间和并发数,也就是降低单笔请求处理时间或者增加并发数。

  对于单笔请求处理时间,其公式为:

  单笔请求处理时间=数据计算时间 数据读写时间 其它技术导致时间消耗

  很显然降低单笔请求处理时间就需要降低三个因素消耗的时间。

  1.降低单笔请求处理时间第一原则是,只计算一次.缓存计算结果

  2.降低数据读取时间,分三种

  2.1.Global的,系统启动时加载

  2.2.LongTime,可采用LRU方式cache

  2.2.Peroperation.第一次访问加载,operation结束后丢弃.

  3.降低数据写入时间

  例如文件写入通过buffer一次flush;对于SQL采用batch提交(Hibernate的做法)。

对我有帮助
(0)
0%
对我没帮助
(0)
0%
返回顶部
在线反馈
在线反馈