• 欢迎访问 winrains 的个人网站!
  • 本网站主要从互联网整理和收集了与Java、网络安全、Linux等技术相关的文章,供学习和研究使用。如有侵权,请留言告知,谢谢!

架构设计(5):架构愿景分析

系统架构 winrains 来源:规速 12个月前 (10-11) 26次浏览

架构愿景实际是回答了哲学家经常思考的三个问题:
我是谁? (问题是什么,现状)
从哪里来? (原因:为什么出现问题)
到哪去? (愿景和目标是什么)

一、前言:架构设计的步骤

架构设计非常适合使用瀑布模式开发,特别是需要升级架构的系统。
瀑布开发模式简单直接,思路清晰,将项目从头到尾划分为不同的阶段,严格定义每个阶段的输入输出,并且十分重视文档。瀑布模型的特点:
1、简单直接,思路清晰,需求明确。
2、需要有完善的文档并需要实时更新维护。
其优点:
1、可以保证系统在整体上的充分把握,可以保证整个软件产品有较高的质量,保证缺陷能够被提前发现和解决。
2、可以使系统具备良好的扩展性和可维护性。

二、架构愿景和目标

有时候我们经常把愿景和目标混为一谈,我们首先需要区别愿景和目标:
1、愿景笼统,目标具体,。比如:架构设计做做到高可用,高性能,高可扩展,这些是笼统的概念,没有具体的指标要求。
2、目标是即将实现,能够通过努力实现的规划,愿景是一幅前景,能够指引我们前进的理想。
3、 愿景有助于确定发展目标,发展目标为实现愿景服务。
架构愿景:是一种团队内心的愿望,是脑筋的一幅图画,是一种驱动力,愿意实践、追求,来达到某一个境界,能追求到某一种成就。是团队成员希望架构往哪个方向发展,包括具体目标、设计原则、质量要求。
架构目标:架构达成某些具体的指标,比如可用性达到99.99%等。
因此我这里认为架构的愿景分析是包含目标.

三、架构愿景的层次

架构的愿景是相对于一个范围来说的,在一个特定的软件功能范围之内,谈架构愿景才有实际的意义,例如针对软件的全局或某个子系统/模块。在这个特定的范围中,订立了架构愿景之后,这个范围内的所有设计原则将不能违背架构愿景。这是非常重要的,是架构愿景的最大的用处。有了这样的保证,我们就可以保证设计的一致性和有效性。任何一项设计的加入,都能够融入到原先的架构中,使得软件更加的完善,而不是更加的危险。
我们根据架构适用范围的不同,把架构愿景分为几个类别讨论:

1、软件系统全局(架构模式)

软件全局的架构是我们所最关心的,因此也会花费最多的笔墨。
软件全局中的架构愿景一般很难具体化到代码级别,其实你会发现,就算是具体化到了代码级别,也会因为实际中存在的问题,导致代码没有太多的价值。因此,为软件全局设置的架构愿景可以以原则、或是架构模式的方式体现,并用自然语言或伪代码描述。例如,可以为一个系统规定三层架构作为其愿景,并指出三层的分类原则和具体目标。注意,我们需要指出分类原则,否则规定三层架构并没有太大的意义,因为三层架构随着实现平台的不同、开发人员的不同而有很大的差异,如果不能够规定一个可操作的规范,那么愿景是没有意义的。

2、子系统/模块级、或是子问题级的架构愿景

这时候的架构愿景已经是比较明确的了,因为已经存在明确的问题域。例如界面的设计、领域模型的设计、持久层的设计等。这里的愿景制定本质上和全局的愿景制定差不多,具体的例子我们也不再举了。但是要注意一点,你不能够和全局愿景所违背。在操作上,全局愿景是设计团队共同制定出来的,而子/系统模块级的架构愿景就可以分给设计子团队来负责,而其审核则还是要设计团队的共同参与。这有两个好处,一是确保各个子模块(子问题)间不至于相互冲突或出现空白地带,二是每个子设计团队可以从别人那里吸取设计经验。
在设计时,同样我们可以参考其它的资料,例如相关的模式、或规范(界面设计指南)。在一个有开发经验的团队,一般都会有开发技术的积累,这些也是可供参考的重要资料。
我们在这个层次的愿景中主要谈一谈子模块(子问题)间的耦合问题。一般来说,各个子模块间的耦合程度相对较小,例如一个MIS系统中,采购和销售模块的耦合度就比较小,而子问题间的耦合程度就比较大,例如权限设计、财务,这些功能将会被每个模块使用。那么,我们就需要为子模块(子问题)制定出合同接口(Contact Interface)。合同的意思就是说这个接口是正式的,不能够随意的修改,因为这个结构将会被其它的设计团队使用,如果修改,将会对其它的团队产生无法预计的影响。合同接口的制定、修改都需要设计团队的通过。此外,系统中的一些全局性的子问题最好是提到全局愿景中考虑,例如在源自需求模式中提到的信贷帐务的例子中,我们就把一个利息计算方式的子问题提到了全局愿景中。

3、代码级的愿景 (代码设计模式)

严格的说这一层次的愿景已经不是真正的愿景,而是具体设计了。但是我们为了保证对架构设计理解的完整性,还是简单的讨论一下。这一个层次的愿景一般可以使用类图、接口来表示。但在类图中,你不需要标记出具体的属性、操作,你只需要规定出类的职责以及类之间的相互关系就可以了。该层次愿景的审核需要设计子团队的通过。
而设计细分到这个粒度上,执行愿景设计的开发人员可能就只有一两个左右。但是比较重要的工作在于问题如何分解和如何归并。分解主要是从两个维度来考虑,一个是问题大小维,一个是时间长短维。也就是说,你(设计子团队负责人)需要把问题按大小和解决时间的长短分解为更细的子问题,交给不同的开发人员。然后再把开发人员提出的解决方法组合起来。

四、架构愿景的形成过程

架构愿景的形成的源头是需求,需要特别指出的是,这里的需求主要是那些针对系统基本面的需求。比如说,系统的特点是一个交互式系统,还是一个分布式系统。这些需求将会影响到架构愿景的设计。在收集影响架构愿景的各项需求之后,按照需求的重要性来设计架构愿景。
架构愿景的设计并不需要很复杂的过程,也不需要花费很多的时间。我们已经提过,架构远景的主要目的就是为了能够在开发团队中传播设计思路,因此,架构愿景包括基本的设计思路和基本的设计原则。

1、问题或者需求的背景或者特点:

1)公司背景: 了解公司主要干嘛,成立多久,涉及哪些业务, 业务发展情况(过去,现在,未来)等。
2)业务特点: 业务特色(业务核心价值), 业务流程(流程是否复杂, 要求是否灵活), 业务变化(业务需求是不是经常变化)情况等
3)系统特点: 这是主要针对需要重构的系统架构设计而言:主要内容:

  • 系统整体特点: 如系统庞杂: 如业务特色经多年的快速发展, 内部系统越来越多, 彼此间交互和依赖越来越复杂。
  • 系统划分特点: 系统边界模糊、 职责不清、 耦合过深, 导致系统难以维护和扩展。
  • 业务流程特点: 流程过于分散以及流程的硬编码导致,对流程变化的支持缓慢。
  • 数据分布特点: 多系统间的数据的不合理的集中与分散, 在系统越来越复杂的情况下,严重影响系统的性能与可扩展能力。
  • 开发模式特点: 多种技术并存的情况下, 开发模式的选择, 直接关系到开发效率及运维效率。

4)技术特点: 主要了解现在系统使用哪些技术: 系统版本是否统一, 开发平台是否统一,数据库, 开源组件或者框架是否统一.

2、提出期望目标(愿景范围)

期望目标也是来源于需求,主要指客户(可能是老板)或其他利益相关人提出的项目(产品)愿景。愿景表达了客户的目标以及对系统的期望。从愿景中我们可以获得许多架构分析所需要知道的知识,例如明确客户最期望达到的目标,以此可以确定场景与风险的优先级;了解客户的不同目标,可以由此识别系统客户的不同角色,明确不同的利益相关人的态度。
1)业务响应能力:

  • 降低系统耦合, 提升对变化的响应速度。
  • 改善系统架构, 更好地支持业务扩展。
  • 建立流程引擎, 更灵活地支持业务流程变化。

2)系统质量:
合理地增加或减少系统间交互及补偿, 提升系统性能、 稳定性。
3)开发效率:
合理划分系统, 通过系统职责的分离, 对开发组的职责进行合理分配, 同时建立更完整的公共平台、 基础框架、 基础类库, 提高开发效率。
4)运维水平:
完善配置、 监控、 预警、 日志系统, 提升系统运维配置效率及排查问题的速度.

3、指定架构具体目标:衡量系统好坏的标准.

通过愿景范围,就可以确定架构的实现具体目标。识别架构目标,就需要了解是谁需要使用架构,理解架构的约束(技术约束、使用约束和部署约束)。如同架构在软件开发中起到的作用,架构目标一方面是业务需求和用户的要求,另一方面也是技术和应用系统的要求。架构目标是架构师、 团队和用户( 可能老板)达成的一致共识,而一旦确立了架构目标,该目标就会成为团队的一致共识。一个系统的架构,最终实现了架构师的设计目标,我们就可以说这是一个好架构。
架构旨在为业务需求和技术需求之间搭建起相同的桥梁,并找到合适的方式实现这些需求。好的架构必须能够减少与技术解决方案相关的业务风险。它最好是灵活的,能够处理软硬件以及业务需求等的变化,考虑整体影响设计决策的因素,在质量属性之间权衡,并努力满足用户、系统和业务的需求:

用户的目标: 首先需要明确用户的分类,因为不同类别的用户,他们的关注点是不相同的。例如管理层关注的目标,可能更多地是考虑组织因素,例如项目成本,周期与收益。如果是系统的使用者,则主要考虑业务因素,关心的是与自己工作相关的功能是否满足需求。如果是系统的运维成员,则主要考虑技术因素,例如系统的可维护性、健壮性、可扩展性、可伸缩性等质量属性。
业务目标: 我们并不需要了解每个细节功能的需求,而是关注业务的期望值。了解业务目标,不是要识别业务流程、业务规则或者业务所要处理的数据。例如业务目标提出了提升工作效率,改善工作质量的要求,确定了应该由系统自动完成的功能,明确对业务需求变化的处理。
系统的目标: 和技术直接相关,尤其是架构的质量因素。系统目标可能包含对系统规模、用户数、并发量等的要求。系统目标也可能对软硬件平台提出了约束性要求。
具体目标指标:
正确性:系统首先需要正确,运行稳定
可用性: 系统必须非常可靠,一般业界更倾向用 N 个9 来量化可用性, 最常说的就是类似 “4个9(也就是99.99%)” 的可用性。
开发效率: 降低开发成本和降低公司在快速巨变的行业里面的时间和机会成本。互联网目前是一个快鱼吃慢鱼的时代,已经不是大鱼吃小鱼了。因为小鱼在一夜之间就长大了,把大鱼吃掉了。
伸缩性: 用户激增的时候,系统可以伸缩来支持用户的增长或流量高峰。
安全性:安全也是一个商业公司的命脉,攻击、泄密、破解,前一段闹的沸沸扬扬的各种用户信息泄露,足以说明安全的重要性。
扩展性:在增加新模块或者新的技术时,能比较容易的扩展。
高性能:性能其实也是用户体验的一部分,尤其是用户量不断增多,性能是节省成本的重要手段。
可维护性:一个系统上线之后,80%时间需要不断的更新及增加新的功能,可维护性是一个架构的基本需求。

4、确定架构质量要求

5、规范架构设计总体原则

五、架构愿景目标和需求分析关系

架构目标和需求分析是可以并行进行,但从一开始明确架构目标才是最佳的选择,因为架构目标是整个架构过程所要努力达到的方向。不了解架构目标,搭建出来的系统架构再好,也可能不符合客户的需求。
由于需求非常贴近现实,若直接拿来当作目标的话,一叶障目不见森林的缺点。甚至,会有短视而缺乏远见之嫌。于是,透过观想愿景来汇集更多视角、扩大视野、产生洞见,成为系统开发的理想目标。
架构愿景和目标可以衡量需求是否合理: 在需求分析阶段, 从需求方收集到的需求,不一定是合理的. 比如需求要求可用性必须是100%。可能需求方也没有想清楚自己想要的是什么,可能在沟通过程中有信息失真,可能需求方的需求太局限于当前现实而忽略了未来发展.因此衡量需求是否合理和依照需求表象来挖掘真实需求是很重要的。这就是需要架构设计立足现实,着眼未来。
任何架构设计都需要一定灵活扩展性,但是基于现实需求去推演往往不能正确充分的判断需求的发展方向;但是基于未来愿景的回溯所作的设计,已经具备了未来性,决策的未来型是由愿景的正确性来保证的。
需求分析从现实出发,不但找出问题,并且理清它的现实条件和限制。
观想愿景则指引出我们的方向和目标。
架构设计就从这个目标出发,以终为始,从愿景映射到现实。恰好与需求分析是相反的视角,两者互补而相成,殊途而同归,才能得出一条从现实通往目标之路(或蓝图),这就是所谓的架构了。
参考: 总结网上相关资料
https://www.ibm.com/developerworks/cn/linux/software_engineering/Methodology/part8/index.
《携程架构变迁》

作者:规速

来源:https://blog.csdn.net/hguisu/article/details/80748295


版权声明:文末如注明作者和来源,则表示本文系转载,版权为原作者所有 | 本文如有侵权,请及时联系,承诺在收到消息后第一时间删除 | 如转载本文,请注明原文链接。
喜欢 (0)