程序的伸缩性
如果我们研究这些大型消费者业务应用程序采用的架构原理,那么我们可以得出以下结论:
- 所有大型消费者业务应用程序均已构建并利用云计算
- 应用程序是结合使用开源产品和平台来构建的
- 创建当前解决方案集不符合要求或无法扩展的解决方案(例如,HipHop,Hadoop,ChaosMonkey等)
- 在社区内不断进行知识共享(FB / Twitter / Google开源了许多内部产品)
从应用程序可伸缩性的角度来看,出现了以下关键体系结构模式,这些模式用于扩展应用程序
- 无状态应用程序 –现代Web应用程序维护状态,这意味着它们在上次请求的过程中会记住您所做的事情,并且在会话中会记住所有这些数据。 应用程序的“有状态”性质意味着,如果保持该状态的服务器出现故障,则整个用户状态都会丢失。 跨服务器节点同步用户会话数据或保留在数据存储中的传统技术无法很好地扩展。 为了克服此缺点,创建服务器不维护状态的无状态应用程序的整个概念。 该应用程序使用cookie并利用RESTful API来改善用户体验。 诸如Play Framework,Node.js,Vertx.io之类的较新框架都促进了这种无状态应用程序的开发,并且可以很好地随着用户负载的增加而扩展。 用来减轻会话状态的另一个选项是基于高吞吐量内存的键值存储,这在无状态节点之间很常见。
- 数据分片 –规模遇到的另一个问题是数据库服务器的负载不断增加。 DB Server确实采用了诸如“主/从”或“集群”技术之类的技术,再加上强大的功能强大的盒子,但超过100百万的用户,这些技术也失败了。 此外,昂贵的硬件和软件许可使传统的DB选项非常昂贵。 因此,公司已经使用MySQL作为基础,并围绕该MySQL创建了许多解决方案/拓扑。 这些技术之一是数据分片 。 数据分片是数据的水平分区,这意味着表的行是单独保存的。 这种分区方法有许多优点。 由于将表划分并分配到多个服务器中,因此减少了每个数据库中每个表的总行数。 这样可以减小索引大小,从而通常可以提高搜索性能。 可以将数据库分片放置在单独的硬件上,并且可以将多个分片放置在多台计算机上。 这使数据库在大量机器的分布,使数据库性能是分布在多台机器,大大提高了整体performance.Many新的非关系型数据库(俗称NoSQL数据库),如卡桑德拉 ,MongoDB的和HBase的有以数据库分片为主要功能创建的。
- 使数据更接近用户(缓存) –缓存已被大多数Consumer Business Apps采用并很好地使用。 像memcache这样的开源产品提供了跨层(Web层/应用层和数据层)的缓存选项。 Memcache提供了传统缓存解决方案(一致性,兵马俑)的可靠替代方案。 此外,NoSQL解决方案使用缓存引擎来加快数据库的读写操作。 Couchdb使用内存缓存提供内存中的读/写解决方案。
- 服务提供商/消费者模型 –出现的另一种模式是服务提供商和消费者。 它是SOA模型的派生产品,但更加精简和简单。 业务功能通过JSON数据格式的RESTful API作为一组服务公开。 表示层是使用这些服务来建立用户体验的消费者。 构建服务和提供者的技术可以完全分开。 根据最适合用例选择技术 。 合同仅由服务版本和定义强制执行。 前端通常使用PHP或Ruby在rails上构建。 服务是使用Scala,Akka,C ++,Java等构建的。
为什么企业要看这些模式?
- 企业已开始大体上采用云(公共/私有)。 弹性缩放意味着实时响应不断变化的负载模式。 在缺乏扩展能力的情况下,对云的所有投资都是浪费
- 传统的基于CPU / Core的许可模型在云世界中被证明是昂贵的。 企业需要采用许可包随附的OSS框架/解决方案
- 用户的期望提高了几个等级。 对企业应用程序进行了比较,并期望与其他Internet Scale应用程序具有相同的弹性和性能。
- 用于企业应用程序的扩展模型(添加更多CPU)会带来额外的资本支出。 依靠商品服务器或可以在混合云上运行的横向扩展模型(添加更多小型服务器)正变得更具成本效益的解决方案
- 企业正在走向全球,这要求系统能够24X7全天候可用。 当前紧密耦合的应用程序设计不适用于可伸缩性模式
参考: 应用程序可伸缩性:在Tech Spot博客上,我们的JCG合作伙伴 Munish K Gupta 对于企业应用程序仍然难以捉摸 。
翻译自: https://www.javacodegeeks.com/2012/08/application-scalability-still-elusive.html
程序的伸缩性