AWS-亚马逊云为运维做的SUPER SYSTEM

之前使用其他云服务，在运维方面一直都是半手动或者自己写一些程序进行自动化更新和维护。
转到aws后深入学习和使用各种云服务，感觉真的是很强大也很方便。
首先，文档方面很全，想找的问题文档基本都会提到，而且文档结构也很好，文档中安插很多跳转连接到对应的概念或使用方法，虽然有部分中文翻译的不大好，但是中英对照着看还是可以理解的。主要是要去操作才能更好的理解。
其次，计费方面大部分文档里面都有明确计费规则，也提供了计算器来预估计费，仔细一点费用方便不会有太大的坑。
最后，通过大量的实验和使用，我完成了对现有结构线上的监控和运维维护操作的自动化管理，除了因国内因素短信服务搞的很麻烦，其他的都比较好用，主要看自己能否灵活搭配和使用，aws各种应用大多数都是可以互通的，所以搭配很重要。

使用的服务
ec2 云服务器，不用多说
rds 云数据库，直接使用，很多功能也不用自建，节省运维成本
elastiCache 云缓存redis
s3 云文件存储，绝大部分服务都依靠这个使用起来的，比如各种配置文件、各种程序包都可以用它统一上传，从云的各种服务中轻松获取到。
CloudFront 云分发CDN，不过亚马逊云cdn确实强大，不用分国内还是海外，都可以访问到，不像某些云商分开访问
cloudwatch 监控平台，不只是负责监控，也可以做各种统计还有各种触发式、定时任务调度。
ssm 系统管理，以统一的管理方式远程管理所有ec2实例，比如在实例上安装aws各种服务的代理，执行远程命令等。
codebuild 项目构建，本来提供代码存储的地方，但是我想没多少公司也放心把代码放在上面，所以还是打好程序包，使用这个服务来构建docker镜像用了。
ecr aws提供的docker镜像库，在整套系统内使用docker的基础服务。
ecs aws提供的docker容器统一管理，类似k8s但是更没有它那么多概念那么复杂。其实用它主要是因为完全免费，而k8s需要收费或者要在ec2上运行系统。
lambda 无实例计算服务，不用在ec2上运行，按照计算时间收费，支持各种语言，主要作为各种服务的中间粘合剂，比如监控系统想调用一个没有提供服务接口的东西，那就写一个lambda程序调用对应接口的API实现。
sns 消息服务，这个大多数服务商都有，创建主题进行订阅，可以发送邮件、短信（发中国大陆的短信需要走单独流程）。

codepipeline 自动化更新部署的重头戏，配置这个东西能够从代码编译到打包到自动更新服务一步到位，甚至更新失败自动回滚操作，超级方便。使用好这个工具，解决运维一半的工作了。
IAM 技术配置所有服务的时候都要用到，不只是操作控制台的用户权限，服务之间调用的权限划分的也超级细致。一般按照文档操作都没有问题，很多功能也都有自动创建权限组功能。
Toolkit 官方提供的IDE插件，可以直接在IDE上管理一些服务，也可以直接创建一些服务代码比如lambda代码，在开发上提高了效率。

服务的组合
自动部署
s3+cloudwatch+codebuild+ecr+lumbda+ecs
从s3获取到程序包
由codebuild进行镜像制作
上传镜像到ecr
调用lambda提前写好程序调用ecs更新服务（本来有可以直接调用更新，但是必须是蓝绿部署的，我们这种有状态的服务不能接受蓝绿部署）

ps：其实整套部署过程完全是自己组合起来的，本来可以用codepipeline完成一次性配置，但是我的服务是有状态服务，必须停机后再启动新服，不然缓存会有不一致的情况，所以实验了很久才组合出这样的结构。
这样是对以后架构的思考，有状态服务面临很多问题，所以把状态放在缓存中才能解决更多运维问题，也可以降低程序复杂度和耦合度。

异常警报
cloudwatch+sns
这个比较简单，通过配置收集到的指标，按照规则创建警报，不符合指标标准的调用对应的主题来发送预警消息。

以上都是使用一个月的微薄想法，有说的不对和使用不恰当的地方欢迎指出。