《Fundamantals of Software Architecture》 Q&A Part2

本文深入探讨了软件架构的多种风格,包括分层架构、管道架构、微内核架构、基于服务的架构和事件驱动架构。分析了每种风格的基础、特点、优缺点以及适用场景,帮助读者理解如何选择合适的架构风格。
摘要由CSDN通过智能技术生成

第二部分 架构风格

第九章 基础

1.列出分布式计算的8个谬误。
网络是可靠的、零延迟、带宽是无限的、网络是安全的、拓扑结构从不改变、只有一个管理员、传输成本为0、网络是同构的。
2.说出三个分布式架构拥有而单片架构所没有的挑战。
分布式日志、分布式事务、契约维护和版本控制。
3.什么是特征耦合?
特征耦合是指两个都与同一个数据结构有关的模块发生的耦合。由于同时使用同一个数据结构,当数据结构变动时,必然影响这两个模块,从而增加模块间的依赖性,降低模块独立性。
4.有哪些方法可以解决特征耦合问题?
在设计模块结构时,应当尽量将数据结构传递修改为数据传递,从而将特征耦合变为数据耦合,降低耦合度。

第十章 分层架构风格

1.开放层和封闭层的区别是什么?
封闭层意味着当一个请求自顶向下从一个层传递到另一个层,请求不能跳过任何层,而是必须通过它下面的层才能到达下一层。开放层意味着允许请求绕过其他层。
2.描述隔离层的概念和这个概念的好处。
分层隔离性意味着在架构的一个分层中所做的更改通常不会影响其他分层中的组件,前提是这些层之间的契约保持不变。分层隔离性允许在不影响任何其他层的情况下替换架构中的任何层。
3.什么是架构污水池反模式?
当请求作为简单的传递处理从一层移动到另一层,而在每一层中不执行业务逻辑时,就会出现这种反模式。
4.驱动你使用分层架构的主要架构特征是什么?
总体成本和简单性。
5.为什么分层架构风格不能很好地支持可测试性?
对于一个简单的三行变更,大多数开发人员不会花几个小时来执行整个回归测试套件,特别在同时对整个应用程序进行许多其他变更的情况下。
6.为什么敏捷性在分层架构风格中没有得到很好的支持?
随着采用分层架构的应用程序的发展,这种架构的敏捷性将受到不利影响。这种架构风格的可部署性和可测试性都非常低。

第十一章 管道架构风格

1.管道架构中的管道是双向的吗?
由于性能原因,每个管线通常是单向和点对点的。
2.说出四种类型的过滤器及其用途。
生产者:进程的起点,仅供输出,有时称为源。
转换器:接受输入,选择性地对部分或全部数据执行转换,然后将其转发到输出管道。函数式倡导者将这个特性称为map。
测试器:接受输入,测试一个或多个条件,然后根据测试选择性地生成输出。函数式程序员将之称为reduce。
消费者:管道的终点。使用者有时会将管道处理的最终结果保存到数据库中,或者在用户界面上显示最终结果。
3.过滤器可以通过多个管道发送数据吗?
不能,每个管线通常是点对点的(而不是广播的),接受来自一个源的输入,并总是输出到另一个源。
4.管道架构样式是技术分区的还是域分区的?
域分区的。
5.管道架构以何种方式支持模块化?
通过分离各种过滤器类型和转换器之间的关注点可以实现架构模块化。
6.提供两个管道架构样式的示例。
电子数据交换(Electronic Data Interchange,EDI)工具,利用管线和过滤器构建从一种文档类型到另一种文档类型的转换功能。
ETL工具(提取、转换和加载)也利用管道架构,用于从一个数据库或数据源到另一个数据库或数据源的数据流转和修改。

微内核架构风格

1.微内核架构风格的另一个名称是什么?
插件架构。
2.在什么情况下插件组件可以依赖于其他插件组件?
理想情况下,插件组件应该彼此独立,相互之间不存在依赖关系。
3.有哪些工具和框架可以用来管理插件?
框架:Java的Open Service,Gataway Initiative(OSGi),Penrose(Java),Jigsaw(Java)或Prism(.NET)
4.如果你有一个不符合核心系统中的标准插件契约的第三方插件,你会怎么做?
在插件契约和标准契约之间创建适配器,这样核心系统就不需要为每个插件专门编写代码。
5.提供微内核架构风格的两个示例。
Eclipse IDE,Chrome
6.微内核架构风格是技术分区还是域分区的。
它是唯一既可以基于技术分区又可以基于域分区的架构。虽然大多数微内核架构是基于技术分区的,但是域分区方面主要是通过紧密的域-架构的同构来实现的。
7.为什么微内核架构总是一个单一的架构量子?
因为所有请求都必须通过核心系统才能获得独立的插件组件。
8.什么是域/架构同构?
例如,需要为每个位置或客户端进行不同的配置。

第十三章 基于服务的架构风格

1.在典型的基于服务的架构中有多少服务?
4-12个,平均约为7
2.必须在基于服务的架构中拆分数据库吗?
不一定,基于服务的架构通常使用中心化共享的数据库。
3.在什么情况下需要拆分数据库?
需要降低数据库变更的影响和风险的时候。
4.在基于服务的架构中,可以使用什么技术来管理数据库更改?
共享库版本控制
5.域服务是否需要一个容器(如Docker)来运行?
需要。
6.基于服务的架构样式很好地支持哪些架构特征?
敏捷性、可测试性、可部署性。
7.为什么在基于服务的架构中不能很好地支持弹性?
因为与更细粒度的服务(如微服务)相比,功能的重复性更高,因此机器资源使用率不高,成本效益也不高。
8.如何在基于服务的架构中增加架构量子的数量?
用户界面和数据库可以联合,从而在整个系统中产生多个量子。

第十四章 事件驱动的架构风格

1.代理拓扑和中介拓扑之间的主要区别是什么?
代理拓扑与中介拓扑的不同之处在于代理拓扑没有中心事件中介。
2.为了更好地控制工作流,你会使用中介拓扑还是代理拓扑。
中介拓扑
3.代理拓扑通常是利用带有主题的发布-订阅模型还是带有队列的点对点模型?
发布-订阅消息传递模型
4.说出异步通信的两个主要优点
可以增强系统的总体响应能力。故障隔离:服务没有直接调用,不存在级联失败问题。
5.给出一个基于请求模型的典型请求的例子。
客户请求检索他们过去六个月的订单历史记录。检索订单历史信息的方法时向系统发出的一个数据驱动、确定性的请求,用于在特定上下文中检索数据,而不是发出一个系统必须响应的事件。
6.给出一个基于事件模型的典型请求的例子。
在在线拍卖中提交对特地物品的投标。提交投标的并不是向系统发出的请求,而是在宣布当前要价之后发生的事件。
7.在事件驱动的架构中,初始事件和处理事件有什么区别?
初始事件是启动整个事件流的初始事件。初始事件被发送到事件代理中的事件通道进行处理。
8.在从队列发送和接收消息时,有哪些技术可以防止数据丢失?
持久消息队列,同步发送信息、客户端确认模式、最后参与者支持技术
9.使用事件驱动架构的三个主要驱动架构特征是什么?
高性能、可伸缩性、容错
10.事件驱动的架构中有哪些架构特征没有得到很好的支持。
简单性和可测试性。

第十五章 基于空间的架构风格

1.基于空间的架构风格的名字从何而来?
基于空间的架构得名于元组空间的概念,元组空间是一种使用多个并行处理器去通过共享内存进行通信的技术。
2.基于空间的架构与其他架构风格的主要区别是什么?
基于空间的架构风格是专门为解决涉及高可伸缩性、弹性、和高并发性的问题而设计的。
3.请说出组成基于空间的架构中的虚拟化中间件的四个组件的名称。
消息传递网格、数据网格、处理网格和部署管理器。
4.消息传递网格的角色是什么?
消息传递网格管理输入请求和会话状态。当请求进入虚拟化中间件时,消息传递网格组件确定哪些活动处理组件可用来接收请求,并将请求转发到其中一个处理单元。
5.数据写入器在基于空间的架构中扮演什么角色?
数据写入器组件接受来自数据泵的消息,并使用其中包含的信息更新数据库。
6.服务需要什么条件下通过数据读取器访问数据?
数据读取器仅在以下三种情况下调用:同名缓存的所有处理单元实例崩溃、同名缓存内的所有处理单元重新部署、检索复制缓存中不包含的存档数据。
7.小的缓存大小是否会增加或减少数据冲突的机会?
小的缓存大小会增加数据冲突的机会。
8.复制缓存和分布式缓存的区别是什么?哪一个是典型的基于空间的架构?
分布式缓存可以比复制缓存提供更好的数据一致性,因为数据缓存位于单个位置(而不是分散在多个数处理单元中)。但是,复制缓存的性能和容错性更好。
复制缓存是典型的基于空间的架构。
9.列出基于空间的架构中最受支持的三个架构特征。
高可伸缩性、弹性、和高并发性
10.为什么基于空间的架构的测试率如此之低?
在峰值负载下测试成千上万的并发用户是一项非常复杂和昂贵的任务,因此大多数高容量测试都是在实际极端负载的生产环境中进行的。

第十六章 编制驱动的面向服务的架构

1.面向服务的架构背后的主要驱动力是什么?
20世纪90年代后期,很多公司通过与较小的公司合并我,急速增长后成为较大的企业,这些企业需要更复杂的IT化来适应这些增长,于是编制驱动的面向服务的架构应运而生。
2.面向服务的架构中的四种主要服务类型是什么?
业务服务、企业服务、应用程序服务、基础设施服务。
3.列出一些导致面向服务的架构崩溃的因素。
当团队主要围绕重用来构建系统时,组件之间也会产生大量耦合。如果当前的企业服务没有定义正确的事务粒度,开发人员将不得不更改其设计或构建一个几乎相同的新服务来更改事务行为。
4.面向服务的架构是技术分区的还是域分区的?
技术划分。
5.如何在SOA中实现域重用?如何处理可操作的重用?
将所有客户行为隔离到单个客户服务中,从而实现了重用。
在SOA中架构师努力进行增量更改——每个更改都可能产生巨大的连锁反应。

第十七章 微服务架构

1.为什么有界上下文概念对于微服务架构如此重要?
微服务的驱动哲学是有界上下文:每个服务建模一个域或工作流。因此,每个服务都包括在应用中运行所需一切,包括类、其他子组件和数据库模式。
2.确定微服务中是否具有正确的粒度级别的三种方法是什么?
目的:最明显的边界依赖于架构风格的灵感,即域。理想情况下,每个微服务应该具有非常高的功能内聚性,代表整个应用程序贡献一种重要的行为。
事务:有界上下文是业务工作流,在事务中需要协作的实体通常为架构师提供良好的服务边界。因为事务会在分布式架构中引起问题,如果架构师可以设计他们的系统来避免事务,那么就可以产生更好的设计。
编排:如果架构师构建了一组服务,这些服务提供了优秀的域隔离,但是需要大量的通信才能发挥作用,那么架构师可以考虑将这些服务打包到一个更大的服务中,以避免通信开销。
3.边车可能包括哪些功能?
边车组件处理所有的运维关注点,而所有团队则从这种耦合中获益。
4.编制和编排有什么区别?微服务支持哪些功能?微服务中的一种通信风格是否更容易?
编制是由中心化控制来实现,编排是去中心化的自我控制来实现。
微服务支持编制和编排,微服务架构通常利用协议感知的异构互操作性。
5.微服务中的saga是什么?
sage是在微服务中流行的分布式事务。
6.为什么微服务能够很好地支持敏捷性、可测试性和可部署性?
服务的独立部署,每个服务都是独立的项目,可以独立部署,不依赖于其他服务,耦合性低。因此很好支持敏捷性、可测试性、可部署性。
7.性能在微服务中通常是一个问题的两个原因是什么?
分布式架构必须许多网络调用才能完成工作,这导致很高的性能开销,并且它们还必须调用安全检查来验证每个断点的身份和权限。
8.微服务架构是域分区的还是技术分区的?
域分区,其中每个服务边界都应该与领域相对应。
9.描述一个拓扑结果,其中微服务生态系统可能知识一个量子。
10.如何在微服务中实现域重用?如何处理可操作的重用?
边车模式

第十八章 选择合适的架构风格

1.数据架构(逻辑和物理数据模型的结果)以何种方式影响架构风格的选择?
架构师和DBA必须在数据库、模式和其他与数据结构相关的问题上进行协作。架构师必须理解数据设计中可能对其设计产生的影响,特别是当新系统必须和旧的和/或正在使用的数据架构进行交互时。
2.它如何影响你对使用的架构风格的选择?
3.描述架构师用于确定架构样式、数据分区和通信样式的步骤。
先确定架构样式、在决定数据分区,最后决定通信样式。
4.什么因素导致架构师采用分布式架构?
集中式系统是一种Scale out/in,想要提高系统服务性能,要么就是升级多核增加CPU核心数量提高处理能力,要么就是提升其他硬件性能。提升硬件的天花板低,因此当企业的服务扩展到一定程度,无法从提升硬件水平来提高服务质量,分布式架构应运而生。

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

isasiky

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值