企业微服务架构实践

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

企业微服务架构实践

美丽好车的微服务实践是基于Spring Cloud 体系来做的,在具体的开发过程中遇到了不少问题,踩了不少坑,对于微服务也有了实际的切身体会和理解,而不再是泛泛而谈。在整个Spring Cloud 技术栈中,基于不同职责需要,我们选择了相应组件来支持我们的服务化,同时配合Swagger 和Feign 实现接口的文档化和声明式调用,在实际开发过程中极大地降低了沟通成本,提高了研发联调和测试的效率。

从应用架构来看,正是由于基于Spring Cloud 来实现,整个系统完全秉承了微服务的原则,无论是Spring Cloud 组件还是业务系统,都体现了服务即组件、独立部署、去中心化的特性,由此提供了快速交付和弹性伸缩的能力。

接下来我们基于各个组件具体介绍一下美利好车的微服务实践,首先最基本的就是Eureka,其承载着微服务中的服务注册和服务发现的职责,是最基础的组件,必然有高可用的要求。

基于高可用的Eureka 集群实现服务发现

美利好车在生产实践中部署了一个三节点的Eureka Server 的集群,每个节点自身也同时基于Eureka Client 向其它Server 注册,节点之间两两复制,实现了高可用。在配置时指定所有节点机器的hostname 既可,即做到了配置部署的统一,又简单实现了IP 解耦,不需要像官方示例那样用profile 机制区分节点配置。这主要是由于Eureka 节点在复制时会剔除自身节点,向其它节点复制实例信息,保证了单边同步原则:只要有一条边将节点连接,就可以进行信息传播和同步。在生产环境中并不要过多调整其它配置,遵循默认的配置既可。

服务发现

作为服务提供者的Eureka Client 必须配置register-with-eureka 为true,即向Eureka Server 注册服务,而作为服务消费者的Eureka Client 必须配置fetch-registry=true,意即从Eureka Server 上获取服务信息。如果一个应用服务可能既对外提供服务,也使用其它领域提供的服务,则两者都配置为true,同时支持服务注册和服务发现。由于Ribbon 支持了负载均衡,所以作为服务提供者的应用一般都是采用基于IP 的方式注册,这样更灵活。

健康检查

在开发测试环境中,常常都是standlone 方式部署,但由于Eureka 自我保护模式以及心跳周期长的原因,经常会遇到Eureka Server 不剔除已关停的节点的问题,而应用在开发测试环境的启停又比较频繁,给联调测试造成了不小的困扰。为此我们调整了部分配置让Eureka Server 能够迅速有效地踢出已关停的节点,主要包括在Server 端配置关闭自我保护

(eureka.server.enableSelfPreservation=false),同时可以缩小Eureka Server 清理无效节点的时间间隔(eureka.server.evictionIntervalTimerInMs=1000)等方式。

另外在Client 端开启健康检查,并同步缩小配置续约更新时间和到期时间

(eureka.instance.leaseRenewalIntervalInSeconds=10 和

eureka.instance.leaseExpirationDurationInSeconds=20)。

健康检查机制也有助于帮助Eureka 判断Client 端应用的可用性。没有健康检查机制的Client 端,其应用状态会一直是UP,只能依赖于Server 端的定期续约和清理机制判断节点可用性。配置了健康检查的Client 端会定时向Server 端发送状态心跳,同时内置支持了包括JDBC、Redis 等第三

方组件的健康检查,任何一个不可用,则应用会被标为DOWN 状态,将不再提供服务。在生产环境下也是开启了客户端健康检查的机制,但没有调节配置参数。

Eureka 的一致性

在CAP 原则中,Eureka 在设计时优先保证AP。Eureka 各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。而Eureka 的客户端在向某个Eureka 注册时如果发现连接失败,则会自动切换至其它节点,只要有一台Eureka 还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的(不保证强一致性)。除此之外,Eureka 还有一种自我保护机制:如果在15 分钟内超过85% 的节点都没有正常的心跳,那么Eureka 就认为客户端与注册中心出现了网络故障,开启自我保护,支持可读不可写。

Eureka 为了保证高可用,在应用存活、服务实例信息、节点复制等都采用了缓存机制及定期同步的控制策略,比如客户端的定期获取(eureka.client.registryFetchIntervalSeconds),实例信息的定期复制(eureka.client.instanceInfoReplicationIntervalSeconds),Server 的定期心跳检查(eureka.instance.leaseExpirationDurationInSeconds),客户端定期存活心跳

(eureka.instance.leaseRenewalIntervalInSeconds)等等,加强了注册信息的不一致性。服务消费者应用可以选择重试或者快速失败的方式,但作为服务提供者在基于Spirng Cloud 的微服务机制下应当保证服务的幂等性,支持重试。因此如果对一致性的要求较高,可以适当调整相应参数,但明显这样也增加了通信的频率,这种平衡性的考虑更多地需要根据生产环境实际情况来调整,并没有最优的设置。

Config 的高可用及实时更新

高可用方案

Config 的高可用方案比较简单,只需将Config Server 作为一个服务发布到注册中心上,客户端基于Eureka Client 完成服务发现,既可实现配置中心的高可用。这种方式要求客户端应用必须在bootstrap 阶段完成发现配置服务并获取配置,因此关于Eureka Client 的配置也必须在bootstrap 的配置文件中存在。同时我们引入了Spring Retry 支持重试,可多次从Server 端拉取配置,提高了容错能力。另外,在启动阶段,我们配置了failFast=true 来实现快速失败的方式检查应用启动状态,避免对于失败的无感知带来应用不可用的情况。

配置实时同步

在实际的生产中,我们同时基于Spring Cloud Bus 机制和Kafka 实现了实时更新,当通过git 提交了更新的配置文件后,基于webhook 或者手动向Config Server 应用发送一个

/bus/refresh 请求,Config Server 则通过Kafka 向应用节点发送了一个配置更新的事件,应用

相关文档
最新文档