构建meteor应用程序_构建高性能应用程序

构建meteor应用程序

性能是一个单词，用于描述应用程序性能时描述多个方案。 当有人说时，我需要一个高性能应用程序； 这可能意味着以下任何/全部：

• Web等待时间短（意味着页面加载时间短）
• 可以为越来越多的用户提供服务的应用程序（可扩展性）
• 不会失败的应用程序（高度可用或持续可用）

对于以上每个方面，作为一名架构师，您都需要更深入地挖掘以发现用户的要求。 随着云的出现，每个CIO都希望构建能够满足上述所有方案的应用程序。 随着弹性计算的到来，人们倾向于认为，通过将硬件投入应用程序，我们可能能够实现所有上述目标。

有时，用于实现上述方案的技术是不同的，并且重要的是找到满足上述目标的解决方案的正确方法。 我们将研究一些可以帮助我们实现目标的通用技术

延迟贡献者

应用程序分层–导致延迟的最大因素之一是应用程序分层。 WebServer-> Application Server->数据库以及数据序列化/反序列化的跃点是造成总体延迟的最大因素。 将Web和应用程序层放在同一盒子中，甚至在同一JVM中，可以帮助减少网络延迟因素。 可以在Web层和应用程序层之间的应用程序代码中进行逻辑分隔，但不必进行物理分隔。 使用具有Web / App层的Spring容器可以帮助实现相同目的。 如果应用程序正在使用SOA并进行多个Web服务或JMS消息调用，则网络延迟和数据序列化将再次增加延迟。 诸如IBM Datapower XML Accelerators之类的解决方案可用于减少XML开销。 同样，应用程序可以使用Solace消息路由器来加快消息传递速度。

使数据更贴近应用程序 –数据需要更贴近应用程序，这样可以减少进行所有这些数据库连接调用和从DB获取数据的过程。 应用程序可以缓存数据以减少对DB的调用。 还可以使用诸如memcached / ehCache之类的缓存服务器在Web /应用程序层上缓存数据。 Web层可以缓存静态HTML片段/图像/ javascript / CSS文件等数据。 应用程序层可以缓存非事务性数据（如查找映射）。 诸如Hibernate之类的映射工具也支持数据缓存。 如果它是Internet Web应用程序，则还可以利用CDN（内容交付网络）/边缘网络（如Akamai）来加快静态内容的交付。

磁盘I / O –应用程序性能链中的另一个薄弱环节是磁盘I / O。 克服磁盘I / O限制的一种方法是将数据也保留在内存中。 在内存数据库（如Volt DB或Solid DB或Oracle TimesTen）中，XTP解决方案（如Oracle一致性，IBM eXtreme Scale，GigaSpaces eXtreme应用程序平台）可用于加快应用程序性能。

优化的硬件 –托管应用程序的硬件也可以进行调整以减少延迟。 诸如10G / 20G网络，光纤通道，低延迟交换机，SSD（固态驱动器）之类的优化（不使用虚拟化）可以确保减少应用程序延迟。

传输机制 –有时，传输机制还会增加应用程序延迟。 例如，安全通信（例如https）可能会增加延迟，并在接收端解密数据会产生额外的开销。 一种方法是在负载均衡器/防火墙上卸载SSL。

最后，您需要衡量所有问题以解决瓶颈。 一旦解决了明显的瓶颈，就可以开始研究类似的问题–缓存颠簸，算法不佳，数据膨胀，错误的尺寸设计等，以挤压出那种性能。 提到的所有技术可能不适用于所有场景，架构师需要根据等待时间要求进行呼叫。

应用可扩展性

可伸缩性是指应用程序以有效方式处理不断增长的数据量和并发性而不会影响性能的能力。 需要注意的重要一点是，可伸缩性不应以应用程序性能为代价。 一些可以帮助扩展应用程序的技术

无状态应用程序/服务 -应用程序应将其状态存储在某个集中式存储库中，但应用程序本身应为无状态。 这意味着在本地文件系统上不存储数据或状态。 无状态应用程序允许添加任意数量的应用程序实例，以适应不断增长的需求。 但是很快，集中式存储库开始成为瓶颈。 随着数据的不断增长，像（RDBMS）这样的存储库可能开始崩溃。 解决此问题的一种方法是最小化数据库中的可变状态。 为了处理这种情况，需要应用诸如数据分片之类的技术。 管理数据库中写争用的另一种方法是查看对某些或所有应用程序数据使用NoSQL数据存储的可能性。

负载平衡 –随着流量开始上升，应用程序可以通过添加其他服务器实例来为请求提供服务来处理其他负载。 负载平衡器将确保所有服务器都无法正常工作，超出规定的负载，并且应在负载上升时自动添加新实例（自动扩展）。 还可以使用Master-Master拓扑或Master-Slave（具有分区读写数据）等技术为数据库增加负载平衡，以处理额外的负载。 但是，如果数据的传输范围为PB，则需要使用具有数据复制技术的数据分片。 内存中数据网格体系结构也可以用于缩放数据。

容错/动态可发现元素 –处理在大型集群中运行的应用程序时，避免手动干预非常重要。 例如，当应用程序负载达到定义的负载时，应用程序监视应该能够添加一个新实例，并且负载平衡器应该能够识别出该实例以利用它。 同样，当数据分片时，应用程序应该能够识别并查找要连接的新IP。 同样，如果应用程序无法连接到特定资源，则应用程序应足够智能以识别故障并尝试访问备用资源可用性。 对于所有此类可由应用程序利用的容错方案，应用程序将需要具有中央元数据存储库。

应用程序可用性

应用程序的可用性很大程度上取决于可伸缩性。 以下因素会影响应用程序的可用性

冗余 –应用程序需要可扩展，以便能够补偿任何实例（无论是硬件还是软件）的丢失。 冗余需要在软件，硬件，电源甚至数据中心级别的所有层上构建。 即使数据中心消失了，用户也应该能够访问该应用程序。 很多时候，冗余程度和停机时间是解决方案投入资金的一个因素。 请记住，在当今技术的背景下，有些问题无法解决。 例如跨地理位置分开的数据中心的实时数据镜像或数据同步。

容错 –应用程序必须是容错的（例如重试机制），以确保它可以利用动态分配的资源来保持运行。

监视/测试 –应用程序可用性的另一个被忽略的因素是应用程序监视。 如果未正确监视应用程序，则可能无法检测到中断，从而导致应用程序不可用。 监视整个应用程序堆栈并采取纠正措施的能力非常重要。 此功能是在一段时间内构建的。 一旦应用程序具有监视，自动扩展功能，进行测试以确保其正常工作也很重要。 Netflix使用的诸如Chaos Monkey之类的东西非常有帮助。

配置数据 –任何需要连续可用的应用程序都必须能够使用配置运行。 例如，如果应用程序引入了新的服务接口，则应用程序应具有使用新接口或继续使用旧接口的能力。 当推出新功能/服务时，这个因素变得非常重要，而所有这些功能/服务都无法立即推出。

参考： Tech Spot博客上的JCG合作伙伴 Munish K Gupta提供了构建高性能应用程序的信息。

翻译自: https://www.javacodegeeks.com/2012/04/building-high-performance-applications.html

构建meteor应用程序