LAMP 堆栈是否适合企业使用？答案

【问题标题】：Is the LAMP stack appropriate for Enterprise use?LAMP 堆栈是否适合企业使用？
【发布时间】：2010-09-25 21:10:20
【问题描述】：

LAMP（Linux、Apache、MySQL、PHP/Ruby/Python）堆栈是否适合企业使用？

明确地说，“企业”是指大型或超大型公司，其中安全性、稳健性、技能组合的可用性、总拥有成本 (TCO)、可扩展性和工具的可用性是关键考虑因素。换句话说，一家寻求外部采用框架/架构的公司 - 在这种环境中，无处不在的东西将被视为比异国情调/深奥的东西更“有效”。

我见过 Oracle、IBM 和 Sun 在 LAMP 堆栈上为各种企业实施系统的用例。我还看到了一些例子，其中像 yellowpages.com (Ruby on rails) 和 Facebook (php) 等网站都是基于它构建的。但是，这些示例都不是我正在寻找的。

我真的想找到一些例子，说明它是大型银行（例如花旗集团）、电信公司（例如 AT&T）或制造商（例如 Proctor and Gamble）的企业标准。为了清楚起见，我不是在寻找一个在有限意义上使用它的例子（比如在摩根大通），而是它是 CRM、制造系统或人力资源管理等系统的核心平台，以及内部和外部网站。

到目前为止，我所看到的看法是，基于 LAMP 堆栈构建的应用程序执行速度较慢且灵活性较差。我听到的一些论点是：

Linux 的支持不如 Unix、Solaris 或 Windows 服务器好。
Apache 比 BEA WebLogic 或 IIS 等 Web 服务器更难配置和维护。
对于业余爱好者来说，MySQL 是一个“尚未准备好迎接黄金时段”的数据库，而不是 SQL Server 或 Oracle 的竞争对手（尽管 PostgreSQL 似乎以更健壮而闻名）。
PHP / Ruby on rails 针对 CRUD（创建、读取、更新和删除操作）进行了优化。尽管在构建 CRUD 密集型 Web 应用程序时这是一个优势，但两者的执行速度都比 Java/Java EE 或 C#（它们都是常见的企业标准）慢。此外，许多应用程序和系统（如制造系统）具有许多非 CRUD 功能，使用 PHP 或 Ruby 甚至 Python 可能更难构建。

任何人都可以提供论据来支持或反驳 LAMP 堆栈适合企业的想法吗？

谢谢！

卡

更新：Some times the LAMP Stack is Appropriate for Enterprise Use: Externally-Facing Blogs

【问题讨论】：

“电信公司（即贝尔）”你指的是哪家公司？
我指的是任何电信公司。例如，贝尔或 KT。
en.wikipedia.org/wiki/American_Telephone_%26_Telegraph_Company
有趣——尽管已经用扎实的内容解决了这个问题，但由于一些 LAMP 爱好者无法客观地处理这个问题，我显然被否决了。这只是LAMP人气大赛吗？如果是这样，那我为什么要费心给出一个诚实和经验丰富的答案呢？
@Rob：你为什么删除你的答案？我没有经验来判断它的准确性，但它看起来是一个有价值的贡献。

标签： php ruby architecture lamp enterprise

【解决方案1】：

大型企业使用 LAMP 堆栈有两个主要问题：

TCO：考虑到 LAMP 基本上是免费的，企业仍然可以通过其他商业解决方案实现更低的总运营成本
可支持性：企业无需支付额外费用即可从商业供应商处获得全天候的专业支持

【讨论】：

Yuval，TCO 包括支持成本 - 我看到研究表明开源软件的 TCO 可能高于专有软件，因为技能组合不太常见（因此更昂贵）。你能提供支持吗？
我知道，这就是我所说的，或者至少是我的意思:)

【解决方案2】：

我相信这并不是因为这项技术还为时过早，也不是什么让 AT&T 这样的大公司继续在企业层面全面实施。这些公司的 IT 支出预算如此之大，以至于他们最不想做的就是在开源技术所需的定制和增强上花费更多，以满足他们的业务需求。

所以他们寻找的（来自我的咨询经验）是购买和运行产品包，而不必在研究和破解部分上花费更多。使用开源构建的公司已经在全球范围内建立了自己的支持小组来满足大型企业不太愿意做的任何支持需求。他们需要快速、确定地完成工作，并且他们可以付款。

【讨论】：

【解决方案3】：

在这种环境中，无处不在的东西会被视为比异国情调/深奥的东西更“有效”。

虽然由于语言中存在许多缺陷，我个人不会推荐 PHP，但它肯定无处不在。随着 phusion 乘客的出现，共享托管公司对 Rails 的支持也在迅速增长。在 90% 以上的共享主机帐户支持开箱即用的 Rails 之前，我最多再给它一两年。如果这不是无处不在，那是什么？

Linux 的支持不如 Unix、Solaris 或 Windows 服务器好。

如果这让您感到困扰，请从 RedHat 购买支持，或者安装 Solaris 并从 Sun 购买支持。两者都将为您提供与 Microsoft 一样好的支持

Apache 比 BEA WebLogic 或 IIS 等 Web 服务器更难配置和维护。

我不能代表 BEA WebLogic，但在配置了 Apache、IIS 和 Tomcat 之后，Apache 是最容易理解的，并且很容易找到 的示例和文档。

对于业余爱好者来说，MySQL 是“尚未准备好迎接黄金时间”的数据库，而不是 SQL Server 或 Oracle 的竞争对手。

Oh really?。您应该将告诉 NASA、Google、CERN、路透社等公司作为您的使命，他们都在使用尚未准备好迎接黄金时段的业余爱好者数据库。

PHP / Ruby on rails 针对 CRUD 进行了优化，并且两者的执行速度都比 Java/Java EE 或 C#（它们都是常见的企业标准）慢。

这里有两件事：

针对 CRUD 进行了优化 - 这完全无关紧要。
Rails 和一些 python/php 框架针对 CRUD 应用程序进行了优化。许多 C#/Java 框架也针对 CRUD 应用程序进行了优化。但是，如果您正在构建的应用程序是 CRUD 应用程序（并且 99% 的 Web 应用程序都是），这难道不是一件好事吗？
如果您不构建 CRUD 应用程序，那么在 ruby/python/php/java/C# 中有很多非 crud 优化的框架。净赢：没有人（因此无关紧要）

执行速度比 Java/C# 慢 - 这无疑是正确的，但也没关系。对于低流量站点，性能差异不会造成任何影响，而对于高流量站点，您的瓶颈将是数据库，无论是 MySQL、oracle 还是其他任何东西。

您要权衡的是开发时间。一旦你使用了所有这些建议来说服你的老板你不会因为使用 LAMP 而失去任何东西，如果你计算数字并向你的他们表明这将需要 6 个人-用 Java 构建网站需要几个月的时间，而在 ruby/python 中构建它只需要 3 个月，这就是它的真正意义所在。

【讨论】：

【解决方案4】：

您的帖子中有一些非常糟糕的神话：

JavaEE 神话： -App 服务器比 apache 更容易配置，不，apache 更容易。 - 你暗示只有 JavaEE 完整的解决方案是企业级的，不。

CRUD 神话： -CRUD 比 JavaEE 慢？怎么回事？ POJO 和 EJB 正在使用 CRUD。限制因素不是 crud，它的服务器吞吐量

无论是什么技术，甚至是 MS，都有 3 个限制瓶颈区域。服务器实现、持久层和应用程序层。选择的技术不是速度因素，因为您可以将一层的优势换成另一层的劣势. 例如，我们可以通过使用文档存储而不是普通 DB 来加速 Java。

大多数新的 Rails 实现都使用非 Apache 服务器，它们的速度比 Apache 快 3 到 5 倍。即使是经过良好调整的 Apache 服务器也可以胜过一些 javaEE 堆栈。问雅虎，因为他们在某些属性上使用 Symfony ..

【讨论】：

【解决方案5】：

我想建议我们确定企业系统的可扩展性要求以及它们与 Web 应用程序相比有何不同。查看一些最具扩展性的系统，例如 Wikipedia、Flickr、Wordpress、Facebook、MySpace 和许多其他系统。您将在那里看到 LAMP 堆栈。我更喜欢 Python（因为我觉得这种语言给人一种更干净的感觉），但我听取了 Cal Henderson (Flickr) 等专家的意见，他写了一本关于可扩展性的书，谈论他如何扩展 MySQL 服务器库。

企业系统的基本特征是什么？

支持、专业知识的可用性、平台/语言的稳定性可能很重要。

但 LAMP 还具有其他功能，例如更快的开发、更容易的可扩展性、大量可供重用的库、多个文档化的可扩展性故事、成熟的 Web 框架。

这里有一些关于构建可扩展系统的建议（我说的是 Web Scale）。鉴于所有这些证据，我一直想知道，为什么 LAMP 还没有为企业应用做好准备的看法不断出现。

对于 Apache，每项 Netcraft 研究都展示了一个非常不同的采用故事。通过服务器的绝对数量，可能会有更多的人具备配置、调整和扩展 Web 服务器的知识。

Scalable Web Architectures Please Look at Market Share of all Servers Aug 1995 to Jan 2009

【讨论】：

【解决方案6】：

没有找到基于 LAMP 构建的企业应用程序的原因不是因为它们不是企业级的，而是在我看来完全不同的东西。很多大玩家都使用 LAMP 或类似软件——Facebook 和 ~~MySpace~~ 立即浮现在脑海。所以这显然不是scale and perf 的问题。

也就是说，我发现没有任何基于 LAMP 构建的企业应用程序的原因是它们固有的开放性。我不想将精算模块构建为 PHP 文件，因为任何人都可以窃取逻辑。另一方面，如果我有一个 DLL，我可以保留控制权。出于这个原因，您找不到很多基于 PHP 构建的 30 试用版应用程序，但使用 ASP.NET 实现这种保护要容易得多。

【讨论】：

MySpace 是用 .NET 而不是 LAMP 构建的。

【解决方案7】：

如果它对 Google 来说足够好，相信我，它对你来说已经足够好了。

【讨论】：

Google 用标准 LAMP 做什么。 AFAIK 那里的平台是高度定制的。
这使得关于 LAMP 的原始声明不太灵活。并且每个人都可以使用大部分定制（例如 Google MySQL 工具）。但谷歌权衡了所有的利弊，深思熟虑并从一开始就选择了 LAMP。这种定制是后来出现的。

【解决方案8】：

我的 2c：

Linux：自从内核 2.6 出现以来，我会说它绝对是一个高质量的操作系统。 2.4 版还不是很完善，2.2 只是个玩笑，但 2.6 真的很好。不过，在选择分发时要小心。根据我的经验，RedHat/CentOS 非常好，如果你有一个好的管理员，显然 Debian（原始的，不是 Ubuntu！）可以很好地设置。我对 OpenSUSE 的体验不是很好。

Apache：没用过，但我不明白为什么会有问题。

MySQL：这是堆栈的最薄弱环节。我不打算在这里详细介绍 - 如果您有兴趣，请查看 reddit.programming 上的 cmets。更好地了解 PostgreSQL。

PHP/Perl/Ruby/Python：我使用过 Perl，在较小程度上使用过 Python。它们可能适用于基于 Web 的应用程序，其中大部分工作由 Web 服务器和 DBMS 完成。但是，我确实更喜欢静态类型系统，并且更愿意选择 Java/C# 用于业务应用程序和 C++ 用于系统编程。

【讨论】：

【解决方案9】：

我认为大型商业 CRM 和 HR 应用程序可能偏向于交付大型商业 RDBMS 产品作为其产品的基础。如果不出意外，他们肯定更愿意团结起来对抗共同的威胁。

如果他们集成了没有许可和支持费用的产品，他们将很难证明其合理性。

【讨论】：

【解决方案10】：

只是想我会在 LAMP 上运行的网站列表中添加另一个网站 - 维基百科。世界第七大网站，完全用 PHP 编写并运行 MySQL，他们只有两三个付费开发人员。当然，他们有一些志愿者的帮助，但不是很多，而且规模还不错。不知道您是否真的称他们为“企业”，但对于如此庞大且受欢迎的网站，他们似乎做得很好。

Linux 被认为没有得到很好的支持作为 Unix、Solaris 或 Windows 服务器。

正如上面其他人所说，给 Red Hat 打个电话，我相信他们会不同意。并且对 Linux 完全免费的支持量是惊人的。

Apache 更难配置和比 BEA 等 Web 服务器维护 WebLogic 或 IIS。

这取决于您要问的是谁。通常管理 IIS 服务器的人可能会这样看待它。通常管理 Apache 的人不会。这取决于您雇用谁，如果您的堆栈是 LAMP，那么您无论如何都不想雇用没有 Apache 经验的人。

【讨论】：

对于引用：维基百科，只需阅读their Technical FAQ。

【解决方案11】：

“但它是 CRM 和 HR 等系统以及内部和外部网站的核心平台”

首先，找到 LAMP CRM 或 HR 应用程序。

然后为 LAMP CRM 或 HR 应用程序寻找客户。

遗憾的是，第 1 项的示例并不多。因此，您的情况得到了证明。它不能用于企业应用程序，因为 - 目前 - 没有任何您称之为“企业”的应用程序。

不过，你的其他观点非常有趣。

Linux 被认为不如 Unix、Solaris 或 Windows 服务器得到很好的支持。我认为红帽会强烈反对这一点。给他们打电话。我认为他们会做出非常有说服力的推销。阅读他们的success stories。
Apache 比 BEA WebLogic 或 IIS 等 Web 服务器更难配置和维护。通过谁？ Apache 网站管理员？还是 IIS 网站管理员？这完全是主观的。
MySQL 是一个“尚未准备好迎接黄金时段”的数据库。与 Sun Microsystems 合作。我想他们会强烈反对这一点。给他们打电话。我认为他们会做出非常有说服力的推销。阅读他们的success stories。
PHP / Ruby on rails 已针对 CRUD 进行了优化，并且两者都在缓慢执行。可能是真的。 Java 和 Python 可能会更快。 PHP 和 Ruby 并不是 LAMP 中的硬道理。

【讨论】：

SugarCRM 也是垃圾，所以不是一个很好的例子。
其实PHP是在LAMP中的最后一个字。
@Dan Dyer：有趣的是，Python 的人一直告诉我 Python 是 LAMP 中的最后一个词。
@Dan Dyer：就像 XML 是 AJAX 中的最后一个词一样，但我仍然使用 JSON。 S.Lott 的意思是你不依赖于 PHP，就像你不依赖于 Linux 一样。你可以使用 FreeBSD、lighthttpd、PostgreSQL 和 Python，它仍然是 LAMP（FLPP 没有相同的环；）
其实 PHP 是 LAMP 中的最后 3,5,7,9,... 字。

【解决方案12】：

Linux/Apache 是强化的、精简的，并且每个都有很多人（当然价格合适），他们将提供支持，大量有用的工具，许多具有非常高水平的实用工具，可以与它们一起使用并且已经建立在它们之上。

但不确定其他两个。特别是 MySQL 似乎在被 Sun 收购后发生了奇怪的转折，这与该线程中的帖子相反，表明 Sun 可能会产生良好的影响：

http://www.reddit.com/r/programming/comments/7gb8j/oops_we_did_it_again_mysql_51_released_as_ga_with/

【讨论】：

【解决方案13】：

我个人认为 Linux 的支持不如提到的其他操作系统；事实上，硬件供应商通常确实比任何其他操作系统都支持 Linux（Windows 除外，只要您使用主流发行版，他们通常会很好地支持 Linux）。

如果您不使用奇怪的风格（提示：只需使用 RHEL 或与其免费等效的 Centos），Linux 就会得到很好的支持。

MySQL 可能有一些缺点，但在我看来它有很多优点；我们以非预期的方式大规模使用它，但它总体上仍然运行良好（大部分问题是由于我们的版本过时或配置不当）。

LAMP 中的“P”代表什么值得商榷。我觉得 PHP 不是企业级的，因为它有很多单独的缺点（例如糟糕的 unicode 处理、没有命名空间、不一致的 API、不一致的语法、糟糕的版本向后兼容性、重复/过时的功能），它们加起来很难实现一个可维护的系统。

但如果有一个经验丰富的团队，即使您选择 PHP，它也可以用来制作质量极高的应用程序。

【讨论】：

【解决方案14】：

我认为首要标准应该是您团队的技能水平和舒适度，以确保做出的任何平台决策都适合他们。无论您决定如何考虑代码的可伸缩性和可维护性。无论您选择哪种堆栈，工具都很棒。

我个人会将其分解为 3 叠-

Java 堆栈，您拥有 Solaris 或 Enterprise Linux，例如 (RedHat) 和 Weblogic/Websphere/Tomcat 等，Java Enterprise 以及 Hibernate、Spring 等技术。大多数人会选择 Oracle 作为数据库。
Microsoft Stack 和一些开源软件（如果需要） Win Server - IIS - .net/C#（ASP.net 等）- NHibernate、NUnit（单元测试）等。您很可能希望将 SQL Server 用作数据库
上述堆栈都没有，Enterprise Linux 运行着诸如 MySQL（现在属于 Sun 的域，因此可以认真看待）、Apache（那里有 apache 大师）、Ruby（不是我个人的选择）/ PHP（祝你好运）/ Python（我喜欢它，因为它是一种成熟的语言）。从管理代码的角度来看，我会提倡 python 或 ruby。也许对某些人来说可能是 PHP ..我不喜欢它。

【讨论】：

【解决方案15】：

如果你雇佣白痴来实现它，C++ 和 Oracle 将无法扩展。如果您雇用聪明的人并完成工作，PHP 和 MySQL 将可以很好地扩展。

同样的论点也适用于安全性和稳健性。

Facebook、Digg 和 Yahoo 的某些部分在 PHP 上运行。当然，他们雇佣了很多博士程序员。

【讨论】：

是的，这就是答案，编程语言无关紧要，优秀的编码人员才是！
我认为大多数开发人员也不太可能在可扩展性是一个大问题的系统上工作。所有常见的平台（LAMP、.NET、UNIX 等）都可以轻松处理非常大的规模。除非您正在构建下一个 Google，否则您需要担心的远不止这些。

【解决方案16】：

我只想补充一点，我曾多次目睹客户只有在为某些解决方案投入大量资金时才会感到自在，即使这会使企业集成变得更加困难，尽管您提出了什么样的论据。

【讨论】：

我相信 RedHat 和 Sun 会很乐意接受贵公司的巨额现金 :-)
让我想起了：thedailywtf.com/Articles/…

【解决方案17】：

Linux 被大量使用。 Apache 和 Tomcat 被大量使用。 MySQL 现在可能很健壮。我会改用 PostgreSQL。银行将使用 Oracle，但那里对 Java 和 Tomcat 有很好的支持。 PHP 用的比较多，但是很多大公司更喜欢 Java。

在我看来，你最好不要争论 Linux（可能是商业支持的版本）Tomcat、Java、Tomcat|Oracle|MSSQL 解决方案。

您将需要一个 Linux 系统管理员，尤其是随着服务器数量的增加，尽管我确信您可以在此之前获得一个兼职系统管理员。如果公司已经有 Windows 系统管理员，那么争论 Linux 将是艰难的。

【讨论】：

【解决方案18】：

严格来说是一种主观意见，但我个人认为 MySQL 和在较小程度上 PHP 有点弱点，但肯定有很多人不同意，大公司也选择了 LAMP。

我希望看到 postgres 甚至 SQLite 从 MySQL 市场中分一杯羹，我希望看到更多基于 mono、jsp 或 cocoon 的应用程序。我猜 LAMP 对于一个总称来说有点太具体了。 :)

【讨论】：

【解决方案19】：

我想你会发现很多企业使用 Linux 服务器，通常由 Redhat、Novell 或 IBM 支持，而 Apache 也是常用的。

但许多企业倾向于使用 Oracle 或 IBM DB2 等数据库，而不是开源产品 - 尽管有许多企业并不真正需要这些系统提供的那种功能，并且可以使用 MySQL 或 PostgreSQL。

对于网络服务器语言，我认为您几乎可以使用任何东西。但是，如果您使用 Apache，则使用 PHP、Ruby 或 Python 可能更容易，而如果您使用 IIS、Weblogic 或 Domino，则使用 Java / C# 会更容易。

【讨论】：

【解决方案20】：

Redhat 和 IBM 完全支持 Linux，Sun 购买了 MySQL，Yahoo 使用 Php，许多公司使用 LAMP 堆栈，但许多公司使用部件。

【讨论】：

为什么投反对票？似乎发生了一些随机射击，因为 JeeBee 的回答和我的投票被否决了，没有明显的原因

【解决方案21】：

IMO 没有针对 Linux 和 Apache 的一般论据；如果您愿意为 Linux 付费，您当然可以获得企业级支持（如果您愿意遵守社区规则，则可以免费获得它的一个很好的近似值）。除非您需要更复杂的功能，否则 Apache 的配置并不难，这在应用服务器中是不可能的。

您当然可以反对 MySQL，因为最近才添加了一些与数据安全有关的最重要的功能。如果您对此感到担心，请改用 PostgreSQL。

至于您编写应用程序所使用的语言：PHP 已被证明能够运行极其庞大和复杂的系统；我更关心可维护性而不是性能。并且 Ruby on Rails 是“针对 CRUD 进行优化的”，只是因为可以在几乎没有时间（字面意思是几分钟）内编写一个简单的 CRUD web 应用程序，但这并不意味着它不适合更复杂的应用程序，只是需要更多时间（仍然少于许多其他语言）

【讨论】：