可伸缩性原则是什么意思

合集下载

信息系统架构设计

信息系统架构设计

信息系统架构设计在当今信息化快速发展的社会中,各类组织和企业对于信息系统的需求越来越迫切。

信息系统架构设计作为信息系统实施的基础,对于系统性能和可扩展性的提升具有重要作用。

本文将对信息系统架构设计的概念、设计原则以及设计过程进行探讨,并结合实际案例进行分析和讨论。

一、信息系统架构设计概述信息系统架构设计是指根据组织或企业的需求,对信息系统进行整体规划和设计的过程。

它涉及到系统的组织结构、组件之间的交互关系、功能模块划分以及技术选型等方面。

信息系统架构设计的目标是实现系统的高效运作、易于维护和扩展,并满足用户的需求。

二、信息系统架构设计原则1. 模块化原则:将系统划分为不同的模块,每个模块具有独立的功能,并通过接口进行交互。

这有利于提高系统的可维护性和可扩展性。

2. 松耦合原则:模块之间的依赖关系应尽量减少,以减少系统的风险和影响范围。

模块之间的通信应采用标准化、松散的接口。

3. 可重用性原则:设计时应尽量考虑到模块的可重用性,以提高开发效率和降低成本。

4. 安全性原则:系统架构设计要考虑到数据的安全性和用户的权限管理,以防止未经授权的访问和数据泄露。

5. 可伸缩性原则:系统需要具备良好的可扩展性,能够满足未来的业务需求和用户量增长。

三、信息系统架构设计过程1. 需求分析:明确系统的功能需求和性能需求,并与用户进行充分沟通,确保设计方案符合用户的期望。

2. 架构规划:根据需求分析的结果,选择合适的架构风格和技术栈。

常见的架构风格包括分层架构、微服务架构等。

3. 组件设计:根据功能需求和架构规划,设计各个组件的功能和接口,并确定它们之间的协作关系。

4. 技术选型:根据设计需求,选择适合的技术工具和框架,并评估其性能和可扩展性,以确保系统稳定和高效运行。

5. 性能测试与优化:对设计的系统进行性能测试,找出性能瓶颈,并采取优化措施,提升系统的响应速度和吞吐量。

6. 安全评估:对系统进行安全评估,识别潜在的安全风险,并采取相应的安全措施,确保系统的数据和用户安全。

系统架构设计的五大原则(四)

系统架构设计的五大原则(四)

系统架构设计的五大原则系统架构设计是软件开发过程中至关重要的一环,好的系统架构可以保证系统的稳定性、可靠性和扩展性。

在进行系统架构设计时,有一些基本原则是需要遵循的。

本文将探讨系统架构设计的五大原则,以帮助读者更好地理解系统架构设计的重要性。

1. 模块化模块化是系统架构设计的基本原则之一。

在进行系统架构设计时,需要将系统拆分成若干个独立的模块,每个模块负责特定的功能。

这样做有助于降低系统的复杂度,提高系统的可维护性和可扩展性。

模块化的设计还有利于团队协作,不同的团队成员可以分别负责不同模块的开发和维护,提高工作效率。

同时,模块化设计也有助于系统的测试和调试,可以更快速地定位和解决问题。

2. 松耦合松耦合是系统架构设计的另一个重要原则。

在进行系统架构设计时,需要尽量降低模块之间的耦合度,模块之间的依赖关系应尽量简单和清晰。

这样做有助于提高系统的灵活性和可维护性,当一个模块需要修改时,不会对其他模块造成影响。

松耦合的设计还有助于系统的升级和扩展,可以更方便地引入新的功能和技术,提高系统的可扩展性和适应性。

3. 高内聚高内聚是系统架构设计的又一重要原则。

在进行系统架构设计时,需要确保每个模块的功能尽可能集中,模块内部的各个组件之间应具有紧密的关联性,完成特定的功能。

高内聚的设计有助于降低系统的复杂度,提高系统的可维护性和可扩展性。

高内聚还有助于提高系统的性能,有效减少模块之间的通信开销,提高系统的运行效率。

4. 统一性统一性是系统架构设计的重要原则之一。

在进行系统架构设计时,需要遵循一致的设计风格和规范,确保系统的各个模块之间具有统一的接口和交互方式。

这样做有助于降低系统的学习和维护成本,提高团队协作的效率。

统一性的设计还有助于提高系统的可靠性和稳定性,减少系统出错的可能性。

同时,统一性的设计也有助于提高系统的可扩展性,新的功能和模块可以更容易地集成到系统中。

5. 可伸缩性可伸缩性是系统架构设计的最终目标之一。

技术架构管控原则_概述说明以及解释

技术架构管控原则_概述说明以及解释

技术架构管控原则概述说明以及解释1. 引言1.1 概述技术架构管控原则是指在软件开发和项目实施过程中,为了保证系统的稳定性、可扩展性和可维护性等方面的要求,对技术架构进行有效的管理与控制。

随着信息技术的快速发展,技术架构在企业中起到至关重要的作用。

合理的技术架构能够帮助企业提高系统的性能、安全性以及可靠性,进而提升竞争力并满足用户需求。

1.2 文章结构本文分为以下几个部分:引言、技术架构管控原则概述、技术架构管控原则的要点一、技术架构管控原则的要点二以及结论与总结。

通过逐步展开讨论,阐述了技术架构管控原则在软件开发过程中的重要意义以及具体应用案例。

1.3 目的本文的目的是介绍和解释技术架构管控原则,并通过详实的案例分析来说明这些原则在实际项目中的应用价值。

通过研究和总结现有实践经验,旨在提供给读者一个清晰的概念和理解,以便在实际项目中能够更好地应用技术架构管控原则,提高软件系统的质量和效率。

注意:由于人工智能模型输出限制,可能无法完全满足您所需的内容格式。

如有需要,请根据以上文本自行调整为适当的格式。

2. 技术架构管控原则概述:技术架构在软件开发和系统设计中扮演着重要的角色,它涉及到对系统各个组件、模块以及它们之间关系的定义和组织。

而技术架构的管控原则则是用来指导并管理技术架构设计和演化过程中的方针和准则。

2.1 技术架构定义:技术架构是一种描述软件系统或应用程序各个组成部分之间关系与交互方式的抽象表示。

它主要以结构、组件、接口、数据流等方式表达,并提供了设计和实现整个系统所需的指南。

2.2 管控原则介绍:管控原则是指为了确保技术架构能够满足系统需求,实现预期目标,在整个开发过程中需要遵循的规范和约束。

这些原则可以包括不同方面,如性能、可扩展性、安全性等,以及相关团队协作规范等。

2.3 管控原则的重要性:技术架构管控原则在软件开发过程中起到至关重要的作用。

首先,它们可以帮助团队建立统一认可的技术架构概念,避免不同开发者之间的理解误差。

数据库设计四大原则

数据库设计四大原则

数据库设计四大原则数据库设计是指根据业务需求和数据特点,合理地组织和存储数据的过程。

数据库设计的好坏直接影响了数据库的性能、安全性、可维护性和可扩展性。

因此,数据库设计需要遵循一些基本的原则,以保证数据库的高效运行和良好发展。

本文将介绍数据库设计的四大原则,分别是范式化原则、安全性原则、可伸缩性与可扩展性原则和规范化原则。

一、范式化原则范式化原则是指将数据组织成多个关系表的过程,目的是减少数据冗余,提高数据的一致性和可靠性。

范式化原则有多个级别,从第一范式(1NF)到第五范式(5NF),每个级别都有一定的规则和要求。

一般情况下,数据库设计应该遵循第三范式(3NF),即满足以下条件:表内的每一个值都只能被表达一次,即不存在重复的列或行。

表内的每一行都应该被唯一的标识(有唯一键)。

表内不应该存储依赖于其他键的非键信息,即不存在传递依赖。

范式化原则可以有效地避免数据的插入异常、删除异常和更新异常,提高数据操作的效率和准确性。

但是,过度的范式化也会带来一些问题,如增加了表的数量和连接操作,降低了查询速度和易用性。

因此,在实际的数据库设计中,需要根据具体的业务场景和数据特点,适当地进行反范式化处理,即在满足范式化要求的基础上,适当地增加冗余字段或合并表,以提高查询性能和用户体验。

二、安全性原则安全性原则是指保护数据库免受未经授权的访问、修改或破坏的过程,目的是确保数据的完整性、机密性和可用性。

安全性原则包括以下几个方面:数据库管理和使用人员权限分离,即根据不同的角色和职责,分配不同的访问权限和操作权限,避免权限滥用或泄露。

数据库采用合理的加密算法和认证机制,防止数据被窃取或篡改。

数据库定期进行备份和恢复,防止数据丢失或损坏。

数据库及时更新补丁和防火墙,防止数据库被攻击或入侵。

安全性原则是数据库设计中至关重要的一个方面,如果忽视了安全性原则,可能会导致数据泄露、损毁或丢失,给企业或个人带来巨大的损失或风险。

云计算架构设计的五大原则

云计算架构设计的五大原则

云计算架构设计的五大原则在当今数字化时代,云计算成为了企业和个人的重要工具。

它不仅提供了高效的数据存储和处理能力,极大地降低了IT成本,还为创新和发展提供了无限可能。

云计算的架构设计至关重要,这决定了系统的可靠性、可伸缩性和性能。

在云计算架构设计中,以下五大原则应该被注重。

第一原则:可伸缩性可伸缩性是云计算架构设计中最重要的原则之一。

随着业务的发展和用户的增长,系统必须能够随之扩展,以满足不断增长的需求。

通过合理的水平扩展和垂直扩展,企业可以根据具体的业务需求来调整资源的规模和配置,从而提供高性能的云服务。

而在云计算的架构设计中,采用可伸缩性的原则可以确保系统在面临大规模流量冲击时仍能保持稳定运行。

第二原则:高可用性在云计算环境中,高可用性是至关重要的。

云计算架构设计需要考虑到各种可能的故障情况,并采取相应的措施来防止和恢复故障。

采用多台服务器进行冗余备份、使用故障转移和负载均衡等技术,可以确保系统在遇到硬件或软件故障时能够自动切换和恢复,保持服务的连续性和稳定性。

第三原则:数据安全性云计算架构设计必须重视数据的安全性。

用户的敏感数据必须得到有效的加密保护,同时要为数据的备份和灾难恢复提供安全的机制。

合理的身份认证和访问控制是云计算环境中最基本的安全措施,而云计算架构设计应该采用最佳的安全实践,例如使用安全通信协议和防火墙,以保护数据的完整性和隐私。

第四原则:可扩展性可扩展性是云计算架构设计中需要考虑的重要原则之一。

随着业务的发展,企业需要不断添加新的功能和服务。

因此,云计算架构设计需要具备良好的可扩展性,以便能够快速适应新的业务需求。

采用微服务架构、使用容器化技术和借助无服务器计算等新兴技术,可以实现系统的模块化和解耦,进而提高系统的可扩展性。

第五原则:弹性云计算架构设计应该具备弹性,即能够根据需求动态调整资源的使用量。

通过云平台提供的自动化部署和伸缩功能,可以根据实际负载情况来动态调整资源的分配,从而实现优化的资源利用和费用控制。

网络拓扑设计的基本原则与实践

网络拓扑设计的基本原则与实践

网络拓扑设计的基本原则与实践网络拓扑设计是建立和规划一个网络的基础,它决定了网络的性能、可靠性和扩展性。

一个好的网络拓扑设计可以提高网络的吞吐量、降低延迟、增加可靠性,并便于网络的管理和维护。

在进行网络拓扑设计时,有一些基本原则和实践值得我们关注和遵循。

1. 网络拓扑设计的基本原则(1)简单性原则:网络拓扑设计应该尽可能简单,以提高网络的可维护性。

复杂的网络拓扑不仅增加了网络管理的难度,也容易引起潜在的问题。

简单的网络拓扑可以减少故障排查的难度,并提高故障诊断和恢复的效率。

(2)可靠性原则:网络拓扑设计应该考虑网络的可靠性和冗余性。

通过使用冗余设备、链路和路由,可以提高网络的容错能力,并避免单点故障。

在设计中,应该避免单一故障点和单一路径,以保证网络的高可用性和稳定性。

(3)伸缩性原则:网络拓扑设计应该具备良好的伸缩性,以适应不断增长的用户数量和流量。

在设计中,应该考虑到网络的扩展性和带宽的分配,以满足未来的增长需求。

采用模块化和可扩展的设计,可以方便地进行网络的升级和扩展。

(4)安全性原则:网络拓扑设计应该注重网络的安全性。

通过合理的网络分隔、访问控制和安全策略,可以保护网络免受攻击和入侵。

在设计中,应该考虑到网络的安全需求,并采取适当的安全措施,以保护网络的机密性、完整性和可用性。

2. 网络拓扑设计的实践(1)层次化设计:层次化设计是常用的网络拓扑设计方法,它将网络划分为若干个层次,每个层次负责不同的功能。

典型的设计包括核心层、分布层和接入层。

核心层负责网络之间的连接,分布层负责不同区域的连接,接入层负责用户的接入。

通过层次化设计,可以减少网络中的广播和冲突,提高网络的可扩展性和性能。

(2)冗余设计:冗余设计是保证网络可靠性的重要手段。

通过使用冗余设备、链路和路由,可以避免单点故障,提高网络的容错能力。

常用的冗余设计包括冗余交换机、冗余链路和冗余路由协议。

在实践中,应合理选择冗余方案,考虑成本和性能的平衡。

网络拓扑结构设计

网络拓扑结构设计

网络拓扑结构设计网络拓扑结构是指计算机网络中各个节点之间的连接方式和组织结构,它对于网络性能和可靠性有着重要的影响。

一个好的网络拓扑结构设计能够提高数据传输的效率和可靠性,降低网络故障的发生率。

本文将讨论网络拓扑结构设计的原则和常见的拓扑结构类型。

一、网络拓扑结构设计原则1. 可靠性原则网络拓扑结构应该具有高可靠性,即当某一部分网络出现故障时,其他部分能够继续正常工作。

为了实现高可靠性,可以采用冗余设计和备份路径等技术手段。

例如,通过使用冗余链路可以避免单点故障的出现,使用备份路径可以在主路径故障时提供替代的数据传输路径。

2. 可伸缩性原则网络拓扑结构应该具有良好的可伸缩性,即能够根据需求进行扩展和调整,而不影响整体性能。

随着网络规模和业务量的增大,网络需要支持更多的节点和用户,因此需要能够快速扩展和添加新的节点。

3. 经济性原则网络拓扑结构设计应该在满足性能需求的前提下尽量节约成本。

成本包括建设成本、维护成本和运营成本等。

在设计中应该合理利用已有的资源,避免不必要的设备和链路投入。

同时,应该考虑长期的可用性和可扩展性,避免频繁更换和升级。

4. 灵活性原则网络拓扑结构应该具有良好的灵活性,即能够适应不同的网络需求和变化。

随着技术的不断发展和业务的不断变化,网络需要具备适应性和可调节性。

因此,网络拓扑结构设计应该具备一定的灵活性,能够快速适应需求的变化。

二、常见的网络拓扑结构类型1. 星型拓扑星型拓扑是最简单和常见的网络拓扑结构之一。

它采用集线器或交换机作为中心节点,所有的其他节点通过链路直接连接到中心节点。

星型拓扑结构具有明确的层次关系和集中式管理,易于维护和故障排除。

然而,当中心节点发生故障时,整个网络将无法正常工作。

2. 总线型拓扑总线型拓扑是将所有节点连接到同一条总线上的结构。

节点之间相互竞争使用总线进行数据传输。

总线型拓扑结构简单,易于扩展和添加新的节点。

然而,总线作为共享资源,当多个节点同时发送数据时可能发生冲突,导致数据传输效率下降。

综合布线7个子系统设计原则

综合布线7个子系统设计原则

综合布线7个子系统设计原则
综合布线系统设计的原则是为了确保网络通信设备之间的高效连接和数据传输。

以下是综合布线系统设计的七个子系统设计原则:
1. 标准化:使用符合国际、行业或厂商标准的设备和组件,确保系统的兼容性和互操作性。

2. 可伸缩性:设计系统时要考虑未来的扩展和升级需求,以便系统能够适应日益增长的信息传输需求。

3. 冗余性:在系统设计中引入冗余以提供备用路径,以防止单点故障导致整个系统瘫痪。

4. 安全性:采用适当的安全措施,如身份验证、数据加密和防火墙等,以保护系统免受未经授权的访问和攻击。

5. 灵活性:在系统设计中考虑到不同设备和技术的变化,以便能够灵活地适应新的技术和设备的接入。

6. 管理性:设计系统时要考虑到对系统的管理和监控,包括对设备进行配置、故障诊断和性能监测等功能的支持。

7. 可靠性:选择高品质的设备和组件,确保系统能够持续稳定地运行,并能够快速识别和解决故障。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

可伸缩性原则是什么意思
系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。

下面是小编为你整理的架构师面试题,希望对你有所帮助!
从最简单的水平来看,可伸缩性就是做更多的事情。

更多的事情可以是响应更多的用户请求,执行更多的工作,或处理更多的数据。

设计软件这件事本身是复杂的,而让软件做更多的工作也有其特有的问题。

这篇文章针对构建可伸缩软件系统提出了一些原则和方针。

1. 减少处理时间增加应用所做工作数量的一个方法就是减少完成单项工作所花费的时间。

举例来说,减少处理一个用户请求所需的时间意味着你能在同样长的时间内处理更多的用户请求。

这里有一些
本原则适用的例子和一些可能的实现策略。

并置(Collocation):通过并置数据和代码,减少因获取所需数据而产生的必要开销。

缓存:如果数据和代码不能并置,就缓存数据,以减少反复取数据的开销。

池化:通过池化昂贵的资源,减少与其使用相关的开销。

并行化:通过分解问题、并行化独立的步骤,减少完成一个工作单元所需的时间。

分区处理:通过分割处理代码、并置相关的分区,尽可能将相关的处理过程集中在一起。

远程处理:减少访问远程服务所花费的时间,比如可以通过更粗粒度地划分接口。

远程还是本地是明确的设计决策,不能随意来回更动,这一点应当牢记。

还要考虑分布式计算的第一准则——不要分布你的对象。

软件开发人员总爱在不需要的地方引入抽象和层。

是的,这些概念对软件组件之间的解耦来说是很好的工具,但它们可能会增加复杂性、影响性能,尤其是在每层的数据表示之间都需要转换的情况下。

因此,减少处理时间还要注意保证抽象不要过于抽象化,并且没有过多的分层。

另外,对于我们视为理所当然的运行时服务,有必要理解其成本,因为除非它们提供了特定的服务水平协议,否则很有可能最终会成为应用中的瓶颈。

2. 分区减少单个工作单元的处理时间能达到不错的效果,但当你达到单进程方案的极限,最终还是需要对系统作水平伸缩。

在典型的Web应用中,水平伸缩可能很简单,只要加入更多的Web服务器来处理用户请求,再给它们加上负载均衡就行了。

但是,你可能会发现总体架构的某些部分会成为资源争用的焦点,因为一切东西都会在同一时间变得忙碌起来。

一个很好的例子就是所有Web服务器后端的单一数
据库服务器。

当这个单一的数据库服务器变成瓶颈时,你必须改变方法,其中一种方式就是采用分区策略。

简而言之,这涉及到将架构的单个部分分解成更小、更容易管理的部分。

将单个的元素分割成更小的部分能实现水平伸缩,这恰恰也是eBay这样的大型网站采用、以此来确保它们的架构可伸缩的技术。

分区是一个很好的解决办法,尽管你可能会发现牺牲了一致性。

至于如何分割你的系统,那要看情形而定。

真正无状态的组件能简单地作水平伸缩,将工作负载分散到所有实例上,让组件的所有实例都能有效地运行。

另一方面,如果需要维护某状态,你需要找到一种工作量分割策略能允许有状态组件的多重实例,让每个实例负责工作和/或数据的一个独特的子集。

3. 可伸缩性在于并发可伸缩性天生就和并发联系在一起;毕竟,它就是要在同样的时间内做更多的工作。

像EJB早期版本这样的技术试图提供一种简化的编程模型,鼓励我们编写单线程的组件。

遗憾的是,组件往往要依赖于其它组件,还是导致了并发问题。

如果没有考虑并发,系统中的数据会很容易被损坏。

另一方面,围绕并发做了太多的保护会导致系统实质上变成串行的,限制了伸缩的能力。

并发编程不是很难做到,在构建可伸缩系统的时候,有一些简单的原则会有所帮助。

如果你确实需要持有锁(比如本地对象、数据库对象等),试着尽可能短地持有它们。

设法减少对共享资源的争用,并尽可能是争用避开关键处理路径(比如通过异步调度工作)。

任何针对并发的设计都需要预先完成,以便能被充分地理解哪些资源可以被安全共享、哪里可能会是潜在的可伸缩性瓶颈。

4. 必须知道需求为了构建一个成功的软件系
统,你需要知道你的目标是什么、你针对什么去做。

尽管功能性需求往往是明确的,但常常会缺少非功能性需求(或系统质量需求)。

如果你真是需要构建一套高可伸缩的软件,那你首先需要调查清楚关键组件/工作流的以下特质:目标平均性能和峰值性能(即响应时间、延迟等)。

目标平均负荷和峰值负荷(即并发用户、信息量等)。

性能和可伸缩性可接受的极限。

性能也许不是最紧要的方面,但你必须尽早知道这个信息,因为处理可伸缩性的方法会由性能需求决定。

5. 持续测试理解了需求就可以开始设计和构建解决方案。

我们提出的设计、编写的代码实际上都是静态的,所以你在执行之前不能完全断定它会怎样运转。

此外,所有关于性能和可伸缩性的决策应该由证据支持的原因也在于此,而且应当从项目一开始就收集和审核这些证据,此后也要一直继续。

换句话说,就是设立贯穿系统的可度量目标,证实并度量实际的性能,并在项目的各个阶段考虑性能。

最常犯的错误之一是,我们对系统性能和可伸缩性的见解会被我们自己的经验或道听途说所混淆。

你可能要审核对工程做出的其它决策,这样做的原因之一是要满足系统的非功能性特性。

比如说,非功能性需求可能会影响你选择不使用标准,改用非主流/流行的一些东西。

非功能性需求可能会打破僵化的教条,证据胜过教条。

6. 架构先行或许对构建可伸缩的系统来说最重要的原则是,如果你需要使系统具备这样的性质,就必须预先设计出这样的性质。

很多人(包括我自己)陷入的陷阱,就是以为可以构建一个应用,它会自动地垂直伸缩(scale up)或水平伸缩(scale out),尤其是在J2EE刚出现的时候。

设计为可水平伸缩的应
用几乎总能垂直伸缩,但是设计为垂直伸缩的应用几乎不可能水平伸缩。

大多数应用能通过在更加强大的硬件上运行来垂直伸缩,但水平伸缩却是一个更为复杂的问题。

比如说,你怎么确保数据在应用实例之间保持一致性?你如何使你的单例和同步代码块跨线程工作?当然,预先思考这件事情不一定等同于做一个瀑布式的、预先的大设计。

迭代和敏捷过程都是助力,它们能提供一个框架帮助我们可以做出刚好够用的设计来解决问题。

要务实。

哦,不管我们自认为是多么擅长于设计可伸缩的应用,不要相信自己、尽早地编写/测试代码才是最好的举动。

7. 着眼于全局最后,记着要着眼于全局——看到树木之前先看看森林。

对我们来说,在细粒度代码级别调整组件确实很容易,但最终需要优化的却是作为一个整体的系统。

关注每一个环节的性能和可伸缩性,必要时牺牲局部的优化。

如果你需要使用性能分析工具确定瓶颈,不妨去做,但在对全局的性能有所认识之前先不要急于动手。

由于性能与整个系统所有等待时间的集合成反比,任何等待时间增加得比负载还快的操作都会成为问题。

尽管说了这么多,但我还想指出,如果你发现满足性能和可伸缩性目标很困难,那就有必要怀疑一下是否选择了正确的架构。

还是那句话,着眼于全局,确保有人在承担架构师的责任。

总结这篇文章针对构建可伸缩应用提出了一些原则和方针,覆盖了软件开发过程中许多不同的方面。

无论谁要构建可伸缩的系统,我能给他的最好建议就是你需要明确地考虑并设计你的系统。

可伸缩性不是魔术,它也不会无偿获得。

最后一点,更快的硬件也许能救你于一时,但还是不要依赖它为妙!关于本文
2005年年底,英国伦敦举办了针对架构师的非官方峰会,本文中的大多数原则就来源于其中一场可伸缩性讨论的一些笔记。

该峰会由Alexis Richardson、Floyd Marinescu、Rod Johnson、John Davies、Steve Ross-Talbot组织。

题为“JP Rangaswami谈企业中的开源与信息前景”的视频也来源于此峰会。

关于作者Simon是一名注重实践的软件架构师,他在Detica’的全球金融市场集团工作。

Simon专心参与的项目有桌面客户端和Web应用,也有高度可伸缩的分布式系统和面向服务的体系架构(SOA)。

他的专攻技术是Java,作为一名注重实践的权威,他被要求建议并设计解决方案;定义、交付并保证所选择的架构适合于目的,能满足非功能性需求。

Simon已经编写或与他人合著过很多Java EE Web技术相关的书籍,在数次会议上发表过演讲,并创建了Coding the Architecture——一个介绍关于软件架构实用和务实观点的网站。

阅读英文原文:Scalability Principles查看全文:/architecture/scalability-principles. html
面试题相关文章:
1.求职面试题目及答案大全
2.经典面试题
3.竞聘上岗面试题及答案
4.抗压能力面试题及参考答案
5.经典情景面试题及参考答案。

相关文档
最新文档