向后兼容(非破坏性)的修改 新增 API 接口 新增请求字段 新增响应字段 在不改变其他响应字段的行为的前提下，非资源（例如，ListBooksResponse）的响应消息可以扩展而不必破坏客户端的兼容性...请求、响应消息定义专属message，不要使用Google的empty message 原本是向后兼容的修改也会导致不兼容。例如添加一个字段，就需要创建新的message，从而影响兼容性。...修改字段的类型 即使新类型是传输格式兼容的，这也可能会导致客户端库生成的代码发生变化，因此必须增加 major 版本号。 对于编译型静态语言来说，会容易引入编译错误。...给资源消息添加 读取/写入 字段 例如put方法里的参数增加字段，可能会导致库里该字段被零值覆盖。...不理解 读取 字段为什么影响兼容性 单个接口发生向后不兼容的修改时，可将改接口函数改为xxxV2。如果很多接口都发生破坏性修改，可直接建立V2目录。
“1”可能会减少向后兼容性问题，但看起来很奇怪。（repr(True) 将始终返回“True”。） =>“True”。 几乎所有评审人都同意这一点。...这对于向后兼容性很重要：因为比较之类的操作当前返回整数值，所以无法确定现有应用程序怎么使用这些值。...以前，这些首选的真假值是 1 和 0；本 PEP 将首选值更改为 True 和 False，并修改内置操作以返回这些首选值。 兼容性 因为要向后兼容，所以布尔类型拥有一些不严格的属性。...兼容性要求的另一个结果是表达式“True and 6”的值为 6，类似地，表达式“ False or None”的值为 None。...（此外，它会破坏向后兼容性。但是，即使它不破坏，出于前面的原因，我仍然反对。） 还应该提醒新手，没有理由写： if bool(x): ... 因为布尔值隐含在“if”中。
在这篇文章中，我们将探讨一些引入非破坏性变更的技巧。常见的主题是：添加、不更改或删除。我们还将从一开始就讨论如何设计您的 API 以实现兼容性。...此示例说明，对于向后兼容性而言，只满足调用兼容性是不够的。事实上，您不能对函数的签名进行向后兼容的更改。 与其更改函数的签名，不如添加一个新函数。...但是，稳定的 API 不能将导出的函数更改为接受context.Context，因为它会破坏该函数的所有使用。 相反，可以增加新的函数。...例如，在设计构造函数时，更喜欢返回具体类型。与接口不同，使用具体类型可以在将来添加方法而不会破坏用户。该属性允许您的模块在将来更容易扩展。...默认值为零将保留启用 keep-alive 的原始行为，并使用默认时间段。 新字段有一种微妙的方式可以意外地破坏用户代码。如果一个结构中的所有字段类型都是可比较的，那么这些类型的值可以用 == 和 !
P++ 是临时代号，可能会更改。 今日消息，不久前从 Zend 公司离职的 Zeev Suraski 以 PHP 开发组成员的身份提议要创建 PHP 方言，暂命名为 P++。 ?...> 此外，他们可能会找到将整个名称空间标记为 P++ 的方法，因此框架不必将每个单独的文件明确标记为 P++。 那作为开发者的我们，是否需要在 PHP 和 P++ 之间做出选择？...换句话说，这种新方言本质上可能更加严格，它可能会更加大胆地消除向后兼容，并删除被认为是“包袱”的元素（例如短标签），并添加更复杂的特性，尤其是那些非常适合严格类型化的语言的，而无需为 PHP 方言引入相同的复杂性...严格性和类型相关的功能可能只适用于 P++，并且只能在 P++ 文件中使用。向后兼容偏差将保留在 PHP 中（这并不意味着向后兼容永不会被打破，只是每个这样的案例必须有良好的投资回报案例）。...P++ 提案旨在首先关注兼容性破坏元素，例如严格的操作、类型转换逻辑的更改、数组索引处理、需要变量声明等等，并且旨在在 P++ 的第一期提供它们。
如果添加了没有默认值的字段，向前与向后兼容性都会遭到破坏。...另一方面，只要 Avro 支持转换类型，就可以改变模式中字段的「数据类型」，但是对于「字段名称」的改变，读模式可以包含字段名称的别名，从而支持向后兼容，但是不能向前兼容；类似地，向联合类型「添加分支」也是向后兼容...为了保持兼容性，通常可考虑的更改包括添加可选的请求参数和在响应中添加新的字段 如果将 RPC 用于跨组织边界的通信，服务的兼容性会变得更加困难。...，该中介会暂存消息。...而如果要对基于 Actor 的应用程序执行滚动升级，仍需要担心向前与向后兼容性问题，因为消息可能会从运行新版本的节点发送到运行旧版本的节点，反之亦然。
本文可作为读者的参考，帮助读者了解应该考虑哪些类型的向后兼容性 API/SDK，以及哪些类型应该被有意忽略。...我们的目标是让大家对不同类型的破坏性变更都能有办法应对。 我们先从基本的 API 兼容性开始研究，然后再讨论更细致的向后兼容性概念。...API 兼容性 关于向后兼容性，人们最认可的形式是和 API 中的直接变更有关系的。这些变更可能是 API 签名中的变更，例如对参数、其数据类型或返回类型的修改。...双向流、繁琐的 API 和处理大型负载等场景需要更针对性的序列化方法。这可能会带来一类难以察觉的破坏性变更。 以一个用于本地日志系统的 SaaS API 为例。...依赖兼容性 你的 SDK 的依赖项也会引入破坏性变更。除非你“隐藏”依赖项并将它们打包到你的发行版中（但这并不一定是最好的办法，甚至可能无法做到！）
但为了习惯，后面行文仍然用向后/前兼容。 其中，向后兼容比较常见，因为时间总是向前流逝，版本总是升级，那么升级之后的代码总要处理历史积压的数据，自然会产生向后兼容的问题。...数据类型和模式演变 修改数据类型比较麻烦：只能够在相容类型中进行修改。 如不能将字符串修改为整形，但是可以在整形内修改：32 bit 到 64 bit 整形。...ProtoBuf 没有列表类型，而有一个 repeated 类型。其好处在于兼容数组类型的同时，支持将可选（optional）单值字段，修改为多值字段。...数据模式允许不读取数据，仅比对模式来做低成本的兼容性检查。 对于静态类型来说，可以利用代码生成做编译时的类型检查。...消息队列通常是面向字节数组的，因此你可以将消息按任意格式进行编码。如果编码是前后向兼容的，同一个主题的消息格式，便可以进行灵活演进。
这些例子显示了测试发现的不兼容性与API检查发现的不兼容性是不同的。当然，测试也不是完全保证兼容性的，但它比仅仅进行API检查更完整。.../myprog 正如我们稍后将看到的，Go 1.21将这个GODEBUG机制推广，使其成为所有可能破坏性变化的标准。 SHA1。这是一个更微妙的协议变化的例子。...毕竟，我们希望尽可能少地破坏程序。 在Go 1.21中扩展GODEBUG支持 为了在我们一直在研究的这些微妙的情况下改进向后兼容性，Go 1.21扩展并正式化了GODEBUG的使用。...例如，在Go 1.21中，panic(nil)现在会导致一个（非nil）的运行时恐慌，所以recover的结果现在可以可靠地报告当前的goroutine是否在恐慌。...参见[Go，向后兼容性，和GODEBUG(https://go.dev/doc/godebug)以获取更多细节。
要获取特定请求类型的总计数，需要更新该工具以跨不同版本进行聚合。 KIP-225将度量标准“records.lag”更改为使用主题和分区标记。...由于硬件故障导致IOException，日志目录可能会脱机。用户需要监视每个代理度量标准offlineLogDirectoryCount以检查是否存在脱机日志目录。...对于阅读从新格式下转换的邮件的旧消费者，也会产生类似的效果：如果获取的大小设置不至少与max.message.bytes即使各个未压缩消息小于配置的提取大小，消费者也可能无法取得进展。...特别是，在消息格式设置为0.10.0后，不应将其更改回早期格式，因为它可能会破坏0.10.0.0之前版本的消费者。...LZ4压缩消息处理已更改为使用可互操作的成帧规范（LZ4f v1.5.1）。为了保持与旧客户端的兼容性，此更改仅适用于消息格式0.10.0及更高版本。
改变程度和范围取决于这些变更如何影响每个客户，以及合约改变后服务的向后兼容性。 合约的版本化使得启用新的、包含合约变更的服务功能时能够为仍旧使用老版本合约的客户提供向后兼容性。...在这种情况下，向后兼容性是由不同合约而不是同一合约的不同版本所支持的。许多基于JMS的消息系统都是采用这种方式，尤其是使用ObjectMessage消息类型的系统。...例如，基于Java的接收端可以使用instanceof关键字来检查通过消息发送的对象类型，然后根据对象类型来采取响应的步骤。...图1-2 合约版本化的主要目的就是提供向后兼容性。...我看到的微服务中所实现的一个比较好的设计是将认证工作委托给一个独立的服务，而保留授权工作在微服务内部。尽管这一设计可以修改为将认证和授权都交由单独的服务来完成，我还是倾向于将授权包含在微服务自身当中。
但是随着时间的推进，你的业务可能会发生了变化，与此同时，你的Protocol Buffer消息类型的需求也会随之变化。 也就是说：有一些字段可能会发生变化，可能会添加一些字段，也可能会删除一些字段。...为了达到此目的，Protocol Buffer制定了一些更新消息类型的规则： 不要修改任何现有字段的数字（tag） 你可以添加新的字段，那些使用旧的消息格式的代码仍然可以将消息序列化，您应该注意这些元素的默认值...类似的，新代码所创建的消息也可以被旧代码解析：旧的二进制在解析的时候会忽略新的字段。 字段可以被删除，只要它们的数字（tag）在更新后的消息类型中不再使用即可。...你也可以把字段名改为使用“OBSOLETE_”前缀而不是删除字段，或者把这些字段的数字（tag）进行保留（reserved），以免未来其它开发者不消息使用了删除字段的数字。...默认值 默认值在更新Protocol Buffer消息定义的时候有很重要的作用，它可以防止对现有代码/新代码造成破坏性影响。它们也可以保证字段永远不会有null值。
，把二进制的消息体逆向还原成请求对象，即“反序列化” 将二进制转换为对象 RPC框架为何需要序列化？...，无需类似 XML 解析器； 序列化反序列化速度很快，不需要通过反射获取类型； 消息格式升级和兼容性不错，可以做到向后兼容。...3.3 通用性和兼容性 某类型为集合类的入参服务调用者不能解析了，服务提供方将入参类加一个属性之后服务调用方不能正常调用，升级了RPC版本后发起调用时报序列化异常… 通用性和兼容性的优先级考虑很高，直接关系到服务调用稳定性和可用率...看重这种序列化协议在版本升级后的兼容性，是否支持更多的对象类型，是否跨平台、跨语言，是否有很多人已用过并踩过很多坑，其次考虑性能、效率和空间开销。 3.4 安全性 JDK原生序列化存在漏洞。...如果序列化存在安全漏洞，线上服务可能被入侵： 首选Hessian与Protobuf，性能、时间开销、空间开销、通用性、兼容性和安全性上，都满足要求： Hessian使用更方便，在对象的兼容性上更好 Protobuf
使用构造函数强制转换简单类型。例：int(myFloat)代替(int)myFloat。 另外重构代码时，编译器会立即通知您是否强制转换会很危险。...向前的二进制兼容性：链接到新版本库的代码可与旧库一起使用。 源代码兼容性：代码无需修改即可编译。 在次要版本中保持向后二进制兼容性+向后源代码兼容性。...在修补程序版本中保持向前和向后二进制兼容性+向后和向后源代码兼容性： 不要添加/删除任何公共API(例如：全局函数，公共/受保护/私有方法)。...这确保widget可以在不破坏二进制兼容性的情况下得到修复。 从Qt导出的所有函数必须以'q'或'Q'开头。可以使用"symbols"自动测试来验证。...没有浮点数比较(-Wfloat-equal)： 使用qFuzzyCompare将值与增量进行比较。 使用qIsNull来检查浮点数是否为二进制0，而不是将其与0.0进行比较。
无GIL会是未来长期Python构建的唯一模式，但考虑到向后兼容性，对支持「无GIL」构建模式所需的第三方代码更改，将在带有GIL的构建模式下进行工作。...团队仍在考虑两种构建模式的ABI兼容性要求和其他细节，以及对向后兼容性的影响。 在完全切换为「无GIL」构建模式之前，需要看到社区对其的支持。...不能只是将默认构建模式改为「无GIL」，然后期望社区解决所需的工作。 核心开发人员要在新的构建模式下获得经验，并处理现有代码的线程安全性。...具体实施时间将取决于API更改的向后兼容性和社区还需做的工作量。预计这个过程可能需要一年或两年，甚至更长时间。...- 长期：目标是「无GIL」成为默认构建模式，并移除GIL的所有痕迹，同时尽量不破坏向后兼容性。不希望这段时间持续太久，因为同时存在两种常见构建模式可能给社区带来负担，但也不能仓促行事。
枚举不兼容性 可以导入 proto2 消息类型并在 proto3 消息中使用它们，反之亦然。...这意味着您可以将字段从这些类型之一更改为另一个字段而不破坏向前或向后兼容性。...但是请注意，当消息反序列化时，客户端代码可能会以不同的方式对待它们：例如，未识别的 proto3 枚举类型将保留在消息中，但消息反序列化时如何表示是与语言相关的。...当消息编码时，键和值被连接成一个字节流。当消息被解码时，解析器需要能够跳过它无法识别的字段。这样，可以将新字段添加到消息中，而不会破坏不知道它们的旧程序。这就是所谓的 “向后”兼容性。...protocol buffers 最后一个非常棒的特性是，即“向后”兼容性好，人们不必破坏已部署的、依靠“老”数据格式的程序就可以对数据结构进行升级。
通过定义消息结构，可以指定每个字段的名称、类型和顺序。高效的序列化和反序列化相比于其他序列化机制（如XML和JSON），Protobuf具有更高的性能和更小的数据体积。...可扩展性和兼容性Protobuf支持数据结构的向前和向后兼容。当数据结构发生变化时，可以向旧的数据结构中添加新的字段，而不会影响已有的数据。这种可扩展性使得系统可以在不中断服务的情况下进行升级和演化。...另外，由于Protobuf支持多种编程语言，开发人员可以根据消息结构定义自动生成对应编程语言的代码，使得不同团队之间可以更方便地进行数据交换和协作。...版本兼容性：Protobuf在消息结构发生变化时，支持向前和向后兼容。但是，当消息结构变化较大时，可能会出现一些兼容性问题。比如，删除或重命名字段可能会导致旧版本的代码无法正确处理新版本的数据。...与Protobuf相比，MessagePack的主要优点是更容易阅读和理解，但它的可扩展性和兼容性较弱。 选择使用哪种数据交换格式需要根据具体的应用场景和需求来决定。
我们不希望出现另一个 Python 3 的情况，所有适应 no-GIL 构建所需的任何第三方代码更改应只适用于 with-GIL 构建（尽管仍要解决更老 Python 版本的向后兼容性问题）。...我们仍在考虑对这两个构建的 ABI 兼容性和其他细节的要求，以及对向后兼容性的影响； 在我们承诺完全转向 no-GIL 之前，需要看到社区的支持。...我们不能只是更改默认设置，更希望社区弄清自己需要做什么工作来给予支持。我们核心开发团队需要获得新构建模式及相关所有内容的经验。...具体的时间将取决于很多因素，比如 API 更改最终兼容性如何、社区认为他们仍然需要做多少工作等。我们预计这至少需要一至两年的时间。...一旦我们宣布支持，预计将有一些 distributor 会开始默认发布 no-GIL。 长期来看，我们希望 no-GIL 成为默认方式，并删除 GIL 的所有痕迹（但不会不必要地破坏向后兼容性）。
本文将详细解释这一建议的原因，并提供例子说明为什么将Context作为参数传递比存储在其他类型中更为重要。...用户可能会问自己： 既然New接受一个context.Context，那么构造函数是否正在执行需要取消或有截止日期的工作？...规则的例外：保持向后兼容性 当Go 1.7（引入了context.Context）发布时，大量API不得不以向后兼容的方式添加context支持。...因此，维护者选择在http.Request结构体中添加context.Context，以支持context.Context而不破坏向后兼容性： // Request代表一个由服务器接收或客户端发送的HTTP...知识要点总结表格： 关键点 描述 Context作为参数 提高了可读性和灵活性 避免在Structs中存储Context 防止生命周期和作用域混淆 向后兼容性 在必要时，可以在struct中添加Context
具体表现为向后兼容与向前兼容，这一点将在后文做出更详细的解释。 更小更快：序列化的目的之一是进行网络传输，在传输过程中数据流越小传输速度自然越快，可以整体提升系统性能。...事实上字段编号的使用是 proto 中非常重要的一环，在使用中务必遵循以下原则： 字段编号一旦被分配后就不应更改，这是为了保持向后兼容性（咱们会在后文详细说明）。...如果在消息定义中使用这些保留字段号之一，协议缓冲区编译器将报错提示。...当旧版本的代码遇到新版本生成的消息时，由于字段编号的重新分配，可能会引发解析错误或不预期的行为。...兼容性 如果现有的消息类型不再满足您的需求，你可以对其进行一定程度的变更。 如果添加新字段，请勿更改任何现有字段的字段编号。
开发人员可能希望通过删除不推荐的函数、重命名类型或将复杂的包拆分成可管理的部分来集成他们学到的经验教训。...这类更改需要下游用户努力将代码迁移到新的 API，因此，如果不仔细考虑好处大于成本，就不应该进行这些更改。 对于仍处于试验阶段的项目–在主要版本 v0，用户预期会出现偶尔的破坏性更改。...本文中的示例将遵循主版本子目录策略，因为它提供了最大的兼容性。我们建议模块作者遵循这一策略，只要他们有用户在 GOPATH 模式下进行开发。...向后兼容的更改和错误修复将导致新的次要版本和补丁版本(例如，v1.1.0、v2.0.1等)。 结论（Conclusion） 主要版本更改会导致开发和维护开销，并需要下游用户的变更迁移。...因此，在发布稳定版本之前，维护人员应该验证他们的 API，并仔细考虑在 v1 之后是否真的需要破坏性更改。
领取专属 10元无门槛券
手把手带您无忧上云
