手动部署与Amazon Elastic Beanstalk

通过使用Elastic Beanstalk来创buildEC2实例并为典型的Java Web应用程序设置tomcat服务器和部署等，我们获得的优势是什么。 负载均衡，监控和自动缩放是唯一的优势吗？

假设我的Web应用程序使用数据库，我在EC2实例本身安装了数据库。 当自动调节发生时，数据库将在新创build的实例中创build，或者它将访问我在主实例中创build的数据库。如果在自动调节发生时只创build副本，那么实例之间会发生数据同步？

Answer 1

所有提到的负载平衡，监视和自动调整都是绝对的优势。

但是，您必须这样思考：在真正的平台即服务 （PAAS）中，目标是将应用程序与平台分开。 作为开发人员，您只需要担心您的应用程序。 平台“租”给你。 平台“实例”会自动更新，pipe理，缩放，平衡等。 你只要上传你的WAR文件，它就可以工作（至less在理论上）。

EC2本身不是PAAS。 这更像是IAAS（ 基础设施即服务 ）。 您仍然需要照顾服务器实例，在其上安装软件，保持更新等。

Elastic Beanstalk是一个PAAS系统。 App Engine和Azure等等。

在真正的PAAS系统中，DBMS是独立于Web应用程序服务器的组件。 原因很明显：DBMS不能安装在用于应用程序服务器的实例上，因为根据stream量创build和销毁实例时，DBMS将会丢失！ 无论如何，将DBMS和应用程序服务器放在同一台机器/实例上通常不是一个好主意。

在PAAS系统中，DBMS是一项单独的服务。 对于亚马逊，这将是亚马逊RDS 。 就像使用Elastic Beanstalk一样，您不必担心应用程序服务器，只需上传WAR文件和RDS，就不必担心DBMS，而只需部署数据库。

Elastic Beanstalk和RDS在一起工作得非常好，特别是在部署在延迟时间非常短的相同可用区域时。

最后，使用Elastic Beanstalk不会比已部署的资源（EC2实例和负载均衡器）花费更多。 但是，RDS并不便宜，而且肯定比为应用程序服务器和DBMS使用单个EC2实例要昂贵。

Answer 2

Elastic Beanstalk不仅仅是负载平衡，监视和自动调节。

1）通过存储和pipe理不同版本的应用程序来pipe理应用程序版本，使您可以轻松地在不同版本的应用程序之间来回切换。

2）为每个应用程序提供“环境”的概念，允许您在每个环境中部署不同版本的应用程序。 例如，如果要设置单独的QA和DEV环境，并且希望在DEV中首先轻松部署构build，那么当您的QA团队准备好进行下一个构build时，可以在QA中部署相同版本的应用程序。

3）将重要的容器configuration属性（例如Tomcat内存设置）外部化到Elastic Beanstalk控制台和API。 因此，您可以轻松保存设置并在环境之间复制它们。

4）通过控制台查看应用程序日志文件，并将日志文件自动滚动并存档到S3。 （无可否认，这个function目前有点弱。）