网站推广--html关键词代码解说,线条类网站,网站建设 广州网站建设专业公司,wordpress的关键字哪里设置最近#xff0c;阅读了Will Larson的文章Introduction to Architecting System for Scale#xff0c;感觉很有价值。作者分享了他在Yahoo!与Digg收获的设计可伸缩系统的架构经验。在我过往的架构经验中#xff0c;由于主要参与开发企业软件系统#xff0c;这种面向企业内部…最近阅读了Will Larson的文章Introduction to Architecting System for Scale感觉很有价值。作者分享了他在Yahoo!与Digg收获的设计可伸缩系统的架构经验。在我过往的架构经验中由于主要参与开发企业软件系统这种面向企业内部的软件系统通常不会有太大的负载量太多的并发量因而对于系统的可伸缩性考虑较少。大体而言只要在系统部署上考虑集群以及负载均衡即可。本文给了我很多启发现把本文的主要内容摘译出来并结合自己对此的理解。 Larson首先认为一个理想的系统对于容量Capacity的增长应该与添加的硬件数是线性的关系。换言之如果系统只有一台服务器在增加了另一台同样的机器后容量应该翻倍。以此类推。这种线性的容量伸缩方式通常被称之为水平伸缩“Horizontal Scalability”。 在设计一个健壮的系统时自然必须首要考虑失败的情况。Larson认为一个理想的系统是当失去其中一台服务器的时候系统不会崩溃。当然对应而言失去一台服务器也会导致容量的响应线性减少。这种情况通常被称为冗余“Redundancy”。 负载均衡 无论是水平伸缩还是冗余都可以通过负载均衡来实现。负载均衡就好似一个协调请求的调停者它会根据集群中机器的当前负载合理的分配发往Web服务器的请求以达到有效利用集群中各台机器资源的目的。显然这种均衡器应该介于客户端与Web服务器之间如下图所示 本文提到了实现负载均衡的几种方法。其一是Smart Client即将负载均衡的功能添加到数据库以及缓存或服务的客户端中。这是一种通过软件来实现负载均衡的方式它的缺点是方案会比较复杂不够健壮也很难被重用因为协调请求的逻辑会混杂在业务系统中。对此Larson在文章以排比的方式连续提出问题以强化自己对此方案的不认可态度 Is it attractive because it is the simplest solution? Usually, no. Is it seductive because it is the most robust? Sadly, no. Is it alluring because it’ll be easy to reuse? Tragically, no. 第二种方式是采用硬件负载均衡器例如Citrix NetScaler。不过购买硬件的费用不菲通常是一些大型公司才会考虑此方案。 如果既不愿意承受Smart Client的痛苦又不希望花费太多费用去购买硬件那就可以采用一种混合Hybird的方式称之为软件负载均衡器Software Load Balancer。Larson提到了HAProxy。它会运行在本地需要负载均衡的服务都会在本地中得到均衡和协调。 缓存 为了减轻服务器的负载还需要引入缓存。文章给出了常见的对缓存的分类分别包括预先计算结果precalculating result例如针对相关逻辑的前一天的访问量、预先生成昂贵的索引pre-generating expensive indexes例如用户点击历史的推荐以及在更快的后端存储频繁访问的数据的副本例如Memcached。 应用缓存 提供缓存的方式可以分为应用缓存和数据库缓存。此二者各擅胜场。应用缓存通常需要将处理缓存的代码显式地集成到应用代码中。这就有点像使用代理模式来为真实对象提供缓存。首先检查缓存中是否有需要的数据如果有就从缓存直接返回否则再查询数据库。至于哪些值需要放到缓存中呢有诸多算法例如根据最近访问的或者根据访问频率。使用Memcached的代码如下所示 key user.%s % user_id
user_blob memcache.get(key)
if user_blob is None:user mysql.query(SELECT * FROM users WHERE user_id\%s\, user_id)if user:memcache.set(key, json.dumps(user))return user
else:return json.loads(user_blob) 数据库缓存 数据库缓存对于应用代码没有污染一些天才的DBA甚至可以在不修改任何代码的情况下通过数据库调优来改进系统性能。例如通过配置Cassandra行缓存。 内存缓存 为了提高性能缓存通常是存储在内存中。常见的内存缓存包括Memcached和Redis。不过采用这种方式仍然需要合理的权衡。我们不可能一股脑儿的将所有数据都存放在内存中虽然这会极大地改善性能但比较起磁盘存储而言RAM的代价更昂贵同时还会影响系统的健壮性因为内存中的数据没有持久化容易丢失。正如之前提到的我们应该将需要的数据放入缓存通常的算法是least recently used即LRU。 CDN 提高性能降低Web服务器负载的另一种常见做法是将静态媒体放入CDNContent Distribution Network中。如下图所示 CDN可以有效地分担Web服务器的压力使得应用服务器可以专心致志地处理动态页面同时CDN还可以通过地理分布来提高响应请求的性能。在设置了CDN后当系统接收到请求时首先会询问CDN以获得请求中需要的静态媒体通常会通过HTTP Header来配置CDN能够缓存的内容。如果请求的内容不可用CDN会查询服务器以获得该文件并在CDN本地进行缓存最后再提供给请求者。如果当前网站并不大引入CDN的效果不明显时可以考虑暂不使用CDN在将来可以通过使用一些轻量级的HTTP服务器如Nginx为静态媒体分出专门的子域名如static.domain.com来提供服务。 缓存失效 引入缓存所带来的问题是如何保证真实数据与缓存数据之间的一致性。这一问题通常被称之为缓存失效Cache Invalidation。从高屋建瓴的角度来讲解决这一问题的办法无非即使更新缓存中的数据。一种做法是直接将新值写入缓存中通常被称为write-through cache另一种做法是简单地删除缓存中的值在等到下一次读缓存值的时候再生成。 整体而言要避免缓存实效可以依赖于数据库缓存或者为缓存数据添加有效期又或者在实现应用程序逻辑时尽量考虑避免此问题。例如不直接使用DELETE FROM a WHERE…来删除数据而是先查询符合条件的数据再使得缓存中对应的数据失效继而根据其主键显式地删除这些行。 Off-Line处理 这篇文章还提到了Off-Line的处理方式即通过引入消息队列的方式来处理请求。事实上在大多数企业软件系统中这种方式也是较为常见的做法。在我撰写的文章《案例分析:基于消息的分布式架构》中较为详细地介绍了这种架构。在引入消息队列后Web服务器会充当消息的发布者而在消息队列的另一端可以根据需要提供消费者Consumer。如下图所示。对于Off-Line的任务是否执行完毕通常可以通过轮询或回调的方式来获知。 为了更好地提高代码可读性可以在公开的接口定义中明确地标示该任务是On-Line还是Off-Line。 引入Message Queue可以极大地缓解Web服务器的压力因为它可以将耗时较长的任务转到专门的机器上去执行。 此外通过引入定时任务也可以有效地利用Web服务器的空闲时间来处理后台任务。例如通过Spring Batch Job来执行每日、每周或者每月的定时任务。如果需要多台机器去执行这些定时任务可以引入Spring提供的Puppet来管理这些服务器。Puppet提供了可读性强的声明性语言来完成对机器的配置。 Map-Reduce 对于大数据的处理自然可以引入Map-Reduce。为整个系统专门引入一个Map-Reduce层来处理数据是有必要的。相对于使用SQL数据库作为数据中心的方式Map-Reduce对可伸缩性的支持更好。Map-Reduce可以与任务的定时机制结合起来。如下图所示 平台层 Larson认为大多数系统都是Web应用直接与数据库通信但如果能加入一个平台层Platform Layer或许会更好。 首先将平台与Web应用分离使得它们可以独立地进行伸缩。例如需要添加一个新的API就可以添加新的平台服务器而无需增加Web服务器。要知道在这样一个独立的物理分层架构中不同层次对服务器的要求是不一样的。例如对于数据库服务器而言由于需要频繁地对磁盘进行I/O操作因此应保证数据库服务器的IO性能如尽量使用固态硬盘。而对于Web服务器而言则对CPU的要求比较高尽可能采用多核CPU。 其次增加一个额外的平台层可以有效地提高系统的可重用性。例如我们可以将一些与系统共有特性以及横切关注点的内容如对缓存的支持对数据库的访问等功能抽取到平台层中作为整个系统的基础设施Infrastructure。尤其对于产品线系统而言这种架构可以更好地为多产品提供服务。 最后这种架构也可能对跨团队开发带来好处。平台可以抽离出一些与产品无关的接口从而隐藏其具体实现的细节。如果划分合理并能设计出相对稳定的接口就可以使得各个团队可以并行开发。例如可以专门成立平台团队致力于对平台的实现以及优化。 原文链接:http://agiledon.github.io/blog/2013/02/27/scalability-system-architecture-lessons/转载于:https://www.cnblogs.com/fuwanhong/archive/2013/05/31/3110646.html
