3个月以来，豆子把AWS核心的基本服务都上手过了一遍。在了解各个服务功能的基础上，现在终于整合ELB，Auto Scaling，RDS，CloudFront等功能实现一个高可用（High availabilty)的WordPress网站了。相对于豆子最开始创建的那个WordPress Blog，所有的LAMP stack都在一台虚拟机上，如果挂了又没有及时备份，就会丢失很多数据。这些都是血的教训啊。（参见博文 http://beanxyz.blog.51cto.com/5570417/1535770 ）
下面这张很NB的截图来自AWS，很详细直观的解释了AWS的高可用结构。
里面每一个单块服务豆子都尝试过，现在要把他们整合在一起。
用户通过Route53 DNS解析 CloudFront的Edge Server 地址实现快速访问，Orgin Server地址则指向 S3 bucket（参见 博客 http://beanxyz.blog.51cto.com/5570417/1532813）
然后指向我们的Elastic Load Balancer，这里会自动分流到不同AZ，通过Auto Scaling的功能自动根据CPU负荷增加或者删除服务器。（参见博客 http://beanxyz.blog.51cto.com/5570417/1536261 ）
然后Web Server可以指向中间层，Application Server 或者直接指向我们的数据库服务器 。
RDS 实例通过Multiple AZ实现自动同步和Failover （参见博客 http://beanxyz.blog.51cto.com/5570417/1531843 ）
比照上面的结构图，我们的高可用的WordPress 网站基本需求是这样：
-
用户通过DNS解析Elastic Load Balancer的URL，ELB转发请求到其中任何一台Word Press的EC2实例，该Web Server通过3309端口访问远程的MySQL RDS实例；
-
MySQL通过Multiple-AZ实现高可用；
-
Web Server通过ELB实现高可用；
-
根据CPU或者其他负荷标准，ELB里面可以自动增加，删除EC2实例；
-
Auto Scaling 创建的服务器必须自动更新到最新版本；
-
博客涉及的所有的图片和视频必须保存在S3 Bucket上面，并通过CloudFront实现CDN加速，博客的媒体资源URL自动重定向指向CDN的地址进行解析。
豆子的参考设计主要来自Linux Academy的培训视频。下面一篇博客我们来一一实现以上的配置要求。
