达内网站开发学习培训,会展平面设计主要做什么,网络架构师证书怎么考,衡阳seo优化报价(这期先了解Dapr#xff0c;之后在推出如何搭建Dapr#xff0c;以及如何使用。)
目录
引言#xff1a;
Service Mesh定义
Service Mesh解决的痛点
Istio介绍
Service Mesh遇到的挑战
分布式应用的需求
Multiple Runtime 理念推导
Dapr 介绍
Dapr 特性
Dapr 核心…(这期先了解Dapr之后在推出如何搭建Dapr以及如何使用。)
目录
引言
Service Mesh定义
Service Mesh解决的痛点
Istio介绍
Service Mesh遇到的挑战
分布式应用的需求
Multiple Runtime 理念推导
Dapr 介绍
Dapr 特性
Dapr 核心模块
Dapr 核心Component Building Block
Dapr 整体架构
Dapr 微软落地场景 引言
从 2010 年的时候SOA 架构就已经在中大型互联网公司中开始流行阿里也在2012 年开源了 Dubbo 。而之后微服务架构开始流行大量互联网和传统企业都投身到微服务的建设中。在国内逐渐形成了Dubbo 和 Spring Cloud 两大微服务阵营。在2016 年的时候微服务领域一个更具有前沿性更加符合容器和 Kubernetes 的微服务方案正在孕育这个技术被称为 Service Mesh(服务网格)。时至今日Service Mesh 理念已经得到了大范围普及很多公司都在 Service Mesh 领域有了落地。
Service Mesh定义
Service Mesh 是一个基础设施层主要围绕服务间通信来进行。现在的云原生应用的服务拓扑结构非常复杂Service Mesh 可以在这种复杂拓扑结构中实现可靠的请求传送。Service Mesh 是以 Sidecar 的方式运行应用旁边会运行一个独立的 Service Mesh 进程Service Mesh 负责远程服务的通信。军用三轮摩托车和 Service Mesh 非常相像军用三轮摩托车上一个士兵负责开车一个士兵负责对人发起射击。
服务注册与发现服务之间调用服务之间降级熔断服务之间链接追踪服务监控
Service Mesh解决的痛点 传统的微服务架构大都以 RPC 通信框架为基础在 RPC SDK 中提供了服务注册/发现服务路由负载均衡全链路跟踪等能力。应用业务逻辑和 RPC SDK 在同一个进程中这种方式给传统微服务架构带了很多挑战中间件能力相关代码侵入到了业务代码中耦合性很高推动 RPC SDK 的升级成本非常高进而也导致了 SDK 版本分化非常严重。同时这种方式对应用开发者的要求比较高需要有丰富的服务治理的运维能力有中间件的背景知识使用中间件的门槛偏高。
通过 Service Mesh 方式将一些 RPC 的能力进行下沉这样可以很好的实现关注点分离、职责边界的明确。随着容器和 Kubernetes 技术的发展Service Mesh 已经成为云原生的基础设施。
Istio介绍 在 Service Mesh 领域中 Istio 毫无疑问是当中的王者。Istio 由控制面和数据面构成在 Service Mesh 中不同的 Service 之间通过 Proxy Sidecar 进行通信。Istio 最核心功能是流量管理通过数据面和控制面协调完成。Istio 是由 Google 联合IBMLyft 一起发起的是 CNCF 生态版图 Service Mesh 领域的最纯正血统有望成为Service Mesh事实标准。
Istio 的数据面默认使用 EnvoyEnvoy 是社区里默认的最佳数据面。Istio 数据面和控制面的交互协议是 xDS。
Service Mesh小结
Service Mesh 定位就是提供服务间通信的基础设施社区里主要支持 RPC 和http 。采用 Sidecar 方式部署支持部署在 Kubernetes 和虚拟机之上。Service Mesh 采用原协议转发所以 Service Mesh 也被称为网络代理。正是由于这种方式方式所以可以做到对应用的零侵入。
Service Mesh遇到的挑战 用户在云上部署业务的形态主要有普通应用类型和FaaS类型。Faas 场景下比较吸引用户的是成本和研发效率成本主要通过按需分配和极致的弹性效率来达成。而应用开发者期望通过 FaaS 提供多语言的编程环境提升研发效率包括启动时间、发布时间、开发的效率。
Service Mesh 的实现本质是原协议转发原协议转发可以给应用带来零侵入的优势。但是原协议转发也带来了一些问题应用侧中间件SDK还需要去实现序列化和编解码工作所以在多语言实现方面还有一定成本随着开源技术的不断发展使用的技术也在不断迭代如果想从 Spring Cloud 迁移到 Dubbo 要么应用开发者需要切换依赖的 SDK如果想借助Service Mesh来达到这个效果Service Mesh 需要进行协议转换成本较高。
Service Mesh 更加聚焦于服务间的通讯而对其他形态的 Mesh 的支持上非常少。比如 Envoy 除了在 RPC 领域比较成功外在 Redis、消息等领域的尝试都未见成效。蚂蚁的 Mosn 中支持了 RPC 和消息的集成。整体多 Mesh 形态的需求是存在的但是各个 Mesh 产品各自发展缺少抽象和标准。如此多形态的 Mesh 是共用一个进程吗如果是共用一个进程那么是共用一个端口吗许多问题都没有答案。而控制面方面从功能角度来看的话大都围绕流量来展开。看过 xDS 协议里的内容核心是围绕发现服务和路由来展开。其他类型的分布式能力在 Service Mesh的控制面中基本没有涉及更谈不上抽象各种类似 xDS 的协议去支持这些分布式能力。
因为成本和研发效率等原因FaaS 受到了越来越多客户的选择FaaS 对多语言和编程 API 的友好性上有了更多诉求那么 Service Mesh 在这两块还是不能给客户带来额外的的价值。 分布式应用的需求 Bilgin Ibryam 是 Kubernetes Patterns 的作者是 RedHat 的首席中间件架构师在 Apache 社区里非常活跃。他发表了一篇文章对当前分布式的一些困难和问题进行了抽象将分布式应用需求分成了 4 个大种类生命周期、网络、状态、绑定。每种类型下面还有一些子能力如 Point-to-Point pub/sub Caching 等比较经典的中间件能力。应用对分布式能力有如此多的需求而 Service Mesh 显然不能满足应用的当前的需求。Biligin Ibryam 还在文章中提出了 Multiple Runtime 的理念来解决Service Mesh 的困境。
Multiple Runtime 理念推导 在传统的中间件模式下应用和分布式能力是在一个进程中以 SDK 方式进行集成。随着各种基础设施下沉各种分布式能力从应用中移到了应用外。如 K8s 负责了生命周期相关的需求Istio、Knative 等都负责一些分布式能力。如果将这些能力都移动到独立的 Runtime 中那么这种情况无论从运维层面还是资源层面来看都是没办法接受的。所以这时候肯定需要将部分 Runtime 进行整合最理想的方式肯定是整合成一个。这种方式被定义成 Mecha 中文意思是机甲的意思就像日本动漫里主人公变身穿上机甲机甲的每个部件就像一个分布式能力机甲里的人对应的是主应用也叫 Micrologic Runtime 。 这两个 Runtime 可以是一对一的 Sidecar 方式这种非常适合传统的应用也可以是多对一的 Node 模式适合边缘场景或者网管模式下。
那么对于将各种分布式能力进行整合的 Mecha Runtime 这一目标本身问题不大那么怎么整合呢对 Mecha 有什么要求呢
Mecha 的组件能力是抽象的任何一个开源产品可以快速进行扩展和集成。Mecha 需要有一定的可配置能力可以通过 yaml/json 进行配置和激活。这些文件格式最好能和主流的云原生方式对齐。Mecha 提供标准的 API 和主应用之间的交互的网络通信基于此 API 来完成不再是原协议转发这样对于组件扩展和 SDK 的维护都能带来极大的便利性。分布式能力中的生命周期可以将部分能力交接过底层的基础设施比如 K8s。当然有些复杂的场景可能需要 K8s、APP、Mecha Runtime 一起来完成。
既然最理想只剩下一个 Runtime , 那么为什么还叫 Multiple Runtime 呢因为应用本身其实也是一个 Runtime 再加上 Mecha Runtime 所以至少是两个 Runtime 。
Dapr 介绍
前面的 Multiple Runtime 介绍地比较抽象可以来从 Dapr 来重新理解下 Multiple Runtime 。Dapr 是 Multiple Runtime 的一个很好的践行者所以 Dapr 肯定和应用共存的要么是 Sidecar 模式要么是 Node 模式。Dapr 这个词其实是不是造出来的而是 Distributed Application Runtime 的首字母拼接而成Dapr 这个图标可以看出来是一个帽子这个帽子其实是一个服务生的帽子表示的含义是要为应用做好服务。
Dapr 是由微软开源的阿里巴巴深度参与合作。当前的 Dapr 已经发布多个版本现在已经接近生产的能力。 既然 Dapr 是 Multiple 的最佳实践者那么 Dapr 的运行机制也是基于 Mulitple Runtime 的理念来构建的。Dapr 对分布式能力进行了抽象定义了一套分布式能力的 API而且这些 API 是基于 Http 和 gRPC 来构建的这种抽象和能力在 Dapr 中被称为 Building BlockDapr 为了支持开源产品和商业化等不同类型的产品对 Dapr中的分布式能力进行扩展内部拥有一套 SPI 扩展机制这种 SPI 机制叫 Components 。应用开发者在使用 Dapr 之后只需要针对各种分布式能力的 API 来进行编程而无需过多关注具体的实现而 Dapr 中根据 Yaml 文件可以自由激活对应的组件。
Dapr 特性 应用开发者使用各种多语言的 Dapr SDK 就可以直接拥有各种分布式能力。当然开发者也可以自己基于 HTTP 和 gRPC 来完成调用。Dapr 可以运行在大部分环境里包括你自己电脑的环境或者任何 Kubernetes 环境下或者边缘计算场景或者阿里云、AWS、GCP 等云厂商。
Dapr 社区里已经集成了 70 的 components 实现应用开发者可以快速进行选择和使用。相似能力的组件的替换可以通过 Dapr 里完成应用侧可以做到无感知。
Dapr 核心模块 我们从 Dapr 产品模块纬度来解析下看为什么 Dapr 是 Mulitiple Runtime 的一个很好实践。
Component 机制确保了可以快速扩展能力的实现现在社区已经有的 Components实现已经有 70 个以上不只包含开源产品还包含云上的商业化产品。
Building Block 表示的的分布式能力现在只支持 7 个后续需要更多的分布式能力能够进来。BuildingBlock 现在支持了 HTTP 和 gRPC 这两种开放而且普及度已经非常高的协议。而 Dapr 中 Building Block 下具体那些 Components 会被激活需要依赖 YAML 文件来进行。正因为 Dapr 中采用了 HTTP、gRPC 的方式暴露能力所以在应用侧想要支持多语言的标准的API编程界面就变得更为容易了。
Dapr 核心Component Building Block 一个 Building Block 由 1 个或多个 Component 组成Binding的Building Block 包含 Bindings 和 Middleware 两个 Component 。
Dapr 整体架构 Dapr 和 Istio 一样也有数据面和控制面。控制面有 Actor PlacementSidecar Injector Sentry OPerator。Actor Placement 主要为 Actor 服务Sentry 做安全和证书相关的工作Sidecar Injector 主要负责 Dapr Sidecar 的注入。Dapr 里激活某个组件实现是通过 YAML 文件来完成的YAML 文件可以通过两种方式来指定一种是本地指定运行时参数另外一种是通过控制平面 Operator 来完成将组件激活的文件以 K8s CRD 方式存储并下发到 Dapr的Sidecar 中。控制面的 2 个核心组件都依赖于 K8s 来运行。现在的 Dapr Dashboard 功能还很弱短期还不到增强的方向现在各个组件的集成之后各个组件的运维还需要在原来的控制台里完成Dapr 控制平面不参与具体组件实现的运维。
Dapr 微软落地场景
Dapr 经历了多年的发展在微软内部的落地情况是怎么样的呢 Dapr 的 github 上有两个项目workflows 和 Azure Functions Dapr extensions。Azure Logic App 是微软的一个基于云上的自动工作流平台。而 Workflows就是整合了 Azure Logic App 和 Dapr。Azure Logic App 中有几个关键的概念Trigger 和 Connector 和 Dapr 非常契合。Trigger 可以使用 Dapr 的 Input Binding 来完成依赖 Dapr 的 Input Binding 的大量组件实现可以扩大流量入口的类型。而 Connector 和 Dapr 的 Output Binding 或者 Service Invocation 的能力非常匹配可以快速访问外部资源。Azure Functions Dapr extensions 则是基于Azure Function extension 做的 Dapr 支持可以让 Azure Function 快速使用上Dapr 的各种 Building Block 的能力同时能给函数开发者带来多语言的相对简单一致的编程体验。 Azure API Management Service和上面提到的两个落地场景的角度不太一致它是前提是应用之间已经通过Dapr Sidecar方式进行访问应用的提供的服务通过Dapr来进行暴露。这时候如果非K8s的应用或者跨集群的应用想要访问当前集群的服务就需要一个网关这个网关可以直接暴露Dapr的能力在网关中会增加一些安全和权限的控制。当前支持3种Building BlockService Invocation、pub/sub、resource Bindings。
Dapr 小结
Dapr 提供的面向能力的 API 能够给开发者带来支持多语言的一致的编程体验同时这些 API 的SDK相对比较轻量级。这些特性非常适合 FaaS 场景。而随着 Dapr 集成生态的不断完善开发者面向能力编程的优势将进一步扩大通过 Dapr 可以更加方便地将 Dapr 组件的实现进行替换而无需开发者做代码的调整。当然原来的组件和新的组件实现必须是相同类型的分布式能力。
Dapr 和 Service Mesh 差异点
提供能力Service Mesh 专注服务调用Dapr 提供的分布式能力范围更广覆盖多种分布式原语。
工作原理Service Mesh 采用原协议转发做到零侵入Dapr 采用多语言SDK 标准API 各种分布式能力。
面向领域Service Mesh 对传统微服务的无侵入升级支持很友好Dapr 对面向应用的开发者提供了更加友好的编程体验。
