第一章 服务网格的历史

微服务存在的问题：

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

　　网络调用代替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 国内服务网格的兴起