基础设施运维的四个阶段
1、“人肉”阶段
2、脚本阶段
3、工具阶段
4、敏捷基础设施阶段
基础设施即代码，一个全栈工程师在没有运维人员参与的情况下，申请生产环境的资源，自动化配置，部署应用
无需运维人员，全部自动化，通过容器封装环境，开发人员直接将所有软件和依赖封装到容器中，<br>打包成镜像，生产环境直接部署镜像，通过容器实现开发、测试、生产环境的一致。通过容器调<br>度平台管理容器、通过配置文件描述环境，资源利用率更高。
1-监控告警服务
海恩法则：每一起严重的事故背后必然有29次轻微事故和300起未遂先兆，以及1000起事故隐患。
监控数据采集
1-直接上报，通过SDK直连应用，拉取响应的监控数据
2-通过日志上报
3-通过agent上报，监控系统在镜像中默认安装一个agent，用来获取各个系统的监控指标
监控数据接收
1-推模式，Monitor提供API，业务服务主动推送数据给Monitor
2-拉模式，业务服务提供API，Monitor根据业务注册的API和配置来拉取数据
监控数据存储
一般采用时序数据库。InfluxDB/OpenTSDB/Druid/Graphite等
开源监控实现：Prometheus
Prometheus是一套开源的监控、报警、时间序列数据库的组合。<br>在2016年加入CNCF（Cloud Native Computing Foundation）,成为K8S之后的第二个由基金会主持的项目。
Grafana
一个类似Kibana的东西，也是对后端的数据进行实时展示，大家的日常使用中Kibana是跟着Logstash、ElasticSearch等组件一起使用做日志展示、索引、分析的，造成了一种假象就是Kibana就只有这种用法了，Kibana也可以接入其他数据源的，不过大家最长用的还是展示日志，Grafana是什么呢？该项目你可能没听过，也比较年轻，他一般是和一些时间序列数据库进行配合来展示数据的，例如：Graphite、OpenTSDB、InfluxDB等。
2-分布式消息中间件
ActiveMQ
Apache开源，历史悠久，功能丰富，适配各种协议，有鉴权机制。缺点性能低，社区越来越不活跃。
RabbitMQ
基于erlang开发，是采用Erlang语言实现的AMQP协议的消息中间件，最初起源于金融系统，用于在分布式系统中存储转发消息。<br>RabbitMQ发展到今天，被越来越多的人认可，这和它在可靠性、可用性、扩展性、功能丰富等方面的卓越表现是分不开的。
Kafka
基于Scala和Java开发，起初是由LinkedIn公司采用Scala语言开发的一个分布式、多分区、多副本且基于zookeeper协调的分布式消息系<br>统，现已捐献给Apache基金会。它是一种高吞吐量的分布式发布订阅消息系统，以可水平扩展和高吞吐率而被广泛使用。目前越来越多<br>的开源分布式处理系统如Cloudera、Apache Storm、Spark、Flink等都支持与Kafka集成。
RocketMQ
基于java开发（阿里消息中间件），是阿里开源的消息中间件，目前已经捐献个Apache基金会，<br>它是由Java语言开发的，具备高吞吐量、高可用性、适合大规模分布式系统应用等特点，经历过双11的洗礼，实力不容小觑。
3-分布式缓存 Redis/Memcached
1、支持的数据结构：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作（最为常用的数据类型主要由五种：String、Hash、List、Set和Sorted Set），Memcached只支持KV结构，对于复杂结构需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。<br>
2、内存使用效率：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，<br>由于其组合式的压缩，其内存利用率会高于Memcached。
3、性能对比：两者性能都足够高，吞吐量都接近10万TPS，响应时间都为毫秒级。由于Redis只使用单核，而Memcached可以使用多核，<br>所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis<br>最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。<br>
4、持久化：Redis虽然是基于内存的存储系统，但是它本身是支持内存数据的持久化的，而且提供两种主要的持久化策略：RDB快照和AOF日志。<br>而memcached是不支持数据持久化操作的。
5、集群管理：Memcached本身并不支持分布式，因此只能在客户端通过像一致性哈希这样的分布式算法来实现Memcached的分布式存储。<br>Redis支持多种集群模式。
客户端模式：在客户端做负载均衡（利用Zookeeper或者Etcd等）
代理模式：在客户端和服务端之间加一层代理，由代理进行负载均衡，客户端无感知。开源实现有Twemproxy、Codis等
SideCar模式：SideCar模式与代理模式很像，不同点在于SideCar模式的Proxy需要和业务服务部署在一起，<br>这样能比代理模式得到更好的性能，并且控制力比客户端模式更好。
无中心模式-Redis Cluster：无中心架构绝对的去中心化，元数据分布在所有节点上，不会轻易丢失。<br>所有节点彼此互联（PING-PONG机制），节点之间使用Gossip协议。
4-分布式任务调度服务
Tbschedule
Tbschedule是阿里开源的分布式任务管理服务，采用Zookeeper进行分布管理，代码非常简单，可塑性很好。
Elastic-Job
当当开源，在国内应用非常广泛，文档比较丰富，同样采用Zookeeper作为分布式协调服务实现任务调度的。
5-分布式ID
UUID
开发软件基金会OSF制定的计算标准，用到了以太网卡MAC地址、纳秒级时间、芯片ID码等
Twitter的SnowFlake：SnowFlake是非常优秀的ID生成方案，如果能用SnowFlake的地方绝对不用UUID。
Ticket Server：Flickr采用的一种分布式ID生成方案，利用MySql自增长ID实现。它的设计思路是利用数据库中auto_increment的特性和<br>MySQL特有的REPLACE INFO命令来实现，可以利用多台MySQL实现高扩展性和高可用性。
