阿里云代理商-阿里云服务器-阿里云数据库-重庆典名科技

微服务架构和容器云集成的集群和负载均衡

发布时间: 2020-09-29 13:36:15文章作者: 网站编辑阅读量: 198
  微服务架构和容器云集成的集群和负载均衡。微服务作为一项在云中部署应用和服务的新技术已成为当下最新的热门话题。但大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务,而红帽说API应该是重点。
  
  企业和服务提供商正在寻找更好的方法将应用程序部署在云环境中,微服务被认为是未来的方向。通过将应用和服务分解成更小的、松散耦合的组件,它们可以更加容易升级和扩展,理论上是这样。
  
  微服务架构和Kubernetes+Docker容器云集成后的服务发现和负载均衡问题。
  
  前面谈到在采用Eureka服务注册中心的时候,对于同一个微服务模块A,我们可以启动多个微服务实例,不同的端口号。在端口启动后通过Eureka来实现服务的自动注册和发现。然后通过Ribbon来实现服务访问的负载均衡处理。
  
  也就是说我们添加和部署微服务模块A节点是手工完成的。
  
  但是在DevOps持续集成下,在实施Kubernetes+Docker容器云后,我们可以通过k8s来实现微服务节点资源的动态扩展。扩展的Pod资源统一由Kubernetes来实现集群负载均衡均衡,即对外只需要通过Node+端口号访问即可。
  所以在这个时候实际有两种做法
  所以在这个时候实际有两种做法。
  
  做法1:不再使用Eureka服务注册和发现
  
  在这种时候,不再使用Eureka服务注册发现,而是通过Kubernates动态部署后的VIP进行访问,由Kubernates来进行后台节点的负载均衡。
  
  这个时候我们只能够按常规调用Http Rest API接口的方式进行接口消费和调用,类似原来的Feign声明式调用可能不再适合。也就是说在这种场景下你只使用SpringBoot开发独立的能够暴露Http Rest API接口的微服务。不再使用SpringCLoud框架中的Eureka+Feign+Ribbon。
  
  做法2:采用Eureka来替代Kubernetes中的Service
  
  在这种场景下,即不使用Kubernetes本身的集群功能,而是将动态部署出来的微服务模块还是自动化注册到Eureka服务注册中心统一管理。也就是还是按传统的SpringCLoud框架体系来进行架构搭建。
  
  在这种思路下可以进一步保留SpingCLoud下的限流,容错,心跳监测等方面的关键能力。
  
  做法3:进一步的思路还是ServiceMesh
  
  实际上我们看到进一步的思路还是类似Istio的完全去中心化微服务治理方案。在这种模式下可以更好的通过Sidecar来实现相关服务注册,发现,限流熔断,安全等各种关键服务治理管控能力。 
  微服务的基本思想在于考虑围绕着业务领域组件来创建应用
  微服务的基本思想在于考虑围绕着业务领域组件来创建应用,这些应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台,使部署、管理和服务功能交付变得更加简单。
  
  微服务是利用组织的服务投资组合,然后基于业务领域功能分解它们,在看到服务投资组合之前,它还是一个业务领域。

  开创性地实现了微服务架构框架中诸如断路器、流量仪表板、服务网关等特性  

  微服务这一概念出现于2012年,是因软件作者Martin Fowler而流行,他承认这并没有精确地定义出这一架构形式,虽然围绕业务能力、自动化部署、终端智能以及语言和数据的分散控制有一些常见的特性。 阿里云服务器
联系客服免费领取更多阿里云产品新购、续费升级折扣,叠加官网活动折上折更优惠