PHP开发者构建分布式应用需警惕的八大误区
Peter Deutsch在1997年提出了七个分布式计算的误区，后来James Gosling（Java之父）又补充了一个。这些误区对PHP开发者来说至关重要，因为我们每天都在构建分布式应用：mashup、与SOAP和REST服务交互的应用、通过Facebook、Google或Twitter API进行用户身份验证、从远程数据库和缓存服务检索信息等等。我们构建的正是分布式计算应用。因此，理解这八个误区及其影响至关重要。
关键要点:
这显然是不正确的。尽管自1995年以来，网络延迟降低，带宽显着增加，但说网络可靠是错误的。假设我们搭建了一个简单的应用程序，它不使用太多服务——一个使用MySQL作为后端的PHP应用程序。似乎没什么问题。然而，假设我们后来决定使用像Xeround这样的MySQL托管服务提供商来满足我们的数据库需求。即使具有良好的可扩展性和高可用性，如果他们的系统出现问题怎么办？如果他们的基础设施遭受DDoS攻击或由于内部问题而出现停机怎么办？我们经常听说99.999%的正常运行时间，但这仍然不是100%。随着服务的激增和当今通常高度可用的带宽，很容易忘记没有什么是完美的。您如何在应用程序中考虑服务的故障？
虽然延迟可能很低，确实比几年前低得多，但它永远不会为零。引用Arnon Rotem-Gal-Oz在其《分布式计算误区详解》文章中的话：以大约300,000公里/秒（3.6 * 10E12 teraangstrom/两周）的速度，即使处理是实时完成的，从欧洲到美国再返回的ping也至少需要30毫秒。
这是坏事吗？好坏参半。根据我们应用程序的结构和可用的资源，我们可以很大程度上减轻延迟问题。我们可以使用Amazon Web Services之类的服务托管我们的应用程序，并利用S3，以便我们的数据位于世界各地的多个区域，使其更接近我们的最终用户，并减少网络上应用程序的延迟。但即使我们可以减少延迟，我们也无法消除它。我们可以采用一系列方法和架构来减少它对我们的影响，但无论我们做什么，它都将始终存在。您在设计应用程序时是否考虑过这一点？
带宽真的可以无限吗？如果是这样，无限的代价是什么？当我们考虑到网络正日益转向移动化时，一切旧事物都焕发了新生。我并不是说我们从拨号上网的速度开始重新开始，更新的4G网络比早期的2G和3G网络快得多。但是，即使是它们的峰值数据速率目前也低于标准宽带连接。此外，随着移动宽带的普及，寻求使用我们服务的潜在用户数量（我们都想受欢迎，至少取得Facebook的一些成功）正在以惊人的速度增长。考虑来自mobithinking的这些统计数据：
鉴于此，可以公平地说，尽管带宽速率及其在世界范围内的普及率正在提高，但用户增长率却抵消了这一点。更进一步说，随着移动宽带提供的巨大灵活性，自然而然地出现了明确的临时服务消耗。您是否为服务上潜在的巨大负载做好了准备？你能处理这种可用性带来的峰值吗？
我认为无需过多细节就可以公平地说，这是，并且将永远是错误的。如果您有任何疑问，也许您应该与LinkedIn或eHarmony成员谈谈。当我们设计和部署我们的应用程序时，我们在应用程序的托管位置（例如Rackspace、PagodaBox或cloudControl）以及应用程序本身的设计中，对安全性投入了多少精力？根据SecurityAffairs，Prolexic报告：
鉴于网络并不安全，我们需要确保我们正在将良好的安全实践作为当然的事情来使用。鉴于Chris Shiflett的博客、Essential PHP Security、PHP安全联盟等来源的大量良好建议，很难不知道如何在我们的应用程序核心融入安全性以及为什么要这样做。您的安全实践是什么？您是否评估了您部署的供应商？
不会吗？真的吗？它不会改变，还是我们只是不知道？当我们将应用程序托管给其他人时，我们只是不知道。如果提供商重新配置他们的数据中心、升级它、调整它，无论出于何种原因，拓扑结构都会发生变化。鉴于前面提到的智能手机使用率的提高，拓扑结构经常发生变化。从用户和提供商的角度来看，拓扑结构几乎每天都在变化！如果拓扑结构发生变化，并且它依赖的外部服务无法再访问，导致例如无法访问数据库，那么这肯定是一个问题。但是，如果在我们的提供商内部发生变化，并且应用程序继续运行，那么它可能不是问题。当然，编写一个小型且以简单配置托管的应用程序很容易。但应用程序会发生变化，那些越来越受欢迎的应用程序更是如此。您是否在设计中考虑了拓扑结构的变化？您如何解释或处理应用程序设计和部署设计中的故障？
“但是我的应用程序由单个服务提供商托管。他们提供操作系统、数据库和Web服务器支持，”你说。好吧，假设那是您的应用程序，真的只有一个管理员吗？如果真的只有一个管理员，你会真的相信提供商会处理你的应用程序吗？如果他们生病或休假，我会讨厌想到会发生什么。通常，至少会有几个管理员，尽管每个管理员的技术和更广泛的敏锐程度可能不同。应该制定策略，例如网络入侵检测和其他安全策略，但不能保证他们都会以相同的彻底性和尽职尽责来遵守这些策略。鉴于当今可用的众多托管提供商以及更新DNS记录所需的时间很少，我们有很多选择和灵活性，如果一个提供商没有满足我们的需求和期望，我们可以转向另一个提供商。您是否考虑过这会如何影响您？如果您无法轻松更换供应商怎么办？如果您有大量的供应商锁定，或者移动成本很高怎么办？如果您的应用程序架构不够灵活怎么办？您可以采取哪些措施来减轻此类风险？
与迄今为止的所有陈述一样，这的有效性也很不可能。如果支持我们应用程序的服务器位于同一数据中心的同一机架中，那么传输成本可以大大降低，但就时间成本而言。货币成本呢？是的，我们可以根据需要无限地弹性地向上和向下扩展，并且可以在地理位置分散的数据中心之间存储我们的应用程序数据，以便它尽可能接近我们的最终用户，但代价是什么？您的应用程序或服务的架构组成是什么？就成本或时间而言，它是否接近于零？如果您能减少一个，它是否会增加另一个？
与其他误区不同，我认为作为PHP开发者，我们天生就理解这一点。我们在Windows、Linux、Solaris、BSD和Mac OS X服务器上托管我们的应用程序。我们使用MySQL、SQLServer、SQLite、PostgreSQL、mongoDB、Hadoop和Oracle来存储数据。我们通过需要不同接口的XML或JSON使用外部服务。作为一个多操作系统和多服务社区，可以说从早期开始，我们就从未期望过同构网络。但问题仍然需要提出，您的方法是否灵活？您可以处理多个数据库和数据源吗？您是否使用相关的设计模式，例如抽象工厂，来使用透明的代码接口从各种来源和类型消费数据？或者如果需要执行像从XML切换到JSON这样简单的事情，您的代码是否会中断？
结论
我认为，作为PHP开发者，分布式计算的八大误区与以往一样重要。鉴于大量可用的信息和资源，我们处于一个非常有利的地位来理解它们并减轻由此产生的风险。您怎么看？在开发应用程序和服务时，您是否考虑到了它们？您认为这八个误区如何影响您的应用程序？
(图片保持不变)
以上是PHP开发人员分布式计算的8个谬误的详细内容。更多信息请关注PHP中文网其他相关文章！
