无责任畅想:云原生中间件的下一站

简介: 本文源自 2020 年 12 月 20 日作者在云原生社区 meetup 第二期北京站演讲 《Apache Dubbo-go 在云原生时代的实践与探索》的部分内容

自从以 2013 年开源的 docker 为代表的的容器技术和以 2014 年开源的 K8s 为代表的容器编排技术登上舞台之后,相关技术从业人员从认知和体感上接受,云原生时代真的到来了。

当然也有很多资深技术人员认为,云原生时代要从 2010s 时以 OpenStack 为代表的虚机编排时代开始。当然,也有人说其实云原生技术诞生很早,可以从巨型机时代在巨型机上虚拟出若干小型机开始追溯。

在云原生时代,不变镜像作为核心技术的 docker 定义了不可变的单服务部署形态,统一了容器编排形态的 k8s 则定义了不变的 service 接口,二者结合定义了服务可依赖的不可变的基础设施。有了这种完备的不变的基础设置,就可以定义不可变的中间件新形态 -- 云原生中间件。

云原生时代的中间件,包含了不可变的缓存、通信、消息、事件(event) 等基础通信设施,应用只需通过本地代理即可调用所需的服务,无需关心服务能力来源。

微服务框架

从最早的单体应用时代到分布式技术时代,流行的是微服务技术。微服务时代各大公司都沉淀出了具有代表性的一些服务通信框架,如 Google 的 gRPC,阿里的 Dubbo 和 HSF,百度的 bRPC 等等。多个服务通信框架之间的竞争,基本上是在大公司之间进行角力。

站在使用者的角度,当然期待一个网络框架在进化过程中能够保持向前兼容性,多个框架之间保持互通性。

1. 服务框架的向后兼容性

通信框架的基础是通信协议和序列化协议,其中很重要的问题就是新版本协议对旧版本的向后兼容性。在一个组织中一般都使用统一的通信框架,但现实中可能因为各种原因,同一个框架的序列化协议或者通信协议的向后兼容能力差,会导致使用不同版本通信框架的各个服务之间的异构化。如采用了 pb v2 和 pb v3 的通信框架不兼容,不遑多让的 Thrift 0.8.x 与 Thrift 0.9.x 之间也不兼容。

不过 Protobuf v3 或者 Protobuf v2 的各个子版本之间的向前和先后兼容性还是不错的,但还是有一些弱鸡公司的内部序列化协议无论是否采用 TLV 形式,其协议各个版本的之间还是无法兼容,进而导致各个子版本的服务框架相互异构,最终导致使用了不同版本的服务框架的业务背上大量包袱无法快速演进,有些新版本的业务中存在各种神逻辑可能不是为了兼容旧版本的业务逻辑,而是为了兼容旧版本框架的通信协议。

2. 多框架之间的互通性

一个常识是,组织规模膨胀到足够大的程度后,不可能有一个通用的框架适用于所有的场景,一些大经济实体随着业务体量变大,业务类型变得庞杂,不可避免地存在一些重复的轮子,这些庞大规模的组织因为其规模效应,任何一个适用于特定场景的框架只要能在内部找到若干落地应用场景就足以让其开发维护成本变得可负担且收益甚大。

公司内部各个分公司之间可能存在不同服务框架导致各个服务之间通信异构化越来越严重,如阿里内部早前存在异构的 Dubbo 和 HSF(目前阿里内部 HSF 和 Dubbo 已经开始融合, HSF 已经采用 Dubbo 作为内核以 Dubbo 插件的形式存在),如当下的阿里的 HSF 和各个收来的新公司之间的网络通信,其间通信可能不得不借助于 Proxy 形式的通信网关。

每个服务框架各个子版本之间需要保持向后兼容,各个服务框架之间的兼容可能需要网关代理。

3. 多语言框架之间的互联

除了序列化协议、通信框架的异构外,还普遍存在着因为各个不同语言技术栈之间差异导致的异构:每种语言都有个各自的序列化协议和通信框架。如 Java 世界就存在着 Spring Cloud 和 Dubbo 两大服务治理框架,Spring Cloud 尚无多语言版本实现,相比之下 Dubbo 的多语言工作稍好一些。

4. 打通打平不同的技术体系

同一实体内部不同公司之间有两三个不同服务框架的情况已经算是很好了,大公司组织内部可以容忍适量的重复造轮子,但大量的重复造轮子就过犹不及了。据说有巨头内部不同部门之间存在各自的 RPC 服务框架 ,其总体服务框架超 100+!

随着国内互联网行业发展由于头部效应趋向性明显,在大鱼吃小鱼的时代背景下,大公司与收购来的公司之间的技术体系异构也是云原生时代中间件面临的一个问题,二者之间因为业务规模不同带来的服务注册中心、配置中心、语言技术栈、服务鉴权、缓存和存储等诸多技术不统一。有的刚收来的公司甚至使用了大公司的竞争对手的云平台,这就又带来了平台级的差异,诸如此类的异构问题不一而足。

借助网络代理技术,可以初步快速打通不同技术体系之间的异构差异。

5. 通信代理的必要性

除了南北向通信的网络接入层代理外,微服务时代使用同一通信框架的各个服务实体之间直接进行通信,很少听说各个服务实体之间通过代理 Proxy 进行通信,其根由是各个通信实体之间通信框架同构。

或者说,网络通信代理被各个强悍的通信框架给消化掉,以 Proxyless SDK 的形式存在,如服务发现、服务路由、容灾限流、负载均衡等功能都存在于各个服务框架的 SDK 中。

但随着多协议多语言等各种因素导致的各个框架之间的各种异化,大家普遍相信:没有什么差异不是一层 Proxy 解决不了的。

6. Service Mesh

2016 年之后兴起的 Service Mesh 技术区分为 Proxy Service Mesh 和 Proxyless Service Mesh,至于二者之间的差异可参见本文 2019 年的一篇文章 Service Mesh 形态刍议。目前比较流行的 Service Mesh 技术形式是 Proxy Service Mesh,其比较有代表性的组件有数据面的 envoy 和控制面的 Istio。

一些 Service Mesh 技术文档宣称,将服务框架的序列化协议、通信能力、服务治理能力沉淀到服务网格的代理(如 envoy 这类数据面 sidecar)中,可有如下收益:

  • 服务框架 SDK 会变的非常轻量,甚至完全沉淀到 sidecar 中。
  • 多语言、多协议和多种通信方式之间的差异将被磨平。
  • 统一流量控制,提升系统的弹性。
  • 统一监控设施,提高可观测性。
  • 统一安全可信认证,提升安全性。
  • 升级过程业务无感,做到平滑升级,提升可靠性。
  • 提升业务版本迭代速度。
  • 快速打通不同技术治理体系之间的差异。
  • 在 Mesh 和 非 Mesh 模式之间快速切换。

有人可能据此误以为 Service Mesh 技术可将业务和服务框架的复杂性消灭于无形,将 Istio + sidecar 形式为代表的服务网格可以定义为 Service Mesh 的终极形态。

Sidecar 与中间件

Proxy Service Mesh 的数据面的 sidecar 仅具备通信能力,业务应用和 sidecar 之间仍然存在一个 gap:微服务时代应用所使用的中间件系统的能力需要沉淀到 sidecar 中。

1. Sidecar 的能力

Proxy Service Mesh 中 sidecar 的一个典型代表是 envoy,其本质是一个具备通信能力的 local proxy,具备如下数据面能力:

  • 流量控制
  • 序列化协议转换
  • 通信协议转换
  • 数据路由控制

实际上, envoy 仅仅是提供了这些能力的接口,至于具体的序列化协议转换、通信协议转换插件等工作还是需要相关的基础设施开发人员去做的。

除了序列化协议和通信协议转换,中间件的其他能力向 Proxy 下沉的过程中,都需要做大量的 envoy filter 层面的工作。相对于 Proxyless 形式的 Service Mesh,Proxy Service Mesh 成本没有任何变化,其对业务的侵入性也没有减轻更多。

2. 协议下沉

如果说 Proxyless Service Mesh 形态下的 SDK 升级需要业务层面做很多改造,Proxy Service Mesh 形态下的业务从 Proxyless 向 Proxy 形态升级过程中改造成本也不可谓不小。如果通信协议采用了 Protobuf V3,Proxy Serivce Mesh 形态下的业务升级协议时可能做到平滑升级:只升级 Proxy 不用升级业务服务实体。但现实是一些公司内部的私有协议根本做不到向后兼容,其成本就是升级协议时服务网格的 Proxy 和业务实体一起升级,至于期望的平滑升级就很难做到了。

诸般问题的核心是 Local Proxy 没有统一通信协议和序列化协议,仅仅注重于流量劫持。

3. 有状态的应用

Service Mesh 技术的一些爱好者假设服务实体是一个无状态的服务,其代理也当然是一个无状态的 sidecar,然后宣传 Service Mesh 时代的各种红利。

至于那些有状态的应用,大公司有人有钱耗费巨量人日成本后,把状态转移到 Proxy 中去,让应用无状态,但业务无感知的平滑升级是就难做到了。这个成本对大经济实体来说当然是可负担且收益甚大的,但不是一些中小厂家所能承受的,他们在踩完各种坑后,可能神奇的发现他们根本没有实力实现有状态的 sidecar。

4. 复杂性守恒

总结一番,基于 sidecar 搭建一个 Proxy Service Mesh 可能存在如下工作:

  • 不同序列化协议转换
  • 不同通信协议之间的转换
  • 同一序列化协议多版本之间的转换
  • 私有和公开通用的序列化协议之间的转换
  • 对单体时代或者微服务时代的业务进行改造升级
  • 业务应用和 sidecar 同时升级带来的额外运营维护
  • 有状态的 Sidecar 的开发测试与维护
  • 应用和代理的优雅退出和平滑升级
  • 不同技术体系之间的互通
  • Mesh 模式和非 Mesh 模式之间的切换

面对这些难度层层递进的工作,中小厂家很有可能就会退缩到微服务技术体系。其最根本的原因是:同等级别的业务形态下,技术复杂性守恒,总成本守恒。一如微服务技术至于单体技术:各个单一服务都被拆分的足够简单,但单体技术的复杂性转换为了巨量服务之间的复杂性。

另一种 Mesh

以 Service Mesh 技术为代表的的云原生技术体系根植于以 K8s 为代表的的云原生基础设施之上。

1. 协议标准化

云原生中间件 Proxy 的下一站除了被动地去兼容各种协议,更应该主动的去统一序列化协议,如自身直接支持 Protobuf v3 协议,业务也采用这种可保证向后兼容的协议即可。

除了被动地去兼容各种通信框架做互联互通,可以更主动地向事实上的通信框架 gRPC 或者通信协议 HTTP 靠拢。gRPC 有各种语言的 SDK 库。各种语言自身会主动提供 HTTP 通信协议库,且 HTTP2.0 向后兼容 HTTP 1.1。例如微软的 Dapr,就直接提供 gRPC 和 HTTP 两种通信协议的 API,上层业务需要做的是选择其中一种通信协议的 API 进行开发。

2. Service Proxy

一些的云原生时代的事实上的标准通信设施有:2008 年开源的 protobuf v2 和 2014 年开源的 protobuf v3 统一了序列化协议;2016 年 gRPC 发布 v1 之后逐渐成了跨语言首选的通信库。

除了序列化协议和通信协议,微服务时代的中间件体系大概有如下技术栈:

  • RPC,其代表是 Dubbo/Spring Cloud/gRPC 等。
  • 限流熔断等流控,如 hystrix/sentinel 等。
  • Cache,其代表是 Redis。
  • MQ,其代表有 kafka/rocketmq 等。
  • 服务跟踪,如兼容 Opentracing 标准的各种框架。
  • 日志收集,如 Flume/Logtail 等。
  • 指标收集,如 prometheus。
  • 事务框架,如阿里的 seata。
  • 配置下发,如 apollo/nacos。
  • 服务注册,如 zookeeper/etcd 等。
  • 流量控制,如 hystrix/sentinel 等。
  • 搜索,如 ElasticSearch。
  • 流式计算,如 spark/flink。

把各种技术栈统一到一种事实上的技术标准,才能反推定义出不可变的中间件设施的终态。把上面这些事实上的中间件梳理一番后,整体工作即是:

  • 统一定义各服务的标准模型
  • 定义这些标准模型的可适配多种语言的 API
  • 一个具备通信和中间件标准模型 API 的 Proxy
  • 适配这些 API 的业务

 

上图定义一种不同于 istio + Envoy 的另一种可能的 Proxy Service Mesh 进化路径。该 Service Mesh 模型下的 sidecar 不仅仅是一个 Local Proxy,更应该是一个提供各个中间件技术栈标准能力的 Service Proxy。

Service Proxy 可能是一个集状态管理、event 传递、消息收发、分布式追踪、搜索、配置管理、缓存数据、旁路日志传输等诸多功能于一体的 Proxy, 也可能是分别提供部分服务的多个 Proxy 的集合,但对上提供的各个服务的 API 是不变的。

3. Application Mesh

或者更进一步,可以把 Service Proxy 拆分为两个 Proxy:

  • 仍然以现有的以劫持网络流量的 sidecar 形式存在的 Local Proxy。
  • 另一个专门提供各个 Service API 的 Application Proxy。

Application Proxy 可以是一个独立存在的进程或者容器,也可以是一个可被应用调用嵌入式的 SDK 库。无论是 Proxy 形式还是 Proxyless 形式,这都是一种新形态的 Service Mesh,可被称之为 Application Mesh。
Application Proxy 可以依赖于 Local Proxy,亦可不依赖。如人们常说的三级缓存其实也是一种 Application Mesh 形态,从进程内的 local cache 到本机(容器、虚拟机 or 物理机)cache proxy 一直回溯到 cache cluster, 应用只需要从 local cache 处获取数据即可。

当然,Application Mesh 亦可不依赖于特定的基础设施平台,包括 k8s,本文就不展开讨论了。

除了 Service Mesh 技术带来的收益,Application Mesh 具有如下更多的收益:

  • 更好的扩展性与向后兼容性

基于标准的 API,其服务的不变性得到极大改善,不变性可以确保中间件的向后兼容与更好的扩展能力。基于标准 API,第三方服务商可以在云厂商提供的基础设施之上扩展出更多形态的中间件设施。

  • 与语言无关

统一序列化协议和通信协议后,无特定语言依赖是很自然的事情。主流语言都会支持 HTTP 协议,gRPC 库自身能够提供主流语言的支持。无特定语言绑定带来的另一个间接好处是更好的可移植性。

  • 与云平台无关

通过标准的服务让应用做到无云平台依赖,统一了中间件技术栈的平台提供的技术能力相同的,云平台使用者没有被云服务提供商绑架的危险。

  • 应用与中间件更彻底地解耦

通过标准协议和标准 API 让应用与中间件彻底解耦,让开发者在开发阶段对新类型 Proxy 的有感,做到业务上线后业务对 Proxy 及其底层系统的升级过程无感知,即更好地平滑升级。

  • 应用开发更简单

基于标准 API,应用开发者甚至可以用单体时代的服务框架开发分布式应用,提升应用版本迭代速度。

  • 更快的启动速度

状态从应用转移到代理后,可以通过提前预热代理,让应用瞬时批量启动。

未来的收益

任何技术都不是没有代价的。诚如微服务技术带来了服务数量的剧增,Service Mesh 技术带来了吞吐的降低和延时的增加,但下一站的云原生中间件形态会带来的是另一种新的价值形态,相比而言这个代价是可以接受的。

1. 业务价值

就其浅显的技术价值而言,做到基础中间件技术的统一后,即可做到无关语言,无关各个具体的中间件实体。减轻业务开发人员负担,使其专注于业务逻辑,做到真正的快速迭代与平滑升级,提升研发效率的同时降低各种成本。

2. 云平台无关

新形态带来的商业价值就是无云平台依赖,各平台间相互之间的竞争就不会停留在某种独有的核心技术优势上,而是在同一技术体系下不断降低服务成本,提供更好的用户体验、更强的服务能力与更亲民的价格。
能够且愿意实现这种终态 proxy 的组织当然不是各中小型业务厂家,所以统一了这些标准服务 API 的 Proxy 之下的应该是提供这些标准服务的各大云厂商。越早向统一服务模型靠拢的云厂商越快得利,越相信自己私有服务能力的云厂商越孤立。

3. 初创公司的机会

基于大厂提供的基础设施,可以孕育出一个独立的 service proxy 生态:一些第三方的初创厂家专职提供云原生中间件解决方案。

基于新形态的中间件方案,Low Code 或者 No Code 技术才能更好落地。单体时代的 IDE 才能更进一步 -- 分布式时代的 IDE,基于各种形态中间件的标准 API 之对这些中间件的能力进行组合,以 WYSIWYG 方式开发出分布式应用。

4. 打破大厂内部藩篱

对一些大厂组织内部而言,可借助真正形态的 Service Mesh 技术栈可以统一大经济实体内部技术栈,打破人为的各种异构隔离,提升研发运维效率和物理资源利用效率,降低整体人力与资源的交付运维成本。

5. 走向新时代

以统一技术形态的 Service Mesh 为基础的云原生中间件技术体系真正发起起来,在其之上的 Serverless 才有更多的落地场景,广大中小企业才能分享云原生时代的技术红利,业务开发人员的编码工作就会越来越少,编程技术也会越来越智能--从手工作坊走向大规模机器自动生产时代。

作者简介

于雨(github @AlexStocks),dubbogo 社区负责人,一个有十多年服务端做着基础架构和中间件研发一线工作经验的程序员,陆续参与和改进过 Redis/Pika/Muduo/dubbo-go/Sentinel-go 等知名项目,目前在蚂蚁金服可信原生部从事容器编排和 service mesh 工作。

原文链接 

本文为阿里云原创内容,未经允许不得转载

 

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

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

相关文章

深度剖析:Redis 分布式锁到底安全吗?看完这篇文章彻底懂了!

作者 | Kaito 来源 | 水滴与银弹阅读本文大约需要 20 分钟。大家好,我是 Kaito。这篇文章我想和你聊一聊,关于 Redis 分布式锁的「安全性」问题。Redis 分布式锁的话题,很多文章已经写烂了,我为什么还要写这篇文章呢?因…

Spring Boot 微服务性能下降九成!使用 Arthas 定位根因

简介: 接收到公司业务部门的开发反馈,应用在升级公司内部框架后,UAT(预生产)环境接口性能压测不达标。 背景 接收到公司业务部门的开发反馈,应用在升级公司内部框架后,UAT(预生产&a…

阿里研究员:线下环境为何不稳定?怎么破

简介: 为什么线下环境的不稳定是必然的?我们怎么办?怎么让它尽量稳定一点? 这篇文章想讲两件事: 为什么线下环境[1]的不稳定是必然的?我们怎么办?怎么让它尽量稳定一点? 此外&#…

谁说技术男不浪漫!90后程序员2天做出猫咪情绪识别软件

整理 | 王晓曼出品 | CSDN(ID:CSDNnews)9月1日,一则关于#程序员2天做出猫咪情绪识别软件#的话题登上微博热搜,参与阅读的人数达到了8218.1万,讨论次数1.3万,引发网友们的热议。高手在民间&#…

闲鱼如何一招保证推荐流稳如泰山

简介: 风雨不动安如山 背景 近几年互联网的快速发展中,互联网业务发展越来越复杂,业务也被拆分得越来越细,阿里内部业务也发生着翻天覆地的变化,从最初的单体应用,到后面的分布式集群,再到最近…

电商直播平台如何借助容器与中间件实现研发效率提升100%?

简介: 经过实际场景验证及用户的综合评估,电商直播平台借助全面的云原生容器化能力和中间件产品能力,大幅提升开发部署运维效率达50%~100%,极大地提升了用户体验,为业务持续发展打下了坚实的基础。 前言 直播带货是近…

在游戏运营行业,Serverless 如何解决数据采集分析痛点?

简介: 众所周知,游戏行业在当今的互联网行业中算是一棵常青树。在疫情之前的 2019 年,中国游戏市场营收规模约 2884.8 亿元,同比增长 17.1%。2020 年因为疫情,游戏行业更是突飞猛进。玩游戏本就是中国网民最普遍的娱乐…

字节大战腾讯元宇宙;Docker 自己定制镜像;VMware 云桌面助力秦皇岛市第一医院;微软开源 Cloud Katana;...

NEWS本周新闻回顾字节大战腾讯元宇宙:布局社交产品Pixsoul,上线游戏“重启世界”字节投资的代码乾坤,已于近日正式上线了元宇宙游戏《重启世界》。就在两个月前,被称为“元宇宙第一股”的Roblox登陆国内,由腾讯改名为《…

从 RxJS 到 Flink:如何处理数据流?

简介: 前端开发的本质是什么?响应式编程相对于 MVVM 或者 Redux 有什么优点?响应式编程的思想是否可以应用到后端开发中?本文以一个新闻网站为例,阐述在前端开发中如何使用响应式编程思想;再以计算电商平台…

Spring RSocket:基于服务注册发现的 RSocket 负载均衡

简介: RSocket 作为通讯协议的后起之秀,核心是二进制异步化消息通讯,是否也能和 Spring Cloud 技术栈结合,实现服务注册发现、客户端负载均衡,从而更高效地实现面向服务的架构?这篇文章我们就讨论一下 Spri…

双非院校计算机系毕业的学生能进大厂吗?

谈到大厂,我们常常会主动匹配与之对应的高学历。其实不论是大厂还是小公司,都是会筛简历的,这个毋庸置疑。从大厂招聘的结果上看,高学历人才的数量占据大头,而那些成功进入BAT、网易等大厂的专科生、二本三本学生&…

Python - 深夜数据结构与算法之 Heap Binary Heap

目录 一.引言 二.堆与二叉堆介绍 1.Heap 堆 2.Binary Heap 二叉堆 3.HeapifyUp 添加节点 4.HeapifyDown 删除节点 5.Heap 时间复杂度 6.Insert & Delete 代码实现 三.经典算法实战 1.Smallest-K [M14] 2.Sliding-Window-Max [239] 3.Ugly-Number [264] 4.Top-…

如何 0 改造,让单体/微服务应用成为 Serverless Application

简介: 随着 2013 年以 Docker 为代表的容器技术、CNCF 基金会以及 K8s 的发展等,云原生开始被广大开发者所熟知。云原生时代之前还有两个阶段:一是自建 IDC 机房,二是简单地把原有的应用搬迁到云上。自建 IDC 机房很难获得高可用、…

一文了解阿里一站式图计算平台GraphScope

简介: 随着大数据的爆发,图数据的应用规模不断增长,现有的图计算系统仍然存在一定的局限。阿里巴巴拥有全球最大的商品知识图谱,在丰富的图场景和真实应用的驱动下,阿里巴巴达摩院智能计算实验室研发并开源了全球首个一…

c++如何禁用指定的键盘布局_Karabiner Elements for Mac 键盘键位自定义改键工具

文章来源于:风云社区Karabiner Elements for Mac 12.5Karabiner Elements(早期是Karabiner,更早是KeyRemap4MacBook)是功能强大且稳定的macOS键盘定制器。上【风云社区】,搜索软件名字,即可查看下载特征&am…

Docker Desktop 向大公司宣告收费,网友大呼:是时候弃用了!

作者 | 苏宓 出品 | CSDN(ID:CSDNnews) 在容器引擎 Docker 诞生的 8 年间,其与开源的容器编排 Kubernetes 共同推动容器技术在云计算领域的应用,也让自身在全球范围内受到了广泛的关注。可以说,做过云计算开…

如何接地气地接入微前端?

简介: 微前端带来明显好处的同时,也面临着痛点。对于已有站点,如何在老的技术栈基础上接入一个微前端?需要哪些通 一 、前言 微前端,这个概念已经在国内不止一次的登上各大热门话题,它所解决的问题也很明显…

东南亚再造天猫 Lazada品牌商城LazMall举办第二届品牌未来论坛

9月1日,东南亚领先的旗舰电商平台Lazada在新加坡滨海湾金沙会展中心举办了2021 LazMall Brands Future Forum年度品牌未来论坛(以下简称“BFF”)。该论坛以“奔向未来:东南亚的数字商务时代”为主题,在庆祝Lazada品牌商…

高可用的本质

简介: 无论是一个域,一个BG,还是一个站点,虽然范围有大有小,对象有所不同,但其高可用的理念都是相通的,今天将自己对高可用的一点点思考以及总结的【nPRT公式】分享给大家。 我是乐羊&#xff0…

技术干货 | 深度解构 Android 应用面临紧急发版时的救星方案:mPaaS 热修复——DexPatch

简介: 关于 Android 热修复方案——DexPatch 的介绍与使用说明 方案介绍 为了解决 Native 模块上线后的问题,mPaaS 提供了热修复功能,实现不发布客户端 apk 场景下的热修复。目前 Android 端热修复主要包括 andfix 和 dexpatch,考…