我试图理解无服务器架构,它说明了两个不同的东西:
作为应用程序开发人员,您只考虑您的功能,而不考虑服务器职责。好吧,服务器仍然必须在某个地方。通过服务器,我在这里理解它的意思是:
- 在基础设施端物理服务器/VM/容器
- 以及在软件方面:比如说,Tomcat
现在,我在 Cloud Foundry 工作,研究了 Cloud Foundry 的 ER 即 Diego Architecture 和 Cloud Foundry 的 buildpack 和开放式 Service Broker API 工具。实际上,Cloud Foundry 也已经在一个“类似”模型上工作,其中应用程序开发人员专注于他的代码,并且在 buildpack 的帮助下部署模型准备一个具有所需 Java 运行时和 Tomcat 运行时的 droplet,然后使用它来创建一个花园容器服务于用户请求。因此,开发人员不必担心 Tomcat 服务器或 VM/容器的来源。那么,我们不是已经在 Cloud Foundry 中满足了这一要求吗?
您的代码在执行期间开始存在,然后死亡。我同意这与我们在 Cloud Foundry 中编写的应用程序/微服务不同,因为它们是长时间运行的服务器进程。现在,如果我要在 Tomcat Web 服务器上开发具有 3 个 REST 端点(myapp/resource1、myapp/resource2、myapp/resource3 )的 Java webapp/微服务,我需要:
- 物理机或虚拟机或容器,
- Java 运行时
- Tomcat容器能够运行我的war文件。
按照 Serverless 的建议,我推断我应该只专注于非常具体的功能,比如处理对myapp/resource1的请求。现在,在这种情况下:
- 我对应的 Java 类应该是什么样子?
- 我在哪里可以访问 J2EE 对象,例如 HttpServletRequest 或 HttpServletResponse 对象以及其他 http 或 servlet 或 JAX-RS 或 Spring MVC 提供的由 Tomcat 运行时创建的对象?
- 我的 Java 类是否在执行期间创建并在执行后销毁的容器中执行?如果是,谁来管理这样一个容器的创建/销毁?
- 甚至需要Tomcat吗?是否有一种完全不同的通用方式来处理对这三个 REST 端点的请求?是不是有点像 httpd 服务器使用 python/Java CGI 脚本来处理 http 请求?