<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Service-Mesh - 标签 - 研发日志 · R&amp;D Log</title><link>https://rd163.visword.com/tags/service-mesh/</link><description>Service-Mesh - 标签 - 研发日志 · R&amp;D Log</description><generator>Hugo -- gohugo.io</generator><language>zh-CN</language><managingEditor>whutluohui@gmail.com (小智晖)</managingEditor><webMaster>whutluohui@gmail.com (小智晖)</webMaster><copyright>本作品采用知识共享署名-非商业性使用 4.0 国际许可协议进行许可。</copyright><lastBuildDate>Mon, 24 Mar 2025 00:00:00 +0800</lastBuildDate><atom:link href="https://rd163.visword.com/tags/service-mesh/" rel="self" type="application/rss+xml"/><item><title>Envoy xDS 协议介绍</title><link>https://rd163.visword.com/posts/xds-for-envoy/</link><pubDate>Mon, 24 Mar 2025 00:00:00 +0800</pubDate><author><name>小智晖</name></author><guid>https://rd163.visword.com/posts/xds-for-envoy/</guid><description><![CDATA[<p>xDS（Extensible Discovery Service，可扩展发现服务）是 Envoy 代理用来从控制面（Control Plane）获取动态配置的一组 gRPC/REST API 的统称。这里的 &ldquo;x&rdquo; 代表具体的资源类型，例如 Listener、Route、Cluster、Endpoint，分别对应 LDS、RDS、CDS、EDS。借助 xDS，Envoy 能够在不停机、不 reload 的情况下热更新监听器、路由表、上游集群、证书等几乎所有运行期配置，这正是 Istio、Higress 等服务网格与云原生网关实现毫秒级配置生效的底层基础。</p>]]></description></item><item><title>k8s 服务网格（Service Mesh）</title><link>https://rd163.visword.com/posts/k8s-service-mesh-istio/</link><pubDate>Sun, 12 Jan 2025 00:00:00 +0800</pubDate><author><name>小智晖</name></author><guid>https://rd163.visword.com/posts/k8s-service-mesh-istio/</guid><description><![CDATA[<p>希腊语言中大概是风帆的意思， 发音  [iːst&rsquo;iəʊ] ，相当于中文的 伊斯特亿欧。</p>
<h2 id="1-为何使用服务网格why" class="headerLink">
    <a href="#1-%e4%b8%ba%e4%bd%95%e4%bd%bf%e7%94%a8%e6%9c%8d%e5%8a%a1%e7%bd%91%e6%a0%bcwhy" class="header-mark"></a>1. 为何使用服务网格？(Why)</h2><ul>
<li>服务网格并没有给我们带来新功能，它是用于解决其他工具已经解决过的问题，只不过这次是在云原生的  Kubernetes 环境下的实现。</li>
<li>MVC 三层 Web 应用程序架构下，服务之间的通讯并不复杂，在应用程序内部自己管理即可，但是在现今的复杂的大型网站情况下，单体应用被分解为众多的微服务，服务之间的依赖和通讯十分复杂，出现了 Twitter 开发的 Finagle、Netflix 开发的 Hystrix 和 Google 的 Stubby 这样的 ”胖客户端“ 库，这些就是早期的服务网格，但是它们都近适用于特定的环境和特定的开发语言，并不能作为平台级的服务网格支持。</li>
<li>在云原生架构下，容器的使用给予了异构应用程序的更多可行性， Kubernetes 增强的应用的横向扩容能力，用户可以快速的编排出复杂环境、复杂依赖关系的应用程序，同时开发者又无须过分关心应用程序的监控、扩展性、服务发现和分布式追踪这些繁琐的事情而专注于程序开发，赋予开发者更多的创造性。</li>
</ul>
<h2 id="2-简介what" class="headerLink">
    <a href="#2-%e7%ae%80%e4%bb%8bwhat" class="header-mark"></a>2. 简介（What）</h2><p>服务网格有如下几个特点：</p>]]></description></item><item><title>k8s 服务网格（Service Mesh）</title><link>https://rd163.visword.com/posts/k8s-service-mesh/</link><pubDate>Sun, 12 Jan 2025 00:00:00 +0800</pubDate><author><name>小智晖</name></author><guid>https://rd163.visword.com/posts/k8s-service-mesh/</guid><description><![CDATA[<p>希腊语言中大概是风帆的意思， 发音  [iːst&rsquo;iəʊ] ，相当于中文的 伊斯特亿欧。</p>
<p>如果用一句话来解释什么是服务网格，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。</p>]]></description></item><item><title>K8s 服务网格配置发现协议</title><link>https://rd163.visword.com/posts/k8s-service-mesh-config-proto/</link><pubDate>Sun, 12 Jan 2025 00:00:00 +0800</pubDate><author><name>小智晖</name></author><guid>https://rd163.visword.com/posts/k8s-service-mesh-config-proto/</guid><description><![CDATA[<p>在服务网格场景下，控制面需要把监听器、路由、集群、端点、证书等配置高效、一致地下发到数据面（每个 sidecar 代理）。本文梳理 Istio 历史上使用过的两类配置分发协议：基于订阅的 <strong>MCP</strong> 与 Envoy 原生的 <strong>xDS</strong>。</p>]]></description></item><item><title>Kmesh：基于 eBPF 的内核原生服务网格数据平面</title><link>https://rd163.visword.com/posts/k8s-service-mesh-kmesh/</link><pubDate>Sun, 12 Jan 2025 00:00:00 +0800</pubDate><author><name>小智晖</name></author><guid>https://rd163.visword.com/posts/k8s-service-mesh-kmesh/</guid><description><![CDATA[<h2 id="背景" class="headerLink">
    <a href="#%e8%83%8c%e6%99%af" class="header-mark"></a>背景</h2><p>像 Istio 这样的服务网格（Service Mesh）已经成为管理复杂微服务架构的核心手段，提供流量管理、安全（mTLS）和可观测性等能力。Sidecar 模型——在每个业务 Pod 旁注入一个 Envoy 代理——是过去几年最主流的数据平面实现。它功能完备、对应用透明，但在性能与资源开销上代价不菲。</p>]]></description></item><item><title>Kubernetes 中文指南</title><link>https://rd163.visword.com/posts/k8s-handbook/</link><pubDate>Sun, 12 Jan 2025 00:00:00 +0800</pubDate><author><name>小智晖</name></author><guid>https://rd163.visword.com/posts/k8s-handbook/</guid><description><![CDATA[<h2 id="术语解释" class="headerLink">
    <a href="#%e6%9c%af%e8%af%ad%e8%a7%a3%e9%87%8a" class="header-mark"></a>术语解释</h2><ul>
<li>Istio: Istio 是由 Google、IBM 和 Lyft 开源的微服务管理、保护和监控框架. Istio 并不是首字母缩写，但如果一定要说它代表着什么，也许会是 “I Secure, Then I Observe”（我保护，我观察），或者 &ldquo;I’m Sexy To Infrastructure Operators.&quot;（我对基础设施运营商富有吸引力）。</li>
</ul>
<h2 id="k8s-与-云原生的关系" class="headerLink">
    <a href="#k8s-%e4%b8%8e-%e4%ba%91%e5%8e%9f%e7%94%9f%e7%9a%84%e5%85%b3%e7%b3%bb" class="header-mark"></a>k8s 与 云原生的关系</h2><h3 id="云原生定义" class="headerLink">
    <a href="#%e4%ba%91%e5%8e%9f%e7%94%9f%e5%ae%9a%e4%b9%89" class="header-mark"></a>云原生定义</h3><p>云原生是一种行为方式和设计理念，究其本质，凡是能够提高云上资源利用率和应用交付效率的行为或方式都是云原生的。</p>]]></description></item><item><title>北极星（Polaris）</title><link>https://rd163.visword.com/posts/tencent-polaris/</link><pubDate>Sun, 12 Jan 2025 00:00:00 +0800</pubDate><author><name>小智晖</name></author><guid>https://rd163.visword.com/posts/tencent-polaris/</guid><description>&lt;p>在微服务与分布式架构里，服务实例动态扩缩容、跨语言调用、跨环境互通是常态，随之而来的服务注册发现、流量控制、故障容错、配置下发等问题都需要一个统一的治理面来承载。北极星（Polaris，项目代号 PolarisMesh）正是腾讯针对这一诉求开源的服务发现与治理平台，在腾讯内部已经支撑了百万级服务注册和十万亿级日接口调用，通用性与稳定性经过大规模验证。&lt;/p></description></item></channel></rss>