pcl获取点云中的每个点_在云中扩展服务器的11个技巧

我们公司最近开始为具有大量用户群的客户构建应用程序。 这意味着我们需要摆脱传统的服务器设置，开始扩展服务器以一次处理数百个请求。 反过来，这要求我学习传统服务器设置与当今更现代方法之间的区别。

迈向云

在过去（几​​十年前）的日子里，为您的运营增加更多的服务器空间包括让某人安装硬件，然后让人们为您维护该硬件。 不仅存在购买和维护硬件的成本，而且还存在服务器上物理空间的成本。 由于每个服务器的空间都有限，因此快速增长可能会造成问题。

今天，只需单击几下鼠标，您便可以在云中获得一台服务器：基本上，其他人将为您维护硬件，并且您可以在许多英里之外配置新硬件。 您还可以添加许多服务器，而无需任何其他资源。 这使扩展比以前容易得多。

传统设置

传统的安装程序由承载应用程序的单个服务器以及单独的数据库服务器组成。 此设置通常适用于小型项目和不需要扩展的项目。 有时候，过度优化设置没有意义。 我们公司通过这种方式主持了许多项目。

“我们正在将一些较大的项目迁移到更现代的基础架构中，这将使我们的应用程序可以优雅地扩展。 ”

建立可扩展的基础架构

我们正在使用可扩展的基础架构来创建可扩展的应用程序。 为了成为一家更出色的开发公司，我们决定采用Heroku的十二要素应用程序方法，该方法专门用于构建SaaS（软件即服务）应用程序。 总而言之，该过程可通过将各个部分分开来确保您的应用程序易于扩展。 您应该能够解决一个难题，而不必担心会破坏一切。 换句话说，您的资源不应相互依赖，以至于移动或更改一个组件都会破坏您的基础架构。

十二要素应用程序方法易于遵循。 并非我们所有的项目都在那儿，但是我们正在努力尽可能地接近。 扩展时，请特别注意可处置性的因素9：通过快速启动和正常关闭来最大化鲁棒性。

最佳实践

您可以尝试对所有内容进行优化，也可以高效地花费时间，并努力取得低谷的成果，以使您的应用达到80％的目标。 我们的首席基础架构工程师喜欢80/20的方法：20％的工作将使您达到目标的80％。 本节研究了可以帮助您接近所需位置的简单事物。 让我们看一些例子。

1.设置负载平衡

方案A ：您的网页出现在Reddit的首页上，突然之间您获得了疯狂的访问量。 你是做什么？

这是负载平衡器和运行多个服务器的地方。 将负载均衡器视为空中交通管制员。 它接收所有传入流量并将其定向到可以处理该流量的服务器。 它还知道，如果服务器出现故障，则不应向该方向发送任何流量。 就像黑盒子一样对待负载均衡器：您不必担心负载均衡是如何完成的，但是请放心，它会完成。 新的传入流量不会最终击中服务器，因为负载平衡器会将新流量定向到可以处理的服务器。

方案B ：一场自然灾害袭击了整个东海岸。 您的应用程序将如何React？

如果发生这种情况，那么一切都会很好，因为您将在各个可用区域中启动服务器，对吗？ 您的负载均衡器将知道您在东海岸的所有服务器都已关闭，并且应该开始向西海岸的服务器发送邮件。

2.保持不同的环境相同

我们公司有四个不同的环境：本地，开发，暂存和生产。 我们试图使它们尽可能彼此相似。 这样可以避免任何可能归因于环境变量的问题。 例如，重要的是，不要依赖开发环境中生产中无法访问的任何内容。

3.使用无状态服务器

通常，不要将需要访问的信息存储在Web应用程序的服务器中。 服务器的每个副本都应该看起来相同，并且您不需要将信息从一台服务器复制到另一台服务器。 理想情况下，您将为应用程序服务器创建一个映像，并能够使用该映像启动许多其他服务器。 将数据库和应用程序服务器分开。

4.经常停止服务器

紧急演习有时看起来很愚蠢，但实践却很完美。 至关重要的是，每个人都知道在紧急情况下如何做出React，并实际练习了如果真的发生了怎么办。 如果发生火灾，人们可能会知道应该前往紧急出口，但是您不希望他们忘记如果实际发生火灾，紧急出口会是什么样。

服务器问题也是如此。 您可能认为自己已经为最坏的情况做好了准备，但是除非您知道系统在服务器出现故障时会如何做出实际React，否则您可能并没有为无法使服务器宕机的情况做好准备。 这就是为什么使用无状态服务器至关重要的原因。 不要连接到服务器-经常将它们关闭。 您应该能够停止然后重新启动服务器，而不必担心会破坏某些东西。

您要放心，因为您的一些服务器可能会在半夜关闭，并且在您能够在早上解决问题之前，系统就可以正常运行。

5.零瓶颈

瓶颈要求您找出导致应用程序运行缓慢的真正原因。 您不想开始追寻可能不是实际问题的事物； 寻找最大的瓶颈，并花时间尝试解决这些问题。

我们在公司使用Django，因此我们喜欢​​使用Django Debug Toolbar来确定实际上使我们变慢的原因。 降低速度可能是由于查询数据库的次数过多而导致的。 摆脱瓶颈可以大大帮助您确保应用程序性能更好。

6.运行后台任务

如果您可以推迟做某事直到以后，请考虑使用后台任务。 例如，您可能需要进行昂贵的API调用，因此您无需立即将信息返回给用户。 我们使用Celery Task Queue管理可以推迟到以后的任务。 有时候，我们不需要用户获得即时反馈，因此，只要有可能，我们就会将该任务分担给我们可以给予它应有注意的时间。

7.缓存您所能

如果您的网站提供大量静态内容，那么缓存肯定会为您加快速度。 一遍又一遍访问您的网站的用户将只需要加载新内容。 如果自他们上次访问您的网站以来没有太大变化，则加载时间将非常快。

缓存的方式有几种：浏览器缓存和使用内容分发网络（CDN），该网络可提供具有高可用性和高性能的内容。 您可以在资产上设置到期日期，因此最好对不经常更改的事物（而不是经常更改的事物）设置更长的到期日期。 例如，徽标图像可能很少更改，而您HTML页面将更频繁地更改。 基本上，缓存无需更改硬件即可帮助提高性能。

8.设置自动缩放

现在，您可以通过单击按钮来启动新服务器。 借助如此轻松地启动和销毁服务器的功能，您可以确保始终有足够的服务器来处理您要处理的流量。 您甚至可以为服务器设置时间，使其在高流量时间内启动，而在低流量时间内关闭。 如果您碰巧知道用户的模式，则可以在任何给定时间扩展和缩减拥有的服务器数量。

9.让整个团队参与进来

您团队中的每个人都可以在一定程度上帮助您提高性能和扩展规模。 每个人都可以做一些事情，以确保您的团队更轻松地实施保护措施，以确保您的应用程序能够处理流量高峰或持续不断的大量流量。

确保团队中的每个人都在问正确的问题。 例如，是否确实需要某些功能，或者仅仅是具有某些功能？

10.抽出时间进行测试

建立时间线以测试基础架构很重要。 从第一天开始，并不是所有事情都会顺利进行。 您需要对应用程序进行压力测试，并且需要在生产环境中查看您的应用程序。 如果您的时间轴中未内置测试应用程序以进行扩展的功能，则您可能会发现巨大的问题，这些问题的修复会导致延迟。

11.考虑容器

我们公司正计划采用一种更现代的方法来处理我们的Web应用程序。 理想情况下，我们希望将基础架构转换为使用容器。

听说容器时，我想到的第一件事就是想知道容器与虚拟机之间的区别是什么。 他们听起来真的很像我。 好吧，事实证明，在保持应用程序可扩展性方面，容器比虚拟机更好。 它们就像虚拟机一样，但是缺少复制硬件的全部功能。 现在，我们可以运行一个Linux实例，并让我们的容器位于顶部，它们共享相同的操作系统。 因此，对于扩展应用程序而言，容器似乎是一种重量更轻，更具成本效益的解决方案。

结论

尽管这些做法可能无法解决所有问题，但它们将帮助您开始着手进行扩展，并在需要处理数亿用户时为您提供良好的基础。

为确保您拥有高度可扩展的应用程序基础结构，应执行以下操作：

• 使用负载平衡器。
• 使用自动缩放。
• 不要害怕随机停止服务器。
• 修复需要修复的内容，而不是您认为应该修复的内容。
• 确保有时间测试应用程序并解决所有问题。

---

翻译自: https://www.ibm.com/developerworks/cloud/library/11-tips-for-scaling-servers-in-the-cloud/index.html