通过使用Elastic Beanstalk，通过为典型的Java Web应用程序手动创建EC2实例和设置tomcat服务器并部署等，我们获得了哪些优势 . 负载均衡，监控和自动扩展是唯一的优势吗？
假设我的Web应用程序使用数据库，我在EC2实例本身安装了数据库 . 当发生自动调整时，数据库将在新创建的实例中创建，或者它将访问我在主实例中创建的数据库...如果在自动调标发生时它只创建副本，那么实例之间会发生数据同步吗？
您提到的所有内容，如负载 balancer ，监控和自动扩展，绝对是优势 .
但是，您必须以这种方式思考：在真正的Platform as a Service（PAAS）中，目标是将应用程序与平台分开 . 作为开发人员，您只需担心您的应用程序 . 该平台对你来说是"rented" . 平台"instances"会自动更新，管理，缩放， balancer 等 . 您只需上传您的WAR文件，它就可以正常工作（至少在理论上） .
EC2本身不是PAAS . 它更像是IAAS（Infrastructure as a Service） . 您仍然需要处理服务器实例，在其上安装软件，更新它们等 .
Elastic Beanstalk是一个PAAS系统 . 所以App Engine和Azure等等 .
在真正的PAAS系统中，DBMS是与Web应用程序服务器分开的组件 . 原因很明显：DBMS不可能安装在用于应用程序服务器的实例上，因为在根据您的流量创建和销毁实例时，DBMS将丢失！无论如何，将DBMS和应用程序服务器放在同一台机器/实例上通常都不是一个好主意 .
在PAAS系统中，DBMS是一项单独的服务 . 对于亚马逊，它将是Amazon RDS . 就像Elastic Beanstalk一样，您不必担心DBMS，只需部署数据库即可 .
Elastic Beanstalk和RDS可以很好地协同工作，尤其是在部署在相同可用区域时，延迟会非常低 .
最后，使用Elastic Beanstalk不会比部署的资源（EC2实例和负载均衡器）花费更多 . 但是，RDS并不便宜，并且肯定比使用单个EC2实例同时用于应用程序服务器和DBMS更昂贵 .
Elastic Beanstalk不仅仅是负载 balancer ，监控和自动扩展 .
1）通过存储和管理应用程序的不同版本来管理应用程序版本，使您可以轻松地在不同版本的应用程序之间来回切换 .
2）每个应用程序都有“环境”概念，允许您在每个环境中部署不同版本的应用程序 . 这很方便，例如，如果您想要设置单独的QA和DEV环境，并且您希望在DEV中首先轻松部署构建，然后在QA团队为下一个构建做好准备时在QA中部署相同版本的应用程序 .
3）将重要的容器配置属性（例如Tomcat内存设置）外部化到Elastic Beanstalk控制台和API . 因此，您可以轻松保存设置并在环境之间进行复制 .
4）通过控制台查看应用程序日志文件，并自动将日志文件滚动和存档到S3 . （不可否认，这个功能目前有点弱 . ）
我在EC2专用（Nginx和Gunicorn）和Beanstalk环境（CentOS和Apache2）中部署了一个应用程序 .
我的观察：
BeanStalk是Paas . 手动创建EC2实例（IAAS）就像从头开始做所有事情，但你有可靠的控制权 .
BeanStalk默认附带CentOS和Apache（Httpd） . 您可以在专用实例中选择操作系统 .
这些对我很重要的事情，
在Beanstalk环境中出现了很多504错误 .
BeanStalk服务器崩溃时很难调试，因为日志也不会显示，也无法进入机器 . 这是非常重要的 .
安装/配置Celery，Redis等工具（需要运行另一个端口）等 . 在专用实例中更容易 .
就我而言，我必须扩展（Beanstalk）服务器才能运行某些软件包的安装（如pandoc） . 这些东西在Ubuntu中更简单 .
BeanStalk中的缩放更容易 . 克隆服务器在BeanStalk中很简单 .
我在两种情况下都采用了micro（专用和Beanstalk） . 我觉得专用微实例更好 .
Beanstalk中的自动部署 . 我必须编写脚本来自动执行相同的操作，这很好，因为它只有一次 .
3 回答
您提到的所有内容，如负载 balancer ，监控和自动扩展，绝对是优势 .
但是，您必须以这种方式思考：在真正的Platform as a Service（PAAS）中，目标是将应用程序与平台分开 . 作为开发人员，您只需担心您的应用程序 . 该平台对你来说是"rented" . 平台"instances"会自动更新，管理，缩放， balancer 等 . 您只需上传您的WAR文件，它就可以正常工作（至少在理论上） .
EC2本身不是PAAS . 它更像是IAAS（Infrastructure as a Service） . 您仍然需要处理服务器实例，在其上安装软件，更新它们等 .
Elastic Beanstalk是一个PAAS系统 . 所以App Engine和Azure等等 .
在真正的PAAS系统中，DBMS是与Web应用程序服务器分开的组件 . 原因很明显：DBMS不可能安装在用于应用程序服务器的实例上，因为在根据您的流量创建和销毁实例时，DBMS将丢失！无论如何，将DBMS和应用程序服务器放在同一台机器/实例上通常都不是一个好主意 .
在PAAS系统中，DBMS是一项单独的服务 . 对于亚马逊，它将是Amazon RDS . 就像Elastic Beanstalk一样，您不必担心DBMS，只需部署数据库即可 .
Elastic Beanstalk和RDS可以很好地协同工作，尤其是在部署在相同可用区域时，延迟会非常低 .
最后，使用Elastic Beanstalk不会比部署的资源（EC2实例和负载均衡器）花费更多 . 但是，RDS并不便宜，并且肯定比使用单个EC2实例同时用于应用程序服务器和DBMS更昂贵 .
Elastic Beanstalk不仅仅是负载 balancer ，监控和自动扩展 .
1）通过存储和管理应用程序的不同版本来管理应用程序版本，使您可以轻松地在不同版本的应用程序之间来回切换 .
2）每个应用程序都有“环境”概念，允许您在每个环境中部署不同版本的应用程序 . 这很方便，例如，如果您想要设置单独的QA和DEV环境，并且您希望在DEV中首先轻松部署构建，然后在QA团队为下一个构建做好准备时在QA中部署相同版本的应用程序 .
3）将重要的容器配置属性（例如Tomcat内存设置）外部化到Elastic Beanstalk控制台和API . 因此，您可以轻松保存设置并在环境之间进行复制 .
4）通过控制台查看应用程序日志文件，并自动将日志文件滚动和存档到S3 . （不可否认，这个功能目前有点弱 . ）
我在EC2专用（Nginx和Gunicorn）和Beanstalk环境（CentOS和Apache2）中部署了一个应用程序 .
我的观察：
BeanStalk是Paas . 手动创建EC2实例（IAAS）就像从头开始做所有事情，但你有可靠的控制权 .
BeanStalk默认附带CentOS和Apache（Httpd） . 您可以在专用实例中选择操作系统 .
这些对我很重要的事情，
在Beanstalk环境中出现了很多504错误 .
BeanStalk服务器崩溃时很难调试，因为日志也不会显示，也无法进入机器 . 这是非常重要的 .
安装/配置Celery，Redis等工具（需要运行另一个端口）等 . 在专用实例中更容易 .
就我而言，我必须扩展（Beanstalk）服务器才能运行某些软件包的安装（如pandoc） . 这些东西在Ubuntu中更简单 .
BeanStalk中的缩放更容易 . 克隆服务器在BeanStalk中很简单 .
我在两种情况下都采用了micro（专用和Beanstalk） . 我觉得专用微实例更好 .
Beanstalk中的自动部署 . 我必须编写脚本来自动执行相同的操作，这很好，因为它只有一次 .