diff --git a/ServiceMesh/What-is-ServiceMesh.md b/ServiceMesh/What-is-ServiceMesh.md index 863f4d47..9b45cb6b 100644 --- a/ServiceMesh/What-is-ServiceMesh.md +++ b/ServiceMesh/What-is-ServiceMesh.md @@ -16,9 +16,9 @@ 通过下述时间点，感受服务网格从无到有，被社区接受，巨头入局，众人皆捧的发展历程： -- 2016 年 9 月：在 SF MicroServices 大会上，术语“Service Mesh”首次在公开场合提出，标志着**服务网格的概念从 Buoyant 公司走向社区，并逐渐获得广泛认可和推崇**。 -- 2017 年 1 月：Linkerd 加入 CNCF，并被归类到 CNCF 新设立的“Service Mesh”分类，表明**服务网格的设计理念得到了主流社区的认可**。 -- 2017 年 4 月：Linkerd 发布 1.0 版本，标志着服务网格实现了关键里程碑——被客户接受并在生产环境中大规模应用，**服务网格从“虚”转“实”**。 -- 2017 年 5 月：Google、IBM 和 Lyft 联合发布 Istio 0.1 版本，以 Istio 为代表的**第二代服务网格开始登场**。 +- 2016 年 9 月：在 SF MicroServices 大会上，术语“Service Mesh”首次在公开场合提出，服务网格的概念从 Buoyant 公司内部走向社区。 +- 2017 年 1 月：Linkerd 加入 CNCF，被归类到 CNCF 新设立的“Service Mesh”分类，这表明**服务网格的设计理念得到了主流社区认可**。 +- 2017 年 4 月：Linkerd 发布 1.0 版本，服务网格实现了关键里程碑 —— 被客户接受，在生产环境中大规模应用。**服务网格从“虚”转“实”**。 +- 2017 年 5 月：Google、IBM 和 Lyft 联合发布 Istio 0.1 版本，以 Istio 为代表的**第二代服务网格登场**。 - 2018 年 7 月：CNCF 发布了最新的云原生定义，将服务网格与微服务、容器、不可变基础设施等技术并列，**服务网格的地位空前提升**。 - 2022 年 7 月，Cilium 发布了“无边车模式”的服务网格，2 个月之后，Isito 发布了全新的数据平面模式 “Ambient Mesh”，服务网格的形态开始多元化。 \ No newline at end of file diff --git a/ServiceMesh/overview.md b/ServiceMesh/overview.md index 79728694..73cd1dcf 100644 --- a/ServiceMesh/overview.md +++ b/ServiceMesh/overview.md @@ -1,6 +1,6 @@ # 8.5 服务网格的产品与生态 -2016 年，Buoyant 公司发布了第一代服务网格 Linkerd。同一时期，离开 Twitter 的工程师 Matt Klein 加入了 Lyft，启动了 Envoy 项目。第一代服务网格稳步发展时，世界的另一角落，Google 和 IBM 两个巨头开始联手，与 Lyft 一起启动了 Istio 项目。 +2016 年，Buoyant 公司发布了 Linkerd。同一时期，离开 Twitter 的工程师 Matt Klein 加入了 Lyft，启动了 Envoy 项目。第一代服务网格稳步发展时，世界的另一角落，Google 和 IBM 两个巨头联手，与 Lyft 一起启动了 Istio 项目。 Istio 的最大创新在于为微服务系统带来了前所未有的控制力： - 以 Linkerd 为代表的第一代服务网格，通过 Sidecar 模式控制微服务间的流量； @@ -60,7 +60,7 @@ Linkerd2 的架构如图 8-13 所示，增加了控制平面，但整体相对 Linkerd 和 Istio 在性能和资源成本上的显著差异，要归因于 Linkerd2-proxy，该代理为 Linkerd 的整个数据平面提供动力。因此。上述基准测试很大程度上反映了 Linkerd2-proxy 与 Envoy 之间的性能和资源消耗对比。 -虽然 Linkerd2-proxy 性能卓越，但由于其使用编程语言 Rust 相对小众，开源社区的贡献者数量稀少。截至 2024 年 6 月，Linkerd2-proxy 的贡献者仅有 53 人，而 Envoy 的贡献者则多达 1,104 人。此外，Linkerd2-proxy 不支持服务网格领域的 xDS 控制协议，其未来发展将高度依赖于 Linkerd 本身的进展。 +虽然 Linkerd2-proxy 性能卓越，但使用的编程语言 Rust 相对小众，开源社区的贡献者数量稀少。截至 2024 年 6 月，Linkerd2-proxy 的贡献者仅有 53 人，而 Envoy 的贡献者则高达 1,104 人。此外，Linkerd2-proxy 不支持服务网格领域的 xDS 控制协议，其未来发展将高度依赖于 Linkerd 本身的进展。 [^1]: 参见 https://github.com/linkerd/linkerd2 [^2]: 这项测试工作还诞生服务网格基准测试工具 service-mesh-benchmark，以便任何人都可以复核结果。https://github.com/kinvolk/service-mesh-benchmark，以便任何人都可以复核结果。 diff --git a/network/networking.md b/network/networking.md index f02f9d9f..20788d8f 100644 --- a/network/networking.md +++ b/network/networking.md @@ -19,7 +19,7 @@ Linux 系统收包流程，如图 3-1 所示。 7. 内核协议栈处理完成后，数据包被传递到 socket 接收缓冲区。应用程序利用系统调用（如 Socket API）从缓冲区读取数据。至此，整个收包过程结束。 -分析 Linux 系统处理网络数据包的过程，我们注意到潜在问题：**数据包的处理流程过于冗长**。处理流程涉及到多个网络层协议栈（如数据链路层、网络层、传输层和应用层），网络层协议栈之间需要封包/解包，还有频繁的操作系统上下文切换。对于设计网络密集型系统，Linux 内核的瓶颈不可忽视，优化内核参数是不可或缺的一环。 +分析 Linux 系统处理网络数据包的过程，我们注意到潜在问题：**数据包的处理流程过于冗长**。处理流程涉及到多个网络层协议栈（如数据链路层、网络层、传输层和应用层），网络层协议栈之间需要封包/解包，还有频繁的上下文切换（Context Switch），都让 Linux 内核的瓶颈不可忽视。对于设计网络密集型系统，优化内核参数是不可或缺的一环。 除了想办法优化内核参数，业界提出了“绕过内核”的技术思路，如图 3-1 所示的 XDP 和 DPDK 技术，笔者将在 3.4 节中详细介绍它们的原理与区别。