《构架与架构师》PPT课件.ppt

第0章 构架与架构师 构架 起因：17世纪20年代，瑞典和波兰交战。瑞典国 王下令建造巨型战舰瓦萨战舰。 要求：舰长70m，载员300人，两层甲板装载64门 重炮 设计师：henrik大师 考虑因素：工期、性能、功能、安全性、可靠性 、造价等。 实现方法：先按单层炮舰设计，在扩充为双层。 结果：试航礼炮未放完，就翻入水中。 分析原因：比例严重失调（构架存在问题） 说明问题：？ 软件构架 第0章 构架与架构师 构架 软件构架师技术、商业好社会等诸多因素 作用的结果，而软件构架的存在反过来又 会影响技术、商业和社会环境，从而影响 到未来的构架。这种相互影响的周期称为 构架商业周期 软件构架商业周期 办公室里的争论 办公室里，关于什么是软件架构，争论正酣。 u 程序员说，软件架构就是要决定需要编写哪些类，使用哪些现成框架。程 序经理笑了； u 程序经理说，软件架构就是模块的划分和接口的定义。系统分析员笑了； u 系统分析员说，软件架构就是为业务领域对象的关系建模。配置管理员笑 了； u 配置管理员说，软件架构就是开发出来的以及编译过后的软件到底是个啥 结构。数据库工程师笑了； u 数据库工程师说，软件架构规定了持久化数据的结构，其他一切只不过是 对数据的操作而已。部署工程师笑了； u 部署工程师说，软件架构规定了软件部署到硬件的策略。用户笑了； u 用户说，软件架构就是决定一个个子系统如何划分。程序员又笑了； u 大家想了想说，这些架构视图好像我们都需要啊，软家架构师哭了。 上述争论可以总结为一句话：不同涉众看待软件架构的视角是不同的不同涉众看待软件架构的视角是不同的 第0章 构架与架构师 构架 1.构架受系统涉众的影响： 软件构架的产生 开发 组织的 管理层 涉众 客 户 涉 众 维 护组 织涉 众 最 终用 户涉 众 进行 市场营 销的涉 众 成本 要低， 人人都 得有活 干 特性突出 、很快能投 放市场、成 本低、有竞 争力 行为、 性能、安 全性、可 靠性、易 用性 可 修改 性 成本要 低，及时 交付、不 要改动太 频繁 第0章 构架与架构师 构架 2.构架受开发组织的影响 Eg：人员技能、开发进度和预算、直接投资和长 期投资、子系统的转包等 3.构架受设计师的素质和经验的影响 4.构架受技术环境的影响 Eg：基于web、面向对象、支持中间件等 5.其他影响因素 Eg：与涉众的交流 6.构架对诸影响因素的反作用 软件构架的产生 架构师 架构师这个称呼不是拍脑袋想出来的，是有 国际标准（ISO/IEC 42010）可查的。架构师是 软件开发活动中的众多角色之一，它可能是一个 人、一个小组，也可能是一个团队。微软对架构 师有一个分类参考，我们参考一下，他们把架构 师分为4种：企业架构师EA(Enterprise Architect)、基础结构架构师 IA(Infrastructure Architect)、特定技术架构 TSA(Technology-Specific Architect)和解决方 案架构师SA (Solution Architect)。 软件架构师 第0章 构架与架构师 架构师 软件架构师- 名人堂 第0章 构架与架构师 架构师 1、确认需求 在项目开发过程中，架构师是在需求规格说明书完成后介入 的，需求规格说明书必须得到架构师的认可。架构师需要和 分析人员反复交流，以保证自己完整并准确地理解用户需求 。 2、系统分解 依据用户需求，架构师将系统整体分解为更小的子系统和组 件，从而形成不同的逻辑层或服务。随后，架构师会确定各 层的接口，层与层相互之间的关系。架构师不仅要对整个系 统分层，进行“纵向”分解，还要对同一逻辑层分块，进行 “横向”分解。 软件架构师的功力基本体现于此，这是一项相对复杂的工作 。 软件架构师主要职责 第0章 构架与架构师 架构师 3、技术选型 架构师通过对系统的一系列的分解，最终形成了软件的 整体架构。技术选择主要取决于软件架构。 Eg：Web Server运行在Windows上还是Linux上？数据库采用MSSql、 Oracle还是Mysql？需要不需要采用MVC或者Spring等轻量级的框架 ？前端采用富客户端还是瘦客户端方式？类似的工作，都需要在这 个阶段提出，并进行评估。 架构师对产品和技术的选型仅仅限于评估，没有决 定权，最终的决定权归项目经理。架构师提出的技术方 案为项目经理提供了重要的参考信息，项目经理会从项 目预算、人力资源、时间进度等实际情况进行权衡，最 终进行确认。 软件架构师主要职责 第0章 构架与架构师 架构师 4、制定技术规格说明 架构师在项目开发过程中，是技术权威。他需要协 调所有的开发人员，与开发人员一直保持沟通，始终保 证开发者依照它的架构意图去实现各项功能。 架构师与开发者沟通的最重要的形式是技术规格说 明书，它可以是UML视图、Word文档，Visio文件等各种 表现形式。通过架构师提供的技术规格说明书，保证开 发者可以从不同角度去观察、理解各自承担的子系统或 者模块。 软件架构师主要职责 第0章 构架与架构师 架构师 1、架构师就是项目经理 架构师不是项目经理。项目经理侧重于预算控制、 时间进度控制、人员管理、与外部联系和协调等等 工作，具备管理职能。一般小型项目中，常见项目 经理兼架构师。 2、架构师负责需求分析 架构师不是需求分析员。需求分析人员的工作是收 集需求和分析需求，并与最终用户、产品经理保持 联系。架构师只对最终的需求审核和确认，提出需 求不清和不完整的部分，他会跟需求分析员时刻保 持联系。架构师是技术专家，不是业务专家。 软件架构师理解误区 第0章 构架与架构师 架构师 3、架构师从来不写代码 这是一个尚存争论的问题。目前有两种观点： 观点1：架构师不写代码，写代码纯体力活，架构师 写代码大材小用。架构师把UML的各种视图交给开发 人员，如果有不明确的地方，可以与架构师随时沟 通。 观点2：架构师本来自于程序员，只是比程序员站的 层面更高，比程序员唯一多的是经验和知识，所以 架构师也免不了写代码。 软件架构师理解误区 第0章 构架与架构师 架构师 软件架构师基本素质 愿意并有能力进行沟通：确定表述系统设计时 的最佳工具和构件，以促进有效的意见交换。 具有处理谈判细节方面的经验：优秀的架构师 能够有效地评估技术可能性，并能在不损失项目 的主要价值的前提下制订开发计划来处理各种利 害关系和限制。 第0章 构架与架构师 架构师 软件架构师基本素质 自觉主动；积极解决设计问题：架构师的日常 工作目标经常并不明确。会预计各种设计问题并 加以解决通常在没有任何具体指示的情况下 自觉进行。 抽象思维和分析：架构师必须能够理解表述模 糊的概念并将其变成相关各方能够理解的项目构 件。 开发人员经常具有很强的数学能力，而好的 架构师则倾向于表现出更强的口头表达能力。 第0章 构架与架构师 架构师 软件架构师基本素质 假设有三名优秀的程序员: A 尤其擅长沟通与团队管理； B 的编程功底深厚，且对新技术能快速掌 握； C 在逻辑思维和抽象能力方面表现优秀。 您会重点培养哪位程序员成为架构师？ 第0章 构架与架构师 架构师 软件架构师卓越的程序员（1 ） 1.架构师是使用代码作画的大师。一个架构师的价 值在于，他不仅能看到系统的美，而且能够在建造系 统的时候能够把这些美创造出来。(尊崇“优美”、“ 简约”) 2.不编程的架构师的职业生涯是短暂的 -Fred George “代码就是设计与残酷现实之黄昏的交汇”(Code is when design meets the harsh reality of dawn.) - Kent Beck 第0章 构架与架构师 架构师 软件架构师抽象思维（2） 优秀的数学家、物理学家以及软件架构师有着很多 相似的素质，甚至往往能够一人精通这好几个领域 ，其中很重要的原因就是这个抽象思维的能力。Eg ： UML之父James Rumbaugh 拥有条理清晰的逻辑思维能力的人，“就像稀有动 物那样难找” - eBay的Randy Shoup 驾驭概念的技能，在我看来是每一个人最高的潜力 - Fred George 第0章 构架与架构师 架构师 软件架构师技术前瞻性（3） 铁打的程序员，流水的技术。程序员的开发生涯 可能长达几十年，但一门技术的平均寿命却不长 。 1.作为程序员们的技术领袖，架构师必须有很好 的技术前瞻性，要先于大家了解到最新的技术。 （英语） 2.技术前瞻性还体现在对新技术的选择上。（逻 辑思维能力和接受能力） 第0章 构架与架构师 架构师 软件架构师问题解决大师（4 ） 透过问题看本质 Eg：电子商务站这样大型的系统有两个层面的功能 ： 垂直功能（抽象思维）：如买、卖、搜索、付款等 。 水平功能（本质）：如数据库、事件与消息系统、 服务基础设施、展示框架等。 非功能（本质）：功能，性能，可伸缩性，可管理 性，安全性，以及可用性。 - eBay架构师Randy Shoup 第0章 构架与架构师 架构师 软件架构师内力（5） 内力更多的是一种思考能力，结合技术的思考能力 。光有程序开发的能力，不会思考，那只能做个代 码狂人。只思考而没有脚踏实地的技术开发能力， 那就是忽悠人的表现。 1.内功的修炼第一层，自然是开发技术的培养。 2.其次是对架构的熟悉，对各种架构做到了熟于心 。 3.高层次的修炼，就在于不同技术的学习。才能更 好地抽象软件的使用环境，选择符合需要的架构以 及开发模式。 第0章 构架与架构师 架构师 软件架构师多领域知识（6） 架构师：要成为百科全书式的智者 1.架构师学习更多跨领域知识，也是为了在接受一 个项目时，能更快更准确的找到解决问题的命门 2.好的架构师必须参与更大的项目 如果多学习跨领域、跨学科的东西，会不会成为什 么都懂，但什么都不精的人？ 第0章 构架与架构师 架构师 软件架构师权衡取舍（7） 架构师：每天要在鱼和熊掌之间做选择 1.没有一个人可以建造一个没有缺陷的架构。这个项目可能 缺乏时间，缺乏金钱，缺乏人手，或者缺乏合适的技术。 2.系统能够承受的范围内做出一些“权衡妥协”（哪些内容 是必要的、不可丢弃的;哪些是暂时可以不予考虑的。） “在一个理想的世界中，只存在唯一一个一致模型：在实施 一次升级之后，所有观察者都能够看到这个升级。” - Werner Vogels “对于一个共享数据的系统而言，数据持续性、系统可用性 、对网络划分的耐受性这三个属性（property）是不可调和 的，任何时候只能同时达成两个。” -加州大学的Eric Brewer教授提出了CAP理论 第0章 构架与架构师 架构师 软件架构师沟通能力（8） 架构师的沟通主要在于开发团队内部，一种纯技术上的沟通 。 第0章 构架与架构师 软件架构师管控能力（9） 架构师所需要的管理与控制，其实是从技术的角度，对一些问 题的控制，特别是开发过程中的监控，而不是普通意义上的纯 粹管理。 软件架构师艺术气质（10） 系统应当是优美的，而这优美体现在系统的伸缩性、安全性、 可维护性、可靠性和可移植性等健康因素。 一个优美的系统则是可以像有机的生命一样成长的，这是因为 从系统开始架构的那一刻起，架构师就考虑到这个系统以后将 会面临的挑战，为系统的成长预留好空间。 架构师 软件架构师跟踪生命周期 分析：好的架构师会考虑非技术影响，以便了解需求和将在其中进行 开发的环境。架构师可为风险评估任务带来广泛的软件经验供参考。 设计：在高级设计期间，好的架构师会收集问题空间的各个抽象元素 ，并就其进行