【问题标题】:Single technology stack vs. multiple technologies for high scale site用于大规模站点的单一技术堆栈与多种技术
【发布时间】:2011-04-22 12:53:52
【问题描述】:

由于旧设计存在大量维护问题,我最近收到了关于重写现有网站的建议。

基本上,该公司正在考虑完全重写 aprox。他们网站的 90% 目前是使用内部框架用 PHP 编写的。

该公司希望重建后端,并在某种程度上重建前端,以尽量减少他们的维护问题,并更容易引入新的人才,而无需花费数月的时间来学习架构在他们成为有影响力的开发者之前。

我们提出了几种可能的架构,其中一些涉及使用现有的脚本 Web 框架(例如 Cake、Django 或 RoR)以及一些 Java 甚至 .Net 中的编译语言框架来重写整个站点。 此外,我们还提出了一些跨技术解决方案 - 例如在 Django 中构建的带有 Scala 后端的 Web 应用程序。

我想知道使用单一技术堆栈(例如 RoR)与使用两者之间的交叉(例如 RoR 与 Scala,就像 Twitter 现在做的那样)和虎钳对比有什么好处。

考虑到这家公司的网站是一个高流量网站,每天有超过 100 万的独立访问者,将在很长一段时间内(几个月到一年)...

谢谢

【问题讨论】:

  • 您列出了五种非常不同的技术作为可能的解决方案。维护人员的语言选择不是一个因素吗?
  • 并非如此。他们已经决定他们最好选择正确的技术并重新培训开发人员,而不是在 PHP 中重建它。不过我问了完全相同的问题:)

标签: ruby-on-rails django architecture frameworks


【解决方案1】:

一般来说,我不认为任何特定的技术堆栈在性能方面比其他任何堆栈都好; Facebook 在 PHP 上运行,我直接知道 Java 和 .Net 也可以很好地扩展。根据你所说的,我现在更担心与可维护性相关的问题,而不是性能和可伸缩性。

一般来说,如果可能,我会保持在一个众所周知的技术堆栈内:

  • 为知名平台/技术堆栈找到(优秀)员工会更容易;市场上会有更多,而且价格不会像技能太稀有那样昂贵。
  • 拆分您的技术意味着您需要更广泛的知识;通过坚持使用单一技术堆栈,您可以专注于它,从而获得更好/更快的结果。
  • 人们倾向于专注于一个平台/技术堆栈,因此更容易找到技术 X 的开发人员,而不是技术 X、Y 和 Z。
  • 团队成员可以更轻松地处理系统的不同部分,因为它们都是用相同的技术编写的 - 大概是以类似的方式。
  • 在集成方面,同一技术堆栈中的项目可以更好地协同工作,跨入不同堆栈会很快变得更加困难和难以支持。
  • 如果您确实想使用不同的技术,请确保边界清晰 - 基于标准或与技术无关的东西,例如 Web 服务/JSON 调用。

【讨论】:

  • 很好的建议,谢谢,但正如我回复 Jas 时,考虑两种技术的原因是为了两全其美 - 使用编译语言的强大后端(甚至 facebook 使用 HipHop 来编译他们的 PHP到 C++ 和 Twitter 使用 Scala),并为实际网站(Django 或 RoR)提供易于使用的 Web 框架。
  • 那很酷。我对 Cake、Django 或 RoR 一无所知,所以很抱歉我帮不上什么忙。我建议你写一篇论文,查看所有选项并考虑:你追求的结果,系统的背景;对于您确定的每个选项:优点/缺点、风险、限制。
  • 我们可能会这样做,我正在寻找你们的想法,看看我是否遗漏了什么:)
【解决方案2】:

重写整个代码库需要付出巨大的努力和巨大的压力,首先,您最好从初始时间估计的两倍或三倍开始。 你可以从两个角度考虑你的问题:

  1. 平台数量。为了最大限度地减少和管理这项任务的复杂性,通过尽可能少地使用新技术/平台来减少精神压力绝对是您的当务之急。例如,经常被引用的 RoR 优于 PHP+Smarty 的一个优势是,使用 RoR,您不必学习新的表示语言。

  2. 学习新技术需要团队合作。如果您现有的团队已经能够使用 PHP、Django 等,但不是 RoR,那么您最好重用现有技能,因为开发人员的精神压力会更小。

【讨论】:

  • 谢谢。它不是我的开发人员 acually,我建议其他人 :) 但没关系。显然,将其保留为一种技术更容易,但他们担心扩展问题,因此他们不想在后端使用脚本语言,但仍然希望脚本语言易于用于实际的 Web 应用程序 - 所以我们是考虑使用 Django 或 RoR。
【解决方案3】:

单一技术意味着更少的移动目标;只要满足要求,越简单越好。因此,根据需要使用尽可能多的技术,但仅此而已。技术不重要;正确的技术是让您的工作更轻松的技术。所以,问问自己你目前的痛点是什么,以及这些技术将如何提供帮助。

【讨论】:

    【解决方案4】:

    使用 Smalltalk 和 Seaside 最容易获得正确的架构和干净的代码,尤其是当您使用 Gemstone 进行持久性时。在这种规模下,您将不得不与他们讨论许可费用。您可能从他们对 Maglev 所做的 Ruby 工作中了解他们。

    【讨论】:

      猜你喜欢
      • 2011-08-07
      • 2011-05-27
      • 1970-01-01
      • 1970-01-01
      • 2015-03-21
      • 1970-01-01
      • 2016-10-06
      • 2016-11-11
      • 2020-03-13
      相关资源
      最近更新 更多