基于云的架构设计

以前，我们经常用Nginx做负载均衡，用智能DNS来轮询服务器;现在，利用云服务就能快速的部署和响应。AWS目前提供上千种服务，需要根据自身的业务场景进行合理的架构设计，因此云服务架构也并不是一件“简单”的事情，这里分享的是一套比较常用的架构设计，先来看一下架图：

图中从用户层接入，这里分了两个访问节点，Route 53(域名解析服务)是用户访问进我们应用的入口，而CloudFront也就是CDN，用来加速静态文件或者下载文件提供给用户。用户通过Route 53 进入到负载均衡器(ELB)，ELB会自动分配用户即流量到后端服务器(EC2)，在多个EC2或同一台EC2不同端口之间进行容错，保证用户的访问都是可用。

EC2作为虚拟服务器(虚拟机)，具备了自有伸缩与水平扩展的能力，而运维需要配置Auto Scanling组来让他进行自动扩展，当用户流量进来，先通过ELB进行流量分发，当某天流量爆发的时候，通过提前预设的规则EC2进行扩展，流量一旦下降，就自动回收，以节省成本。

利用AWS提供的VPC服务配置不同子网来把业务资源进行合理化的网络隔离，以提高网络安全性。在这里S3起到了一个非常好的中继服务，S3本质是一个存储桶，你可以把他当成FTP，把日志丢到S3、把静态文件放在S3提供给上面提到的CDN去进行分发、也可以把打包好的代码放到S3进行自动化部署。

这样一来，企业就能减少了对服务器本身的接触与操作，再加上利用IAM服务对云服务(资源)的权限控制，以规范运维人员对线上资源的操作行为，降低人为风险。

这套架构设计并不复杂，从容的实现了高可用+安全性，但在架构设计中仍需考虑怎么契合企业自身业务的特点，进行合理化调配与逻辑处理，既能满足业务需求，又能降低成本。

云应用的混合监控

当我们做好应用架构设计，就需要去监控这套架构和各种业务应用的运行了，监控各个节点上的服务是否按我们的配置正常运转。AWS提供的CloudWatch可以针对资源的利用率监控，利用这一点可以构建自动化处理事件，用CloudWatch来监控服务资源，用脚本来监控服务器内部服务的运行情况，当然就算所有的内部资源和服务都是正常，也不一定表示业务就正常。

混合监控下的告警处理

大家会发现我们使用了CloudWatch+自定义脚本+监控宝，那么问题来了，一旦业务出现异常，那必然是一场邮箱+短信的无敌轰炸，导致重要的报警淹没在海量报警之中，无法及时跟进处理。

在这样的混合监控下，要减轻运维人员的负担，就需要一个控制中心把来自各方的告警与业务进行整合，在系统中先对告警优先级进行排序，将不影响业务的轻告警放置在工作时间发出，重要告警整合不同告警来源的信息统一进行发送，第一时间引起运维人员重视，并判断告警风险。

当告警准确的派发给运维人员，自然也就指定了处理责任人，在海量告警面前运维人员需要进行沟通、分配处理，可能导致处理不及时，责任不明确，甚至遗漏的情况。

在混合监控下，整合监控信息、分级处理，针对项目派发给运维人员并要求回执结果，即把合适的告警在合适的时间发给合适的人，处理效率将大大提升。利用服务架构来展现出来所有资源及业务的健康状态，在平台上可以直观了解业务是否健康，而不是被动的等着告警。