标签: 微服务

1.背景介绍 1.1.业务背景 服务网格（Service Mesh）是微服务架构中的一种重要技术，它主要处理服务之间的通信，为服务间的信息交换提供更安全、更快速且更可靠的基础设施层。服务网格将服务治理从业务逻辑中剥离出来，拆解为独立的进程，实现异构系统的统一治理和增强网络安全。 一个典型的服务网格部署示意图如下： 其中绿色方块为应用服务，蓝色方块为代理。应用服务之间通过代理进行通信，整个服务通信形成图中的蓝色网络连线，图中所有蓝色部分就形成了服务网格。 服务网格的主要特点包括： 无侵入性：服务网格的设计理念是将通信和管理逻辑与业务逻辑解耦，使得业务逻辑无需关注通信细节，从而实现了对业务代码的无侵入性。 统一治理：通过服务网格，可以实现对微服务架构中所有服务的统一治理，包括服务发现、负载均衡、安全认证、监控和跟踪等功能。 可扩展性：服务网格支持多种微服务框架和服务治理能力，能够轻松扩展以支持更多的服务和场景。 服务网格的架构通常包括控制平面和数据平面，其中控制平面用于配置、管理和监控数据平面中的Sidecar代理，提供服务发现、负载均衡、安全认证等功能。 数据平面主要由边车Sidecar组成，它以轻量级的网络代理形式存在，与每个微服务实例部署在同一个主机或容器中，作为服务的附属组件运行。边车的主要职责是拦截和处理服务之间的通信流量，并与控制平面进行交互，实现服务发现、负载均衡、安全认证、监控和跟踪等功能。 边车的工作流程通常包括以下几个步骤： 拦截通信流量：边车代理拦截服务之间的所有入站和出站请求和响应。 服务发现：边车代理向服务注册中心注册服务实例，并根据需要动态地发现和管理服务实例。 负载均衡：边车代理根据配置的负载均衡算法，将请求分发到多个服务实例中，以提高服务的可用性和性能。 安全认证：边车代理可以实施安全认证策略，确保服务之间的通信是安全的。 监控和跟踪：边车代理收集和传输服务间的通信流量数据，以实现监控、日志记录、错误追踪和性能调优等功能。 综上所述，服务网格是微服务架构中的重要组成部分，它们共同为服务间的通信提供了安全、快速且可靠的基础设施层，并实现了对业务代码的无侵入性服务治理。 1.2.问题与挑战 在微服务架构中引入服务网格确实可以带来诸多好处，如简化服务治理、提高安全性和可观察性等，但同时也伴随着一系列问题和挑战。以下是几个主要方面： 边车带来的资源开销： 每个微服务应用都都需要运行一个边车代理，实际部署是每个POD部署一个边车容器。边车容器需要额外的计算资源来处理服务间的通信，默认情况下每个边车容器占用0.2个CPU核。假设一台服务器运行了60个POD，那么边车容器将额外占用12个CPU核。 业务转发时延增加： 应用程序的每个数据包都必须通过边车容器，数据包在应用程序和内核之间往返多次，如下对比是单个pod进或出增加的时延。 如图所示，右侧的是引入服务网格的方案，Pod内多了边车容器，相比左侧未引入服务网格的方案，数据包增加了内核往返次数，增加了时延。 通过上述分析可以看出，在微服务架构中引入服务网格确实带来了资源开销和转发时延的问题。 2.方案介绍 2.1.整体方案架构 服务网格DPU卸载解决方案将服务网格的sidecar边车容器集中卸载到DPU卡上执行，可以显著降低服务器CPU的算力消耗。同时，DPU卡高性能转发引擎实现了网络转发功能的加速，从而能够有效降低业务时延。该方案支持和原生Istio的无缝对接，对用户业务无侵入，可以实现业务的平滑迁移。 如图所示，红色系为本方案涉及本方案涉及部分，包括DPU卡及其提供给到主机侧的SRIOV vf口、主机侧CNI(istio-dpu-cni)。 业务容器的流量治理功能由DPU卡上的共享服务代理dpu-proxy提供，它由原生的边车容器从POD中抽离出来卸载到DPU卡上。它的配置由istio-dpu-cni通过对接istio获取并转换为集中式配置并下发下来。流量通过DPU提供的vf口到达DPU侧的dpu-proxy进行流量治理。 此架构的控制面仍为原生的istio，下发xDs配置给转发面；服务网格CNI（istio-dpu-cni）做为DPU卡在k8s集群的接口，无缝对接istio/收集集群信息，相当于DPU管理面给DPU组件下发配置及规则，使DPU卡可以实现原生的透明流量劫持以及流量治理的功能；DPU卡上的dpu-proxy做为服务网格的转发面，接收配置并根据配置对流量进行流量治理。 集群内的主机上插入DPU卡（红色），在主机侧集群内部署安装服务网格CNI（istio-dpu-cni组件）后，istio-dpu-cni组件可无缝对接控制平面K8s及Istio获取服务网格及网络配置、使能DPU卡上的共享服务代理dpu-proxy及转发引擎dataplane、下发相关的启动配置，主机即具有服务治理功能。之后在部署业务POD时，业务添加高速网口vf后，提供用户接口，使业务流量通过vf到达DPU侧dpu-proxy进行流量治理与转发。 2.2.方案描述 2.2.1.主机侧组件服务网格CNI实现管理平面 服务网格CNI（istio-dpu-cni组件）在主机侧k8s集群部署，无缝对接控制平面K8s及Istio获取配置等信息，转换为共享式代理配置下发到DPU侧的共享代理；基于DPU板卡的sriov功能，可给业务POD添加低时延高速网口vf及分配置IP地址；同时使能DPU侧转发引擎dataplane，给dataplane下发引流转发配置。 如图所示，服务网格CNI包括istio-dpu-controller、istio-dpu-adapter和istio-dpu-cni三个组件： ① istio-dpu-controller 使用daemonset方式部署在集群master上 主要是用于生成dpu级别的集中式服务网格配置，收集集群信息如pod变化、nodename等，转换为istio的inbound和internal 配置，并下发给对应节点的istio-dpu-adapter。 ② istio-dpu-adapter 使用daemonset部署在每个主机节点上 主要是用于无缝对接原生控制平面istio，可自动获取配置，转换集群内信息把原生配置聚合为共享式服务网格配置下发给代理dpu-proxy。 ③ istio-dpu-cni 使用daemonset部署在每个主机节点上 可配置网络模式是underlay或者overlay，针对性下发不同的网络规则；收集集群内信息（node, ns, service, pod等），提供用户接口可对dpu侧的转发引擎dataplane下发转发及引流规则，使dataplane能进行透明劫持低时延业务流量到dpu-proxy做流量治理。 除自研的CNI外，引入的开源组件为multus、sriov、spiderpool（不涉及开源组件的改动），通过二进制或pod的形式部署在需要的节点上。 2.2.2.DPU侧组件转发引擎及代理实现转发平面 如图所示，DPU侧组件包括转发引擎dataplane和共享服务代理dpu-proxy两个组件。在DPU卡的soc上，部署两个容器组件实现服务网格转发面功能，流量透明劫持及流量治理。 ① 共享服务代理dpu-proxy采用容器方式部署在DPU卡的SOC上 扩展封装原生边车代理istio-proxy为DPU共享服务代理dpu-proxy。它解析istio-dpu-adapter下发的动态共享式服务网格配置，对进出本机的低时延业务流量进行治理与转发。支持原生的四层TCP流量及七层HTTP流量治理；支持generic-proxy框架对其他七层流量进行流量治理。 ② 转发引擎dataplane采用容器方式部署在DPU卡的SOC上 dataplane接入协议栈(内核/用户态），并可通过vcl共享内存方式与共享服务代理dpu-proxy交互；接收istio-dpu-cni下发的转发及引流规则，根据规则把流量劫持到dpu-proxy；治理过的流量按转发规则进行网络封装及转发；dataplane加载vf-representer，通过NP（网络转发引擎）从vf-representer口收发对应pod内vf口的流量。 2.2.3.DPU共享服务代理流量转发模型 同主机内的业务互访如图（红色），client端业务流量经高速口vf到达DPU共享服务代理进行服务治理后，再经转发引擎dataplane转发到本主机的server端Pod。 跨主机业务互访如图（蓝色），client端业务流量经高速口vf到达DPU共享服务代理进行服务治理。治理后流量到达转发引擎dataplane，根据转发规则转到目标主机的DPU上共享服务代理做inbound入口流量治理。治理后流量再经转发引擎dataplane转到目标主机的server端Pod。 3.方案优势 3.1.方案优势 本方案创新性的将服务网格边车代理集中卸载到DPU上，可以带来一系列显著的优势，包括以下几个方面： ①显著降低服务器开销： 资源消耗减少： 传统的边车模式需要在每个服务容器旁边部署一个边车代理，这会导致大量的资源消耗（如CPU、内存）。通过将代理集中部署在DPU上，可以消除这些额外的资源消耗，使主机侧的资源更加专注于业务逻辑处理。 优化资源利用率： DPU作为专门的硬件加速单元，能够更高效地处理网络流量和加密解密等任务，从而释放主机CPU资源，提高整体系统的资源利用率。 ②极致的低时延： 用户态协议栈Bypass内核： 通过将网络处理移至DPU的用户态协议栈，绕过传统的内核态处理，可以显著减少数据包在内核与用户空间之间切换的开销，从而大幅降低网络延迟。 服务网格快路径： 自研的服务网格快路径技术可以进一步优化网络路径，减少不必要的处理步骤，确保数据包能够以最短的路径和最快的速度在网络中传输。 ③即插即用： 无侵入式服务治理： 集中式代理模式允许在不修改现有应用代码的情况下实现服务治理功能，如流量管理、安全控制等。这使得新服务的部署和现有服务的升级变得更加简单快捷。 灵活部署： DPU作为独立的硬件组件，可以轻松地集成到现有的服务器架构中，实现即插即用。这种灵活性使得企业可以根据实际需求快速调整网络架构和服务部署策略。 ④增强的安全性和隔离性： 服务隔离： 通过DPU上的集中式代理，可以减少不同服务和边车容器之间的干扰，防止潜在的安全风险。 综上所述，将边车代理集中卸载到DPU上是一种高效、灵活且安全的网络架构优化方案，能够显著降低开销、提升系统的性能并增强安全性和隔离性。 3.2.未来与展望 服务网格DPU卸载解决方案，作为云原生时代的一项创新技术，其核心价值在于显著优化了边车代理模式所带来的资源消耗问题，并大幅降低了业务请求在微服务间的转发时延。 随着云原生技术和微服务架构在各行各业的深入渗透，特别是在云计算、金融科技、物联网、边缘计算等领域，对于高效、可靠、可扩展的系统架构需求日益迫切。服务网格DPU卸载解决方案正是顺应这一趋势，凭借其卓越的性能提升和资源优化能力，展现出了极为广阔的应用前景和市场空间。 更为重要的是，该方案和技术正处于快速发展和不断完善的阶段。随着DPU技术的不断创新和服务网格框架的持续演进，未来将有更多高级功能被集成到DPU中，如更精细的流量管理、增强的安全策略执行、智能的数据处理加速等。服务网格DPU卸载方案将吸引更多行业巨头、初创企业以及技术开发者加入DPU生态，共同探索和实践DPU技术的潜力，推动其标准化、生态化的发展进程。 总之，服务网格DPU卸载解决方案作为云原生和微服务架构下的技术探索，展现出了巨大的潜力，有望成为推动云原生技术普及和深化的关键力量，为数字化转型注入新的活力和动力。 本方案来自于中科驭数软件研发团队，团队核心由一群在云计算、数据中心架构、高性能计算领域深耕多年的业界资深架构师和技术专家组成，不仅拥有丰富的实战经验，还对行业趋势具备敏锐的洞察力，该团队致力于探索、设计、开发、推广可落地的高性能云计算解决方案，帮助最终客户加速数字化转型，提升业务效能，同时降低运营成本。

如今，关于微服务依然存在许多误解，企业盲目追求这种炫酷技术并不可取。同时，这种盲目行为对于希望用微服务来有效解决问题的公司很不利。不是说任何特定的技术都是缺乏实际价值的，如微服务、Kubernetes、Lambda函数之类的新技术是否被企业采纳，也许都取决于错误的理由。很多时候，企业可能只因为它比较流行就使用这些术语，却没有真正让它的技术优势在棘手的问题上发挥作用，或者提供切实可行的解决方案。从某种程度上说，它夸大了技术的实际作用，还给架构的合理选择和使用制造了障碍，这对于其他技术来说也很不公平。 因此，虹科想通过这篇文章来为大家一一澄清对于微服务所流传的五大误解。 微服务简介 微服务作为基础设施构建块提供了诸如服务解耦、数据存储自治、小型化开发和测试设置，缩短应用程序上线时间的优势。容器及其编排工具的可用性也提高了微服务的采用。每个微服务都是围绕一个特定的业务上下文——一个目标、焦点或问题领域。这些模块化的服务通过 API 进行通信，以便在应用程序中执行它们自己的功能。微服务应用程序的敏捷性、孤立性和专注性带来了显著的优势。包括： 1.团队授权： 小型独立团队可以快速部署代码，以非常敏捷的速度适应不断变化的要求； 2.灵活性 ：每个服务都可以使用最适合其独特需求的技术来构建； 3.可重用性 ：简单和模块化的代码是可重用的，可以应用于多种目的，以实现更快的开发； 4.隔离 ：隔离确保应用程序组件可单独操作和可扩展，并提供故障隔离，以防止微服务的 故障相互影响。 误解一：微服务可以解决所有问题 老话常说："当企业只有一把锤子的时候，一切看起来都像钉子"。如果微服务能帮企业解决实际难题，那自然好。但许多企业可能认为： 1.只要有应用场景，那么微服务就是解决方案。 Redis企业版数据库的合作伙伴解决方案架构师Lars Rosenquist建议：“首先，企业要搞清什么是微服务；然后，企业需要了解自己的应用架构出了什么问题；最后，才对两者进行匹配进行方案制定。但是很少人愿意真的这么做。” 2.多数技术只能解决特定企业规模的具体问题 。Lars Rosenquist解释说："如果是像Netflix这样的大公司，企业的应用消耗了三分之一的互联网流量，那就必须进行架构，才能使技术发挥作用。但如果企业是一家运营规模较小的公司，比如一家本地银行，那就不需要了。人们经常是在为他们想要解决的而不一定是真正存在的问题进行优化。” 3.大多数用例都不需要微服务。 编程专家建议：要尽量避免 "庞大的单体架构不好，庞大的单体架构是旧的解决方案"的心态，反之，企业在采用微服务方法之前，就应摒弃这样的错误认知。 误解二：微服务降低了复杂性 其实，微服务架构几乎都会增加复杂性。若不加以控制，它甚至还会变成一个分布式系统，使得架构更加混乱。因为： 1.微服务并不能解决系统设计问题。i DIA计算公司的软件开发顾问George Dinwiddie说：“如果企业不能创建一个具有高内聚低耦合的单体设计，那它很难把微服务做好。” 正如康威定律所言，先从一个单体开始，然后企业在增添开发人员时再去提取服务。Rosenquist认为："对于一个单体应用程序，它包含了所有的逻辑、通信和复杂性。通过微服务，企业却能打破这一常规。因为像通信模式之类的现在都属于企业基础设施的一部分。” 2.微服务不能消除复杂性。 微服务只是把复杂性移到了不同的抽象层，并没有真正让它消失。比方说，企业如果使两个应用程序组件处于同一个应用程序、同一个进程，甚至在同一个CPU中相互通信，那这个应用程序的速度一定是非常快的。但是对于微服务，这些应用组件被放在了不同机器上，它们之间相隔了一个网络，一整套基础设施，甚至可能是在不同的云中。这对于通信、故障模式及性能评估方面都会是非常大的挑战。” 使用虹科Redis企业版数据库，可以让管理复杂性变得更容易!但不要忽视复杂性是仍然存在的。 3.架构的复杂导致调试应用程序更加困难 。为了更好地管理这种复杂性，还需要确保企业的监控和可观察性工作做到位。尽管微服务方法可使企业的代码不再那么复杂，但 Rosenquist指出：“当要部署或管理它时，也许不再那么容易，企业现在并非只有一个而是有多个应用程序需要调试。这些应用程序在多个实例上运行，而这些实例也在整个架构中实现负载均衡。所有的这些通常都比使用单一的应用程序更为复杂。因此，要想实现成功部署，则需加强类似于日志聚合和可观察性之类事件的关注。” 4.不太复杂的代码并不一定能转化为不太复杂的系统。 Redis的开发领导者William Johnston指出"从代码的角度来看，单个服务可能更好理解，但企业用微服务创建的系统的复杂性会比单体复杂得多。"特别是在已经超负荷工作的小团队中，这也许意味着需要花费更多的开发时间。虽然能促使开发人员去学习应用领域和整个系统，但对于时间期限紧迫或缺乏技术经验的团队来说，微服务不可能“慢慢来”！因为微服务作为一种相当不同的操作方式，技术要求十分高。从长远看，整个系统的耦合度降低可以让重构更容易，但这也需付出很高的代价，并且开发人员的生产力可能会大幅下降，还可能影响对质量的保证。基于此，一个微服务依赖于这么多关系，它的测试难上加难。 Redis企业版数据库微服务可通过快速和灵活的数据模型降低复杂性 备注：康威定律是马尔文康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。 误解三：一种架构可以适用于一切 一种架构难以应用于企业的所有场景： 1.企业的旧应用程序可能不支持这些架构类型的模式。 企业也不应该认为自己可以立即开始重构旧的应用程序，要区分单体、微服务和函数。一个函数只做一件事，它们属于事件驱动型，是为特定的架构服务的。但在企业流程方面，如果企业分解掉所有的系统，最终会有一千个组件，企业也就不再具有优势。 2.最好的方法取决于具体的使用情况。 举个例子，一家银行很可能有相当多的单体系统。但为企业移动银行应用提供动力的微服务应用大约占到了50%-60%，其余的才是函数。因此，一家企业在架构方面应用场景是多样化的。 无论企业使用的是什么软件架构或模式，一个优秀的工程团队都要学会找到最有效的方法。 单体与微服务架构的比较 误解四：微服务主要是一种技术 1.实际上微服务解决的是一个业务或组织的可扩展性问题。 Johnston指出："微服务解决的是一个技术问题，如果未达到这个目标，那就是浪费时间。很多人甚至是部分大型企业启动一个新的应用程序时，都认为他们需要从分离领域的方式及微服务开始，但如果企业对业务领域没有一个明确的定义，就不该从微服务开始。” 再一次引用康威定律，企业软件环境中和组织整体中的通信模式是相似的。 Rosenquist认为："假设企业想从一个单体架构转换到一个微服务架构，应先建立在本身的组织架构上。比如，将团队分开，确保每个微服务属于其中一个团队，这其实是一个管理问题，而非一个技术挑战。” 2.应当确保每个人都理解微服务的含义，以及该技术解决业务问题的方式。 不同部门对微服务的本质往往有不同的看法。采用微服务架构是否能获得优势取决于这个问题的大小以及采用该技术的团队本身。 误解五：微服务允许团队使用他们喜欢的技术 这其实并不完全是一个误解，因为对团队来说，使用不同的平台并不总是一个好主意。 Johnston认为：“人们普遍认为可以使用他们喜欢的语言、工具和平台，这是微服务的一个优势。但如果企业团队很大，甚至有分布在世界各地，比如，一些团队可能擅长.NET，而另一些则擅长Java。那么对于他们特定服务的业务领域，使用某种特定技术可能对他们有利。”然而，Johnston提醒说：“对额外环境的开发是以增加系统的复杂性为代价的，企业架构师也需要了解系统的复杂性。 " Rosenquist建议："企业可以为每个微服务选择不同的技术，但如果企业有500个微服务，仅使用5种技术会更好而不是500种不同的技术。”当然，这些都是例子，没有一个放之四海而皆准的方法，企业应当在管理和加大开发复杂性之间找到平衡点。 关于微服务的误解众多 以上是我们分享给大家的关于微服务流传较广的误解，但并不仅限于此。虹科云科技在这里也为大家整理了一些其他关于微服务的误解： 1.微服务能加速业务 。Johnston建议："由于网络跳转的增加，微服务会引发速度下降。企业必须接受最终的一致性，但在其他类型的应用程序中企业可以不需要这么做。” 2.微服务实际上是很小的。 技术咨询公司Archium的联合创始人Graham Le提到：“不要被微服务中的【微】所迷惑。微服务应该比单体小，但最理想的是，一个服务能覆盖一个中等规模的领域。小只是一个相对的术语；但重点不是让他们变得非常小。” 3.每种客户端都需要对应一个微服务。 咨询公司Blue Herring的DevOps架构师Mark W. Schumann表示"这种想法是错误的，但他们一直在这样认为！与之相反，应该考虑每个资源对应一个微服务"。 Redis企业版可以解决的微服务问题 作为一个多租户解决方案，Redis Enterprise 企业在微服务之间隔离数据。最重要的是，它允许用户对数据库进行调优，以在性能和数据一致性/持久性之间保持权衡。Redis企业版数据库还可用于将实时性能扩展到缓存之外的一些微服务用例，如；服务内通信和事件源，也通常被用作支持单个微服务的轻量级数据库。Redis企业版数据库在微服务方面主要具有以下优势，为客户提供最全面的解决方案： 1.降低系统复杂性。 每个Redis 企业版数据库缓存的各个方面都可以为每个微服务定制，提供简化的管理，以减少微服务架构带来的操作复杂性。 2.提供实时速度更快的微服务。 所有的网络延迟都会降低应用程序的性能。Redis企业版数据库提供了一种方法来收回服务间通信损失的大部分时间，具有数据查询和消息传递的亚毫秒性能，让微服务应用速度更快。 3.多租户支持。 多租户违背了微服务完全隔离单个应用组件的做法，因此，系统经常遇到争夺资源的挑战，个别服务可能过度消耗其他微服务共享的资源。用户可以在Redis企业版数据库安装上为所有微服务部署多个数据库实例，而且数据在数据库之间保持隔离。Redis企业版数据库的内置机制通过触发重新分片或跨节点移动来平衡吞吐量/延迟，从而保护实例不受影响。 4.高可用性与自动故障检测。 Redis企业版数据库的架构提供了自动故障检测和零停机时间扩展，对使用它的微服务完全透明。故障检测和故障转移可以在几秒钟内完成，并且不会丢失数据，高度可靠、随时可用。 5.原生 Kubernetes 容器编排和管理。 用户可以在 Kubernetes 环境中把 Redis企业版数据库容器作为云原生数据库服务进行协调。二者集成可以实现多种功能。 6.支持多种部署模式。 无论用户的微服务是在私有云环境、企业内部还是在云中运行，Redis企业版数据库的灵活部署选项都能让微服务尽可能地接近数据，并使用户可以完全控制它的数据。 虹科Redis企业版软件（Redis Enterprise）是企业级的数据库软件，也是一款实时数据平台，为全球超过8500家知名企业提供实时数据服务。具有 线性可扩展性、高可用性、持久性、备份和恢复、地理分布、分层内存访问、多租户、安全性 等8大核心功能、拥有RediSearch、RedisJSON等7大【Redis企业版特有模块】，可以任何规模在云、本地和混合部署中运行现代应用程序，提供无服务器、多模型的数据库解决方案。Redis企业版的核心优势是采用Redis on flash分层存储技术即【内存+闪存+磁盘】的存储方式，其Active-Active地理分布式架构允许跨地理位置同时进行数据读写操作、拥有亚毫秒延迟和极高吞吐量。 虹科是Redis企业版的中国区战略合作伙伴，若感兴趣白皮书： 《Redis Enterprise 如何用于微服务缓存》 ，以及关于如何消除微服务存在的问题有任何其他疑问，欢在评论区进行交流或者联系我们！