咖啡男孩之SRE之路

Spring Cloud Config分为服务端和客户端两部分。服务端作为分布式服务配置中心，是个独立的微服务，用来连接配置仓库（Gig、SVN、本地等方式）并给客户端提供配置信息。客户端是各个微服务结点，配置了config的服务地址，从配置中心获取获取和加载配置信息。

通过Spring Cloud Sleuth (1)-入门篇我们已经引入了Sleuth的基础模块完成一次任务链的跟踪，但是由于日志文件都离散的存储在各个微服务结点上，日常运维时仅仅通过查看日志文件来分析定位问题还是一件繁琐的问题。所以我们需要一些工具来收集、存储、分析和展示日志信息，例如ELK（ElasticSearch、Logstash、kibana）组件。

在微服务框架中，一个由客户端发起的请求在后端系统中会经过多个不同的的服务节点调用来协同产生最后的请求结果，每一个前段请求都会形成一条复杂的分布式服务调用链路，链路中的任何一环出现高延时或错误都会引起整个请求最后的失败。Spring Cloud Sleuth提供了一套完整的服务跟踪的解决方案。

Spring Cloud Stream将消息投递和消费定义成3个概念，本文主要了解下这3个概念如何实现的，与不同的MQ是如何结合的。

前面博文尝试使用了Srping Cloud Bus, 里面引入了spring-cloud-starter-bus-kafka和spring-cloud-starter-bus-amqp，实时上它们分别依赖了spring-cloud-starter-stream-kafka和spring-cloud-starter- stream –rabbit，真正实现与这些消息代理进行交互操作的是Spring Cloud Stream。一定程度上我们将Spring Cloud Bus理解为使用了Spring Cloud

基于Spring的微服务结点在能力上没有高低贵贱之分，但是在角色上会分为边缘服务和内部服务两部分。内部服务顾名思义是为对内暴露服务的结点，供架构内部来调用；边缘服务是对外部网络暴露的服务结点，也就是对外API接口。 开发人员头疼的地方：为了防止我的程序在网络上被人攻击，我们需要写各种权限机制，这些机制在每个微服务结点都要实现一次。一旦鉴权上有什么bug，又要全部节点上推倒重来，噩梦。运

Hystrix的特性：熔断器：当某个服务单元发生故障之后向调用方返回一个错误而不是一直等待，避免了故障在分布式系统中的蔓延。服务降级：fallback是Hystrix执行失败的后备服务，fallback也可以发起另一个Hystrix请求。服务熔断：只有当超过断容器请求数而且失败次数大约一定概率时，才会启动熔断机制。默认是请求20次以上失败50%就启动断熔。请求缓存：客户端缓存，减少对服务端的http交互次数。@CacheResult、@CacheRemove请求合并：也是为了减少http通信上的消

在前面学习Spring Cloud Config的时候最后留了一个尾巴，当我们微服务结点的量级达到一定规模时，一个个维护和refresh服务结点动态更新最新配置信息将会成为一个很费精力的问题，所以Spring framework又推出个新套件Spring Cloud Bus消息总线。

前面博文搭建了一个Eureka+Ribbon+Hystrix的框架，虽然可以基本满足服务之间的调用，但是代码看起来实在丑陋，每次客户端都要写一个restTemplate，为了让调用更美观，可读性更强，现在我们开始学习使用Feign。

前篇博文讲解了Spring Cloud Config的入门部分，虽然搭建起来了一整套服务配置框架（配置服务、客户端、Git仓库），但是如果要达到生产使用级别还存在着3个缺陷：1，config-server单结点，需要高可用性。2，config-server包含全系统的配置，安全需要加固3，config-client配置是启动加载的，不能刷新本篇博文就针对这3个缺陷给出解决方案。

Hystrix Dashboard是Hystrix的仪表盘组件，主要用来实时监控Hystrix的各项指标信息，通过界面反馈的信息可以快速发现系统中存在的问题。Dashboard使用时注意事项：

前面介绍了很多Spring Cloud的组件，本篇按照自己的角度来做一次归纳。Spring Cloud技术应用从场景上可以分为两大类：润物无声类和独挑大梁类。润物无声，融合在每个微服务中、依赖其它组件并为其提供服务。Ribbon，客户端负载均衡，特性有区域亲和、重试机制。Hystrix，客户端容错保护，特性有服务降级、服务熔断、请求缓存、请求合并、依赖隔离。Feign，声...