服务治理-梳理和调研

1.总体概述

1.1. 根据实现方式分类

1. 微服务1.0：
   1. 用库的形式在微服务应用程序中导入使用。
   2. 基于nginx，kong等
2. 微服务2.0：用代理的方式为应用服务提供能力-服务网格（Service mesh）
   1. 用直接代理的方式, Linkerd1.0
   2. sidecar的形式运行，基于k8s  istio

1.2.服务网格-service mesh

服务网格（Service mesh）是用于处理服务间通信的专用基础设施层。它负责通过一系列措施来保证服务间请求的可靠传递，对上层业务应用透明，类似于操作系统的TCP/IP。

tcp/ip: 机器间通信，应用层无须关注：数据包结构，路由转发，丢包重试，有序传输等等

servicemesh：服务间通信，应用层无须关注：服务发现，负载均衡，故障恢复，指标收集，高可用策略(降级，限流，重试等），安全，等等

实际上，服务网格通常通过一组轻量级网络代理来实现，这些代理与应用程序代码一起部署，而不需要感知应用程序本身

 

绿色方块为微服务，蓝色方块为 service mesh 的代理，蓝色线条为服务间通讯。可以看到蓝色的方块和线条组成了整个网格。这个网络就是 Service Mesh。

2.微服务1.0的通用方案

3.业界开源方案

3.1已有方案的比较

	开源框架	时间	维护/主导	说明	备注
第一代	Linkerd 1.*	2016 年 1 月 15 日，0.0.7版本 2017 年 4 月 25 日，Linkerd 1.0 版本发布	Buoyant	2016 年 1 月 15 离开 Twitter 的基础设施工程师 William Morgan 和 Oliver Gould，在 GitHub 上发布了 0.0.7 版本，他们同时组建了一个创业小公司 Buoyant，业界第一个 Service Mesh 项目诞生。 2016 年下半年，Linkerd 陆续发布了 0.8 和 0.9 版本，开始支持 HTTP/2 和 gRPC，1.0 发布在即；同时，借助 Service Mesh 在社区的认可度，Linkerd 在年底开始申请加入 CNCF。2017年1月23日，Linkerd加入CNCF 面对 Google 和 IBM 加持的 Istio，Linkerd 实在难有胜算，随着 Istio 的稳步推进和日益成熟，外加第二代 Service Mesh 的天然优势，Istio 取代第一代的 Linkerd 只是个时间问题。 2017 年 7 月 11 日，Linkerd 发布版本 1.1.1，宣布和 Istio 项目集成，成为 Istio 的数据面板
	Envoy	2016 年 9 月 13 日直接发布 1.0.0 版本	Lyft	2016 年，Matt Klein 在 Lyft 默默地进行 Envoy 的开发。Envoy 诞生的时间其实要比 Linkerd 更早一些，只是在 Lyft 内部不为人所知 稳扎稳打的 Envoy 在 2017 年一方面继续收获独立客户，一方面伴随 Istio 一起成长。作为业界仅有的两个生产级 Service Mesh 实现之一 2017 年 9 月 14 日，Envoy 加入 CNCF，成为 CNCF 的第二个 Service Mesh 项目	Envoy 是一个用 C ++开发的高性能代理，用于管理 Service Mesh 中所有服务的所有入站和出站流量。 Istio 利用 Envoy 的许多内置功能 被越来越多企业使用，不仅仅稳稳占据 Istio 官配 Sidecar 的位置，而且在网络代理、负载均衡器、网关等领域开始占据传统产品的领地，如 nginx、kong。 被 Istio 之外的多个公司的 Service Mesh 框架项目采用，如 AWS 的 App Mesh, F5 的 Aspen Mesh, 微软的 Service Frabric Mesh，国内包括腾讯 Tecent Service Mesh，阿里的 Dubbo Mesh。Envoy 明显有成为 Service Mesh 的数据平面标准的趋势。 Envoy 的 xDS API，已经成为 Service Mesh 数据平面 API 的事实标准。
第二代	Istio	2017 年 5 月 24 日，Istio 0.1 版本 2018.1.31，0.5版本 。。。 2018.7.31，1.0版本 。。。 2020.3.5，1.5版本	由 Google ， IBM ，Lyft主导	2017 年 5 月 24 日，Istio 0.1 release 版本发布，Google 和 IBM 高调宣讲，社区反响热烈，很多公司在这时就纷纷站队表示支持 Istio   stio 作为第二代 Service Mesh，通过控制平面带来了前所未有的控制力，远超 Linkerd。 Istio 通过收编和 Linkerd 同为第一代 Service Mesh 的 Envoy，直接拥有了一个功能和稳定性与 Linkerd 处在一个水准的数据平面（也就是作为 sidecar 模式部署的 proxy）。 基于 C++ 的 Envoy 在性能和资源消耗上本来就强过基于 Scala/JVM 的 Linkerd。 Google 和 IBM 组合在人力、资源和社区方面的影响力远非 Buoyant 这样的小公司可以比拟 Istio 背负使命： 建立 Google 和 IBM 在微服务市场的统治地位。 为 Google 和 IBM 的公有云打造杀手锏级特性。 在 k8s 的基础上，延续 Google 的战略布局。 在社区方面，Istio 借助 Google 和 IBM 的大旗，外加自身过硬的实力、先进的理念，很快获得了社区的积极响应和广泛支持。包括 Oracle 和 Red Hat 在内的业界大佬都明确表示对支持 Istio	Istio 可以在虚拟机和容器中运行 Istio 的组成（1.5之后融为单体） Pilot：服务发现、流量管理 Mixer：访问控制、遥测 Citadel：终端用户认证、流量加密 Service mesh 关注的方面 可观察性 安全性 可运维性 Istio 是可定制可扩展的，组建是可拔插的 Istio 作为控制平面，在每个服务中注入一个 Envoy 代理以 Sidecar 形式运行来拦截所有进出服务的流量，同时对流量加以控制 应用程序应该关注于业务逻辑，非功能性需求交给 Service Mesh
	Conduit	2017 年 12 月 5 日，0.1.0 版本 2018 年 7 月，在 Conduit 发布 v0.5.0 时将 Conduit 更名为 Linkerd 2.0。	Buoyant	Conduit 的整体架构和 Istio 一致，借鉴了 Istio 数据平面 + 控制平面的设计，同时别出心裁地选择了 Rust 编程语言来实现数据平面，以达成 Conduit 宣称的更轻、更快和超低资源占用 继 Isito 之后，业界第二款第二代 Service Mesh 产品就此诞生 在 2018 年年中，Buoyant 意识到继续同时支撑 Linkerd1.x 和 Conduit 两条产品线已经不合时宜。而且 Linkerd1.x 的硬伤太过明显：因此，合并产品线，放弃 Linkerd 1.×，将力量集中到 Conduit 这个未来方案就成为自然选择
其它	nginMesh	2017 年 9 月，0.1.6 版本。 2017 年 12 月 6 日，nginMesh 0.2.12 版本发布。 2017 年 12 月 25 日，nginMesh 0.3.0 版本发布。	nginx	nginMesh 的定位是作为 Istio 的服务代理，也就是替代 Envoy
	Kong			然后是 Kong，但是这个比默默无闻的 nginMesh 更加低调，只是曾经有传闻 Kong 有意 Service Mesh，但是后来没了下文 2018年 12 月 21 日，kong 1.0 GA 发布时才明确给出：kong 可以部署为独立的 service mesh proxy
	AWS App Mesh			选择 Envoy 作为数据平面，从而避免和 Istio 在数据平面进行竞争 AWS APP Mesh 支持客户在 EC2 和 Kubernetes 环境下同时部署应用并能实现相互访问，一旦成熟，将有可能是一个大卖点
国内	SOFAMesh SOFAMosn		蚂蚁金服	蚂蚁金服 Service Mesh 的控制平面，跟随社区，Fork 自 Istio，保持同步更新。在 Istio 体系和框架内进行功能补充 / 扩展 / 增强 / 改进，立足于探索并解决 Istio 生产 SOFAMosn蚂蚁金服新型基础设施和中间件的底层网络通用解决方案，可以有多种产品形态，2017 年底启动，基于 Golang 开发。在蚂蚁金服 Service Mesh 中承担数据平面的角色，和 SOFAMesh 项目配合使用，兼容 Istio 体系。代替envoy
	Tencent Service Mesh		腾讯	Envoy+pilot组件
	Dubbo Mesh		阿里	Envoy+pilot组件
	华为 Mesher		华为	自行开发
	华为 ASM		华为	控制层依托 Istio 进行扩展和订制
	WeiboMesh		新浪微博	自行开发
	其它

3.2 istio调研

目前两款流行的服务网格开源软件 Linkerd 和 Istio 都可以直接在 kubernetes 中集成，其中 Linkerd 已经成为 CNCF 成员，Istio 在 2018年7月31日宣布 1.0。

 

istio1.5相对于之前，改动较大的一版

1. 改为单体应用（将pilot等组件融合到一起），部署更加简单
2. 扩展能力实现方式（架构还是性能的问题）
   1. envoy层面扩展使用C++内置，需要重新编译
   2. 原来的mixer扩展插件化允许自定义策略和遥测
   3. 使用 WebAssembly（Wasm）将 Istio 的可扩展性模型与 Envoy 统一；提高性能且保证了灵活性
3. 过渡期mixer等功能继续存在，直到1.7版本；wasm生态正在持续构建中

 

4.部署方式

是否支持宿主机部署（非k8s）方式

1. 从 Linkerd 1.* 和 Envoy的支持，（第一代）
2. 到 Istio / Linkerd 2.* 的不支持，（第二代）
   1. 相比虚拟机，k8s提供了太多便利。随着容器的普及，k8s的一统天下，社区对云原生的日益接受，虚拟机模式失宠容易理解
3. 再到 AWS app mesh 和 Google Traffic Director 的支持
   1. AWS 考虑商业竞争
   2. google 考虑 理想与现实的差距