读《阿里云运维架构》感想
这两天翻完了《阿里云运维架构》这本云计算运维方面的书籍,开了开眼。对于云计算的运维和本地IDC机房的运维方面区别还是很大,笔者挑着自己知道的和实践过的知识来分享一点自己的感悟。
在运维阶段方面,我发现传统的IDC机房大部分还是在脚本和工具阶段,还有一些是平台化的监控,比如zabbix等等,剩下的几乎全是人工阶段。反思现在有些运维工作,还有一些是人肉操作,比如定期检查磁盘空间、文件是否同步、更新局域网服务器时间等等,其实很多都可以脚本化来检查,鼠标到处点击来查看是过于低效。
五个云计算的产品,云服务器ECS、RDS关系型数据库、SLB负载均衡、OSS对象存储服务、VPC专有网络 。笔者只体验过云服务器ECS,在上面做了一些简单的测试,其他服务也没有体验。在第一次登录到云服务器上时, 发现网络类型VPC专有网络只有一个网卡,后面才知道公网数据是通过NAT方式流转到网卡上。
技术架构有四个方面。单机架构,一台高性能服务器来完成使用功能;集群架构,使用VIP技术来解决单点问题;分布式架构,引入负载均衡技术;微服务架构,容器的应用,完成业务功能拆分解耦 。VIP技术,笔者以前使用树莓派来做过keepalived来实现,Keepalived让树莓派也可以VIP漂移和Mariadb基于GTID的双主复制配置 ,还有一些故障排除问题。负载均衡技术,以前写过一篇简单的综述:数据中心负载均衡的一点总结,关于二层四层转发,ipvsadm搭建NAT模式配置负载均衡LVS和ipvsadm搭建DR模式配置负载均衡LVS。容器方面,笔者使用docker和podman来完成数据库以及nginx的应用。
以前关注过的DNS负载均衡适用于大规模应用,可以通过host或者nslookup来查询,笔者发现淘宝和百度在应用。可能DNS负载均衡有一个问题既是本地DNS缓存问题,但是通过架构可以解决这个问题。下面是笔者画的导图,负载均衡SLB的指向全部后端云服务器,这样可以避免每一个负载均衡器的负载不一样导致后端服务器的负载流量差别大。

数据库主从架构。经典的主从架构,mysql(mariadb)数据库主备同步。主从架构的扩展(一主多从、主主架构、副本集架构),Mariadb基于GTID的双主复制配置完成主主架构配置,为了防止同时写入导致自增ID冲突导致数据库复制冲突的问题,要修改auto_increment_increment参数,使自增间隔不一样。副本集架构,在主节点故障时,从节点投票选出一个节点成为主节点来保证数据库写入功能,其他从节点同步这个选出的主节点。在mysql中可能需要其他中间件来实现,MongoDB 中可以直接配置实现,但是笔者没有接触过MongoDB ,只使用过mysql 关系型数据库 。
这一本是在学习云技术中了解的,总的来说可以对云产品有一个基础的认识。