作者：邓伟
“得云者可以小胜，用云者可以大胜，维云者无往不胜！”
大家好，我是邓伟，引入了一位运维前辈的话作为今天分享的开场白。相信大家对公有云已经再熟悉不过了，今天我们就来聊聊在aws上的架构设计与混合监控。类似aws的云厂商的出现，让应用架构的搭建更为快速，因为云厂商已经做好了基础服务的架构，而企业的it部门要学会如何最大化利用云服务，但这并不“简单”。
基于云的架构设计
以前，我们经常用nginx做负载均衡，用智能dns来轮询服务器；现在，利用云服务就能快速的部署和响应。aws目前提供上千种服务，需要根据自身的业务场景进行合理的架构设计，因此云服务架构也并不是一件“简单”的事情，这里分享的是一套比较常用的架构设计，先来看一下架图：
aws架构示例
图中从用户层接入，这里分了两个访问节点，route53（域名解析服务）是用户访问进我们应用的入口，而cloudfront也就是cdn，用来加速静态文件或者下载文件提供给用户。用户通过route53进入到负载均衡器（elb），elb会自动分配用户即流量到后端服务器（ec2），在多个ec2或同一台ec2不同端口之间进行容错，保证用户的访问都是可用。
ec2作为虚拟服务器（虚拟机），具备了自有伸缩与水平扩展的能力，而运维需要配置autoscanling组来让他进行自动扩展，当用户流量进来，先通过elb进行流量分发，当某天流量爆发的时候，通过提前预设的规则ec2进行扩展，流量一旦下降，就自动回收，以节省成本。
利用aws提供的vpc服务配置不同子网来把业务资源进行合理化的网络隔离，以提高网络安全性。在这里s3起到了一个非常好的中继服务，s3本质是一个存储桶，你可以把他当成ftp，把日志丢到s3、把静态文件放在s3提供给上面提到的cdn去进行分发、也可以把打包好的代码放到s3进行自动化部署。
这样一来，企业就能减少了对服务器本身的接触与操作，再加上利用iam服务对云服务（资源）的权限控制，以规范运维人员对线上资源的操作行为，降低人为风险。
这套架构设计并不复杂，从容的实现了高可用+安全性，但在架构设计中仍需考虑怎么契合企业自身业务的特点，进行合理化调配与逻辑处理，既能满足业务需求，又能降低成本。
云应用的混合监控
当我们做好应用架构设计，就需要去监控这套架构和各种业务应用的运行了，监控各个节点上的服务是否按我们的配置正常运转。aws提供的cloudwatch可以针对资源的利用率监控，利用这一点可以构建自动化处理事件，用cloudwatch来监控服务资源，用脚本来监控服务器内部服务的运行情况，当然就算所有的内部资源和服务都是正常，也不一定表示业务就正常。
监控宝全网用户体验监控
因此在业务监控上选择了云智慧的监控宝，利用监控宝遍布全国各地和海外各主要国家和地区的数百个分布式监测点，实时检测各地用户访问业务的真实体验情况，第一时间发现因外部原因造成的业务不可用，从而确保业务交付的质量。
混合监控下的告警处理
大家会发现我们使用了cloudwatch+自定义脚本+监控宝，那么问题来了，一旦业务出现异常，那必然是一场邮箱+短信的无敌轰炸，导致重要的报警淹没在海量报警之中，无法及时跟进处理。
在这样的混合监控下，要减轻运维人员的负担，就需要一个控制中心把来自各方的告警与业务进行整合，在系统中先对告警优先级进行排序，将不影响业务的轻告警放置在工作时间发出，重要告警整合不同告警来源的信息统一进行发送，第一时间引起运维人员重视，并判断告警风险。
当告警准确的派发给运维人员，自然也就指定了处理责任人，在海量告警面前运维人员需要进行沟通、分配处理，可能导致处理不及时，责任不明确，甚至遗漏的情况。
在混合监控下，整合监控信息、分级处理，针对项目派发给运维人员并要求回执结果，即把合适的告警在合适的时间发给合适的人，处理效率将大大提升。利用服务架构来展现出来所有资源及业务的健康状态，在平台上可以直观了解业务是否健康，而不是被动的等着告警。
今天分享了一套云运维的架构思路，希望可以帮助大家更好的运用云服务，把救火的事情交给别人来解决。