首页 > 技术文章 > 第一章 服务网格的历史

liufei1983 2019-01-28 21:36 原文

微服务存在的问题:

  实列数多,部署和运维的自动化要求高。

  网络调用代替API,对不可靠的网络依赖强。

  调用链路长,分布式跟踪比较难。

  日志分散严重,跟踪和分析难度大。

  服务分散,受攻击面积更大。

  在不同的服务间,存在协助,需要有更好的跨服务控制协调能力。

     自动伸缩、路由管理、故障控制、存储共享,等等。

 

  为了解决为服务的问题,以K8s为代表的容器云系统出现了,这类容器云系统以容器技术为基础,在进程级别为微服务提供了一致的部署、调度、伸缩、监控、日志等功能。

  

  1.1 Spring Cloud

  为功能层面为微服务治理定义一系列标准的特性:智能路由、熔断、服务注册与发现等。

  Spring Cloud的缺点:

  • 在代码级别对组件进行控制,微服务治理代码与业务逻辑混合,依赖于java实现,与微服务的多语言协作的目的背道而驰;
  • 自身没有对调度、资源、DevOPS等提供相关支持,需要借助其他平台, k8s与其功能有很多重叠;

  1.2 Linkerd

  

  1.3 Istio

  Google、IBM、和Lyft宣布了Istio的诞生。Istio以Envoy为数据平面通过Sidecar的方式让Envoy同业务容器一起运行,并劫持其通信,接受控制平面的统一管理,在此基础上为服务之间的通信提供丰富的连接、控制、观察、安全等特性。

  1.4 国内服务网格的兴起

  

  

  

 

 

 

 

 

  

推荐阅读