唱吧K歌亭基于Docker的微服务架构

正文

请到「今天看啥」查看全文

当一个服务实例向etcd写入地址成功时我们就可以认为当前服务实例已经注册成功，那么当这个服务实例由于种种原因down掉了之后，服务地址自然也需要失效，那么在etcd中要如何实现呢？注意图中的每个文件有一个TTL值，单位是秒，当TTL的值为0时对应的文件将会被etcd自动删除，当每个服务实例启动之后第一次注册时会把存活时间即TTL值初始化为10s，然后每隔一段时间去刷新TTL，用来像向etcd汇报自己的存活，比如7s，在这种情况下基本啥上可以保证服务有效性的更新的及时性，如果在一个TTL内服务down掉了，则会有10s钟的时间是服务地址有效，而服务本身不可用，这就需要服务的调用方做相应的处理，比如重试或这选择其它服务实例地址。

我们服务发现的机制是每个服务自注册，即每个服务启动的时候先得到宿主机器上面的空闲端口，然后随机一个或多个给自己并监听，当服务启动完毕时开始向etcd集群注册自己的服务地址，而服务的使用者则从etcd中获取所需服务的所有可用地址，从而实现服务发现。

同时，我们这样的机制也为容器以HOST的网络模式启动提供了保证，因为BRIDGE模式确实对于网络的损耗太大，被我们一上来就否决了，采用了HOST模式之后网络方面的影响确实不是很大。

当一个服务实例向etcd写入地址成功时我们就可以认为当前服务实例已经注册成功，那么当这个服务实例由于种种原因down掉了之后，服务地址自然也需要失效，那么在etcd中要如何实现呢?注意图中的每个文件有一个TTL值，单位是秒，当TTL的值为0时对应的文件将会被etcd自动删除，当每个服务实例启动之后第一次注册时会把存活时间即TTL值初始化为10s，然后每隔一段时间去刷新TTL，用来像向etcd汇报自己的存活，比如7s，在这种情况下基本啥上可以保证服务有效性的更新的及时性，如果在一个TTL内服务down掉了，则会有10s钟的时间是服务地址有效，而服务本身不可用，这就需要服务的调用方做相应的处理，比如重试或这选择其它服务实例地址.

监控，日志与报警

我们选择Prometheus汇总监控数据，用ElasticSearch汇总日志，主要的原因有：

1. 生态相对成熟，相关文档很全面，从通用的到专用的各种exporter也很丰富。

2. 查询语句和配置简单易上手。

3. 原生具有分布式属性。

4. 所有组件都可以部署在Docker容器内。

Mesos Exporter，是Prometheus开源的项目，可以用来收集容器的各项运行指标。我们主要使用了对于Docker容器的监控这部分功能，针对每个服务启动的容器数量，每个宿主机上启动的容器数量，每个容器的CPU、内存、网络IO、磁盘IO等。并且本身他消耗的资源也很少，每个容器分配0.2 CPU，128MB内存也毫无压力。

在选择Mesos Exporter之前，我们也考虑过使用cAdvisor。cAdvisor是一个Google开源的项目，跟Mesos Exporter收集的8成以上信息都是类似的。而且也可以通过image字段也可以变相实现关联服务与容器，只是Mesos Exporter里面的source字段可以直接关联到Marathon的Application ID，更加直观一些。同时cAdvisor还可以统计一些自定义事件，而我们更多的用日志去收集类似数据，再加上Mesos Exporter也可以统计一些Mesos本身的指标，比如已分配和未分配的资源，所以我们最终选择了Mesos Exporter。

如下图，就是我们监控的部分容器相关指标在Grafana上面的展示：

Node exporter，是Prometheus开源的项目，用来收集物理机器上面的各项指标。之前一直使用Zabbix来监控物理机器的各项指标，这次使用NodeExporter+Prometheus主要是出于效率和对于容器生态的支持两方面考虑。时序数据库在监控数据的存储和查询的效率方面较关系数据库的优势确实非常明显，具体展示在Grafana上面如下图：

Filebeat是用来替换Logstash-forwarder的日志收集组件，可以收集宿主机上面的各种日志。我们所有的服务都会挂载宿主机的本地路径，每个服务容器的会把自己的GUID写入日志来区分来源。日志经由ElasticSearch汇总之后，聚合的Dashboard我们统一都会放在Grafana上面，具体排查线上问题的时候，会用Kibana去查看日志。

请到「今天看啥」查看全文