哪种软件或者场景适合设计为分布式系统架构

Posted 2023-04-28

架构（Architecture）一词源于建筑领域，就是建筑的意思，也是体系结构的意思。 维基百科英文版里对Architecture的解释是：规划、设计和建造建筑物的过程及产物。
Architect/Architecture ?
软件工程 ~ 建筑工程

人的因素，
标准的因素，
技术的因素,
产品的因素，，，软件边际成本是0。
什么是架构

国际标准化组织（International Orgranization for Standardization，ISO）系统和软 件工程标准认为，系统的架构是一系列基本概念或者系统在其环境中表现出来的属性， 体现在它的元素、关系及设计和发展的原则中。

1.架构过程：在系统整个生命周期中构思、定义、表达、记录、交流，验证合适实现，维护和改 进架构的过程，也就是设计过程。

2.架构：一个系统体现在其环境中的元素、关系的基本概念或属性，以及其设计和进化原则。

3.架构描述：表达一个架构的工作产出物（通常指的是各种架构图和设计文档）。

4.架构视图：通过系统的某些关注点的视角，表达一个系统的工作产出物（例如部署视图、开发 视图等）。

5.系统：包含了一个或多个进程，硬件，软件，工具与可以满足需求的人的集合。

6.环境：决定了开发、操作、策略和其他影响系统的设置和条件。

什么是架构

总结：软件架构是一个用于指导系统实现的草图，这个草图越详细对于系统实现的指导 意义越重大，贯穿于软件的整个生命周期。

在建筑领域，大楼尚未建造前，就已经存在于建筑师的脑海里；同样地，系统开始编写 第一行代码之前，就已经存在于软件架构师的心里。至于怎么样把架构草图表达出来呢？ 我们一般都是采用架构图和设计文档的形式。

架构相关的文档就是，用来描述和交流系统架构的媒介

架构的一些概念

架构领域长时间发展，积累了很多的概念和基础知识。 例如，我们经常说得软件领域名词还有模式、组件、服务、模块、类库、框架，平台等，

他们跟架构有什么关系和区别呢？

架构的一些概念-模式

模式是表示上下文环境、动机、解决方案三个方面关系的一个规则，每个模式描述了一 个在特定上下文环境里不断重复发生的问题的一类解决方案。UML中给出的解释更通 俗易懂：模式是对于普遍问题的普遍解决方案。 我们把一类问题的共性抽象出来，这样就可以用同样的处理办法去解决这些问题，从而 形成模式，所以模式是一些经验的总结。 从这个角度来说，软件架构作为一种软件设计过程的指导准则，也是一些经验的积累和 问题的抽象，同样也可以作为一种模式。 更一般的，依据于处理问题领域的粒度不同，我们可以把模式分为架构模式(Architectural Pattern)、设计模式(Design Pattern)、实现模式(Implementation Pattern)三个层次。 • 架构模式是最高层次的模式，在软件过程里描述系统的基础结构、子系统划分，确定职责和边 界，以及相互作用关系。 • 设计模式是用来处理解决程序设计里具体场景下的问题的解决办法。 • 实现模式是最低层次的具体问题处理办法，例如编码规范、命名规则等。

架构的一些概念-类库

类库（Library）是一组可复用的功能或工具的集合，应用系统通过调用它们从而达到 复用功能的目的。 例如，windows应用开发里的各种静态或动态链接库DLL文件，Java开发里项目里依赖 的或者maven中央库里的各种jar包，都是Library，比如apache commons-io、 httpclient，log4j等。 类库根据其所在的语言或平台环境的不同，可以是编译后的二进制执行码或中间码形式 （DLL或jar），也可以是源代码（php、NodeJS里的类库）。类库的调用关系一般在 开发期引入到目标应用的项目中，运行期执行实际调用。

架构的一些概念-框架

框架是基于一组类库或工具，在特定领域里根据一定的规则组合成的、开放性的应用骨 架，比如SSM/SSH框架，甚至Dotnetfx、JDK都算是一种框架。框架具有如下特性： a）支撑性+扩展性：框架不解决具体的业务功能问题，我们可以在框架的基础上添加各种具体的业务功能、 定制特性，从而形成具体的业务应用系统。 b）聚合性+约束性：框架是多种技术点的按照一定规则的聚合体。我们采用了某种框架也就意味着做出了技 术选型的取舍。在很多种可能的技术组合里确定了一种具体的实现方式，后续的其他工作都会从这些技术出 发，也需要遵循这些规则，所以框架本身影完整版获取加微信wxywd8 响到研发过程里的方方面面。 在一个具体的框架之上添加一些基本或可复用的功能，这时候就得到一个介于框架和应 用之间的结构，我们一般叫脚手架（Scaffold），可以用来快速的实现类似项目。

架构的一些概念-模块

模块（Module） 模块是业务或系统的按照特定维度的一种切分，同时也可以看做是各种功能按照某种分 类聚合的一种形式。例如我们的一个电商系统，可以从业务上划分为用户模块，商品模 块，订单模块，支付模块，物流模块，售后模块等。另一方面，我们也可以说用户模块 聚合了用户注册、用户验证等业务功能。这样，我们在设计和开发过程中，就可以按照 模块的维度去组织，比如每个模块新建一个源码的子项目（subproject）、打包成一个 单独的jar包，也可以放到一个项目里用不同的package名称来区分等。模块一般是系 统在较大粒度上的解耦切分，仅次于系统或子系统的级别。 参考技术A 现阶段 Dragonfly 基于 Dragonfly1.x 演进而来，在保持 Dragonfly1.x 原有核心能力的基础上，Dragonfly 在系统架构设计、产品能力、使用场景等几大方向上进行了全面升级。

软件体系架构——质量属性

以《淘宝网》为例，描绘质量属性的六个常见属性场景，将上述整理为一篇博客发表。

1、可用性分析

可用性分析所关注的方面包括：如何检测系统故障，系统故障发生的频度，出现故障时会发生什么情况，允许系统有多长时间非正常运行，什么时候可以安全地出现故障，如何防止故障的发生以及发生故障时要求进行哪种通知。

 

场景：双十一或者春晚抽奖导致淘宝用户猛增

刺激源：淘宝用户

刺激：登录人数过多，导致淘宝无法响应，淘宝瘫痪，网页无法向下进行

制品：淘宝的处理器、通信通道、存储器、进程

环境：用户的正常浏览操作

响应：淘宝页面呈现“网络出现故障，重新刷新”等的提示信息，提示用户下一步操作

响应度量：系统降级模式下继续运行，用户刷新页面或者重新登录之后可继续正常使用。

2、可修改性分析

可修改性是有关变更的成本问题。可以修改什么（制品）和何时进行变更以及由谁进行变更（环境）。

场景：新年来临，淘宝app要修改自己的系统页面，并且添加一些其他的功能

刺激源：系统开发人员

刺激：系统界面要修改为新年主题，增加抽奖红包等功能

制品：淘宝界面即抽奖领取红包界面

环境：淘宝正常登录运行时

响应：针对页面查找构架中需要修改的位置，进行修改添加并且不影响其他功能，对修改进 行测试，部署所做修改

响应度量：系统人员后台更新，测试部署成功自动更新，用户登录即可

3、性能分析

性能与时间有关。事件（中断、消息、用户请求或时间已到）发生时，系统必须做出响应。事件到达和相应有很多特性，但性能基本上与事件发生时，将要耗费系统多长时间做出响应有关。

场景：淘宝用户购买商品

刺激源：淘宝用户

刺激：购买商品

制品：系统生成订单

环境：淘宝正常运行

响应：淘宝生成订单，提示用户进行支付，检测网络环境

响应度量：在短时间内显示商品状态以及支付状态，显示交易的完成度

4、安全性分析

安全性是衡量系统在向合法用户提供服务的同时，阻止非授权使用的能力。试图突破安全防线的行为被称为攻击，它可以是未经授权试图访问数据或服务，或试图修改数据，也可能是试图使系统拒绝向合法用户提供服务。

场景：一个通过身份验证的人试图从外部站点更改系统数据

刺激源：淘宝用户

刺激：试图从外部站点修改系统数据

制品：系统服务、系统中的数据

环境：在线连接有防火墙

响应：对用户身份进行验证，阻止其对数据的访问

响应度量：短时间内审核身份，拒绝其访问，并限制系统可用性

5、可测试性分析

软件可测试性是指通过测试揭示软件缺陷的容易程度。

场景：单元测试人员测试商品浏览查询模块

刺激源：单元测试人员

刺激：测试人员输入商品关键词，进行商品查询

制品：商品搜索模块的代码

环境：在开发时进行

响应：通过商品关键词查询，所检索出的商品信息呈列表显示

响应度量：在较短的时间内完成对商品的检索

6、易用性分析

易用性关注的是对用户来说完成某个期望任务的容易程度和系统所提供的用户支持的种类。

场景：用户取消自己即将生成的交易

刺激源：淘宝用户

刺激：用户放弃自己的商品交易，选择取消交易

制品：淘宝系统

环境：系统正常运行，用户正常购买商品

响应：取消交易成功，淘宝系统删除交易，恢复到以前页面

响应度量：取消在一秒内发生，且不影响后序操作

转载：https://m.sohu.com/a/232685820_371153/?pvid=000115_3w_a