、什么是架构 1.和架构相关
几个问题域 架构需要解决
非业务问题域包括如下: A系统目标:系统性能
稳定性. B.项目目标:开发成本
质量 C.项目过程:需求
不确定性和开发过程团队(Team)协作性 区别
问题域解决的道也不相同！而同问题域区别层次要求解决的道也不尽相同
2.什么是架构
3.架构
背后 为了实现架构
目标涉及到以下 3个方面:技术组织和过程这里举例介绍说明 1)技术对开发效率和运行性能
以及组织和过程影响 案例A．映射
问题公司产品个重要需求是根据客户输入映射到PDF文件上技术上整体实现需要 4个步骤:在PDF文件上画好所有数据域通过读入个XML映射文件获得运行数据并生成FDF合并FDF和PDF生成目标文件后两步工作都由代码自动化了因而实现主要工作在于前两步 在第
个实现版本里XML映射文件DTD太简单致使个xml文件至少在4000行左右同时xml文件太verbose了这样结果直接导致运行系统在峰值时由于XML消耗了大量内存1G内存根本吃不消；同时对XML解析执行使用了CPU大量时间；导致开发人员需要做大量工作开发效率降低了通常需要尽周才能完成个xml文件员工都不愿意做；也导致开发过程漫长开发部门对于BA部门和ST部门要求反应变缓慢 在第 2个版本
实现中重新实现了DTD加入了大量关键字同时也消除了verbose大量缩小了XML大小从4000多行减低到900多行不仅减低了内存使用提高执行效率；也提高了开发效率基本只要天就可以完成个映射文件同时对BA部门和ST部门反应也快了 案例B:脚本
问题产品在web层提供了脚本支持出于方便开发目但是没有对脚本环境限制脚本可以做系统
大部分工作导致开发人员偷懒在web层混入了大量业务逻辑代码最终造成业务逻辑分散而不可控制 2)组织结构对技术
开发效率和应变能力影响 案例A.部门
分工问题开发部门根据区别职责分成AB和C等数个小组大部分开发中互不相干但也有时候需要跨组支持比如B要实现某个需求需要A在定条件在记录个或多个信息
每个开发人员各自负责部分工作导致跨组沟通困难同时由于整个开发部采取任务绩效有时间压力加上只是个小要求于是在A人员同意下B人员直接在A代码中写入业务逻辑每次都是这样小改动不断发展后代码开发变凌乱 案例B.开发
历史问题当某个开发人员写下代码有是问题接手开发人员由于文档不全以及没有测试用例不愿意承担变化代价选择小修小补这个小修小补有可能和有问题代码混杂导致更大代码 3)过程对开发效率和应变能力
以及组织影响 案例A.过程
问题开发部门上下游部门BA部门和ST部门合作关系ST部门绩效考核,考核基于发现
数量导致ST为了完成任务提出些非正常性要求PM部门出于部门方便通常提出些实现难度比较大要求开发部门本身又存在时间压力导致些需求实现本应在低层代码中实现却在高层用蹩足方式实现 [Page]案例B.帮助系统
问题帮助系统开始采用个个单独分散静态页面出于性能考虑和部门负责考虑帮助系统不断改进中过程缺乏组织性文件命名规则随意存储位置随意造成了管理混乱直接后果是页面入口混乱和各自引用关系混乱 在帮助系统
第 2版从静态页面转成动态页面采取统分类和命名规则并统了入口同时采取分级管理引用关系适度冗余虽然减低了运行性能但提高了开发效率和可维护性 2、架构
性能问题解决讨论 性能问题——嗯
个非常神圣而高深问题从我刚刚开始工作时候至今依然是然而我相信定存在个基本思路和思路方法我以为解决性能问题工作还是在于分解,通过分解来确定问题域 先介绍 3个公式性能问题
公式: 总处理单量=总处理时间/单笔请求处理时间*总并发数
这个公式另
个写法为: 总处理时间=单笔请求处理时间*总处理单量/总并发数
区别
写法代表区别个关注点适合区别类型业务类型,般说前种写法代表在线请求后种写法代表后台batch 也有客户给明确要求系统要支持xxx并发
这个就需要了解客户这个并发数是如何计算得来需要通过分析客户业务而通常是根据总处理单量来确定客户实际并发数 但无论如如何
4个变量中总处理单量和总处理时间是先被确定换句话说需要关注是单笔请求处理时间和并发数也就是降低单笔请求处理时间或者增加并发数 对于单笔请求处理时间
其公式为: 单笔请求处理时间＝数据计算时间＋数据读写时间＋其它技术导致时间消耗
很显然降低单笔请求处理时间就需要降低 3个原因消耗
时间 1.降低单笔请求处理时间第
原则是,只计算次.缓存Cache计算结果 2.降低数据读取时间,分 3种
2.1.Global
,系统启动时加载 2.2.LongTime,可采用LRU方式cache
2.2.Peroperation.第
次访问加载,operation结束后丢弃. 3.降低数据写入时间
例如文件写入通过buffer
次flush；对于SQL采用batch提交(hibernate做法) 4.改进计算时间
针对区别技术结构采用区别手段 4.1.让计算支持并发,提高性能,例如采用MapReduce
方式 4.2.改进算法.例如数据库中
SQL改进. 4.3.减少不必要计算时间.
5.减少其它技术原因导致
消耗 如JVM
GC导致性能消耗等 对于总并发数
其公式为: 总并发数＝单机服务器并发能力*总并发服务器数
那么如何确定那些原因需要调整呢
在于两个方面分解: 1.业务层面
业务层面只是指通过业务行为分析,把性能问题分解为区别
部分,每个部分面临性能压力现状和目标,最终确定需要优化问题域. 业务层面分解包括4个内容:功能,内容,时间和区域.最重要
是前 3个. 以ebay为例,ebay对于前端功能划分划分为70多个功能,区别
服务器处理区别功能. [Page]内容是指内容热点,比如对于search来说,就按体育,数码,音乐等划分,区别内容有区别热点数据,以及区别搜索关键匹配.
时间,时间是
个非常重要原因,在些特点是时间段呢,性能要求会非常高.比如下半夜访问点击量和白天就有区别.对于些batch来说,月末或者年末处理单量就有明显提高,比如分红险记息,平时每天只有7000单,而年末会有12w单. 地点划分,不太常见,不过也有助于分配计算资源.
业务层面
分析不仅是确定问题所在,还是确定优化策略.比如有个batch计算,执行时间比较长,而通过业务分析,发现该计算只针对特定业务,系统全部有效单量是12w单,而符合计算要求只有3000单,只要加上个前置判断就可以免除无谓计算,运行时间减少数个小时(大约0.2秒单). 2.技术层面
系统建立时技术结构,通常
个系统结构如下:接入网络,Web服务器,应用服务器,以及数据库服务器. 在这样结构下
要小心分析和验证系统性能瓶颈需要优化Web服务器或者提高数据库并发能力等等这部分网上资料非常多 3、架构
开发成本以及品质问题解决讨论 架构
个重大关注点在于控制开发成本这点很重要通常讲维护成本是开发成本3倍降低开发成本核心在于提高效率这也意味着提高了开发对需求响应时间而时间对公司来说是重要 提高开发效率和品质
基本手段是分解——即充分分离系统中区别关注点好处不用说了可以并发工作每个人面对问题都简单而容易操作而和分解对应集成只有提供了好集成能力分解才成为现实而只有分解了才能清晰提供业务更多适应性 分解和集成
手段分为编程语言和技术框架两个层面所谓语言就是强框架而框架就是弱语言 现代面向对象
语言提供如下能力:抽象和派生能力以及接口隔离能力实际提供两种分解和集成能力: 1.把逻辑分解在两个层次中
而通过继承方式把两个部分集成在起 2.把逻辑
外观和实现分解在两个地方而通过接口实现方式把两部分集成在起 另
种语言AspectJ或者C#语言2.0的后提供特性:把流程逻辑分解在区别地方而通过签名匹配利用代码生成方式来把几部分集成在起 然而语言提供
集成能力毕竟底层而且有限扩展起来也格外小心因而技术框架提供另外集成能力就格外重要: 1.对象关联关系
分解和集成如Spring提供容器管理能力 2.模块间关联关系
分解和集成如OSGiESB等 3.区别系统
类型分解和集成如Spring利用动态代理提供Exporter模式 4.流程逻辑
分解和集成如SpringWebFlow以及jBPM 讨论完手段
现在要转身看看我们面临问题域了；问题域可分解为两种类型业务上和技术上(又见分解分而治的真是老祖宗传下灵丹妙药啊) 1.业务上
问题域分解为逻辑纵向抽象层次以及逻辑横向模块分解和集成 2.技术上
问题域分解为纵向技术主题以及横向技术职责分解和集成 [Page]所以通常而言
领域模型设计中模块分解抽象分层和职责分层都是重要手段问题域为:流程业务实体和计算(包括规则) 对象
抽象分解和集成 对象
依赖分解和集成(模块内和模块外) 流程
分解和集成(页面流工作流以及计算流程) 进程边界:用户请求重定向
以及业务数据持久化等 BTW:通常语言做为架构
基础引入和更换是有巨大风险；而通过提供强大框架能力框架尽可能多完成技术问题并通过元数据模式以及约定降低业务和框架耦合避免框架升级带来不必要成本 从技术手段上
提高开发效率另外两个手段是代码生成和类库引用但代码生成和类库引用都只解决了逻辑分解能力没有提供集成能力所以般情况下需要提供框架集成尤其代码生成需要在系统最外层避免集成带来问题 对于开发团队(Team)来说
额外面临个问题组织内部学习成本问题 1.需要保持分解以及集成能力本身
简约性 这个……其实是
个culture问题不再罗唆！ 2.采用模式和约定是减少学习成本
另种手段ROR兴起就是最好例证 整理总结
下解决架构面临开发成本问题需要如下几个方面: 0.问题域
1.分解和分层
2.架构和类库
SpringHibernate起支撑性作用 3.模式和窍门技巧
4.领域模型
5.思路方法论
5.1.开发思路方法:OO(设计模式)
FP(
式编程) 5.2.设计思路方法:Do
ModelPrototype和业务行为分析模式 架构面临
品质问题则通过自动化测试代码检测工具来完成 必须大量应用自动化测试
减少人工硬调试复杂性重复性和不确定性 自动化测试包括单元测试和集成测试
无论是单元测试还是集成测试对面临需要脱离隔离依赖关系并保证开发并行性
最新评论