服务治理-梳理和调研
1.总体概述1.1.根据实现方式分类微服务1.0：用库的形式在微服务应用程序中导入使用。基于nginx，kong等微服务2.0：用代理的方式为应用服务提供能力-服务网格（Service mesh）用直接代理的方式, Linkerd1.0sidecar的形式运行，基于k8s istio1.2.服务网格-service mesh服务网格（Service mesh）是用于处理服务间通信的专用基础设施层。
1.总体概述
1.1. 根据实现方式分类
- 微服务1.0：
- 用库的形式在微服务应用程序中导入使用。
- 基于nginx，kong等
- 微服务2.0：用代理的方式为应用服务提供能力-服务网格（Service mesh）
- 用直接代理的方式, Linkerd1.0
- 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 | 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
Istio 背负使命：
在社区方面，Istio 借助 Google 和 IBM 的大旗，外加自身过硬的实力、先进的理念，很快获得了社区的积极响应和广泛支持。包括 Oracle 和 Red Hat 在内的业界大佬都明确表示对支持 Istio |
| ||
| 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 |
| 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相对于之前，改动较大的一版
- 改为单体应用（将pilot等组件融合到一起），部署更加简单
- 扩展能力实现方式（架构还是性能的问题）
- envoy层面扩展使用C++内置，需要重新编译
- 原来的mixer扩展插件化允许自定义策略和遥测
- 使用 WebAssembly（Wasm）将 Istio 的可扩展性模型与 Envoy 统一；提高性能且保证了灵活性
- 过渡期mixer等功能继续存在，直到1.7版本；wasm生态正在持续构建中
4.部署方式
是否支持宿主机部署（非k8s）方式
- 从
Linkerd 1.*和 Envoy的支持，（第一代） - 到 Istio /
Linkerd 2.*的不支持，（第二代）- 相比虚拟机，k8s提供了太多便利。随着容器的普及，k8s的一统天下，社区对云原生的日益接受，虚拟机模式失宠容易理解
- 再到 AWS app mesh 和 Google Traffic Director 的支持
- AWS 考虑商业竞争
- google 考虑 理想与现实的差距
K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容
更多推荐
1
0- 0
已为社区贡献3条内容
所有评论(0)