高级系统架构师.ppt

1 高级系统架构师 架构设计思想与原理常见高层架构主流架构小粒度软件架构 2 高级系统架构师 架构设计思想与原理常见高层架构主流架构小粒度软件架构 3 V型软件开发生命周期模型 定义开发过程生成的产品 应当测试每一个交付结果 4 UP统一过程 架构设计过程分为二个阶段 高层设计阶段和详细设计阶段哲学 5 UP中的架构设计和原理 9个核心工作流 代表了所有角色和活动的逻辑分组情况 6 这是开发过程沿时间的动态组织结构 软件生命周期被分解为周期 每一个周期工作在产品新的一代上 UP将周期又划分为四个连续的阶段 初始阶段细化阶段构造阶段交付阶段每个阶段终结于良好定义的里程碑 某些关键决策必须做出的时间点 因此关键的目标必须被达到 阶段和迭代 时间轴 7 初始阶段 初始阶段的目标是为系统建立商业案例和确定项目的边界 本阶段的主要目标如下 明确软件系统的范围和边界条件 括从功能角度的前景分析 产品验收标准和哪些做与哪些不做的相关决定明确区分系统的关键用例 Use case 和主要的功能场景展现或者演示至少一种符合主要场景要求的候选软件体系结构对整个项目做最初的项目成本和日程估计 更详细的估计将在随后的细化阶段中做出 估计出潜在的风险 主要指各种不确定因素造成的潜在风险 准备好项目的支持环境 8 细化阶段 细化阶段的目标是分析问题领域 建立健全的体系结构基础 编制项目计划 淘汰项目中最高风险的元素 本阶段的主要目标如下 确保软件结构 需求 计划足够稳定 确保项目风险已经降低到能够预计完成整个项目的成本和日程的程度 针对项目的软件结构上的主要风险已经解决或处理完成 通过完成软件结构上的主要场景建立软件体系结构的基线 建立一个包含高质量组件的可演化的产品原型 说明基线化的软件体系结构可以保障系统需求可以控制在合理的成本和时间范围内 建立好产品的支持环境 9 构建阶段 在构建阶段 所有剩余的构件和应用程序功能被开发并集成为产品 所有的功能被详尽的测试 本阶段的主要目标如下 通过优化资源和避免不必要的返工达到开发成本的最小化根据实际需要达到适当的质量目标据实际需要形成各个版本 Alpha Beta andothertestrelease 对所有必须的功能完成分析 设计 开发和测试工作采用循环渐进的方式开发出一个可以提交给最终用户的完整产品确定软件站点用户都为产品的最终部署做好了相关准备达成一定程度上的并行开发机制 10 交付阶段 交付阶段的目的是将软件产品交付给用户群体 本阶段的主要目标如下 进行Beta测试以期达到最终用户的需要进行Beta测试和旧系统的并轨转换功能数据库对最终用户和产品支持人员的培训提交给市场和产品销售部门和具体部署相关的工程活动协调Bug修订 改进性能和可用性 Usability 等工作基于完整的Vision和产品验收标准对最终部署做出评估达到用户要求的满意度达成各风险承担人对产品部署基线已经完成的共识达成各风险承担人对产品部署符合Vision中标准的共识 11 统一软件开发过程最佳实践和概念 短时间分区式的迭代和适应性开发使用对象技术在早期迭代中解决高风险和高价值的问题不断的让用户参与评估 反馈在早期的迭代中建立内聚的核心架构不断的验证质量 提早 经常和实际的测试 12 高级系统架构师 架构设计思想与原理常见高层架构主流架构小粒度软件架构 13 常见高层架构 客户服务结构C S 14 常见高层架构 多极体系结构 15 常见高层架构 流处理体系结构 气象台大型运算 16 常见高层架构 代理体系结构 Corba CommonObjectRequestBrokerArchitecture 公共对象请求代理体系结构 MQ银行排队问题 排队系统与客户系统连接 17 常见高层架构 聚合体系结构 即时战略游戏控制权转移 18 常见高层架构 联邦体系结构 军方高层体系结构 HLA 是一个使得仿真再用和相互交互更为容易的通用目的结构体系 19 常见高层架构 基于包图的表示 20 常见高层架构 架构设计方法比较 1 没有一种方法能够适用于所有的应用领域 所以合理的架构设计 往往应该更应该看重方法和思想的融合 把合适的方法到合适的地方 2 设计 优劣程度 的评定标准 大都建立在不可证明的假设的基础之上 所以 优劣程度 评定本身是没有意义的 这种讨论更多的是给出设计的方向 和改进架构的方向 过分强调某项指标往往会得到一个拙劣的设计 3 设计 首先是解决问题的活动 而解决问题的过程和办法是因人而异的 架构风格往往和架构师本人的风格有关 4 方法是重要的 但只有在支撑环境中运用它们才能得到成功 因此不同的支撑环境 往往更适应某种方法 但是各种思想的融合 是得到优秀设计的基础 21 高级系统架构师 架构设计思想与原理常见高层架构主流架构小粒度软件架构 22 主流架构 struts 23 主流架构 AJAX 24 主流架构 AJAX XMLHttpRequest对象 25 主流架构 ORM Hibernat 全自动 注意性能问题Ibatis 半自动 26 主流架构 SOA 面向服务的架构 Service OrientedArchitectureSOA 是一种形式化的分离服务的架构风格 面向服务的架构关注的是哪些是服务向用户提供的功能 哪些是需要这些功能的系统 这种分离 使用一种服务合约 ServiceContract 的机制来完成的 27 主流架构 SOA SOA有以下特性 服务具有明确的接口 合约 与策略 服务通常代表业务功能或者领域 服务拥有模块化的设计 服务被松散的耦合在一起 服务是可以被发现的 服务的位置对客户是透明的 服务是独立于传输层的 服务是独立于平台的 服务粒度的控制SOA系统中的服务粒度的控制是一项十分重要的设计任务 通常来说 对于将暴露在整个系统外部的服务推荐使用粗粒度的接口 而相对较细粒度的服务接口通常用于企业系统架构的内部 构建SOA架构时应该注意的问题服务粒度的控制SOA系统中的服务粒度的控制是一项十分重要的设计任务 通常来说 对于将暴露在整个系统外部的服务推荐使用粗粒度的接口 而相对较细粒度的服务接口通常用于企业系统架构的内部 28 高级系统架构师 架构设计思想与原理常见高层架构主流架构小粒度软件架构 29 面向对象的设计模式与小粒度软件架构 封装变化与面向接口编程 30 面向对象的设计模式与小粒度软件架构 使用适配器模式 Adapter 调适接口 31 面向对象的设计模式与小粒度软件架构 纵向处理 模板方法 TemplateMethod 32 面向对象的设计模式与小粒度软件架构 横向处理 桥接模式 Bridge 33 面向对象的设计模式与小粒度软件架构 代理模式 软件开发需要协同工作 希望开发进度能够得到保证 为此需要合理划分软件 每个成员完成自己的模块 为同伴留下相应的接口 34 面向对象的设计模式与小粒度软件架构 观察者模式 定义对象一对多的依赖关系 当一个对象发生变化的时候 所有依赖它的对象都得到通知并且被自动更新 35 面向对象的设计模式与小粒度软件架构 树状结构 组合模式 36 高级系统架构师2 架构设计方法学设计方案的选择分工 经济学中的机会成本沟通成本文档测试架构设计实践持久化存储表结构设计引入新技术的风险Ejb的缺点Spring简介Eai简介 37 架构设计方法学 面向过程的方法 面向过程方法又称为结构化方法 起源于20世纪70年代 主要由面向过程分析 面向过程设计和面向过程编程三部分组成 面向过程分析 帮助开发人员定义系统需要做什么 处理需求 系统需要什么样的输入和输出 面向过程分析的主要工具是数据流图 DFD 这是一种显示面向过程分析中产生的输入 处理 存储和输出的图形模型 面向过程设计 面向过程设计是为下列事务提供指导 程序集是什么 每个程序应该实现哪些功能能 如何把这些程序组成一张层次图 面向过程设计的主要工具是结构图 这是一种表达程序模块层次的图形模型 面向过程编程 具有一个开始和结束的程序或者程序块 并且程序执行的每一步都由三部分组成 顺序 选择或者循环结构 实现这种思想的最典型的语言就是C 整个面向过程设计的根本目标是 把复杂的系统分解成简单模块的层次图 38 架构设计方法学 面向对象的方法 面向对象的方法由面向对象分析 OOA 面向对象设计 OOD 以及面向对象编程 OOP 三部分组成 面向对象分析 OOA 定义在系统中工作的所有类型的对象 并显示这些对象如何通过相互作用来完成任务 主要工具是统一建模语言 用例图 活动图 状态图 面向对象设计 OOD 定义在系统中人机进行通讯所必需的所有类型的对象 并对每种类型的对象进行细化 以便可以用一种具体的语言来实现这些对象 类图 面向对象编程 OOP 用某种具体语言 C Java C 等 来实现各种对象的行为 包括对象间的消息传递 39 架构设计方法学 体系结构设计的基本方法 面向过程思想的本质是复杂功能按一定的层级逐级分解子功能模块 始终围绕实现处理功能的 过程 来构造系统 这种金字塔型的架构在需求不变更的情况下是很稳定的 然而用户需求大都会发生变化 因此 这种变化对于基于过程的设计来说是灾难性的 用这种方法设计出来的系统结构常常是不稳定的 用户需求变化往往造成系统结构的较大变化 从而需要花费很大的代价才能实现这种变化 优点 层次清晰 容易理解缺点 应变复杂需求的能力差面向对象设计的思想是以现实世界对象所具有的特点 状态 行为 来思考设计的 同时这些对象具有这些特征 封装 继承 多态 优点 以现实世界的角度思考问题 对于复杂需求有很强的应变能力缺点 以面向对象的思维来设计系统 而现实世界的事物间的层次 关系是很复杂的 这样设计出来的系统架构不清晰 不易理解 40 架构设计方法学 体系结构设计的基本方法的应用 综合两种设计方法的优略 在总的架构设计方面 我们应该采取面向过程的的设计方法 以保证整个系统架构的稳定性 程序架构的清晰性 而在每个具体的分层 应该采用面向对象的设计方法 以保证能应对复杂的业务需求 典型架构 J2EE架构 41 架构设计方法学 经济学案例 分工1 42 架构设计方法学 经济学案例 分工2 在这个案例中牧场主无论生产何种产品都比农场主有优势 经济学上称为比较优势 机会成本 为获得某事物而必须放弃的东西牧场主生产1斤牛肉的机会成本是10斤土豆 而农场主生产1斤牛肉的机会成本是16斤土豆 牧场主生产牛肉的机会成本比农场主小的多 比较优势比较大通过贸易可以获得双赢的局面 43 架构设计方法学 经济学案例 分工3 同样的相对于软件工程领域 机会成本这个概念也是非常有用的 每个开发人员都有自己的比较优势 无论是从经济学的角度考量还是从软件的开发维护难度考量 我们都提倡分工 让每个人关注于自己相对擅长的领域 这样可以提供总的生产力 问题 对于软件工程领域 是不是分工越细越好呢 答 不是 单单从机会成本角度考量 似乎分工越细 总的生产力就越高 但是IT业还要有个重要的因素要考量 沟通成本对于一个项目如果分工太细 势必会大大增加我们的沟通成本 那分工的粒度如何确定呢 每个行业有每个行业的分工粒度的适用范围 以一般的B2B商业应用领域常用的软件架构J2EE为例 web层 业务逻辑层 持久化层 这样的分工并不是我们自己凭空想出来的 是商业应用开发多年发展得到的一个经验值 避免教条主义并不是每个软件开发公司 部门这样分工就会获得生产力的最大提升 每个软件开发部门在自身所处公司的不同历史阶段会采取与自身相匹配的开发策略 44 架构设计方法学 沟通成本 1 3人和5人开发一个程序相互通信和交换意见的关系如下图所示将N 3和N 5分别代入上面公式 Ec 3 3 3 1 2 3 Ec 5 5 5 1 2 10 45 架构设计方法学 沟通成本 2 19人 通讯数27 通讯数与人数比为27 19 1 42 与四个人相比 N 4的通讯数为4 4 1 2 6 通讯数与人数比6 4 1 5 工作效率实际上比四个人略优 但工作量大得多了 如果不采用合理的方式 以N 19计算 19 19 1 2 171 通讯数与人数比为171 19 9 这样工作效率是非常低的 46 架构设计方法学 沟通 文档 沟通的一个重要途径 文档对于一个大项目 项目成员和模块较多 则各个小项目组间开发的一个重要依据就是接口文档 接口文档必须得到详细清晰的定义 不能随便更改 文档的作用 从整个纯软件公司来说 对于大部分的用户 像用例图之类的需求分析文档 用户一般都不怎么看 开发方如果跟他确认 他一般都会确认没有问题 但是到最终产品上线后 用户是及其有可能反悔的 虽然以签合同的方式能保证软件公司的利益 但是从长期合作的角度考虑 一般都不会把长期合作关系搞坏 对于我们公司来说 虽然以需求规格说明书的方式定义了我们应该开发的内容 但是业务方会不会认真的去读就不太清楚了 对于开发组来说 文档最重要的一个功能是开发组内部沟通的一个接口 但是目前大多数需求都是一个人从头做到尾 沟通交流的功能暂时好像也不存在 文档的另外一个作用 记录本项目 需求的经验数据 方案 项目开发时间的评估 架构的选择方案分析 新技术选择的优略 为以后的项目 需求提供一定的知识库可供借鉴 文档的内容 应该是实质大于内容 虽然我们可以以UML提供的各种视图来表述我们的需求分析 设计方案 但是并非一定要使用这些来表示 UML出现的初衷也是为了规范交流的工具 都是为了降低沟通成本 而如果我们有更简单易懂的表述方法来表示我们的思想时 可以考虑采用更简单易懂的做法 47 架构设计方法学 风险管控 业务风险 对于复杂需求 前面提到如果客户就根本没有心思去看需求规格说明书的时候 我们该怎么办 策略 DEMO现行的原则 我们可以先实现相关页面 相关的演示数据都是程序里写死的 然后演示给客户看 客户有意见则继续修改 直至客户认可使用界面为止 如果程序写死后台处理的演示数据 那真实的开发怎么办 facade模式 实现了调用方与具体的业务逻辑实现的解耦 struts facade besinessobject layer persistenceobject hibernate dbs技术风险 对于架构师而言 在项目初期应该预见系统实现的难点 对于风险点高的部分应该优先考虑 应该在项目的早期就应该解决 而不是到后期发现后才修修补补 或者用替代方案解决 此方案必然导致系统的架构复杂 凌乱 还可能导致项目的延期 其它风险 人员变动 项目异常终止等等 属于不可控因素 48 架构设计方法学 谈谈测试 对于测试 纯软件公司一般都存在测试组 工作范围 日常的版本测试工作 黑盒 白盒 单元 集成 功能测试 性能测试 压力测试 应该记录统计程序bug的数量 每个bug产生的原因时什么 为决策者提供相应的决策依据 承担起新技术的测试论证工作 为项目决策者对于是否可以使用某项新技术给与论证 49 架构设计实践 持久化存储 持久化存储有三种方式 文件形式 数据量小 数据间的关系较为简单时使用 demo演示数据 简单需求 LDAP 轻量级目录访问协议 存放结构简单而数据量大的信息 LDAP服务器都为读密集型的操作进行专门的优化大多数的LDAP目录服务器并不适合存储需要需要经常改变的数据 例如 用LDAP服务器来存储电话号码是一个很好的选择 但是它不能作为电子商务站点的数据库服务器 存储的组织形式 二叉树 案例 注册表 数据库 适用于数据结构复杂的数据存储 50 架构设计实践 数据库开发历史 最原始的阶段 各个DB厂商各自为营 独立开发自己的数据库驱动程序 业界没有个统一的接口 给程序的移植性 开发人员理解各个厂商的接口标准带来了一定的难度 随着历史的发展 出现了一个国际标准化组织将各个数据库驱动的接口统一 ODBC JDBC 虽然有了一个业界通用的标准 对于数据库厂商来说 不可能再单独按照标准开发一套驱动程序 引出另外一个设计模式 适配器模式 51 架构设计实践 数据库的表结构设计问题 1 关于代码表中代码定义的读取 传统做法 selecta b descriptionfrombusi tabela code tablebwherea status b code 我们为了在页面上现实一些代码的中文含义 一般都习惯在读取业务表时关联代码表 在代码中文含义少量适用的时候 这样做并没有什么问题 当系统中的大量页面都适用了这些基础代码表 而这些代码的具体含义都时通过表关联的方式获取时会带来一定的性能问题 解决方案 将这些基础代码表的信息加载到内存中 在使用时再从内存中读取 案例 核心业务系统中的t string resource表 52 架构设计实践 数据库的表结构设计问题 主键 Table主键的设计 主键应该是有意义的还是无意义的 对于不同的业务场景 可能会有不同的选择 具有实际业务意义的字段 具有 意义更改 的可能性 而主键的变更则会带来很多问题 oracle不支持级联修改 这就意味着在其它引用了有意义的主键的地方你要写额外的程序来维护这些设计 trigger 如果你忘记修改 则会给程序的运行带来很多意想不到的问题 53 架构设计实践 数据库的表结构设计问题 主键2 主键的选择 1 实际业务的业务编号 t company organ 2 oracle的sequence3 max加1 在程序中控制 每次主键都是在原表的最大值后加1 实现1 在db中维护这样一个表记录 记录该表的最大主键值 每次insert时 max加1即可 每次查询时需要锁定 selectpk value 1fromtable awheretable name forupdate 否则可能会读到葬数据 实现2 在程序中实现这样的一个单例类 通过程序来生成值最大的主键 对于只有一个JVM的情况 没有问题 对于分布式应用的开发 不好控制唯一性 4 方案2 3都存在一个问题 就是当我们的应用系统的数据库跟单位的组织架构一样具有层级 而且下级的数据需要向上级汇总 这个时候问题就来了 各个下级系统的业务表的无意义的主键在汇总到上级机构时会有冲突 而如果使用有实际业务意义的业务编号作为系统的主键就不存在这些问题 当然我们还有别的选择 GUID 根据一定的算法 系统时间 网卡MAC地址 CPU序列号等因素考虑生成的随即码 54 架构设计实践 数据库的表结构设计问题 IO操作 简单描述table segment data index rollback extent block之间的关系table创建时 默认创建了一个datasegment 每个datasegment含有minextents指定的extents数 建表的时候初始化分配一定的空间 如果空间不够则继续扩展 每一次的都是按照一定的大小来扩展的 每个extent据据表空间的存储参数分配一定数量的blocks如果影像文件信息存储在DB的blob字段 影像文件在db中必然占用多个extent 对于频繁的存取blob 必然导致频繁的IO调用 效率低下 常用的解决方案 在table中只存储影像文件在文件系统中的存储地址 而不是直接存放在blob字段中 实际应用 核心业务系统中的t image 55 架构设计实践 数据库 传统持久化的开发 以JAVA开发数据库操作为例 传统的数据库操作都是 getConnection createStatement execute close 这样的设计会导致代码的冗余度高 而且每个开发人员都得维护自己的数据库连接 语句 结果集资源等等 在程序没有bug的情况下一切似乎运行的没有问题 但是如果那段程序没有关闭游标 没有关闭连接 问题就来了 对于整个应用系统来说 有时候就会报无足够的连接 没有足够的游标的错误 但是一重启系统 又好了 很难定位问题的所在 我们很难判断是确实因为系统资源不足引起报错 还是程序问题引起的 解决方案 ORM 全称是Object RelationMapping 即对象 关系映射 产品 Hibernate TopLink JDO iBatis这些系统级的问题全部由ORM产品来解决 我们关注于应用领域的开发 ORM并没有降低我们的开发工作量 工作量从写java程序转移到xml文件的配置上 问题似乎解决了 终于可以高枕无忧了 事实远非如此 56 架构设计实践 引入新技术的风险 1 以Hibernate为例 在解决前面所述的开发问题上 Hibernate确实做的不错 不过所有的数据库操作全写在xml文件中 在实际运行时 都是通过反射机制来实现 反射机制简单举例 Objectobj Class forName classname newInstance 由于通过反射机制来使用 必然导致效率会比原来低一些 新技术带来的问题 举例 update语句 对于一般的jdbc访问 只需要写一条update语句就可以了 而Hibernate之前的版本的做法是 先select出符合update条件的语句 再逐条update 在极端情况下 效率会非常低下 select语句 在Hibernate1 0版本上 默认除了查询出主表的信息 还会把有主外键关联的其它表的信息也一同查询出来 这样必然会额外占用系统的资源 而这些问题你可能在项目上线后才会发觉到 因为在项目开发过程中 由于测试数据比较少 很多问题都很难发现 57 架构设计实践 引入新技术的风险 2 除了新技术本身具有的难以觉察的风险外 开源技术本身还具有的其它风险 新技术本身很有可能只是昙花一现 没有后续的升级支持版本 这对于企业开发来说是不可想象的 这意味着原来的新技术解决方案在项目的后期很有可能需要重新改造 成本是昂贵的 还不如一开始就使用老技术 开源技术的版本升级一般不考虑兼容性 升级版本对于同一个方法可能接口会发生改变 或者删除老版本的一些接口 或者方法本身的接口没有发生变化 而实际完成的工作可能已经发生变化 当你好不容易等到一个升级版本发布后 满心欢喜的以为升级版本会解决原来的问题 然而你会发现原来低版本的程序现在都不能使用了 接口被删除了 而一般的产品则不会出现以上的问题 以sun的JDK版本为例 每个升级版本都还是会向下兼容的 例如 java util Date对象 虽然在新版本中不建议使用 但是sun并不会把这个类给删除 而是标志为 Deprecated重新引入的日期类 java util Calendar由于包含了很多复杂的功能和时区信息 所以Calendar是以单例模式来实现的 在JVM一开始加载类时 就将额外的信息加载 而不是每次都new一个对象 提升资源利用 58 架构设计实践 引入新技术的风险 3 是否新技术就不值得引进呢 应对策略 引入时机 应该等新技术成熟以后才使用 最好是新技术出来1 2年后 出了一些后续版本 等论坛上批评的声音相对少了很多的时候才可以考虑使用 充分测试 必须让测试组对这项技术进行比较全面的测试后 由测试组提供相应的测试结果以供项目决策者来决定是否使用 59 架构设计实践 中间件的引入 在中间件技术出现以前 我们传统的开发方法 除了关注业务逻辑 更加需要关注非功能性的需求 安全 事物 线程等等 以银行取款为例 取款本身的业务逻辑并不复杂 验证用户信息 检查余额与取款数额的关系 更新账户余额等 而实际的开发代码中有80 都是用于安全 事物处理等系统方面的问题 导致开发成本非常高 中间件是一种独立的系统软件或服务程序 分布式应用软件借助这种软件在不同的技术之间共享资源 中间件软件管理着客户端程序和数据库或者早期应用软件之间的通讯 中间件在分布式的客户和服务之间扮演着承上启下的角色 如事务管理 负载均衡以及基于Web的计算等 中间件技术刚开始出现时 吹嘘的也正式这个卖点 让开发人员关注于业务逻辑 系统级的问题由中间件来解决 以EJB为例 EJB刚开始出现时 由于他的名声大 导致很多人都以为EJB就是J2EE 开发企业商业应用必然得采取EJB技术 开发人员处于提升自身能力考虑 而且领导也认为EJB是好东西 架构设计必须使用EJB技术 60 架构设计实践 中间件的引入 EJB的缺点 1 EJB的问题根源来自于 以规范驱动实现 历史告诉我们 最成功的标准都是从实践发展来的 而不是由哪个委员会创造出来的 2 EJB善于实现业务对象分布的体系结构 然而这种体系结构究竟有多大程度的普遍性 3 EJB目前使用的最广泛的也就是SLSB 无状态sessionbean 和MDB 消息驱动bean 而这两个恰恰是规范中描述最简单的 再次验证了 最简单的也就是最经久耐用的 4 使用EJB的成本过于高昂 必须购买EJB容器 5 EJB规范过于复杂 没有多少开发人员 架构师有时间来读懂它 6 测试难度大 EJB的测试依赖于EJB容器 难以测试ejb中的业务逻辑 7 EJB致力于解决的中间件问题 目前已经有了更好的解决方案AOP 8 过度工程 为了实现一个简单的业务逻辑 我们往往要开发一堆重复的代码 9 效率 ejb的相互调用都是以远程连接的方式来实现的 而实际调用的却是同一个JVM中的对象方法 61 架构设计实践 J2EE的分布式和可扩展性 很多J2EE的开发者相信 要想构建一个可扩展的系统 最好的途径就是使用分布式的业务对象 这种观点认为 可以使用4个web容器 8个ejb容器 所有业务对象都通过web层远程调用 这样一来 就可以对系统的处理能力进行细粒度的控制 如果吞吐量上升 可以在按照需要 要么增加web容器 要么增加业务对象所在的ejb容器 这种方法可以获得最佳的可扩展性 这里的核心问题是 每次远程方法的调用造成的性能代价太过高昂 以致于理论上还有什么收益的话 也早就被网络传输和对象编组中的损失给大大超过了 对于并置方案来说 每个应用服务器都加载了所有的J2EE组件 包括web层和业务对象 为了实现可扩展性 可以对整个应用系统实现集群式的部署 然后利用硬件负载均衡F5或者web容器的负载均衡功能来分流访问 相比较而言 分布式的架构不见得有比并置架构有更好的可扩展性 而并置架构在应用服务器的成本上要大大低于分布式架构 其实应用的可扩展瓶颈在于底层数据库 搭建数据库的负载均衡 62 架构设计实践 Spring简介 Spring是一个流行的开源的J2EE应用框架 特点 解决被其它框架忽略的部分 在J2EE的各个具体领域都有很多出色的解决方案 web框架 持久化方案 远程调用框架等等 Spring的目标就是提供一种贯穿始终的解决方案 将各种专用框架整合成一个连贯的整体框架 因此 我们说Spring是一个应用框架 而不是web框架 ioc框架 aop框架或者中间层框架什么的 易于选择 Spring有一个清晰的层次划分 用户可以使用其中的单项功能 而不是将自己的整个世界观强加给用户 例如 可以使用JDBC抽象层或者Hibernate集成 易于使用鼓励最佳时间 Sping力求遵循最佳实践 例如 针对接口编程 非侵入性 应用对象应该尽量避免依赖框架 只依赖于具体使用的功能 而非框架 统一配置 应用配置灵活统一 不需要自制Singleton和工厂 从中间层到web控制器 所有的配置需求都可以用统一的方式满足 易于测试 Spring的目标是让现有的技术更容易使用 63 架构设计实践 IOC思想简介 1 业务对象的管理 我们可以通过容器来管理业务对象 如ejb容器 也可以选择不使用容器 甚至不使用一个整体的应用框架 这样会带来这些问题 编写大量的singletom类 大量的工厂类 处理形形色色的配置 有人习惯用properties文件保存配置信息 有人习惯用xml或许和数据库方式 没有容器的帮助 我们通常很难在应用中清晰的区分出一个服务层 缺乏整体统一性也会带来更高的维护成本 容器提供的服务 对象生命周期的管理 查找对象服务 容器的核心就是一个工厂 对象配置管理 提供统一的方式来配置对象运行时所需的参数依赖决议 容器不仅可以管理String int之类简单类型的配置 还可以管理其中各个对象之间的关系 管理应用代码 而不给应用代码强加对容器的依赖 64 架构设计实践 IOC思想简介 2 IoC就是InversionofControl 控制反转 在Java开发中 IoC意味着将你设计好的类交给系统去控制 而不是在你的类内部控制 这称为控制反转 IOC的实现策略 1 依赖查找 ejbJNDI查找 2 依赖注入 设值注入 构造子注入 65 架构设计实践 IOC思想简介 3 H