再看Spring Could微服务的关键组件

Consul是用go开发的开源注册中心服务，内置服务发现与注册、raft一致性协议实现、健康检查、多数据中心等方案。与Eurker相比，consul还能对异构服务如rpc提供支持。

作为微服务系统的核心组件，一旦consul挂掉，所有服务都将停止，因此生产环境中必须要用Consul高可用集群。在Consul集群中有server、client两种角色，集群状态信息都存在server节点，client角色是无状态的，它只是代理转发rpc请求到sever节点，起到缓冲的作用，从而减少server节点数量（server节点越多，达成共识、节点间同步代价越高，一般建议3-5台）。Consul通过集群设计，Raft选举算法，Gossip协议等机制来确保Consul服务的稳定与高可用，如果需要更高的容灾机制，可通过设计双数据中心异地搭建两个Consul数据中心，组成一个异地灾备Consul服务集群。

ConfigServer配置中心是对微服务应用配置管理的服务，如数据库、端口配置等，与Consul一样是一个重要的独立服务组件，所有的微服务应用都要调其服务获取配置信息。随着微服务配置越来越多，如何管好这些配置及它们的更新策略，搭建ConfigServer集群也是保证微服务体系稳定的重要方面。这样的关键组件应该搭建独立的集群、部署在物理机而不是容器里。因为ConfigServer主要是http配置文件访问服务，不涉及节点选举、一致性同步操作，可以按传统方式搭建高可用配置中心。可以单独通过git来管理应用配置文件，ConfigServer通过网关拉取git仓库的配置供服务获取就可以了。

与传统方案通过Nginx做负责均衡方案不同，Spring Could中微服务间调用的负载均衡默认是服务消费端通过Robbin代理实现的客户端负载均衡，同样的服务熔断、限流等机制也是基于Hystrix在消费端实现的，这都需要在消费端进程内部通过代码的方式实现，对消费端存在一定的代码侵入性，这也是后面出现Service Mesh（服务网格）概念的原因之一。

基于Spring Could的微服务体系，通过集成各种开源组件为整个体系服务支持，但在负载均衡、熔断、流控等方面需要对消费端业务进程侵入，于是出现了Service Mesh，其基本思路是通过主机独立的Proxy进行的部署来解耦业务系统流程，Proxy除了负责服务发现和负责均衡外，还负责动态路由、容错限流、监控度量和安全日志等功能。

基于 Spring Cloud 的微服务架构演变史？