Dubbo 在 K8s 下的思考

序言

Dubbo在2011开源之后,一直是国内最受欢迎的RPC框架,之后spring boot和Spring Cloud的面世,助推了微服务的火热程度。计算机的世界变化很快,自从容器和K8s登上舞台之后,给原有的RPC领域带来了很大的挑战。这个文章主要讲述RPC领域遇到的问题,以及RPC怎么去拥抱K8s怀抱的一些思考。

K8S介绍

kubernetes是一个开源的,用于管理云平台中多个主机上的容器化的应用,Kubernetes的目标是让部署容器化的应用简单并且高效,Kubernetes提供了应用部署,规划,更新,维护的一种机制。kubernetes简称K8s。

在Kubernetes中,最小的管理元素不是一个个独立的容器,而是Pod。Pod的生命周期需要注意以下几点:

  • 容器和应用可能随时被杀死
  • Pod Ip和主机名可能变化 (除非使用StatefulSet进行定制)
  • 写到本地的磁盘的文件可能消失,如果想不失效,需要用存储卷

应用,容器,Pod的关系

  • 应用部署在容器中,一般情况下一个应用只部署在一个容器中
  • 一个Pod下可以包含一个或多个容器,一般情况下一个Pod只建议部署一个容器。下列场景除外:

    • side car
    • 一个容器的运行以来与本地另外一个容器。如一个容器下应用负责下载数据,另外一个容器下应用向外提供服务

Service

如果一些Pods 提供了一些功能供其它的Pod使用,在kubernete集群中是如何实现让这些前台能够持续的追踪到这些后台的?答案是:Service。

Kubernete Service 是一个定义了一组Pod的策略的抽象,这些被服务标记的Pod一般都是通过label Selector决定的。Service抽象了对Pod的访问。

默认的Service,通过一个集群Ip获取A Record。但是有时需要返回所有满足条件的Pod Ip列表,这时候可以直接使用 Headless Services

推荐书籍:kubernetes in action

RPC介绍和分析

随着微服务的普及,应用之间的通信有了足够多的成熟方案。Dubbo在2011年开源之后,被大量的中小型公司采用;在Spring Boot推出之后,Spring逐渐焕发出第二春,随即Spring Cloud面世,逐渐占领市场,在中国市场中,和Dubbo分庭抗争;gRPC是google推出的基于Http2的端到端的通信工具,逐渐地在K8s市场上占据统治地位,如etcd,istio等都采用gRPC作为通信工具;Service Mesh从开始概念上就火热,现在逐渐走向成熟,Istio + Envoy(其他sidecar)逐渐开始走上舞台。

应用开发者视角

从功能层面来说,对开发者有感知的功能有:服务实现,服务暴露(注解或配置),服务调用(注解或配置),服务治理等。

从选型角度会关注以下几点:易用性(开发易用性和开箱即用),性能,功能,扩展性等。

框架开发者视角

关键流程:服务暴露,服务注册,服务发现,服务调用,服务治理。

关键知识点:序列化,网络通信,服务路由,负载均衡,服务限流,熔断,降级等服务治理。

主流技术实现

DUBBO/HSF

Dubbo提供了面向接口的远程方法调用。应用开发者定义接口,编写服务并暴露;Client端通过接口进行调用。

Dubbo注册服务的维度是接口维度,每个接口会在注册中心写入一条数据。

Dubbo支持条件路由,脚本路由,Tag路由等。这些路由规则都是强依赖于IP地址

备注:Dubbo和HSF的大部分机制都是相似的,所以下面都以Dubbo作为方案进行讨论。

SpringCloud

Spring Cloud通过Rest形式进行网络调用。应用开发者可以自己编写暴露Rest服务,如springmvc。

Spring Cloud里的服务注册是应用维度(Eureka),Client端和Server端通过约定的方式进行通信。

Spring Cloud提供了一套标准API,而其中Netflix是其中的佼佼者,对这套API进行了实现,对大部分开发者来说,可以回直接依赖和使用Netflix,所以可以说是Netflix提供成了Spring Cloud的核心。但是作为商业公司对开源投入往往会多变,如Eureka已经体制维护。

gRPC

gRPC 是一个 基于 HTTP/2 协议设计的 RPC 框架,它采用了 Protobuf 作为 IDL。gRPC作为端到端的通信方案,可以解决现在的多语言问题。

gRPC本身不提供服务注册,服务治理的功能。但现在可以看到gRPC有趋势往这方面扩展的野心。

K8s

K8s体系里暂时没有公允的通信框架,一般推荐gRPC作为RPC框架。

K8s体系下,默认情况下,Pod的Ip是变化的,所以Pod和Pod之间需要通信的话,有几种方式:

  • Service+DNS:新建一个Service,可以通过标签选择到一组Pod列表,这个service对应一个不变的集群Ip;Client端通过DNS方式或者直接访问集群Ip。这个集群Ip,约等于实现了负载均衡 (Iptable方式)。
  • headless service:headless service和上面的service的区别是,它不提供集群Ip,通过主机名的形式获取一组Ip列表,Client端自己决定访问哪个Pod。

Istio + Envoy

Istio的控制层会向K8s的api server请求并监听Pod信息,service信息等信息。这样Istio中就有了完整的K8s集群中的Pod,service等的完整信息。如果K8s集群中有信息变更,istio中也可以得到通知并更新对应的信息。

Envoy作为Proxy一个最常见的实现,以Envoy作为例子简单介绍。Envoy 通过查询文件或管理服务器来动态发现资源。对应的发现服务及其相应的 API 被称作 xDS。协议内容包括LDS,RDS,CDS等等。

备注:上述知识是通过查阅资料(Istio官网),以及和集团service mesh同学沟通获得。如有问题,欢迎指正。

总结

遇到的问题和挑战

Spring Cloud和Dubbo的共生

Dubbo默认是基于TCP通信,Spring Cloud大部分基于Rest请求。在阿里云实施商业化过程中,发现大量公司需要Spring Cloud应用和Dubbo进行通信,社区主要依靠Dubbo上增加一层网关来解决。

是否有方案进行统一服务注册发现,以及服务调用呢?

Dubbo在K8s场景下的挑战

K8s下Pod的IP是变化的 (默认),dubbo的服务治理高度依赖IP。

K8s的服务注册通过Pod定义完成,服务发现其实是寻找Pod的过程。Pod和应用有一定的对应关系,和dubbo里的接口维度的服务注册发现模型不是很匹配。

Dubbo在Service mesh场景下的生存空间

Dubbo需要进行支持裁剪,Dubbo的大部分功能都可以交由sidecar(proxy)来完成。

如果公司已经在部署了RPC框架,这时候如果需要实施Service Mesh,有什么好的过渡方案吗?

问题梳理

服务定义

服务怎么定义呢?需要从应用开发者角度看待怎么定义服务。

服务在功能维度对应某一功能,如查询已买订单详情。在Dubbo中,对应某个接口下的方法;在Spring Cloud和gRPC对应一个Http请求。如果从面向函数编程角度,一个服务就是一个function。在Java语言中,class是一切编程的基础,所以将某些服务按照一定的维度进行聚合,放到某个接口中,就成了一个接口包含了很多的服务。

从Dubbo角度来解释下:Dubbo是面向接口编程的远程通信,所以Dubbo是面向服务集的编程,你如果想调用某个服务,必须通过接口的方式引入,然后调用接口中的某个服务。Dubbo Ops中提供的服务查询功能,其实不是查询单个服务,而是通过查询接口(服务集)之后获得具体的方法(服务)。

而在Spring Cloud的世界里,服务提供方会将自己的应用信息(Ip+port)注册成应用下的一个实例,服务消费方和服务提供方按照约定的形式进行Rest请求。每个请求对应的也是一个服务。

和K8s里的service的区别

K8s里的service其实是对应到一组Pod+port列表,和DNS联系紧密;用通俗易懂的方式表达:维护了Pod集合的关系映射。和上面讲的服务是属于不同场景下的两个概念。

按照这个方式定义服务,服务治理的粒度其实也是按照服务粒度,可以针对每个服务设置超时时间,设置路由规则等等。但是服务注册的粒度和服务有什么关系呢?

服务注册粒度

一个应用下包含了很多接口,一个接口下包含了很多服务(Dubbo);或者一个应用包含了很多的服务(Spring Cloud)。分析下应用维度注册和接口维度注册的优缺点。会有一篇独立的文章来阐述应用维度注册的方案

接口维度注册

优点:

  • 服务查询按照接口维度查询非常方便,实现难度低
  • 应用拆分或者合并的时候,Client端(消费者)无需关心,做到了让用户无感

缺点:

  • 和K8s等主流平台的模型对应关系不匹配
  • 注册的数据量非常大,有一定的性能风险

应用维度

优点:

  • 和K8s,Spring Cloud等模型对应关系一致
  • 性能上可以得到很大缓解

缺点:

  • 应用拆分或者合并的时候,Client端需要感知 (如果想做到不感知,需要框架开发者维护一份接口和应用映射关系的存储)
  • 如果想对用户保持Dubbo原有的接口维度的查询,需要较多的工作量来保证。
  • 对用户透明度有所减少,需要在OPS上提供其他一些工具。如供应用开发者可以查看具体某个Ip是否提供了某个服务等等。

Dubbo 和 Spring Cloud

目标:Dubbo和Spring Cloud的服务发现进行统一;Dubbo和Spring Cloud可以互相调用。

服务发现统一

Dubbo改造成应用维度的服务注册。(具体不展开,后面文章说明)

打通调用

Dubbo实现中,支持将以Rest协议进行暴露,并且让Spring Cloud识别。@桃谷

Dubbo + K8S

在K8s已经阐述过,下面的内容也是假设一个应用部署在一个容器里,一个容器部署在一个Pod里。

接下来方案的讨论,互相之间其实是有关联的,如服务治理可能会影响到服务注册发现,服务查询也不能依赖于服务注册的内容。整个设计的过程是不断优化的过程。下面所说的内容,以Dubbo来举例说明。

服务治理

Dubbo原有体系里的服务治理是强依赖于IP,当配置了一套服务治理规则的时候,最后都是基于一个或多个Ip地址。

到K8s体系下之后,要考虑的是Pod的Ip不是固定的。所以当前的路由规则不能满足条件,而且会产生很多规则垃圾数据。K8s体系下,通过service查找Pod,是基于label selector; 通过deployment管理Pod,其实也是基于Pod label selector。所以Pod label selector是在K8s习题中比较通用的解决方案。

以路由规则为例,需要支持一种新的路由规则:label路由。通过一定条件匹配之后,将结果定位到以label selector查询到的Pod列表里,而非原来的Ip列表。

要支持label路由,Client端需要获取到Client端自己的Pod label信息,还需要获取到server Pod列表中每个Pod的label信息。

应用获取当前Pod的信息方式

  1. Pod定义环境变量,应用获取

Dubbo提供对环境变量读取的支持,Pod中需要按照Dubbo定义的环境变量设置具体的Pod信息。

  1. 通过Downward Api传递Pod信息

Dubbo需要提供对Downward的目录读取,Pod中需要定制downward的对应配置。

  1. 通过Api server获取数据

最强大的方式,但是应用需要强依赖于Api server。

应用获取其他Pod的信息方式

  1. 通过调用其他Pod的服务获取

依赖于应用能获取自身的Pod信息,同时将自身的Pod信息暴露成服务(rest或dubbo协议)

Client端通过调用对用的Pod获取到对应Pod的完整信息。

  1. 通过api server获取数据

很强大,但增加了对api server的依赖。

服务注册和发现

K8s体系下,RPC服务发现有几种方式:

  • 注册机制:将Ip写入注册中心,用心跳保持连接;当心跳停止,从注册中心删除。
  • 利用Service+DNS:新建一个Service,可以通过标签选择到一组Pod列表,这个service对应一个不变的集群Ip;Client端通过DNS方式或者直接访问集群Ip。这个集群Ip,约等于实现了负载均衡 (Iptable方式)。
  • 利用headless service(DNS):headless service和上面的service的区别是,它不提供集群Ip,通过主机名的形式获取一组Ip列表,Client端自己决定访问哪个Pod。
  • api server: Client端直接请求Api server,获取到Pod的列表,Client自己决定访问Pod的逻辑。同时获取的时候增加watch,api server会将Pod的变化信息同步Client。

通过拿到Server端的Ip或者host,Client端就可以发起Http或者其他协议的请求。

下面介绍符合Dubbo的可行方案:

1. Dubbo + Zookeeper Pod cluster (HSF+CS cluster)

这是最简单的方式,Dubbo本身不需要做任何改造。

带来的问题是增加了ZooKeeper的维护,同时这个方案很不云原生,和K8s的体系没有任何关系。

脑暴

上面方案是将ZooKeeper作为注册中心,那么是否可以将K8s里service作为注册中心呢?dubbo里每个接口去建立一个service,每个应用实例启动过程中去更新Endpoint信息,建立Service-> Endpoint-> Ip列表的关系。

这种方案中K8s service的定义被改造了,而且定义了过多的service,service的维护管理是个难题。

基于K8s的场景

在传统的RPC领域,服务分成服务注册和服务发现。在K8s领域Pod和应用是一对一的关系,K8s本身就提供了Pod查找的能力,所以一定程度上服务注册其实可以不存在,而只需要服务发现。但是这个其实需要一个前提:

dubbo需要将服务注册发现的粒度改造成应用维度。

在运维层面,将app=xxx (应用名)写入到Pod的label中。

2. Dubbo + K8s DNS

如果K8s service提供了cluster Ip,那么Dubbo只负责调用该集群Ip,路由和负载均衡的逻辑则交给了K8s的proxy来完成。此方案削减了Dubbo的核心能力。

接下来讨论headless service提供的能力。

通过请求<service>.<ns>.svc.<zone>. IN A 的方式发起请求获取Ip列表,但是需要轮询方式不断获取更新的Ip列表。参考

服务治理相关的功能,需要在上述服务治理部分中独立支持。

3. Dubbo + Api Server

Pod的容器中部署的dubbo应用,服务注册流程可以直接删除,服务发现功能通过和Api Server进行交互,获取Pod和service信息,同时watch Pod和service的变更。通过这种方式之后,服务治理相关的信息也可以通过Api Server直接获取。

4. Dubbo + Istio + Envoy

Dubbo可以直接使用指定Ip+端口的方式调用同一个Pod下Envoy (也可能是同一个node的Envoy)。Dubbo将路由规则,负载均衡,熔断等功能交给Istio和Envoy。Envoy需要支持Dubbo协议的转发。

所以Dubbo需要完成两个事情:本地IP直连(现有功能), 多余功能裁剪(暂未实现)。

5. Dubbo + Istio

Dubbo 应用不再依赖 Envoy 作为 sidecar ,而是直接和 Istio 进行交互,把 Istio 作为注册中心,作为服务治理的配置中心。

Dubbo 需要提供类似的 xDS 协议,在pilot将service的instance转换成dubbo的协议格式。

Dubbo 还需要去适配 istio 的一些功能,如健康检查,安全相关的逻辑。具体实现可以参考 Envoy 的实现。

6. Dubbo和 Istio 在 K8s 体系下共存

这个可选择的方案较多,我提供两种思路,供大家思考:

所有的服务注册通过K8s的机制完成,所有的服务发现通过 Headless service 完成。sidecar 在创建过程中,需要对原有的 K8s service 进行 update 。

Nacos 作为 Dubbo 的注册中心,并且需要将 K8s 中的数据进行部分中转。Dubbo 应用,将服务注册以应用维度注册到 Nacos ,Istio Pilot 需要识别 Nacos 数据;Istio 的运行机制基本不变,需要将 K8s service instance 的数据写入到 nacos ,供 Dubbo 调用。

7. 云上和云下环境共存 & 云上多集群环境

Istio 提供了跨集群和云上云下的解决方案, kubeFed 作为 K8s 的跨集群解决方案也能起到一定作用。

这个课题的复杂度更加高,心中有了一些答案,期望大家通过上文也有一定的思考。

服务查询

抛出三种方式,供大家思考。

Dubbo原有方式

Dubbo原有的服务查询是针对接口的查询,每个接口会有版本号和组别。接口名+版本号+组别确定唯一的服务集合,这个服务集下有对应的服务提供者和服务消费者(接口级依赖),服务提供者是一组Ip+port列表,服务消费者也是一组Ip+port列表。

当做了改造成应用级别的服务注册或者直接使用K8s自带的Pod发现机制的话,需要做一些改造,这部分改造,和前面提到的一样,放到其他文章里单独说明。

只支持应用查询

和Spring Cloud类似,支持应用维度的查询。查询到具体应用之后,应用详情下包含了Ip+port列表,每个Ip+port其实就是一个应用的实例。点击开每个应用实例,可以查看每个应用的详细信息,详细信息包含了该实例提供了哪些服务。

接口+应用查询均衡

在原来只支持应用查询的基础上,增加一步:支持查询某个接口对应的应用列表,而大部分接口只属于一个应用。

再点击应用列表下具体的应用之后,会跳到应用详情。

总结

上述讨论的是开源的方案,所以相对历史包袱比较少。对一些大公司想从原有的RPC方案切换到云原生的支持,需要考虑更多兼容性和性能,需要付出更大的代价。

云原生的趋势已经势不可挡,在RPC领域究竟哪种方案最终能够胜出,现在还言之过早。我相信Service Mesh 和传统的RPC (Dubbo/ gRPC) 都会有自己的一席之地,一切让时间给我们答案吧。


阿里云双11亿元补贴提前领,进入抽取iPhone 11 Pro:https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110

原文链接
本文为云栖社区原创内容,未经允许不得转载。

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/517593.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

containerd与安全沙箱的Kubernetes初体验

containerd是一个开源的行业标准容器运行时&#xff0c;关注于简单、稳定和可移植&#xff0c;同时支持Linux和Windows。2016年12月14日&#xff0c;Docker公司宣布将Docker Engine的核心组件 containerd 捐赠到一个新的开源社区独立发展和运营。阿里云&#xff0c;AWS&#xf…

Seata 单机环境搭建_01

文章目录一、整合版本说明1. 毕业版本依赖关系(推荐使用)2. 组件版本关系3. 演示版本二、部署单机 TC Server2.1. 下载Seata2.2. 解压缩2.3. 启动2.4. 监听日志2.5. 启动命令讲解一、整合版本说明 1. 毕业版本依赖关系(推荐使用) Spring Cloud VersionSpring Cloud Alibaba V…

学生成绩管理系统java+mysql+swing入门级项目开发

夫陶公清风千古&#xff0c;余又何人&#xff0c;敢称庶几 代码已移至Gitee &#xff1a; https://gitee.com/BreezAm/edu-student 文章目录简要&#xff1a;登陆运行效果主界面运行效果图界面设置运行效果图网络配置界面运行效果图菜单栏运行效果图登陆窗体实现窗体界面设置功…

干货 | 大白话彻底搞懂 HBase RowKey 详细设计

作者 | 且听风吟责编 | Carol封图 | CSDN 付费下载于视觉中国前言RowKey作为HBase的核心知识点&#xff0c;RowKey设计会影响到数据在HBase中的分布&#xff0c;还会影响我们查询效率&#xff0c;所以RowKey的设计质量决定了HBase的质量。是咱们大数据从业者必知必会的&#xf…

Knative 实战:如何在 Knative 中配置自定义域名及路由规则

目前 Knative 中默认支持是基于域名的转发&#xff0c;但域名默认格式是&#xff1a;"{{.Name}}.{{.Namespace}}.{{.Domain}}"&#xff08;这个可以在 config-network 配置&#xff09;。但对于用户来说并不能指定全域名。 另外一个问题就是基于Path 转发的能力&…

混合云模式下 MaxCompute + Hadoop 混搭大数据架构实践

摘要&#xff1a;2019杭州云栖大会大数据企业级服务专场&#xff0c;由斗鱼大数据高级专家张龙带来以 “混合云模式下 MaxComputeHadoop 混搭大数据架构实践” 为题的演讲。本文讲述了从 Apache Hadoop 阶段到 Cloudera CDH 阶段斗鱼大数据架构的发展历程。提出了上云过程中斗鱼…

mybatisplus 一次性执行多条SQL语句

文章目录一、Mysql数据库1. Url2. xml映射文件二、Oracle数据库2.1. 关键点2.2. xml映射文件一、Mysql数据库 关键点&#xff1a;在url后面添加&allowMultiQueriestrue&#xff0c;sql后面添加分号; 1. Url 案例&#xff1a; url: jdbc:mysql://localhost:3306/afsdb?…

没错!Python程序员正在消失,HR:你才知道?

Python为什么这么火&#xff1f;学了Python能干什么&#xff1f;Python程序员有前途吗&#xff1f;几乎所有人脑子里都有这个疑问&#xff0c;感觉现在铺天盖地都是Python的消息&#xff0c;就连刷抖音都能刷到Python&#xff0c;Python已经火出圈了&#xff01;Python为什么这…

swing中模态对话框(setModal(true))和显示对话框(setVisible(true))的编写顺序

今天给大家分享一个鄙人在编程中总结出的一个易错点和最容易让人感到困惑的一个知识点&#xff1a; 当你要从一个窗体跳转到另一个窗体&#xff0c;你把跳转目标的窗体设成模态对话框&#xff0c;设计成模态对话框就是禁止父窗体与子窗体之间操作&#xff0c;简单说就是当调用子…

Service Mesh 初体验

前言 计算机软件技术发展到现在&#xff0c;软件架构的演进无不朝着让开发者能够更加轻松快捷地构建大型复杂应用的方向发展。容器技术最初是为了解决运行环境的不一致问题而产生的&#xff0c;随着不断地发展&#xff0c;围绕容器技术衍生出来越来越多的新方向。 最近几年&a…

mybatisplus 一次性执行多条SQL语句插入(Mysql篇)

文章目录一、数据库部分1. 创建数据库2. 初始化表结构二、代码部分2.1. controller2.2. mapper接口2.3. 映射文件2.4. 参数封装三、测试验证3.1. 发起请求3.2. 查看数据库3.3. 配置文件部分一、数据库部分 1. 创建数据库 创建more-insert 2. 初始化表结构 -- 一次性插入多张…

带领国产数据库走向世界,POLARDB底层逻辑是什么?

POLARDB 是阿里云自主研发的下一代云原生分布式数据库&#xff0c;100%兼容MySQL、PostgreSQL等开源数据库&#xff0c;高度兼容Oracle语法&#xff0c;使用RDS服务的客户不需要修改应用代码&#xff0c;可以一键迁移到POLARDB&#xff0c;体验更大的容量&#xff0c;更高的性能…

基于java+swing+mysql+JFeeChart的企业人力资源管理系统(1)

文章目录一&#xff0c;前言二&#xff0c;项目运行图&#xff08;1&#xff09;主界面&#xff08;管理员界面&#xff09;&#xff08;2&#xff09;员工资料运行图&#xff08;3&#xff09;全部员工查看运行图&#xff08;4&#xff09;部门管理运行图&#xff08;5&#x…

十年架构师:我是这样手写Spring的,用300行代码体现优雅之道

起源Spring作为一个开源框架&#xff0c;于2003 年兴起的一个轻量级的Java 开发框架&#xff0c;由Rod Johnson 在其著作《Expert One-On-One J2EE Development and Design》中阐述的部分理念和原型衍生而来。它是为了解决企业应用开发的复杂性而创建的。框架的主要优势之一就是…

深度 | 打败围棋冠军后,机器智能下一步能战胜黑客吗?

阿里妹导读&#xff1a;从深蓝战胜象棋冠军到AlphaGo战胜围棋冠军&#xff0c;每一次机器智能在特定领域战胜人类&#xff0c;都会引发整个社会的广泛关注。洞察了棋类博弈真相的机器智能&#xff0c;接下来能洞察网络安全的真相并且在黑客博弈中战胜人类吗&#xff1f;在机器智…

mybatisplus 一次性执行多条SQL语句插入(Oracle篇)

文章目录一、数据库部分1. 创建数据库2. 初始化表结构二、代码部分2.1. controller2.2. mapper接口2.3. 映射文件2.4. 参数封装三、测试验证3.1. 发起请求3.2. 查看数据库3.3. 配置文件部分一、数据库部分 1. 创建数据库 创建more-insert 2. 初始化表结构 -- 一次性插入多张…

从310到蚂蚁森林,蚂蚁金服在线图计算的创新与实践

蚂蚁金服过去十五年&#xff0c;重塑支付改变生活&#xff0c;为全球超过十二亿人提供服务&#xff0c;这些背后离不开技术的支撑。在 2019 杭州云栖大会上&#xff0c;蚂蚁金服将十五年来的技术沉淀&#xff0c;以及面向未来的金融技术创新和参会者分享。我们将其中的优秀演讲…

Seata 与 Nacos注册中心整合实现集群环境搭建_02

接上一篇&#xff1a;Seata 单机环境搭建_01 文章目录一、整体架构二、安装步骤2.1. 创建数据库2.2. 初始化表结构2.3. 修改配置文件2.4. 调整数据库驱动2.5. 修改配置中心三、 启动和验证3.1. 启动nacos3.2. 启动TC Server3.3. 验证高可用一、整体架构 我们来学习部署集群 Se…

趣谈程序员真香定律:源码即设计

来源 | 码砖杂役责编 | Carol封图 | CSDN 付费下载自视觉中国我们经常谈论架构&#xff0c;讨论设计&#xff0c;却甚少关注实现和代码本身&#xff0c;架构和设计固然重要&#xff0c;但要说代码本身不重要&#xff0c;我不同意&#xff0c;Robert C.Martin大叔也不同意&#…

Nacos 1.1.4 发布,业界率先支持 Istio MCP 协议

Nacos是阿里巴巴开源的服务发现与配置管理项目&#xff0c;本次发布的1.1.4版本&#xff0c;主要带来的是与Istio的对接功能&#xff0c;使用的是Istio最新的MCP协议。本文将介绍包括这个功能在内的新版本发布的功能。 升级指南 服务端 0.8.0及以上版本&#xff1a; 解压安…