官宣：Istio 1.1正式发布，Java 12 也来了！新功能速看

Posted 2021-04-13 行云创新

虽然Istio1.0的目标是生产可用，但从去年 7 月份 1.0 发布以来，在性能和稳定上并不能受人满意。为了帮助人们将 Istio 投入生产，官方团队做了很多工作。今日，官方宣布备受关注的Istio 1.1已经正式发布！中文文档也同时释出。

此外，自 2 月 7 日开始，Java 12 / JDK 12 就进入了 RC 阶段。按照发布周期，美国当地时间 3 月 19 日，也就是今天——Java 12也正式发布了！

ServiceMesher官宣

我们很高兴地宣布 Istio 1.1 发布！

1.1 版本的主题是“Enterprise Ready”（企业级就绪）。我们很高兴看到越来越多的公司在生产中使用 Istio，但是随着一些大公司加入进来，Istio 也遇到了一些瓶颈。

我们关注的主要领域包括性能和可扩展性。随着人们将 Istio 逐步投入生产，使用更大的集群以更高的容量运行更多服务，可能会遇到了一些扩展和性能问题。Sidecar 占用了太多资源增加了太多的延迟。控制平面（尤其是 Pilot）过度耗费资源。

我们投入了很多精力在使数据平面和控制平面更有效率上。在 1.1 的性能测试中，我们观察到 sidecar 处理 1000 rps 通常需要 0.5 个 vCPU。单个 Pilot 实例能够处理 1000 个服务（以及 2000 个 pod），需要消耗 1.5 个 vCPU 和 2GB 内存。Sidecar 在第 50 百分位增加 5 毫秒，在第 99 百分位增加 10 毫秒（执行策略将增加延迟）。

我们也完成了命名空间隔离的工作。您可以使用 Kubernetes 命名空间来强制控制边界以确保团队之间不会相互干扰。

我们还改进了多集群功能和可用性。我们听取了社区的意见，改进了流量控制和策略的默认设置。我们引入了一个名为 Galley 的新组件。Galley 验证 YAML 配置，减少了配置错误的可能性。Galley 还用在多集群设置中——从每个 Kubernetes 集群中收集服务发现信息。我们还支持了其他多集群拓扑，包括单控制平面和多个同步控制平面，而无需扁平网络支持。

更多信息和详情请查看发布说明。

该项目还有更多进展。众所周知 Istio 有许多可移动部件，它们承担了太多工作。为了解决这个问题，我们最近成立了 Usability Working Group（可用性工作组）（可随时加入）。社区会议（周四上午 11 点）和工作组里也发生了很多事情。您可以使用 GitHub 凭据登录 discuss.istio.io 参与讨论！

感谢在过去几个月里为 Istio 作出贡献的所有人——修补 1.0，为 1.1 增加功能以及最近在 1.1 上进行的大量测试。特别感谢那些与我们合作安装和升级到早期版本，帮助我们在发布之前发现问题的公司和用户。

最后，去浏览最新文档，安装 1.1 版本吧！Happy meshing！

其他资料

为了帮助大家学习和了解 Istio，分享实践经验，ServiceMesher 社区自成立以来积累了如下资料。

Istio Handbook

社区名义推出开源电子书《Istio Handbook——Istio 服务网格进阶实战》，ServiceMesher 社区作为中国最早的一批在研究和推广 Service Mesh 技术的开源社区决定整合社区资源，合作撰写一本开源电子书作为服务网格智库。

Istio 知识图谱

Istio 知识图谱是由 ServiceMesher 社区成员协作编制的 Istio Service Mesh 中的知识结构图谱。

Java 12 新特性

Java 12 带来了一系列新特性：

下边分别来看看：

JEP 189: Shenandoah: A Low-Pause-Time Garbage Collector (Experimental)

Shenandoah：低暂停时间的 GC（实验性功能）

新增了一个名为 Shenandoah 的 GC 算法，通过与正在运行的 Java 线程同时进行 evacuation 工作来减少 GC 暂停时间。使用 Shenandoah 的暂停时间与堆大小无关，这意味着无论堆是 200MB 还是 200GB，都将具有相同的暂停时间。

JEP 230: Microbenchmark Suite

微基准测试套件

JDK 源码中新增了一套微基准测试套件，开发人员可通过它轻松运行已有的微基准测试并创建新的基准测试。

JEP 325: Switch Expressions (Preview)

Switch 表达式（预览功能）

对 switch 语句进行了扩展，使其不仅可以作为语句（statement），还可以作为表达式（expression），并且两种写法都可以使用传统的 switch 语法，或者使用简化的 "case L ->" 模式匹配语法作用于不同范围并控制执行流。这些更改将简化日常编码工作，并为 switch 中的模式匹配（JEP 305）做好准备。

JEP 334: JVM Constants API

JVM 常量 API

引入 API 来对关键类文件（key class-file）和运行时工件（run-time artifacts）的名义描述（nominal descriptions）进行建模，特别是可从常量池加载的常量。

在新的 java.lang.invoke.constant 包中定义了一系列基于值的符号引用（JVMS 5.1）类型，它们能够描述每种可加载常量。

符号引用以纯 nominal 形式描述可加载常量，与类加载或可访问性上下文区分开。有些类可以作为自己的符号引用（例如 String），而对于可链接常量，定义了一系列符号引用类型（ClassDesc、MethodTypeDesc、MethodHandleDesc 和 DynamicConstantDesc），它们包含描述这些常量的 nominal 信息。

JEP 340: One AArch64 Port, Not Two

只保留一个 AArch64 实现

在保留 32 位 ARM 实现和 64 位 aarch64 实现的同时，删除与 arm64 实现相关的所有源码。

JDK 中存在两套 64 位 ARM 实现，主要存在于 src/hotspot/cpu/arm 和 open/src/hotspot/cpu/aarch64 目录。两者都实现了 aarch64，现在将只保留后者，删除由 Oracle 提供的 arm64。这将使贡献者将他们的精力集中在单个 64 位 ARM 实现上，并消除维护两套实现所需的重复工作。

JEP 341: Default CDS Archives

默认类数据共享归档文件

针对 64 位平台，使用默认类列表增强 JDK 构建过程，以生成类数据共享（class data-sharing，CDS）归档。

JEP 344: Abortable Mixed Collections for G1

可中止的 G1 混合 GC

如果混合 GC 的 G1 存在超出暂停目标的可能性，则使其可中止。

JEP 346: Promptly Return Unused Committed Memory from G1

G1 及时返回未使用的已分配内存

增强 G1 GC，以便在空闲时自动将 Java 堆内存返回给操作系统。

为了实现向操作系统返回最大内存量的目标，G1 将在应用程序不活动期间定期执行或触发并发周期以确定整体 Java 堆使用情况。这将导致它自动将 Java 堆的未使用部分返回给操作系统。而在用户控制下，可以可选地执行完整的 GC，以使返回的内存量最大化。

（