学习
实践
活动
工具
TVP
写文章

如何构建高扩展性网站

本篇通过阅读《高扩展性网站的50条原则》,总结出以下内容。   一方面博主没有实际的架构经验,另一方面知识面也不够宽阔,所以只能系统的总结书中的要点,并根据自己的理解做些归纳。 主要内容   本书从多个方面围绕高扩展性提出了50条建议,一个高扩展性网站会随着业务的发展、用户的增加,自由的扩展架构,从而轻松的应付网站的快速发展。下面看看本书的具体内容: ? 比如一个购物网站,缓存器热销产品数据。   26 把对象缓存放在自己的层上   使用单独的缓层,易于扩展和维护。 不合理的使用锁,会影响网站的吞吐量。   33 不要使用多阶段提交   比如两阶段提交:先表决,在提交。这回降低扩展性,因为在其提交事务完成前,是不能作其他操作的。    48 删除事务处理中的商业智能   应该把产品系统与业务系统分离,提高产品的扩展性。   避免业务扩展时,受到系统架构的限制。

46240

如何构建高扩展性网站

主要内容   本书从多个方面围绕高扩展性提出了50条建议,一个高扩展性网站会随着业务的发展、用户的增加,自由的扩展架构,从而轻松的应付网站的快速发展。下面看看本书的具体内容: ? 比如一个购物网站,缓存器热销产品数据。   26 把对象缓存放在自己的层上   使用单独的缓层,易于扩展和维护。 不合理的使用锁,会影响网站的吞吐量。   33 不要使用多阶段提交   比如两阶段提交:先表决,在提交。这回降低扩展性,因为在其提交事务完成前,是不能作其他操作的。    异步通信和消息总线   43 尽可能使用异步通信   异步通信,可以确保每个服务和层之间的独立性,这样易于早呢更加系统的扩展性和减小耦合度。    48 删除事务处理中的商业智能   应该把产品系统与业务系统分离,提高产品的扩展性。   避免业务扩展时,受到系统架构的限制。

28281
  • 广告
    关闭

    热门业务场景教学

    个人网站、项目部署、开发环境、游戏服务器、图床、渲染训练等免费搭建教程,多款云服务器20元起。

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    如何构建高扩展性网站

    本篇通过阅读《高扩展性网站的50条原则》,总结出以下内容。 一方面博主没有实际的架构经验,另一方面知识面也不够宽阔,所以只能系统的总结书中的要点,并根据自己的理解做些归纳。 主要内容   本书从多个方面围绕高扩展性提出了50条建议,一个高扩展性网站会随着业务的发展、用户的增加,自由的扩展架构,从而轻松的应付网站的快速发展。下面看看本书的具体内容: ? 比如一个购物网站,缓存器热销产品数据。   26 把对象缓存放在自己的层上   使用单独的缓层,易于扩展和维护。 不合理的使用锁,会影响网站的吞吐量。   33 不要使用多阶段提交   比如两阶段提交:先表决,在提交。这回降低扩展性,因为在其提交事务完成前,是不能作其他操作的。    参考   【1】《高扩展性网站的50条原则》

    58250

    封装与扩展性

    6.5 封装与扩展性 封装在于明确区分内外,使得类实现者可以修改封装内的东西而不影响外部调用者的代码;而外部使用用者只知道一个接口(函数),只要接口(函数)名、参数不变,使用者的代码永远无需改变。

    28530

    【大型网站技术架构笔记】(四)伸缩性、可扩展性与安全

    网站架构的伸缩性设计 一般手段有两种。一类是根据功能进行物理分离,一类是对单一功能进行集群化来实现。 应用服务器进行伸缩的方法 网站进行伸缩过程中,由于采用了集群技术,所以不可避免的要面对服务集群化后的负载均衡问题。以下有集中比较主要的服务器端负载均衡手段。 其优点在于将负载均衡交给了DNS,省去了网站自己维护的成本。同时DNS也区分了地域,如此可以较为便捷地就近实现负载均衡。 网站的可扩展设计 从系统架构层面来说,一般采用的是分布式消息队列和分布式服务。来达成较大程度的解耦和微服务化。 网站的安全性考虑 常见的攻击方式 这里主要有三种XSS、SQL注入以及CSRF。除此之外还有文件上传漏洞、路径遍历等方式。

    51231

    「可扩展性」可扩展性最佳实践:来自eBay的经验教训

    在eBay,我们每天都在争论的主要架构力量之一是可扩展性。它为我们制定的每一个架构和设计决策着色和推动。 所有这些都来自开发和运营eBay网站的人们的集体经验。 最佳实践#1:按功能划分 无论您将其称为SOA,功能分解还是简单的良好工程,相关的功能都属于一体,而不相关的功能则属于不同。 然而,无论分区方案的细节如何,一般的想法是支持数据分区和重新分区的基础设施将比不支持分区和重新分区的基础设施更具可扩展性。 对于高流量网站,我们必须选择分区容差,因为它是扩展的基础。对于24x7网站,我们通常会选择可用性。因此,即时一致性必须让位。 相反,我想说,可扩展性是功能的先决条件 - 一个“优先级为0”的要求,如果有的话。 我希望您发现这些最佳实践的描述很有用,并且它们可以帮助您以新的方式思考您自己的系统,无论其规模如何。

    31140

    拥抱变化—— 可扩展性杂谈

    本文不想探讨敏捷方面的知识,如何去拥抱变化,而是想要探讨程序的可扩展性,如何在编码过程中,以最小的代价来应对程序未来的变化。 关于可扩展性, 其本身就是一个多方面的概念集合 。 有人说程序的可扩展性必须建立在对未来需求的准确把握上,也有人说程序的可扩展性必须建立在能够对需求变化快速响应上。 可以从两个纬度对可扩展性进行讨论,一是设计可扩展性,二是编码可扩展性,前者从宏观上考虑,后者从微观上考虑,当然编码也是一种设计活动。 本文重点论述编码的可扩展性,对于设计可扩展性,是一个系统性工程,由于作者还没有达到那个高度和境界,所以不敢瞎写,本文基本上不做介绍。 如果类的实现者,在编写代码时,考虑一下可扩展性,采用消息的总长度函数,那么不论怎么添加成员变量,都不用修改消息长度,一劳永逸。

    44510

    NoSQL和数据可扩展性

    一系列一致性选项,而不仅仅是与关系数据库ACID的一致性 高可用性,一些具有分区容忍(Cassandra)和一些具有ACID一致性(ArangoDB) 商品硬件上的水平可扩展性 DynamoDB有很多用例,一般是键值存储: 具有亚秒响应时间的web服务广告 存储网站的用户首选项 存储临时“会话”信息,如购物车 使用DynmoDB作为广告投放数据库的示例架构可以在 在Amazon的网站上有一个非常简单的教程:http://docs.aws.amazon.com/amazondynamodb/latest/gettingstartedguide/GettingStarted.Download.html 注意:您可以在我的GitHub网站上找到所有代码。您必须自己下载DynamoDB并在运行这些文件之前将其解包到ext文件夹中。 您可以使用DynamoDB: 存储您的网站的用户信息和网站偏好 存储游戏数据,高分 商店购物车或其他临时数据 更多,更多 有关更多详细信息,请阅读

    1.4K60

    多态、多态的好处(扩展性

    ---- 多态的好处 提高了代码的维护性(继承保证);提高了代码的扩展性。 从而利用多态实现好的扩展性。 /* 多态的扩展性 *//* 程序输出结果: 狗吃肉 狗坐着睡 狗吃肉 狗坐着睡 狗吃肉 狗坐着睡 ---------------

    84540

    微服务扩展性和高可用-可扩展性、高可用性和性能

    chapter=1 Overview 可扩展性、高可用性和性能 术语可扩展性、高可用性、性能和关键任务对于不同的组织或组织内的不同部门来说可能意味着不同的事情。 可扩展性 它是一个系统或应用程序的属性,可以处理更多的工作,或者很容易地进行扩展,以响应对网络、处理数据、数据库访问或日益增长的文件系统资源需求。 水平扩展性 当系统进行扩展时,通过添加与现有节点功能相同的新节点,在所有节点之间重新分配负载,可以横向扩展或向外扩展。 图 1: 集群 垂直扩展性 当系统通过向节点添加处理、主内存、存储设备或网络接口来扩展以满足每个系统的更多请求时,系统会垂直或向上扩展。 SLA建立用于评估系统性能的指标,并提供可用性和可扩展性目标的定义。除非正在制定或已经存在一个SLA,否则谈论任何这些话题都没有意义。

    2.2K30

    影响JavaScript应用可扩展性因素

    作为JavaScript 开发者和架构师,必须承认并了解影响扩展性的因素。虽然不是所有JavaScript 应用都需要扩展,但总有一部分是需要的。 比如,我们很难确认某个系统不需要扩展,不需要为它的可扩展性花费时间和精力。除非我们开发的系统不需要后期维护,否则总会有对增长和成功的预期。 对于JavaScript 开发人员来说, “可扩展性的影响因素”是一个有效的工具。我们不希望一开始就过度设计,更不希望被早期设计绑住手脚,限制了可扩展性。 考虑可扩展性的影响因素可以帮助我们积极地做出准备。在应用后端等系统中,这种“扩展活动”通常是被自动处理的,可能是短暂的访问高峰。 随着软件的不断演进,我们要想成功做点什么,就必须关注“可扩展性的影响因素”。 ? 上图自上而下地展示了可扩展性的影响因素。

    15920

    xwiki功能-可扩展性和性能

    因此,它与Java一样具有扩展性。 多租户 XWiki支持在同一个JVM(即相同的webapp)运行数百甚至数千wiki的能力。

    31910

    架构设计之高可扩展性

    高可扩展性表示可通过加机器线性提高系统处理能力,承担更高流量和并发。 由于峰值的流量不可控,不可能在系统架构设计初期就考虑好机器数量以支持并发。 高可扩展性设计 拆分,把庞杂系统拆分成独立、单一职责的模块。 注意对不同类型模块,拆分原则不同。假如设计一个知乎,那么会有几个模块呢?至少5个模块。 存储层的扩展性 无论是存储数据量,还是并发访问量,不同业务模块间量级相差很大。 比如知乎,关系数据量远大于用户数据量,但用户数据的访问量却远比关系数据大。 业务拆分一定程度提升了系统扩展性,但运行久后,单一业务DB在容量和并发请求量上仍会超过单机限制。需针对DB做二次拆分。 总结 未做拆分的系统虽然可扩展性不强,但简单,无论开发、运维都无需很大精力。

    22820

    高可扩展性系统的设计

    架构设计的高可扩展性表示可通过加机器线性提高系统处理能力,承担更高流量和并发。 由于峰值的流量不可控,不可能在系统架构设计初期就考虑好机器数量以支持并发。 高可扩展性设计 拆分,把庞杂系统拆分成独立、单一职责的模块。 注意对不同类型模块,拆分原则不同。假如设计一个知乎,那么会有几个模块呢?至少5个模块。 存储层的扩展性 无论是存储数据量,还是并发访问量,不同业务模块间量级相差很大。 比如知乎,关系数据量远大于用户数据量,但用户数据的访问量却远比关系数据大。 业务拆分一定程度提升了系统扩展性,但运行久后,单一业务DB在容量和并发请求量上仍会超过单机限制。需针对DB做二次拆分。 总结 未做拆分的系统虽然可扩展性不强,但简单,无论开发、运维都无需很大精力。

    31810

    高可扩展性系统的设计

    高可扩展性设计 拆分,把庞杂系统拆分成独立、单一职责的模块。 注意对不同类型模块,拆分原则不同。假如设计一个知乎,那么会有几个模块呢?至少5个模块。 存储层的扩展性 无论是存储数据量,还是并发访问量,不同业务模块间量级相差很大。 比如知乎,关系数据量远大于用户数据量,但用户数据的访问量却远比关系数据大。 text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMzNTg5NTEw,size_1,color_FFFFFF,t_70#pic_center] 业务拆分一定程度提升了系统扩展性 业务层扩展性 一般从三个维度考虑业务层的拆分方案 业务纬度 重要性纬度 请求来源纬度 首先需把相同业务服务拆分成单独业务池,比方知乎,可按业务维度拆分成用户池、内容池、关系池、评论池、点赞池和搜索池。 总结 未做拆分的系统虽然可扩展性不强,但简单,无论开发、运维都无需很大精力。

    33622

    浅析SAP Subscription Billing可扩展性

    通常来说,任意一个标准产品都不可能满足所有客户的实际需求;因此,随着客户越来越多,产品的可扩展性显着尤其重要。这篇文章简单介绍一下Subscription Billing的可扩展性功能。 1 总体来讲,Subscription Billing的可扩展性可分为两个方面:字段扩展和流程扩展。 字段扩展,通过Custom References实现。 关于SAP Subscription Billing可扩展性的具体细节,大家可以参考SAP官方help document。 Java里面继承的关键字extend,其名词形式就是extensibility,中文翻译就是扩展性。所以,猜想Java语言的设计者们在设计Java语言的时候,认为继承就是一种扩展形式。

    43120

    货币、区块链和社会扩展性

    相反,比特币成功的秘诀在于:用大量的资源消耗和很差的计算扩展性“购买”更有价值的东西——社会扩展性。社会扩展性是指一个组织的能力——一种关系或shared endeavor(协作?)。 匹配可能是互联网最擅长的一种社会扩展性。 鉴于互联网在社会扩展性方面的主要优势是匹配,那么区块链的在社会扩展性方面的一个直接优势是降低对信任的需要(信任成本最小化)。 货币通过增加交易机会来促进社会扩展性。 Gox(兑换比特币的专门网站),没有这种官僚政治,它不会成为值得信赖的金融中介。 计算机和网络很便宜, 扩展计算资源需要很便宜的额外资源。

    10730

    3种方式提升云可扩展性

    在亚马逊云服务中部署被盛赞为是一个很好的方式来实现高扩展性并且你只需要支付你所使用的云计算机性能即可。那么,如何从这项技术中获得最佳的扩展性呢? 1. 在实现高可用性的同时,你也可以通过将大部分的SELECT操作流量发送到另一个服务器来获得可扩展性

    52670

    系统架构设计(3)-可扩展性

    扩展性,描述系统应对负载增加的能力。它不是衡量一个系统的一维指标, 谈论“系统X是可扩展 ”或“不扩展”无太大意义。 相反,讨论可扩展性通常得考虑:“若系统以某种方式增长,应对措施有啥”, “该如何添加计算资源来处理额外的负载” 3.1 描述负载 先得简洁描述系统当前的负载,才能更好讨论后续的增长问题(例如负载加倍,意味啥 所以,为了测试系统的可扩展性而人为地产生负载时,负载生成端要独立于响应时间来持续 发送请求。若客户端在发送请求之前总是等待先前请求的完成,就会在测试中人为缩短服务器端的累计队列深度,带来测试偏差。 3.3 应对负载增加的方案 现在真正讨论可扩展性了,当负载参数增加时, 如何继续保持良好性能呢。 实践中的百分位数 后台服务,若一次完整的服务包含多次请求调用,此时高百分位数指标尤为重要。 若这些假设最终发现是错误的,则可扩展性的努力就白费了,甚至会出现与设计预期完全相反情况。对初创公司或尚未定型产品,快速迭代推出产品功能往往比技入精力来应对不可知的扩展性更重要。

    19120

    Envoy 基础及其可扩展性要领

    Tetrate 工程师暨 Envoy 资深维护者周礼赞在 2019 年 KubeCon 巴塞罗那的讲台上,向听众讲解了 Envoy 的基本概念 [1] 和 深入探讨了它的可扩展性 [2]。 服务网格解决了在大型分布式系统中与可观察性和网络相关的诸多操作问题,而它的可扩展性正好能应用在多种使用场景上。 可扩展性是 Envoy 的一项重点功能。 v=vsGFiOHoMYk&list=PLm51GPKRAmTlVRWGOgP_X_NqOXI4Y_KMO&index=3 [2] 深入谈讨了它的可扩展性: https://www.youtube.com

    28110

    扫码关注腾讯云开发者

    领取腾讯云代金券