PCF会运行嵌入Spring引导jar的Tomcat还是运行自己的tomcat。在PCF中，我们从不提及端口号。在经典方法中，我们在不同的端口号中启动3个Tomcat实例，并在此之前使用apache服务器。 PCF的工作方式是否相同。
这是一个非常广泛的问题，所以我会回答一个非常广泛的回答，但如果您倾向于深入挖掘，可以将您链接到可以找到更多详细信息的位置。
部署Spring引导项目时PCF如何在内部工作将PCF运行嵌入在Spring引导jar中的Tomcat，还是运行自己的tomcat。
运行cf push -p my/cool/file.jar（甚至是file.war）时，cf cli会从该存档中提取所有内容并将其推送到CF. CF存储您的应用程序文件，然后您的应用程序上演。
在暂存期间，Java构建包运行。它查看所有已推送的文件并尝试确定如何处理它们。它知道如何处理几种不同类型的应用程序[1]，包括标准WAR文件和Spring Boot应用程序。构建包将检查您的应用程序，以查看其顺序[2]中是否支持的类型之一，并将选择第一个匹配项。
选择应用类型后，它会运行并安装运行应用所需的内容。对于Spring Boot应用程序，这基本上只是JVM。对于WAR文件，它会安装Tomcat和JVM。此外，它还会写出CF启动应用程序所需的配置和启动命令。
此时，分段已完成，您将拥有所谓的“Droplet”。如果您对暂存工作流程有任何其他疑问，请阅读此处以获取更多详细信息[3]。
此时，应用程序将启动。该平台获取创建的droplet并执行build pack指定的命令以启动app [4]。如果一切顺利，您的应用程序将在CF上启动并运行。
在PCF中，我们从不提及端口号。
正确。平台将告诉您应用程序应该监听的端口。对于Java应用程序，您无需执行任何操作。 Java buildpack将处理配置Spring Boot或Tomcat以启动和侦听正确的端口。
对于Spring Boot应用程序，您可以查看启动命令以了解它是如何执行此操作的。对于Tomcat，它发生在由Java buildpack [5]生成的server.xml中。
在经典方法中，我们在不同的端口号中启动3个Tomcat实例，并在此之前使用apache服务器。 PCF的工作方式是否相同。
是的，不是。您运行的每个应用程序都可以有多个实例如果您将应用程序扩展为具有三个实例，那么就像在经典方法中使用3个Tomcat实例一样。
主要区别在于前面没有Apache Web Server。在Cloud Foundry上，这不是必需的，因为它有自己的称为Gorouter [6]的负载均衡器，可以处理代理到您应用的流量并在可用的应用实例之间进行负载均衡。
这是CF新手所犯的经典错误。他们尝试复制经典架构，并在没有必要的情况下将反向代理服务到他们的应用程序中。这是CF的好处之一。它以可扩展的方式处理您应用的流量路由，让您可以更专注于应用。