update service mesh chapter
Jimmy Song
parent
524eb3d7b1
commit
4e39309d69
22
SUMMARY.md
22
SUMMARY.md
|
|
@ -209,21 +209,18 @@
|
|||
* [OpenKruise](practice/openkruise.md)
|
||||
* [原地升级](practice/in-place-update.md)
|
||||
|
||||
## 领域应用
|
||||
## 服务网格
|
||||
|
||||
* [领域应用概览](usecases/index.md)
|
||||
* [微服务架构](usecases/microservices.md)
|
||||
* [微服务中的服务发现](usecases/service-discovery-in-microservices.md)
|
||||
* [使用 Java 构建微服务并发布到 Kubernetes 平台](usecases/microservices-for-java-developers.md)
|
||||
* [Spring Boot 快速开始指南](usecases/spring-boot-quick-start-guide.md)
|
||||
* [服务网格（Service Mesh）](usecases/service-mesh.md)
|
||||
* [企业级服务网格架构](usecases/the-enterprise-path-to-service-mesh-architectures.md)
|
||||
* [Service Mesh 基础](usecases/service-mesh-fundamental.md)
|
||||
* [Service Mesh 技术对比](usecases/comparing-service-mesh-technologies.md)
|
||||
* [服务网格基础](usecases/service-mesh-fundamental.md)
|
||||
* [服务网格技术对比](usecases/comparing-service-mesh-technologies.md)
|
||||
* [服务网格对比 API 网关](usecases/service-mesh-vs-api-gateway.md)
|
||||
* [采纳和演进](usecases/service-mesh-adoption-and-evolution.md)
|
||||
* [定制和集成](usecases/service-mesh-customization-and-integration.md)
|
||||
* [总结](usecases/service-mesh-conclusion.md)
|
||||
* [Istio](usecases/istio.md)
|
||||
* [使用 Istio 前需要考虑的问题](usecases/before-using-istio.md)
|
||||
* [安装并试用 Istio](usecases/istio-installation.md)
|
||||
* [Istio 中 sidecar 的注入规范及示例](usecases/sidecar-spec-in-istio.md)
|
||||
* [如何参与 Istio 社区及注意事项](usecases/istio-community-tips.md)
|
||||
|
|
@ -236,6 +233,15 @@
|
|||
* [Envoy 的架构与基本术语](usecases/envoy-terminology.md)
|
||||
* [Envoy 作为前端代理](usecases/envoy-front-proxy.md)
|
||||
* [Envoy mesh 教程](usecases/envoy-mesh-in-kubernetes-tutorial.md)
|
||||
|
||||
## 领域应用
|
||||
|
||||
* [领域应用概览](usecases/index.md)
|
||||
* [微服务架构](usecases/microservices.md)
|
||||
* [微服务中的服务发现](usecases/service-discovery-in-microservices.md)
|
||||
* [使用 Java 构建微服务并发布到 Kubernetes 平台](usecases/microservices-for-java-developers.md)
|
||||
* [Spring Boot 快速开始指南](usecases/spring-boot-quick-start-guide.md)
|
||||
|
||||
* [大数据](usecases/big-data.md)
|
||||
* [Spark standalone on Kubernetes](usecases/spark-standalone-on-kubernetes.md)
|
||||
* [运行支持 Kubernetes 原生调度的 Spark 程序](usecases/running-spark-with-kubernetes-native-scheduler.md)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,103 @@
|
|||
## 使用 Istio 前需要考虑的问题
|
||||
|
||||
在使用 Istio 之前，请先考虑下以下因素：
|
||||
|
||||
- 你的团队里有多少人？
|
||||
- 你的团队是否有使用 Kubernetes、Istio 的经验？
|
||||
- 你有多少微服务？
|
||||
- 这些微服务使用什么语言？
|
||||
- 你的运维、SRE 团队是否可以支持服务网格管理？
|
||||
- 你有采用开源项目的经验吗？
|
||||
- 你的服务都运行在哪些平台上？
|
||||
- 你的应用已经容器化并使用 Kubernetes 管理了吗？
|
||||
- 你的服务有多少是部署在虚拟机、有多少是部署到 Kubernetes 集群上，比例如何？
|
||||
- 你的团队有指定云原生化的计划吗？
|
||||
- 你想使用 Istio 的什么功能？
|
||||
- Istio 的稳定性是否能够满足你的需求？
|
||||
- 你是否可以忍受 Istio 带来的性能损耗？
|
||||
|
||||
下面的内容引用自陈鹏[在生产环境使用 Istio 前的若干考虑要素](https://cloudnative.to/blog/the-facts-of-using-istio/)，有删改。
|
||||
|
||||
## 使用 Istio 无法做到完全对应用透明
|
||||
|
||||
服务通信和治理相关的功能迁移到 sidecar 进程中后， 应用中的 SDK 通常需要作出一些对应的改变。
|
||||
|
||||
比如 SDK 需要关闭一些功能，例如重试。一个典型的场景是，SDK 重试 m 次，sidecar 重试 n 次，这会导致 m * n 的重试风暴，从而引发风险。
|
||||
|
||||
此外，诸如 trace header 的透传，也需要 SDK 进行升级改造。如果你的 SDK 中还有其它特殊逻辑和功能，这些可能都需要小心处理才能和 Isito sidecar 完美配合。
|
||||
|
||||
## Istio 对非 Kubernetes 环境的支持有限
|
||||
|
||||
在业务迁移至 Istio 的同时，可能并没有同步迁移至 Kubernetes，而还运行在原有 PAAS 系统之上。 这会带来一系列挑战：
|
||||
|
||||
- 原有 PaaS 可能没有容器网络，Istio 的服务发现和流量劫持都可能要根据旧有基础设施进行适配才能正常工作；
|
||||
- 如果旧有的 PAAS 单个实例不能很好的管理多个容器（类比 Kubernetes 的 Pod 和 Container 概念），大量 Istio sidecar 的部署和运维将是一个很大的挑战；
|
||||
- 缺少 Kubernetes webhook 机制，sidecar 的注入也可能变得不那么透明，而需要耦合在业务的部署逻辑中；
|
||||
|
||||
## 只有 HTTP 协议是一等公民
|
||||
|
||||
Istio 原生对 HTTP 协议提供了完善的全功能支持，但在真实的业务场景中，私有化协议却非常普遍，而 Istio 却并未提供原生支持。
|
||||
|
||||
这导致使用私有协议的一些服务可能只能被迫使用 TCP 协议来进行基本的请求路由，这会导致很多功能的缺失，这其中包括 Istio 非常强大的基于内容的消息路由，如基于 header、 path 等进行权重路由。
|
||||
|
||||
## 扩展 Istio 的成本并不低
|
||||
|
||||
虽然 Istio 的总体架构是基于高度可扩展而设计，但由于整个 Istio 系统较为复杂，如果你对 Istio 进行过真实的扩展，就会发现成本不低。
|
||||
|
||||
以扩展 Istio 支持某一种私有协议为例，首先你需要在 Istio 的 API 代码库中进行协议扩展，其次你需要修改 Istio 代码库来实现新的协议处理和下发，然后你还需要修改 xds 代码库的协议，最后你还要在 Envoy 中实现相应的 Filter 来完成协议的解析和路由等功能。
|
||||
|
||||
在这个过程中，你还可能面临上述数个复杂代码库的编译等工程挑战（如果你的研发环境不能很好的使用 Docker 或者无法访问部分国外网络的情况下）。
|
||||
|
||||
即使做完了所有的这些工作，你也可能面临这些工作无法合并回社区的情况，社区对私有协议的扩展支持度不高，这会导致你的代码和社区割裂，为后续的升级更新带来隐患。
|
||||
|
||||
## Istio 在集群规模较大时的性能问题
|
||||
|
||||
Istio 默认的工作模式下，每个 sidecar 都会收到全集群所有服务的信息。如果你部署过 Istio 官方的 Bookinfo 示例应用，并使用 Envoy 的 config dump 接口进行观察，你会发现，仅仅几个服务，Envoy 所收到的配置信息就有将近 20w 行。
|
||||
|
||||
可以想象，在稍大一些的集群规模，Envoy 的内存开销、Istio 的 CPU 开销、XDS 的下发时效性等问题，一定会变得尤为突出。
|
||||
|
||||
Istio 这么做一是考虑这样可以开箱即用，用户不用进行过多的配置，另外在一些场景，可能也无法梳理出准确的服务之间的调用关系，因此直接给每个 sidecar 下发了全量的服务配置，即使这个 sidecar 只会访问其中很小一部分服务。
|
||||
|
||||
当然这个问题也有解法，你可以通过 sidecar CRD 来显示定义服务调用关系，使 Envoy 只得到他需要的服务信息，从而大幅降低 Envoy 的资源开销，但前提是在你的业务线中能梳理出这些调用关系。
|
||||
|
||||
## XDS 分发没有分级发布机制
|
||||
|
||||
当你对一个服务的策略配置进行变更的时候，XDS 不具备分级发布的能力，所有访问这个服务的 Envoy 都会立即收到变更后的最新配置。这在一些对变更敏感的严苛生产环境，可能是有很高风险甚至不被允许的。
|
||||
|
||||
如果你的生产环境严格要求任何变更都必须有分级发布流程，那你可能需要考虑自己实现一套这样的机制。
|
||||
|
||||
## Istio 组件故障时是否有退路？
|
||||
|
||||
以 Istio 为代表的 sidecar 架构的特殊性在于，sidecar 直接承接了业务流量，而不像一些其他的基础设施那样，只是整个系统的旁路组件（比如 Kubernetes）。
|
||||
|
||||
因此在 Isito 落地初期，你必须考虑，如果 sidecar 进程挂掉，服务怎么办？是否有退路？是否能 fallback 到直连模式？
|
||||
|
||||
在 Istio 落地过程中，是否能无损 fallback，通常决定了核心业务能否接入服务网格。
|
||||
|
||||
## Istio 缺乏成熟的产品生态
|
||||
|
||||
Istio 作为一套技术方案，却并不是一套产品方案。如果你在生产环境中使用，你可能还需要解决可视化界面、权限和账号系统对接、结合公司已有技术组件和产品生态等问题，仅仅通过命令行来使用，可能并不能满足你的组织对权限、审计、易用性的要求。
|
||||
|
||||
而 Isito 自带的 Kiali 功能还十分简陋，远远没有达到能在生产环境使用的程度，因此你可能需要研发基于 Isito 的上层产品。目前有一些服务网格的商业化公司致力于解决 Istio 的产品生态问题，如 [Tetrate](https://tetrate.io) 就是在基于 Istio、Envoy 和 Apache SkyWalking 构建企业级服务网格。
|
||||
|
||||
## Istio 目前解决的问题域还很有限
|
||||
|
||||
Istio 目前主要解决的是分布式系统之间服务调用的问题，但还有一些分布式系统的复杂语义和功能并未纳入到 Istio 的 sidecar 运行时之中，比如消息发布和订阅、状态管理、资源绑定等等。
|
||||
|
||||
云原生应用将会朝着多 sidecar 运行时或将更多分布式能力纳入单 sidecar 运行时的方向继续发展，以使服务本身变得更为轻量，让应用和基础架构彻底解耦。
|
||||
|
||||
如果你的生产环境中，业务系统对接了非常多和复杂的分布式系系统中间件，Istio 目前可能并不能完全解决你的应用的云原生化诉求。
|
||||
|
||||
## 总结
|
||||
|
||||
看到这里，你是否感到有些沮丧，而对 Isito 失去信心？别担心，上面列举的这些问题，实际上并不影响 Isito 依然是目前最为流行和成功的服务网格技术选型之一。Istio 频繁的变动，一定程度上也说明它拥有一个活跃的社区，我们应当对一个新的事物报以信心，Isito 的社区也在不断听取来自终端用户的声音，朝着大家期待的方向演进。
|
||||
|
||||
同时，如果你的生产环境中的服务规模并不是很大，服务已经托管于 Kubernetes 之上，也只使用那些 Istio 原生提供的能力，那么 Istio 依然是一个值得尝试的开箱即用方案。
|
||||
|
||||
但如果你的生产环境比较复杂，技术债务较重，专有功能和策略需求较多，亦或者服务规模庞大，那么在开始使用 Istio 之前，你需要仔细权衡上述这些要素，以评估在你的系统之中引入 Istio 可能带来的复杂度和潜在成本。
|
||||
|
||||
## 参考
|
||||
|
||||
- [你是否真的需要 Istio？ - i.cloudnative.to](https://i.cloudnative.to/istio/begin/do-you-really-need-istio)
|
||||
- [在生产环境使用 Istio 前的若干考虑要素 - cloudnative.to](https://cloudnative.to/blog/the-facts-of-using-istio/)
|
||||
|
||||
|
|
@ -1,8 +1,8 @@
|
|||
# Service Mesh 技术对比
|
||||
# 服务网格技术对比
|
||||
|
||||
这一章主要讲解的是 service mesh 与其他技术之间的区别以及为什么有了 Kubernetes 后还需要用 service mesh。
|
||||
这一章主要讲解的是服务网格其他技术之间的区别以及为什么有了 Kubernetes 后还需要用服务网格。
|
||||
|
||||
为什么有了如 Kubernetes 这样的容器编排我们还需要 Service Mesh 呢，下表是对容器编排调度器的核心功能和缺少的服务级别能力对比。
|
||||
为什么有了如 Kubernetes 这样的容器编排我们还需要 服务网格呢，下表是对容器编排调度器的核心功能和缺少的服务级别能力对比。
|
||||
|
||||
| 核心能力 | 缺少的服务级别能力 |
|
||||
| ---------------------------- | ------------------------------- |
|
||||
|
|
@ -18,10 +18,10 @@
|
|||
| 配置和秘钥管理 | 配额管理 |
|
||||
| / | 协议转换（REST、gRPC） |
|
||||
|
||||
以上是容器编排中缺少的服务级别的能力，当然类似 Kubernetes 这样的容器编排系统中也有服务管理的能力，如 Ingress Controller，但是它仅仅负责集群内的服务对外暴露的反向代理，每个 Ingress Controller 的能力受限于 Kubernetes 的编程模型。对服务进行管理还可以通过例如 Kong、基于云的负载均衡器、API Gateway 和 API 管理来实现，在没有 Service Mesh 的时候还需要如 [Finagle](https://finagle.github.io/blog/)、[Hystrix](https://github.com/Netflix/Hystrix)、[Ribbon](https://github.com/Netflix/ribbon) 客户端库的加持。
|
||||
以上是容器编排中缺少的服务级别的能力，当然类似 Kubernetes 这样的容器编排系统中也有服务管理的能力，如 Ingress Controller，但是它仅仅负责集群内的服务对外暴露的反向代理，每个 Ingress Controller 的能力受限于 Kubernetes 的编程模型。对服务进行管理还可以通过例如 Kong、基于云的负载均衡器、API Gateway 和 API 管理来实现，在没有服务网格的时候还需要如 [Finagle](https://finagle.github.io/blog/)、[Hystrix](https://github.com/Netflix/Hystrix)、[Ribbon](https://github.com/Netflix/ribbon) 客户端库的加持。
|
||||
|
||||
下图是一个使用**客户端库**将应用与服务治理紧耦合的示意图。
|
||||
|
||||
|
||||
|
||||
从图中我们可以看到，应用程序代码与客户端度库紧耦合在一起，不同的服务团队需要一起协调超时和重试机制等。容器编排更适用于分布式应用，API Gateway 通常只需要部署在系统边缘即可，不需要在每个应用中都部署，而 service mesh 却需要在每个服务或者说节点中部署。
|
||||
从图中我们可以看到，应用程序代码与客户端度库紧耦合在一起，不同的服务团队需要一起协调超时和重试机制等。容器编排更适用于分布式应用，API Gateway 通常只需要部署在系统边缘即可，不需要在每个应用中都部署，而服务网格却需要在每个服务或者说节点中部署。
|
||||
|
|
|
|||
|
|
@ -1,14 +1,10 @@
|
|||
# 总结
|
||||
|
||||
最后是对全书的总结，2018年必然是一场服务网格或者说Proxy的战争。
|
||||
既然服务网格这么好，那到底用还是不用，如果用的话应该什么时候用，应该怎么用？这取决于您的公司的云原生技术的成熟度曲线的位置，服务的规模，业务核心和底层基础设施管理是否适应等。
|
||||
|
||||
### 用还是不用
|
||||
技术总是在不断向前发展，容器出现后，解决的软件环境和分发的问题；但是如何管理分布式的应用呢，又出现了容器编排软件；容器编排软件解决的微服务的部署问题，但是对于微服务的治理的功能太弱，这才出现了服务网格，当然服务网格也不是万能的，下一步会走向何方呢？会是 Serverless 吗？我们拭目以待。
|
||||
|
||||
既然Service Mesh这么好，那到底用还是不用，如果用的话应该什么时候用，应该怎么用？这取决于您的公司的云原生技术的成熟度曲线的位置，服务的规模，业务核心和底层基础设施管理是否适应等。
|
||||
|
||||
技术总是在不断向前发展，容器出现后，解决的软件环境和分发的问题；但是如何管理分布式的应用呢，又出现了容器编排软件；容器编排软件解决的微服务的部署问题，但是对于微服务的治理的功能太弱，这才出现了Service Mesh，当然Service Mesh也不是万能的，下一步会走向何方呢？会是Serverless吗？我们拭目以待。
|
||||
|
||||
Service Mesh还有一些遗留的问题没有解决或者说比较薄弱的功能：
|
||||
服务网格还有一些遗留的问题没有解决或者说比较薄弱的功能：
|
||||
|
||||
- 分布式应用的调试，可以参考 [squash](https://github.com/solo-io/squash)
|
||||
- 服务拓扑和状态图，可以参考 [kiali](https://github.com/kiali/kiali) 和 [vistio](https://github.com/nmnellis/vistio)
|
||||
|
|
@ -18,10 +14,10 @@ Service Mesh还有一些遗留的问题没有解决或者说比较薄弱的功
|
|||
- 更高级的 fallback 路径支持
|
||||
- 可拔插的证书授权组建，支持外部的 CA
|
||||
|
||||
下面是采纳Service Mesh之前需要考虑的因素。
|
||||
下面是采纳服务网格之前需要考虑的因素。
|
||||
|
||||
| 因素 | 可以考虑使用Service Mesh | 强烈建议使用Service Mesh |
|
||||
| --------- | ------------------------------------------------------ | ------------------------------------------------------------ |
|
||||
| 因素 | 可以考虑使用服务网格 | 强烈建议使用服务网格 |
|
||||
| ---------- | --------------------------------------------------------- | ------------------------------------------------------------ |
|
||||
| 服务通信 | 基本无需跨服务间的通讯 | 十分要求服务间通讯 |
|
||||
| 可观察性 | 只关注边缘的指标即可 | 内部服务和边缘指标都要考虑以更好的了解服务的行为 |
|
||||
| 客户关注 | 主要关注外部 API 的体验，内外用户是隔离的 | 内部外部用户没有区别体验一致 |
|
||||
|
|
@ -29,3 +25,4 @@ Service Mesh还有一些遗留的问题没有解决或者说比较薄弱的功
|
|||
| 安全模型 | 通过边缘、防火墙可信内部网络的方式控制安全 | 所有的服务都需要认证和鉴权、服务间要加密、zero-trust 安全观念 |
|
||||
|
||||
在考虑完上述因素后，尽量选择开源的平台和解决方案，还要想好开源软件的边界在哪里，哪些能力将是企业版才会提供的。
|
||||
|
||||
|
|
|
|||
|
|
@ -1,25 +1,19 @@
|
|||
# 定制和集成
|
||||
|
||||
例如Istio这样的Service Mesh中有很多地方可以给大家定制，例如作为数据平面的sidecar，虽然默认使用的是Envoy，但是你可以开发自己的sidecar代理；还有Mixer中的各种adpater，你也可以开发自己的adapter来扩展遥测和鉴权功能，[Consul Connect](http://www.servicemesher.com/blog/consul-1-2-service-mesh/)就是个例子。
|
||||
例如 Istio 这样的 Service Mesh 中有很多地方可以给大家定制，例如作为数据平面的 sidecar，虽然默认使用的是 Envoy，但是你可以开发自己的 sidecar 代理。
|
||||
|
||||
当前可选择的开源的代理可以在[landscape](http://layer5.io/landscape/)里找到，例如使用nginMesh替代Envoy作为数据平面。下图是使用nginMesh作为sidecar的架构图。
|
||||
当前可选择的开源的代理可以在 [Service Mesh Landscape](https://layer5.io/service-mesh-landscape) 里找到，例如使用 nginMesh 替代 Envoy 作为数据平面。下图是使用 nginMesh 作为 sidecar 的架构图。
|
||||
|
||||
**nginMesh**
|
||||
## nginMesh
|
||||
|
||||
|
||||
|
||||
通过扩展Istio Mixer adapter来对接不同的监控后端。
|
||||
## MOSN
|
||||
|
||||
|
||||
|
||||
**MOSN**
|
||||
|
||||
还有蚂蚁金服开源的Go语言版的数据平面[MOSN](https://github.com/mosn/mosn)，这是也兼容Istio的SOFAMesh的一部分，也可以单独作为代理使用，详见：[蚂蚁金服开源SOFAMesh](https://jimmysong.io/blog/sofamesh-and-mosn-proxy-sidecar-service-mesh-by-ant-financial/)。
|
||||
还有蚂蚁集团开源的 Go 语言版的数据平面 [MOSN](https://github.com/mosn/mosn)，同时兼容 Istio，也可以单独作为代理使用，详见[在 Istio 中使用 MOSN：另一个数据平面](https://istio.io/latest/zh/blog/2020/mosn-proxy/)。
|
||||
|
||||
|
||||
|
||||
[MOSN](https://github.com/mosn/mosn)的模块架构图。
|
||||
## 参考
|
||||
|
||||
|
||||
|
||||
在未来我们会看到更多定制的数据平面和Mixer适配器出现。
|
||||
- [在 Istio 中使用 MOSN：另一个数据平面 - istio.io](https://istio.io/latest/zh/blog/2020/mosn-proxy/)
|
||||
|
|
@ -1,22 +1,22 @@
|
|||
# Service Mesh基础
|
||||
# 服务网格基础
|
||||
|
||||
> 本文是对[The Enterprise Path to Service Mesh Architecutures](https://www.nginx.com/resources/library/the-enterprise-path-to-service-mesh-architectures/)一书的解读。
|
||||
> 本文是对 [The Enterprise Path to Service Mesh Architectures ](https://www.nginx.com/resources/library/the-enterprise-path-to-service-mesh-architectures/)一书的解读。
|
||||
|
||||
微服务将原先的单体架构中的应用内通信，转变为基于 RPC 的远程通信，虽然这样提高了研发效率，提高了开发语言选择的多样性，但是随着单体应用的解体，原先的巨石散落为石块变得四处都是，如何管理这些微服务就成了难题。当微服务的个数少的时候还可以通过人工配置的方式去管理，但随着业务规模的增大，微服务的数量也可能呈指数级增长，如何协调管理成百上千的服务，这就需要有一套设计良好的框架。
|
||||
|
||||
一直以来都存在一个[谬误](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)，那就是在分布式系统中网络是可靠的。实际上网络是不可靠的，而且也是不安全的，如何保证应用调用和事务的安全性与可靠性，保护微服务的一个专门的基础设施层Service Mesh就应运而生。
|
||||
一直以来都存在一个[谬误](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)，那就是在分布式系统中网络是可靠的。实际上网络是不可靠的，而且也是不安全的，如何保证应用调用和事务的安全性与可靠性，保护微服务的一个专门的基础设施层服务网格就应运而生。
|
||||
|
||||
Service Mesh是建立在物理或者虚拟网络层之上的，基于策略的微服务的流量控制，与一般的网络协议不同的是它有以下几个特点：
|
||||
服务网格是建立在物理或者虚拟网络层之上的，基于策略的微服务的流量控制，与一般的网络协议不同的是它有以下几个特点：
|
||||
|
||||
- 开发者驱动
|
||||
- 可配置策略
|
||||
- 服务优先的网络配置而不是协议
|
||||
|
||||
本章主要介绍Service Mesh的定义和组成，为什么要使用Service Mesh，它可以带来哪些好处。
|
||||
本章主要介绍服务网格的定义和组成，为什么要使用服务网格，它可以带来哪些好处。
|
||||
|
||||
|
||||
|
||||
|
||||
Service Mesh与传统网络的区别就是**硬件或者虚拟网络**与**软件定义网络（SDN）**的区别，我们从上图中可以看到物理和虚拟网络中比起SDN还多了**管理平面**。
|
||||
服务网格与传统网络的区别就是**硬件或者虚拟网络**与**软件定义网络（SDN）**的区别，我们从上图中可以看到物理和虚拟网络中比起 SDN 还多了 \**管理平面**。
|
||||
|
||||
硬件网络中控制平面与数据平面紧耦合，也就是说是与供应商绑定的，管理平面是独立出来的。而 SDN 却给了我们很多自由度，可以通过软件的形式自定义网络，例如 Kubernetes 中的 [CNI](https://jimmysong.io/kubernetes-handbook/concepts/cni.html)。
|
||||
|
||||
|
|
@ -26,13 +26,13 @@ Service Mesh与传统网络的区别就是**硬件或者虚拟网络**与**软
|
|||
|
||||
|
||||
|
||||
### Service Mesh架构
|
||||
### 服务网格架构
|
||||
|
||||
下图是[Conduit](https://condiut.io) Service Mesh（现在已合并到Linkerd2中了）的架构图，这是Service Mesh的一种典型的架构。
|
||||
下图是曾经的 Conduit 服务网格（已合并到 Linkerd2 中了）的架构图，这是服务网格的一种典型的架构。
|
||||
|
||||
|
||||
|
||||
|
||||
Service Mesh中分为**控制平面**和**数据平面**，当前流行的两款开源的Service Mesh Istio和Linkerd实际上都是这种构造，只不过Istio的划分更清晰，而且部署更零散，很多组件都被拆分，控制平面中包括Mixer、Pilot、Citadel，数据平面默认是用Envoy；而Linkerd中只分为linkerd做数据平面，namerd作为控制平面。
|
||||
服务网格中分为**控制平面**和**数据平面**，当前流行的两款开源的服务网格 Istio 和 Linkerd 实际上都是这种构造，只不过 Istio 的划分更清晰，而且部署更零散，很多组件都被拆分，控制平面中包括 Mixer（Istio 1.5 之前版本）、Pilot、Citadel，数据平面默认是用 Envoy；而 Linkerd 中只分为 Linkerd 做数据平面，namerd 作为控制平面。
|
||||
|
||||
**控制平面**
|
||||
|
||||
|
|
@ -51,13 +51,13 @@ Service Mesh中分为**控制平面**和**数据平面**，当前流行的两款
|
|||
- 直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等
|
||||
- 对应用来说透明，即可以做到无感知部署
|
||||
|
||||
### Service Mesh的价值所在
|
||||
### 服务网格的价值所在
|
||||
|
||||
Service Mesh中服务是一等公民，它提供L5的网络流量管理，并提供以下功能：
|
||||
服务网格中服务是一等公民，它提供 L5 的网络流量管理，并提供以下功能：
|
||||
|
||||
**可观察性**
|
||||
|
||||
还是拿Istio做例子，Mixer通过适配器将应用的遥测数据发送给后端监控、日志、认证和份额管理系统。
|
||||
还是拿 Istio 做例子，Mixer（Istio 1.5 之后已从 Istio 内部移除，转而合并到数据平面中） 通过适配器将应用的遥测数据发送给后端监控、日志、认证和份额管理系统。
|
||||
|
||||
|
||||
|
||||
|
|
@ -85,9 +85,9 @@ Service Mesh中服务是一等公民，它提供L5的网络流量管理，并提
|
|||
|
||||
|
||||
|
||||
*OSI模型（图片来自[CSDN](https://blog.csdn.net/yaopeng_2005/article/details/7064869)）*
|
||||
- *OSI 模型（图片来自 [CSDN](https://blog.csdn.net/yaopeng_2005/article/details/7064869)）*
|
||||
|
||||
Service Mesh是在开发和运维之间植入的一个基础设施层。它将服务通信的关注点分离出来，在TCP/IP层之上抽象出一层通用功能。Service Mesh的引入直接导致生产关系的改变进而提高生产效率。具体表现在：
|
||||
服务网格是在开发和运维之间植入的一个基础设施层。它将服务通信的关注点分离出来，在 TCP/IP 层之上抽象出一层通用功能。服务网格的引入直接导致生产关系的改变进而提高生产效率。具体表现在：
|
||||
|
||||
- **运维人员**在修改服务重试超时时间之前无需再知会**开发人员**。
|
||||
- **客户成功**部门在撤销客户的访问权限前无需再知会**运维**。
|
||||
|
|
@ -96,4 +96,4 @@ Service Mesh是在开发和运维之间植入的一个基础设施层。它将
|
|||
|
||||
|
||||
|
||||
这种职责的解耦大大加速了软件的迭代速度，总之你可以把Service Mesh作为OSI模型中的会话层。
|
||||
这种职责的解耦大大加速了软件的迭代速度，总之你可以把服务网格作为 OSI 模型中的会话层。
|
||||
|
|
|
|||
|
|
@ -0,0 +1,92 @@
|
|||
# 服务网格对比 API 网关
|
||||
|
||||
API网关（API Gateway）为所有与应用程序后端交互的客户端流量提供单一的入口和出口点，作为集群南北流量的入口；服务网格既可以管理南北流量，又可以管理集群内部的东西流量，其基本涵盖了 API 网关的功能。
|
||||
|
||||
本文将为你介绍：
|
||||
|
||||
- 为什么需要 API 网关？
|
||||
- 何时使用网关？
|
||||
- 服务网格与 API 网关有什么关系？
|
||||
- 使用服务网格后还需要 API 网关吗？
|
||||
|
||||
## 为什么需要 API 网关？
|
||||
|
||||
客户端可能是你的应用程序的前端，形式是网页或应用程序，也可能是你的组织内部需要与你的应用程序交互的其他内部服务，或者是第三方客户端应用程序和网站。像API代理一样，网关接收传入的请求，并将其引导到系统的相关部分，然后将响应转发回客户端。但API网关不仅仅是一个简单的反向代理服务，它提供了一个统一的接口，并提供了安全、负载均衡、请求和响应转换、监控和追踪等功能。
|
||||
|
||||
## 什么是 API 网关？
|
||||
|
||||
API 网关主要功能是：作为客户端访问的统一界面，并且可以管理 API，确保流量安全。
|
||||
|
||||
### 统一界面
|
||||
|
||||
API网关的主要好处之一是能够将后端系统的复杂性与客户端交互的外向API解耦。API网关在微服务架构中特别受欢迎，在微服务架构中，一个应用程序可能由数十甚至数百个松散耦合的服务组成，这些服务通过网络相互通信。通过将系统分解为微服务（基于业务功能的较小组件），开发团队可以比单体设计更快速地交付变更。
|
||||
|
||||
然而，微服务架构的更大灵活性和敏捷性带来了更大的复杂性；每个服务可能用不同的语言或框架编写，并通过API、RPC或消息协议与其他组件进行通信。这就是API网关的作用。API网关不是要求系统外的客户端直接与各种后端服务交互，而是在系统边缘添加一个API网关，为外部客户提供一个统一的接。网关作为一个抽象层，为整个应用提供面向外部的API端点，并掩盖了底层服务的复杂性。
|
||||
|
||||
在后端和客户端之间有了这个抽象层，又增加了一个好处。微服务架构的优势之一是，各个团队可以快速、定期发布变更。然而，当这些变化涉及到对API的定期更新时，客户端可能很难保持更新。使用API网关可以让面向外部的API端点保持更稳定，后端变化会影响到从网关到后端的连接，而客户端保持不变，除非正在添加或删除功能。
|
||||
|
||||
此外，对于从单体架构过渡到微服务的组织来说，提供一致的面向客户端的接口可以使过渡过程更加顺利，因为这样对前端来说是透明的，后端的变化是隐藏的。
|
||||
|
||||
### 管理 API
|
||||
|
||||
API代理只是简单地路由请求和响应，而API网关则提供了围绕管理传入和传出流量的额外功能。网关还可以处理跨多个后端实例的服务发现和请求的负载均衡。在商业化API的情况下，客户根据请求的数量和/或频率付费，网关可以管理不同客户的速率限制。
|
||||
|
||||
API网关可以通过金丝雀发布来促进新功能的发布过程。网关将指定比例的传入请求路由到服务的新版本，使负责的团队能够监控问题，同时限制任何失败的影响。一旦团队有信心，流量就会切换到新版本。
|
||||
|
||||
网关的配置通常通过命令行界面或管理员API应用的策略进行管理，有些网关还提供管理GUI。
|
||||
|
||||
### 确保流量安全
|
||||
|
||||
作为您的应用程序的入口点，API网关的理想定位是确保传入请求的安全和保护您的系统。在网关上实施身份验证和授权可以防止恶意行为者获得对服务的访问，而节流请求的数量和维护白名单和/或黑名单可以降低分布式拒绝服务攻击的风险。API网关还可以管理客户端之间和系统内部的通信加密。
|
||||
|
||||
在网关处应用安全性，不仅可以减少潜在的攻击面，还可以确保策略的应用一致且高效。在微服务架构中，集中式管理比要求为每个服务实现相同的功能更有效率，因为要实现的话可能会使用不同的语言和框架。
|
||||
|
||||
## 何时需要使用 API 网关？
|
||||
|
||||
虽然API以各种形式存在了几十年，但在过去的10年里，API的数量有了巨大的增长，因为组织越来越多地采用API优先的开发方法。在构建产品时，不是将客户端如网站或基于GUI的应用程序与后端紧密耦合，然后构建和暴露API，以允许第三方与同一系统进行交互，而是专注于提供一个对外的API，该API将被内部和外部的所有客户消费。这样不仅效率更高，而且还能为系统提供更多的使用机会。
|
||||
|
||||
举个简单的例子，一家航空公司有一个管理航班时刻表和可用性的系统。同样的API可以被航空公司自己的网站和移动应用以及第三方旅行预订服务使用，无论是面向企业还是面向消费者。虽然API优先的方法避免了新功能发布时的重复工作，但通过网关提供API可避免客户因后端变化而受到不必要的影响，并允许航空公司监控和确保使用、管理性能和交易变现。例如，航空公司可能希望对来自第三方客户端的请求适用不同的速率限制，并根据交易数量收费。
|
||||
|
||||
虽然API网关位于后端和客户端之间的边界，但这并不意味着它们必须面向外部。网关的目的是为客户提供一个与系统交互的接口，这些客户端可以是内部的，也可以是外部的。
|
||||
|
||||
例如，如果一个组织有多个独立的内部系统，例如一个管理产品订单的系统和一个独立的财务系统，可能需要允许一个系统向另一个系统发出请求。订单管理系统边缘的API网关将允许财务系统请求有关订单的数据。该网关还可以支持一个客户端网络应用，供财务团队用户查看数据和生成报表（进而导致对订单系统的请求）。当然，也可以建立一个由这些功能和数据存储组成的单一系统；系统之间的边界应该在哪里，取决于业务需求和背景。
|
||||
|
||||
## 选择API网关时的考虑因素
|
||||
|
||||
在决定一个API网关是否能满足你的需求之前，了解网关不做什么很重要。在围绕微服务构建的系统中，通过网关进来的每个请求必须被路由到相关的服务。只有在后端服务之间已经存在网络和通信方法的情况下，网关才能路由这些请求。在同步通信或异步通信之间进行选择，是按服务实现还是使用服务网格，这都是系统设计的重要部分，是否需要API网关，如果需要，选择哪一个。
|
||||
|
||||
选择API网关时，要同时考虑你的架构和部署环境。它们现在是什么样子的，你期望它们如何发展？你可能会从头开始构建一个云原生系统，以便利用容器和自动可扩展性的优势，或者你可能会在内部托管系统，并计划随着系统的发展进行混合部署。一些API网关是为特定环境设计的，而另一些则提供了与您的应用程序一起发展的灵活性。
|
||||
|
||||
根据设计，在您的系统中添加一个API网关，会给所有传入和传出的流量增加一个跳转。因此，在为您的系统选择网关时，性能应该是一个关键的考虑因素。并非所有的网关都是一样的，通过网关发送请求所产生的额外延迟会对最终用户产生明显的影响。另一方面，一些网关允许您跟踪请求和响应时间。这些性能数据不仅可以帮助您优化系统，而且还可以在某些东西没有按照预期工作时提供指示。
|
||||
|
||||
## 使用API网关时的最佳实践
|
||||
|
||||
作为系统的单一入口和出口点，网关需要确保对系统的访问安全。确保用户在通过之前进行身份验证和请求授权，应用转换以确保响应中只包含必要的信息，以及速率限制和流量节流都可以在网关上实施。
|
||||
|
||||
网关作为系统的单一入口点，不应该出现单点故障。稳健可靠的设计是一个良好的开端，但根据系统的正常运行时间要求，您可能希望实现API网关的高可用性集群。有些网关要求为每个实例复制数据存储，从而增加了整体成本，而其他网关则支持单数据库和多数据库实现。
|
||||
|
||||
由于所有流量都流经网关，它们是监控流量和观察系统行为理想地点。选择一个能够收集指标、支持日志记录和跟踪并提供分析趋势的仪表板的网关，可以让您更深入地了解您的系统，并使您能够在症状出现时迅速对问题做出反应。
|
||||
|
||||
## 服务网格与 API 网关的关系
|
||||
|
||||
上文说到，API 网关负责管理进出集群的入口，即**南北向流量**；服务网格的首要功能是管理集群内部服务间的流量，即**东西向流量**，而有些服务网格自带 API 网关，如 Istio 内置基于 Envoy 的 API 网关，Istio 中可以声明 Gateway 对象并与 VirtualService 绑定来履行网关职能，这样的服务网格可以接管进出集群及集群内部所有服务的流量。限于服务网格中内置的 sidecar 主要作为代理而存在，而未对作为 API 网关的功能作定制开发，可能在功能上逊色于传统的 API 网关。
|
||||
|
||||
## 使用了 API 网关是否还需要服务网格？
|
||||
|
||||
API 网关和服务网格并非二选一，两者可以同时存在。如果你已经有稳定成熟的微服务中间件，对于集群内服务的安全性、可观察性要求不高，可以继续沿用传统的 API 网关。但是如果你已经开始迁移到服务网格，并且希望构建零信任网络，对集群内服务进行全方位的可观察性分析，可以继续使用 API 网关和服务网格，或逐步将 API 网关迁移到服务网格中。
|
||||
|
||||
## 如何为服务网格选择 API 网关？
|
||||
|
||||
[这篇文章](https://cloudnative.to/blog/how-to-pick-gateway-for-service-mesh/)详细解读了 Kubernetes 如何对外暴露服务，Istio 服务网格是如何支持 API 网关的，虽然 Istio 内置了 Gateway，但是，你仍然可以选择自己喜欢的网关，如 Traefik，参考[在 Istio 服务网格中使用 Traefik Ingress Controller](https://cloudnative.to/blog/using-traefik-ingress-controller-with-istio-service-mesh/)。
|
||||
|
||||
## 结论
|
||||
|
||||
API网关为客户与您的系统进行交互提供了一个一致的接口，也是管理请求和响应的中心点。在微服务架构中，它们可以用来实现原本必须在每个单独服务中复制的功能，并且可以帮助从单体设计向松散耦合的服务平滑过渡。
|
||||
|
||||
在您的系统中添加一个API网关具有许多优势，但它也增加了另一个需要配置和维护的组件，因此您需要确保它得到有效的使用。在选择网关时，请考虑您的系统的现在和未来的需求；一个高性能、低延迟的网关，并可随着系统的发展而扩展功能，将确保它在不给系统增加多余重量的情况下提供价值。
|
||||
|
||||
## 参考
|
||||
|
||||
- [What is the Purpose of an API Gateway? - konghq.com](https://konghq.com/learning-center/api-gateway/)
|
||||
- [如何为服务网格选择入口网关？ - cloudnative.to](https://cloudnative.to/blog/how-to-pick-gateway-for-service-mesh/)
|
||||
- [在 Istio 服务网格中使用 Traefik Ingress Controller - cloudnative.to](https://cloudnative.to/blog/using-traefik-ingress-controller-with-istio-service-mesh/)
|
||||
|
|
@ -1,33 +1,35 @@
|
|||
# 服务网格（Service Mesh ）
|
||||
|
||||
**注意：本书中的 Service Mesh 章节已不再维护，请转到 [istio-handbook](https://www.servicemesher.com/istio-handbook) 中浏览。**
|
||||
Service Mesh 又译作 ”服务网格“，作为服务间通信的基础设施层。Buoyant 公司的 CEO Willian Morgan 在他的这篇文章 [What's a service mesh? And why do I need one?](https://buoyant.io/2020/10/12/what-is-a-service-mesh/) 中解释了什么是 Service Mesh，为什么云原生应用需要 Service Mesh。
|
||||
|
||||
Service mesh 又译作 ”服务网格“，作为服务间通信的基础设施层。Buoyant 公司的 CEO Willian Morgan 在他的这篇文章 [WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE?](https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/) 中解释了什么是 Service Mesh，为什么云原生应用需要 Service Mesh。
|
||||
英文原文如下：
|
||||
|
||||
> A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
|
||||
A服务网格is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the服务网格is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
|
||||
|
||||
今年来以 [Istio](https://istio.io) 和 [Linkderd](https://linkerd.io) 为代表的 Service Mesh 蓬勃发展，大有成为下一代语言异构微服务架构的王者之范，今天又碰巧看到了 Red Hat 的 [Burr Sutter](https://twitter.com/burrsutter) 提出了**8 Steps to Becoming Awesome with Kubernetes**，整个PPT一共60多页，很有建设性，[点此](https://github.com/rootsongjc/cloud-native-slides-share/blob/master/kubernetes/8-Steps-to-Becoming-Awesome-with-Kubernetes-readhat-burrsutter.pdf)跳转到我的GitHub上下载，我将其归档到[cloud-native-slides-share](https://github.com/rootsongjc/cloud-native-slides-share)中了。
|
||||
中文版：
|
||||
|
||||
服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。
|
||||
|
||||
近年来以 [Istio](https://istio.io) 为代表的服务网格蓬勃发展，大有成为下一代语言异构微服务架构的王者之范，下图来自红帽的 [Burr Sutter](https://twitter.com/burrsutter) 在他的主题分享”8 Steps to Becoming Awesome with Kubernetes” 幻灯片中的图片。
|
||||
|
||||
|
||||
|
||||
自我6月份初接触Istio依赖就发觉service mesh很好的解决了异构语言中的很多问题，而且是kuberentes service 上层不可或缺的服务间代理。关于istio的更多内容请参考 [istio 官方文档](https://istio.io)。
|
||||
服务网格可以很好的解决了异构语言中的很多问题，而且是 Kuberentes service 上层的通用的服务间代理。关于 Istio 的更多内容请参考 [Istio 官方文档](https://istio.io)。
|
||||
|
||||
## 什么是 service mesh？
|
||||
## 什么是服务网格？
|
||||
|
||||
Service mesh 有如下几个特点：
|
||||
服务网格有如下几个特点：
|
||||
|
||||
- 应用程序间通讯的中间层
|
||||
- 轻量级网络代理
|
||||
- 应用程序无感知
|
||||
- 解耦应用程序的重试/超时、监控、追踪和服务发现
|
||||
|
||||
目前两款流行的 service mesh 开源软件 [Istio](https://istio.io) 和 [Linkerd](https://linkerd.io) 都可以直接在 kubernetes 中集成，其中 Linkerd 已经成为 CNCF 成员。
|
||||
## 理解服务网格
|
||||
|
||||
## 理解 Service Mesh
|
||||
如果用一句话来解释什么是服务网格，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用服务网格也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给服务网格就可以了。
|
||||
|
||||
如果用一句话来解释什么是 Service Mesh，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心 TCP/IP 这一层（比如通过 HTTP 协议的 RESTful 应用），同样使用 Service Mesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud、OSS，现在只要交给 Service Mesh 就可以了。
|
||||
|
||||
[Phil Calçado](http://philcalcado.com/) 在他的这篇博客 [Pattern: Service Mesh](http://philcalcado.com/2017/08/03/pattern_service_mesh.html) 中详细解释了 Service Mesh 的来龙去脉：
|
||||
[Phil Calçado](http://philcalcado.com/) 在他的这篇博客 [Pattern: Service Mesh](http://philcalcado.com/2017/08/03/pattern_service_mesh.html) 中详细解释了服务网格的来龙去脉：
|
||||
|
||||
1. 从最原始的主机之间直接使用网线相连
|
||||
2. 网络层的出现
|
||||
|
|
@ -36,63 +38,43 @@ Service mesh 有如下几个特点：
|
|||
5. 应用程序的中集成服务发现和断路器
|
||||
6. 出现了专门用于服务发现和断路器的软件包/库，如 [Twitter 的 Finagle](https://finagle.github.io/) 和 [Facebook 的 Proxygen](https://code.facebook.com/posts/1503205539947302)，这时候还是集成在应用程序内部
|
||||
7. 出现了专门用于服务发现和断路器的开源软件，如 [Netflix OSS](http://netflix.github.io/)、Airbnb 的 [synapse](https://github.com/airbnb/synapse) 和 [nerve](https://github.com/airbnb/nerve)
|
||||
8. 最后作为微服务的中间层 service mesh 出现
|
||||
8. 最后作为微服务的中间层服务网格出现
|
||||
|
||||
Service mesh 的架构如下图所示：
|
||||
服务网格的架构如下图所示：
|
||||
|
||||
|
||||
|
||||
图片来自：[Pattern: Service Mesh](http://philcalcado.com/2017/08/03/pattern_service_mesh.html)
|
||||
|
||||
Service mesh 作为 sidecar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在 serivce mesh 中实现。
|
||||
服务网格会在每个 pod 中注入一个 sidecar 代理，该代理对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在服务网格中实现。
|
||||
|
||||
## Service mesh如何工作？
|
||||
## 服务网格如何工作？
|
||||
|
||||
下面以 Linkerd 为例讲解 service mesh 如何工作，Istio 作为 service mesh 的另一种实现原理与 linkerd 基本类似，后续文章将会详解 Istio 和 Linkerd 如何在 kubernetes 中工作。
|
||||
下面是服务网格的工作流程。
|
||||
|
||||
1. Linkerd 将服务请求路由到目的地址，根据中的参数判断是到生产环境、测试环境还是 staging 环境中的服务（服务可能同时部署在这三个环境中），是路由到本地环境还是公有云环境？所有的这些路由信息可以动态配置，可以是全局配置也可以为某些服务单独配置。
|
||||
2. 当 Linkerd 确认了目的地址后，将流量发送到相应服务发现端点，在 kubernetes 中是 service，然后 service 会将服务转发给后端的实例。
|
||||
3. Linkerd 根据它观测到最近请求的延迟时间，选择出所有应用程序的实例中响应最快的实例。
|
||||
4. Linkerd 将请求发送给该实例，同时记录响应类型和延迟数据。
|
||||
5. 如果该实例挂了、不响应了或者进程不工作了，Linkerd 将把请求发送到其他实例上重试。
|
||||
6. 如果该实例持续返回 error，Linkerd 会将该实例从负载均衡池中移除，稍后再周期性得重试。
|
||||
7. 如果请求的截止时间已过，Linkerd 主动失败该请求，而不是再次尝试添加负载。
|
||||
8. Linkerd 以 metric 和分布式追踪的形式捕获上述行为的各个方面，这些追踪信息将发送到集中 metric 系统。
|
||||
1. 控制平面将整个网格中的服务配置推送到所有节点的 sidecar 代理中。
|
||||
2. Sidecar 代理将服务请求路由到目的地址，根据中的参数判断是到生产环境、测试环境还是 staging 环境中的服务（服务可能同时部署在这三个环境中），是路由到本地环境还是公有云环境？所有的这些路由信息可以动态配置，可以是全局配置也可以为某些服务单独配置。
|
||||
3. 当 sidecar 确认了目的地址后，将流量发送到相应服务发现端点，在 Kubernetes 中是 service，然后 service 会将服务转发给后端的实例。
|
||||
4. Sidecar 根据它观测到最近请求的延迟时间，选择出所有应用程序的实例中响应最快的实例。
|
||||
5. Sidecar 将请求发送给该实例，同时记录响应类型和延迟数据。
|
||||
6. 如果该实例挂了、不响应了或者进程不工作了，sidecar 将把请求发送到其他实例上重试。
|
||||
7. 如果该实例持续返回 error，sidecar 会将该实例从负载均衡池中移除，稍后再周期性得重试。
|
||||
8. 如果请求的截止时间已过，sidecar 主动失败该请求，而不是再次尝试添加负载。
|
||||
9. Sidecar 以 metric 和分布式追踪的形式捕获上述行为的各个方面，这些追踪信息将发送到集中 metric 系统。
|
||||
|
||||
## 为何使用 service mesh？
|
||||
## 为何使用服务网格？
|
||||
|
||||
Service mesh 并没有给我们带来新功能，它是用于解决其他工具已经解决过的问题，只不过这次是在 Cloud Native 的 kubernetes 环境下的实现。
|
||||
服务网格并没有给我们带来新功能，它是用于解决其他工具已经解决过的问题，只不过这次是在云原生的 Kubernetes 环境下的实现。
|
||||
|
||||
在传统的 MVC 三层 Web 应用程序架构下，服务之间的通讯并不复杂，在应用程序内部自己管理即可，但是在现今的复杂的大型网站情况下，单体应用被分解为众多的微服务，服务之间的依赖和通讯十分复杂，出现了 twitter 开发的 [Finagle](https://twitter.github.io/finagle/)、Netflix 开发的 [Hystrix](https://github.com/Netflix/Hystrix) 和 Google 的 Stubby 这样的 ”胖客户端“ 库，这些就是早期的 service mesh，但是它们都近适用于特定的环境和特定的开发语言，并不能作为平台级的 service mesh 支持。
|
||||
在传统的 MVC 三层 Web 应用程序架构下，服务之间的通讯并不复杂，在应用程序内部自己管理即可，但是在现今的复杂的大型网站情况下，单体应用被分解为众多的微服务，服务之间的依赖和通讯十分复杂，出现了 Twitter 开发的 [Finagle](https://twitter.github.io/finagle/)、Netflix 开发的 [Hystrix](https://github.com/Netflix/Hystrix) 和 Google 的 Stubby 这样的 ”胖客户端“ 库，这些就是早期的服务网格，但是它们都近适用于特定的环境和特定的开发语言，并不能作为平台级的服务网格支持。
|
||||
|
||||
在 Cloud Native 架构下，容器的使用给予了异构应用程序的更多可行性，kubernetes 增强的应用的横向扩容能力，用户可以快速的编排出复杂环境、复杂依赖关系的应用程序，同时开发者又无须过分关心应用程序的监控、扩展性、服务发现和分布式追踪这些繁琐的事情而专注于程序开发，赋予开发者更多的创造性。
|
||||
|
||||
## Istio VS Linkerd
|
||||
|
||||
当前的Service Mesh实现主要有两大阵营，要给是Linkerd（也是最初提出该概念的），另一个是Istio，当然还有很多其他号称也是Service Mesh，比如Nginx出品的[Nginmesh](https://github.com/nginmesh/nginmesh)。
|
||||
|
||||
| **Feature** | **Istio** | **Linkerd** |
|
||||
| ----------- | ------------- | ---------------------------- |
|
||||
| 部署架构 | Envoy/Sidecar | DaemonSets |
|
||||
| 易用性 | 复杂 | 简单 |
|
||||
| 支持平台 | kuberentes | kubernetes/mesos/Istio/local |
|
||||
| 当前版本 | 0.3.0 | 1.3.3 |
|
||||
| 是否已有生产部署 | 否 | 是 |
|
||||
|
||||
下图是Istio和Linkerd架构的不同，Istio是使用Sidecar模式，将Envoy植入到Pod中，而Linkerd则是在每台node上都以DaemonSet的方式运行。
|
||||
|
||||
|
||||
|
||||
关于Istio和Linkerd的详细信息请参考 [安装并试用Istio service mesh](istio-installation.md) 与 [Linkerd 使用指南](linkerd-user-guide.md)。
|
||||
|
||||
另外出品Linkerd的公司buoyant又推出了[conduit](https://conduit.io)，这是一种更轻量级的Service Mesh。
|
||||
在云原生架构下，容器的使用给予了异构应用程序的更多可行性，Kubernetes 增强的应用的横向扩容能力，用户可以快速的编排出复杂环境、复杂依赖关系的应用程序，同时开发者又无须过分关心应用程序的监控、扩展性、服务发现和分布式追踪这些繁琐的事情而专注于程序开发，赋予开发者更多的创造性。
|
||||
|
||||
## 参考
|
||||
|
||||
- [WHAT’S A SERVICE MESH? AND WHY DO I NEED ONE?](https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/)
|
||||
- [So what even is a Service Mesh? Hot take on Istio and Linkerd](http://redmonk.com/jgovernor/2017/05/31/so-what-even-is-a-service-mesh-hot-take-on-istio-and-linkerd)
|
||||
- [linkerd: A service mesh for AWS ECS](https://medium.com/attest-engineering/linkerd-a-service-mesh-for-aws-ecs-937f201f847a)
|
||||
- [Introducing Istio: A robust service mesh for microservices](https://istio.io/blog/istio-service-mesh-for-microservices.html)
|
||||
- [Application Network Functions With ESBs, API Management, and Now.. Service Mesh?](http://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/)
|
||||
- [What's a service mesh? And why do I need one? - buoyant.io](https://buoyant.io/2020/10/12/what-is-a-service-mesh/)
|
||||
- [So what even is a Service Mesh? Hot take on Istio and Linkerd - hotmonk.com](http://redmonk.com/jgovernor/2017/05/31/so-what-even-is-a-service-mesh-hot-take-on-istio-and-linkerd)
|
||||
- [Introducing Istio: A robust service mesh for microservices - istio.io](https://istio.io/latest/news/releases/0.x/announcing-0.1/)
|
||||
- [Application Network Functions With ESBs, API Management, and Now.. Service Mesh? - blog.christianposta.com](http://blog.christianposta.com/microservices/application-network-functions-with-esbs-api-management-and-now-service-mesh/)
|
||||
- [Pattern: Service Mesh](http://philcalcado.com/2017/08/03/pattern_service_mesh.html)
|
||||
- [Istio官方文档](https://istio.io)
|
||||
- [Istio 官方文档 - istio.io](https://istio.io)
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# 企业级服务网格架构之路
|
||||
|
||||
本节是根据由Nginx赞助，O’Reilly出版社出品的关于服务网格的书籍总结而来，本书标题是 _The Enterprise Path to Service Mesh_ ，还有个副标题 _Decoupling at Layer 5_ ，第一版发行于2018年8月8日。这本书一共61页，本文是我对该书的一些解读，读者可以在[Nginx的网站](https://www.nginx.com/resources/library/the-enterprise-path-to-service-mesh-architectures/)上免费下载阅读完整内容。
|
||||
本节内容是对 O’Reilly 出版社出版的 *The Enterprise Path to Service Mesh* 一书内容的解读，本书还有个副标题 *Decoupling at Layer 5* ，第一版发行于 2018 年 8 月 8 日。读者可以在 [Nginx 的网站](https://www.nginx.com/resources/library/the-enterprise-path-to-service-mesh-architectures/)上免费下载阅读完整内容。
|
||||
|
||||
追本溯源，Service Mesh实际上是一种SDN，等同于OSI模型中的会话层。 每一次技术变革，必然要导致生产力和生产关系的变革，我们看到这种趋势正在加速。本书中给出了企业上Service Mesh的路径，可供广大技术和管理人员参考。
|
||||
追本溯源，服务网格实际上是一种 SDN，等同于 OSI 模型中的会话层。 每一次技术变革，必然要导致生产力和生产关系的变革，我们看到这种趋势正在加速。本书中给出了企业上服务网格的路径，可供广大技术和管理人员参考。
|
||||
|
||||
**注**：若未加声明，本章中所有图片均来自 *The Enterprise Path to Service Mesh* 一书。
|
||||
Loading…
Reference in New Issue