优惠码优惠个人页面-阿里云开发者社区

10分钟让你彻底了解 Java 8 的 Lambda、函数式接口、Stream 用法和原理

10分钟让你彻底了解 Java 8 的 Lambda、函数式接口、Stream 用法和原理就在今年 Java 25周岁了，可能比在座的各位中的一些少年年龄还大，但令人遗憾的是，竟然没有我大，不禁感叹，Java 还是太小了。（难道我会说是因为我老了？）而就在上个月，Java 15 的试验版悄悄发布了，但是在 Java 界一直有个神秘现象，那就是「你发你发任你发，我的最爱 Java 8」. 据 Snyk 和 The Java Magazine 联合推出发布的 2020 JVM 生态调查报告显示，在所有的 Java 版本中，仍然有 64% 的开发者使用 Java 8。另外一些开发者可能已经开始用 Java 9、Java 11、Java 13 了，当然还有一些神仙开发者还在坚持使用 JDK 1.6 和 1.7。尽管 Java 8 发布多年，使用者众多，可神奇的是竟然有很多同学没有用过 Java 8 的新特性，比如 Lambda表达式、比如方法引用，再比如今天要说的 Stream。其实 Stream 就是以 Lambda 和方法引用为基础，封装的简单易用、函数式风格的 API。 Java 8 是在 2014 年发布的，实话说，风筝我也是在 Java 8 发布后很长一段时间才用的 Stream，因为 Java 8 发布的时候我还在 C# 的世界中挣扎，而使用 Lambda 表达式却很早了，因为 Python 中用 Lambda 很方便，没错，我写 Python 的时间要比 Java 的时间还长。要讲 Stream ，那就不得不先说一下它的左膀右臂 Lambda 和方法引用，你用的 Stream API 其实就是函数式的编程风格，其中的「函数」就是方法引用，「式」就是 Lambda 表达式。 Lambda 表达式Lambda 表达式是一个匿名函数，Lambda表达式基于数学中的λ演算得名，直接对应于其中的lambda抽象，是一个匿名函数，即没有函数名的函数。Lambda表达式可以表示闭包。在 Java 中，Lambda 表达式的格式是像下面这样 // 无参数，无返回值() -> log.info("Lambda") // 有参数，有返回值(int a, int b) -> { a+b }其等价于 log.info("Lambda"); private int plus(int a, int b){ return a+b; }最常见的一个例子就是新建线程，有时候为了省事，会用下面的方法创建并启动一个线程，这是匿名内部类的写法，new Thread需要一个 implements 自Runnable类型的对象实例作为参数，比较好的方式是创建一个新类，这个类 implements Runnable，然后 new 出这个新类的实例作为参数传给 Thread。而匿名内部类不用找对象接收，直接当做参数。 new Thread(new Runnable() { @Override public void run() { System.out.println("快速新建并启动一个线程"); } }).run();但是这样写是不是感觉看上去很乱、很土，而这时候，换上 Lambda 表达式就是另外一种感觉了。 new Thread(()->{ System.out.println("快速新建并启动一个线程"); }).run();怎么样，这样一改，瞬间感觉清新脱俗了不少，简洁优雅了不少。 Lambda 表达式简化了匿名内部类的形式，可以达到同样的效果，但是 Lambda 要优雅的多。虽然最终达到的目的是一样的，但其实内部的实现原理却不相同。匿名内部类在编译之后会创建一个新的匿名内部类出来，而 Lambda 是调用 JVM invokedynamic指令实现的，并不会产生新类。方法引用方法引用的出现，使得我们可以将一个方法赋给一个变量或者作为参数传递给另外一个方法。::双冒号作为方法引用的符号，比如下面这两行语句，引用 Integer类的 parseInt方法。 Function s = Integer::parseInt;Integer i = s.apply("10");或者下面这两行，引用 Integer类的 compare方法。 Comparator comparator = Integer::compare;int result = comparator.compare(100,10);再比如，下面这两行代码，同样是引用 Integer类的 compare方法，但是返回类型却不一样，但却都能正常执行，并正确返回。 IntBinaryOperator intBinaryOperator = Integer::compare;int result = intBinaryOperator.applyAsInt(10,100);相信有的同学看到这里恐怕是下面这个状态，完全不可理喻吗，也太随便了吧，返回给谁都能接盘。先别激动，来来来，现在咱们就来解惑，解除蒙圈脸。 Q：什么样的方法可以被引用？ A：这么说吧，任何你有办法访问到的方法都可以被引用。 Q：返回值到底是什么类型？ A：这就问到点儿上了，上面又是 Function、又是Comparator、又是 IntBinaryOperator的，看上去好像没有规律，其实不然。返回的类型是 Java 8 专门定义的函数式接口，这类接口用 @FunctionalInterface 注解。比如 Function这个函数式接口的定义如下： @FunctionalInterfacepublic interface Function { R apply(T t); }还有很关键的一点，你的引用方法的参数个数、类型，返回值类型要和函数式接口中的方法声明一一对应才行。比如 Integer.parseInt方法定义如下： public static int parseInt(String s) throws NumberFormatException { return parseInt(s,10); }首先parseInt方法的参数个数是 1 个，而 Function中的 apply方法参数个数也是 1 个，参数个数对应上了，再来，apply方法的参数类型和返回类型是泛型类型，所以肯定能和 parseInt方法对应上。这样一来，就可以正确的接收Integer::parseInt的方法引用，并可以调用Funciton的apply方法，这时候，调用到的其实就是对应的 Integer.parseInt方法了。用这套标准套到 Integer::compare方法上，就不难理解为什么即可以用 Comparator接收，又可以用 IntBinaryOperator接收了，而且调用它们各自的方法都能正确的返回结果。 Integer.compare方法定义如下： public static int compare(int x, int y) { return (x < y) ? -1 : ((x == y) ? 0 : 1); }返回值类型 int，两个参数，并且参数类型都是 int。然后来看Comparator和IntBinaryOperator它们两个的函数式接口定义和其中对应的方法： @FunctionalInterfacepublic interface Comparator { int compare(T o1, T o2); } @FunctionalInterfacepublic interface IntBinaryOperator { int applyAsInt(int left, int right); }对不对，都能正确的匹配上，所以前面示例中用这两个函数式接口都能正常接收。其实不止这两个，只要是在某个函数式接口中声明了这样的方法：两个参数，参数类型是 int或者泛型，并且返回值是 int或者泛型的，都可以完美接收。 JDK 中定义了很多函数式接口，主要在 java.util.function包下，还有 java.util.Comparator 专门用作定制比较器。另外，前面说的 Runnable也是一个函数式接口。自己动手实现一个例子定义一个函数式接口，并添加一个方法定义了名称为 KiteFunction 的函数式接口，使用 @FunctionalInterface注解，然后声明了具有两个参数的方法 run，都是泛型类型，返回结果也是泛型。还有一点很重要，函数式接口中只能声明一个可被实现的方法，你不能声明了一个 run方法，又声明一个 start方法，到时候编译器就不知道用哪个接收了。而用default 关键字修饰的方法则没有影响。 @FunctionalInterfacepublic interface KiteFunction { /** * 定义一个双参数的方法 * @param t * @param s * @return */ R run(T t,S s); } 定义一个与 KiteFunction 中 run 方法对应的方法在 FunctionTest 类中定义了方法 DateFormat，一个将 LocalDateTime类型格式化为字符串类型的方法。 public class FunctionTest { public static String DateFormat(LocalDateTime dateTime, String partten) { DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern(partten); return dateTime.format(dateTimeFormatter); } }3.用方法引用的方式调用正常情况下我们直接使用 FunctionTest.DateFormat()就可以了。而用函数式方式，是这样的。 KiteFunction functionDateFormat = FunctionTest::DateFormat;String dateString = functionDateFormat.run(LocalDateTime.now(),"yyyy-MM-dd HH:mm:ss");而其实我可以不专门在外面定义 DateFormat这个方法，而是像下面这样，使用匿名内部类。 public static void main(String[] args) throws Exception { String dateString = new KiteFunction<LocalDateTime, String, String>() { @Override public String run(LocalDateTime localDateTime, String s) { DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern(s); return localDateTime.format(dateTimeFormatter); } }.run(LocalDateTime.now(), "yyyy-MM-dd HH:mm:ss"); System.out.println(dateString); }前面第一个 Runnable的例子也提到了，这样的匿名内部类可以用 Lambda 表达式的形式简写，简写后的代码如下： public static void main(String[] args) throws Exception { KiteFunction<LocalDateTime, String, String> functionDateFormat = (LocalDateTime dateTime, String partten) -> { DateTimeFormatter dateTimeFormatter = DateTimeFormatter.ofPattern(partten); return dateTime.format(dateTimeFormatter); }; String dateString = functionDateFormat.run(LocalDateTime.now(), "yyyy-MM-dd HH:mm:ss"); System.out.println(dateString); }使用（LocalDateTime dateTime, String partten) -> { } 这样的 Lambda 表达式直接返回方法引用。 Stream API为了说一下 Stream API 的使用，可以说是大费周章啊，知其然，也要知其所以然吗，追求技术的态度和姿势要正确。当然 Stream 也不只是 Lambda 表达式就厉害了，真正厉害的还是它的功能，Stream 是 Java 8 中集合数据处理的利器，很多本来复杂、需要写很多代码的方法，比如过滤、分组等操作，往往使用 Stream 就可以在一行代码搞定，当然也因为 Stream 都是链式操作，一行代码可能会调用好几个方法。 Collection接口提供了 stream()方法，让我们可以在一个集合方便的使用 Stream API 来进行各种操作。值得注意的是，我们执行的任何操作都不会对源集合造成影响，你可以同时在一个集合上提取出多个 stream 进行操作。我们看 Stream 接口的定义，继承自 BaseStream，机会所有的接口声明都是接收方法引用类型的参数，比如 filter方法，接收了一个 Predicate类型的参数，它就是一个函数式接口，常用来作为条件比较、筛选、过滤用，JPA中也使用了这个函数式接口用来做查询条件拼接。 public interface Stream extends BaseStream> { Stream filter(Predicate<? super T> predicate); // 其他接口} 下面就来看看 Stream 常用 API。 of可接收一个泛型对象或可变成泛型集合，构造一个 Stream 对象。 private static void createStream(){ Stream<String> stringStream = Stream.of("a","b","c"); }empty创建一个空的 Stream 对象。 concat连接两个 Stream ，不改变其中任何一个 Steam 对象，返回一个新的 Stream 对象。 private static void concatStream(){ Stream<String> a = Stream.of("a","b","c"); Stream<String> b = Stream.of("d","e"); Stream<String> c = Stream.concat(a,b); }max一般用于求数字集合中的最大值，或者按实体中数字类型的属性比较，拥有最大值的那个实体。它接收一个 Comparator，上面也举到这个例子了，它是一个函数式接口类型，专门用作定义两个对象之间的比较，例如下面这个方法使用了 Integer::compareTo这个方法引用。 private static void max(){ Stream<Integer> integerStream = Stream.of(2, 2, 100, 5); Integer max = integerStream.max(Integer::compareTo).get(); System.out.println(max); }当然，我们也可以自己定制一个 Comparator，顺便复习一下 Lambda 表达式形式的方法引用。 private static void max(){ Stream<Integer> integerStream = Stream.of(2, 2, 100, 5); Comparator<Integer> comparator = (x, y) -> (x.intValue() < y.intValue()) ? -1 : ((x.equals(y)) ? 0 : 1); Integer max = integerStream.max(comparator).get(); System.out.println(max); }min与 max 用法一样，只不过是求最小值。 findFirst获取 Stream 中的第一个元素。 findAny获取 Stream 中的某个元素，如果是串行情况下，一般都会返回第一个元素，并行情况下就不一定了。 count返回元素个数。 Stream a = Stream.of("a", "b", "c");long x = a.count();peek建立一个通道，在这个通道中对 Stream 的每个元素执行对应的操作，对应 Consumer的函数式接口，这是一个消费者函数式接口，顾名思义，它是用来消费 Stream 元素的，比如下面这个方法，把每个元素转换成对应的大写字母并输出。 private static void peek() { Stream<String> a = Stream.of("a", "b", "c"); List<String> list = a.peek(e->System.out.println(e.toUpperCase())).collect(Collectors.toList()); }forEach和 peek 方法类似，都接收一个消费者函数式接口，可以对每个元素进行对应的操作，但是和 peek 不同的是，forEach 执行之后，这个 Stream 就真的被消费掉了，之后这个 Stream 流就没有了，不可以再对它进行后续操作了，而 peek操作完之后，还是一个可操作的 Stream 对象。正好借着这个说一下，我们在使用 Stream API 的时候，都是一串链式操作，这是因为很多方法，比如接下来要说到的 filter方法等，返回值还是这个 Stream 类型的，也就是被当前方法处理过的 Stream 对象，所以 Stream API 仍然可以使用。 private static void forEach() { Stream<String> a = Stream.of("a", "b", "c"); a.forEach(e->System.out.println(e.toUpperCase())); }forEachOrdered功能与 forEach是一样的，不同的是，forEachOrdered是有顺序保证的，也就是对 Stream 中元素按插入时的顺序进行消费。为什么这么说呢，当开启并行的时候，forEach和 forEachOrdered的效果就不一样了。 Stream a = Stream.of("a", "b", "c");a.parallel().forEach(e->System.out.println(e.toUpperCase()));当使用上面的代码时，输出的结果可能是 B、A、C 或者 A、C、B或者A、B、C，而使用下面的代码，则每次都是 A、 B、C Stream a = Stream.of("a", "b", "c");a.parallel().forEachOrdered(e->System.out.println(e.toUpperCase()));limit获取前 n 条数据，类似于 MySQL 的limit，只不过只能接收一个参数，就是数据条数。 private static void limit() { Stream<String> a = Stream.of("a", "b", "c"); a.limit(2).forEach(e->System.out.println(e)); }上述代码打印的结果是 a、b。 skip跳过前 n 条数据，例如下面代码，返回结果是 c。 private static void skip() { Stream<String> a = Stream.of("a", "b", "c"); a.skip(2).forEach(e->System.out.println(e)); }distinct元素去重，例如下面方法返回元素是 a、b、c，将重复的 b 只保留了一个。 private static void distinct() { Stream<String> a = Stream.of("a", "b", "c","b"); a.distinct().forEach(e->System.out.println(e)); }sorted有两个重载，一个无参数，另外一个有个 Comparator类型的参数。无参类型的按照自然顺序进行排序，只适合比较单纯的元素，比如数字、字母等。 private static void sorted() { Stream<String> a = Stream.of("a", "c", "b"); a.sorted().forEach(e->System.out.println(e)); }有参数的需要自定义排序规则，例如下面这个方法，按照第二个字母的大小顺序排序，最后输出的结果是 a1、b3、c6。 private static void sortedWithComparator() { Stream<String> a = Stream.of("a1", "c6", "b3"); a.sorted((x,y)->Integer.parseInt(x.substring(1))>Integer.parseInt(y.substring(1))?1:-1).forEach(e->System.out.println(e)); }为了更好的说明接下来的几个 API ，我模拟了几条项目中经常用到的类似数据，10条用户信息。 private static List getUserData() { Random random = new Random(); List<User> users = new ArrayList<>(); for (int i = 1; i <= 10; i++) { User user = new User(); user.setUserId(i); user.setUserName(String.format("古时的风筝 %s 号", i)); user.setAge(random.nextInt(100)); user.setGender(i % 2); user.setPhone("18812021111"); user.setAddress("无"); users.add(user); } return users; }filter用于条件筛选过滤，筛选出符合条件的数据。例如下面这个方法，筛选出性别为 0，年龄大于 50 的记录。 private static void filter(){ List<User> users = getUserData(); Stream<User> stream = users.stream(); stream.filter(user -> user.getGender().equals(0) && user.getAge()>50).forEach(e->System.out.println(e)); /** *等同于下面这种形式匿名内部类 */ // stream.filter(new Predicate() {// @Override// public boolean test(User user) {// return user.getGender().equals(0) && user.getAge()>50;// }// }).forEach(e->System.out.println(e));}mapmap方法的接口方法声明如下，接受一个 Function函数式接口，把它翻译成映射最合适了，通过原始数据元素，映射出新的类型。 Stream map(Function<? super T, ? extends R> mapper);而 Function的声明是这样的，观察 apply方法，接受一个 T 型参数，返回一个 R 型参数。用于将一个类型转换成另外一个类型正合适，这也是 map的初衷所在，用于改变当前元素的类型，例如将 Integer 转为 String类型，将 DAO 实体类型，转换为 DTO 实例类型。当然了，T 和 R 的类型也可以一样，这样的话，就和 peek方法没什么不同了。 @FunctionalInterfacepublic interface Function { /** * Applies this function to the given argument. * * @param t the function argument * @return the function result */ R apply(T t); }例如下面这个方法，应该是业务系统的常用需求，将 User 转换为 API 输出的数据格式。 private static void map(){ List<User> users = getUserData(); Stream<User> stream = users.stream(); List<UserDto> userDtos = stream.map(user -> dao2Dto(user)).collect(Collectors.toList()); } private static UserDto dao2Dto(User user){ UserDto dto = new UserDto(); BeanUtils.copyProperties(user, dto); //其他额外处理 return dto; }mapToInt将元素转换成 int 类型，在 map方法的基础上进行封装。 mapToLong将元素转换成 Long 类型，在 map方法的基础上进行封装。 mapToDouble将元素转换成 Double 类型，在 map方法的基础上进行封装。 flatMap这是用在一些比较特别的场景下，当你的 Stream 是以下这几种结构的时候，需要用到 flatMap方法，用于将原有二维结构扁平化。 StreamStream>Stream>以上这三类结构，通过 flatMap方法，可以将结果转化为 Stream这种形式，方便之后的其他操作。比如下面这个方法，将List>扁平处理，然后再使用 map或其他方法进行操作。 private static void flatMap(){ List<User> users = getUserData(); List<User> users1 = getUserData(); List<List<User>> userList = new ArrayList<>(); userList.add(users); userList.add(users1); Stream<List<User>> stream = userList.stream(); List<UserDto> userDtos = stream.flatMap(subUserList->subUserList.stream()).map(user -> dao2Dto(user)).collect(Collectors.toList()); }flatMapToInt用法参考 flatMap，将元素扁平为 int 类型，在 flatMap方法的基础上进行封装。 flatMapToLong用法参考 flatMap，将元素扁平为 Long 类型，在 flatMap方法的基础上进行封装。 flatMapToDouble用法参考 flatMap，将元素扁平为 Double 类型，在 flatMap方法的基础上进行封装。 collection在进行了一系列操作之后，我们最终的结果大多数时候并不是为了获取 Stream 类型的数据，而是要把结果变为 List、Map 这样的常用数据结构，而 collection就是为了实现这个目的。就拿 map 方法的那个例子说明，将对象类型进行转换后，最终我们需要的结果集是一个 List类型的，使用 collect方法将 Stream 转换为我们需要的类型。下面是 collect接口方法的定义： R collect(Collector<? super T, A, R> collector);下面这个例子演示了将一个简单的 Integer Stream 过滤出大于 7 的值，然后转换成 List集合，用的是 Collectors.toList()这个收集器。 private static void collect(){ Stream<Integer> integerStream = Stream.of(1,2,5,7,8,12,33); List<Integer> list = integerStream.filter(s -> s.intValue()>7).collect(Collectors.toList()); }很多同学表示看不太懂这个 Collector是怎么一个意思，来，我们看下面这段代码，这是 collect的另一个重载方法，你可以理解为它的参数是按顺序执行的，这样就清楚了，这就是个 ArrayList 从创建到调用 addAll方法的一个过程。 private static void collect(){ Stream<Integer> integerStream = Stream.of(1,2,5,7,8,12,33); List<Integer> list = integerStream.filter(s -> s.intValue()>7).collect(ArrayList::new, ArrayList::add, ArrayList::addAll); }我们在自定义 Collector的时候其实也是这个逻辑，不过我们根本不用自定义， Collectors已经为我们提供了很多拿来即用的收集器。比如我们经常用到Collectors.toList()、Collectors.toSet()、Collectors.toMap()。另外还有比如Collectors.groupingBy()用来分组，比如下面这个例子，按照 userId 字段分组，返回以 userId 为key，List 为value 的 Map，或者返回每个 key 的个数。 // 返回 userId:ListMap> map = user.stream().collect(Collectors.groupingBy(User::getUserId)); // 返回 userId:每组个数Map map = user.stream().collect(Collectors.groupingBy(User::getUserId,Collectors.counting()));toArraycollection是返回列表、map 等，toArray是返回数组，有两个重载，一个空参数，返回的是 Object[]。另一个接收一个 IntFunction类型参数。 @FunctionalInterfacepublic interface IntFunction { /** * Applies this function to the given argument. * * @param value the function argument * @return the function result */ R apply(int value); }比如像下面这样使用，参数是 User[]::new也就是new 一个 User 数组，长度为最后的 Stream 长度。 private static void toArray() { List<User> users = getUserData(); Stream<User> stream = users.stream(); User[] userArray = stream.filter(user -> user.getGender().equals(0) && user.getAge() > 50).toArray(User[]::new); }reduce它的作用是每次计算的时候都用到上一次的计算结果，比如求和操作，前两个数的和加上第三个数的和，再加上第四个数，一直加到最后一个数位置，最后返回结果，就是 reduce的工作过程。 private static void reduce(){ Stream<Integer> integerStream = Stream.of(1,2,5,7,8,12,33); Integer sum = integerStream.reduce(0,(x,y)->x+y); System.out.println(sum); }另外 Collectors好多方法都用到了 reduce，比如 groupingBy、minBy、maxBy等等。并行 StreamStream 本质上来说就是用来做数据处理的，为了加快处理速度，Stream API 提供了并行处理 Stream 的方式。通过 users.parallelStream()或者users.stream().parallel() 的方式来创建并行 Stream 对象，支持的 API 和普通 Stream 几乎是一致的。并行 Stream 默认使用 ForkJoinPool线程池，当然也支持自定义，不过一般情况下没有必要。ForkJoin 框架的分治策略与并行流处理正好契合。虽然并行这个词听上去很厉害，但并不是所有情况使用并行流都是正确的，很多时候完全没这个必要。什么情况下使用或不应使用并行流操作呢？必须在多核 CPU 下才使用并行 Stream，听上去好像是废话。在数据量不大的情况下使用普通串行 Stream 就可以了，使用并行 Stream 对性能影响不大。CPU 密集型计算适合使用并行 Stream，而 IO 密集型使用并行 Stream 反而会更慢。虽然计算是并行的可能很快，但最后大多数时候还是要使用 collect合并的，如果合并代价很大，也不适合用并行 Stream。有些操作，比如 limit、 findFirst、forEachOrdered 等依赖于元素顺序的操作，都不适合用并行 Stream。最后Java 25 周岁了，有多少同学跟我一样在用 Java 8，还有多少同学再用更早的版本，请说出你的故事。原文地址https://my.oschina.net/u/4519772/blog/4305992

理解 K8s 资源更新机制，从一个 OpenKruise 用户疑问开始

理解 K8s 资源更新机制，从一个 OpenKruise 用户疑问开始背景OpenKruise 是阿里云开源的大规模应用自动化管理引擎，在功能上对标了 Kubernetes 原生的 Deployment / StatefulSet 等控制器，但 OpenKruise 提供了更多的增强功能如：优雅原地升级、发布优先级/打散策略、多可用区workload抽象管理、统一 sidecar 容器注入管理等，都是经历了阿里巴巴超大规模应用场景打磨出的核心能力。这些 feature 帮助我们应对更加多样化的部署环境和需求、为集群维护者和应用开发者带来更加灵活的部署发布组合策略。目前在阿里巴巴内部云原生环境中，绝大部分应用都统一使用 OpenKruise 的能力做 Pod 部署、发布管理，而不少业界公司和阿里云上客户由于 K8s 原生 Deployment 等负载不能完全满足需求，也转而采用 OpenKruise 作为应用部署载体。今天的分享文章就从一个阿里云上客户对接 OpenKruise 的疑问开始。这里还原一下这位同学的用法（以下 YAML 数据仅为 demo）：准备一份 Advanced StatefulSet 的 YAML 文件，并提交创建。如：apiVersion: apps.kruise.io/v1alpha1kind: StatefulSetmetadata: name: samplespec: # ... template: # ... spec: containers: - name: main image: nginx:alpine updateStrategy: type: RollingUpdate rollingUpdate: podUpdatePolicy: InPlaceIfPossible 然后，修改了 YAML 中的 image 镜像版本，然后调用 K8s api 接口做更新。结果收到报错如下：metadata.resourceVersion: Invalid value: 0x0: must be specified for an update而如果使用 kubectl apply 命令做更新，则返回成功：statefulset.apps.kruise.io/sample configured问题在于，为什么同一份修改后的 YAML 文件，调用 api 接口更新是失败的，而用 kubectl apply 更新是成功的呢？这其实并不是 OpenKruise 有什么特殊校验，而是由 K8s 自身的更新机制所决定的。从我们的接触来看，绝大多数用户都有通过 kubectl 命令或是 sdk 来更新 K8s 资源的经验，但真正理解这些更新操作背后原理的人却并不多。本文将着重介绍 K8s 的资源更新机制，以及一些我们常用的更新方式是如何实现的。更新原理不知道你有没有想过一个问题：对于一个 K8s 资源对象比如 Deployment，我们尝试在修改其中 image 镜像时，如果有其他人同时也在对这个 Deployment 做修改，会发生什么？当然，这里还可以引申出两个问题：如果双方修改的是同一个字段，比如 image 字段，结果会怎样？如果双方修改的是不同字段，比如一个修改 image，另一个修改 replicas，又会怎么样？其实，对一个 Kubernetes 资源对象做“更新”操作，简单来说就是通知 kube-apiserver 组件我们希望如何修改这个对象。而 K8s 为这类需求定义了两种“通知”方式，分别是 update 和 patch。在 update 请求中，我们需要将整个修改后的对象提交给 K8s；而对于 patch 请求，我们只需要将对象中某些字段的修改提交给 K8s。那么回到背景问题，为什么用户提交修改后的 YAML 文件做 update 会失败呢？这其实是被 K8s 对 update 请求的版本控制机制所限制的。 Update 机制Kubernetes 中的所有资源对象，都有一个全局唯一的版本号（metadata.resourceVersion）。每个资源对象从创建开始就会有一个版本号，而后每次被修改（不管是 update 还是 patch 修改），版本号都会发生变化。官方文档告诉我们，这个版本号是一个 K8s 的内部机制，用户不应该假设它是一个数字或者通过比较两个版本号大小来确定资源对象的新旧，唯一能做的就是通过比较版本号相等来确定对象是否是同一个版本（即是否发生了变化）。而 resourceVersion 一个重要的用处，就是来做 update 请求的版本控制。 K8s 要求用户 update 请求中提交的对象必须带有 resourceVersion，也就是说我们提交 update 的数据必须先来源于 K8s 中已经存在的对象。因此，一次完整的 update 操作流程是：首先，从 K8s 中拿到一个已经存在的对象（可以选择直接从 K8s 中查询；如果在客户端做了 list watch，推荐从本地 informer 中获取）；然后，基于这个取出来的对象做一些修改，比如将 Deployment 中的 replicas 做增减，或是将 image 字段修改为一个新版本的镜像；最后，将修改后的对象通过 update 请求提交给 K8s；此时，kube-apiserver 会校验用户 update 请求提交对象中的 resourceVersion 一定要和当前 K8s 中这个对象最新的 resourceVersion 一致，才能接受本次 update。否则，K8s 会拒绝请求，并告诉用户发生了版本冲突（Conflict）。上图展示了多个用户同时 update 某一个资源对象时会发生的事情。而如果如果发生了 Conflict 冲突，对于 User A 而言应该做的就是做一次重试，再次获取到最新版本的对象，修改后重新提交 update。因此，我们上面的两个问题也都得到了解答：用户修改 YAML 后提交 update 失败，是因为 YAML 文件中没有包含 resourceVersion 字段。对于 update 请求而言，应该取出当前 K8s 中的对象做修改后提交；如果两个用户同时对一个资源对象做 update，不管操作的是对象中同一个字段还是不同字段，都存在版本控制的机制确保两个用户的 update 请求不会发生覆盖。Patch 机制相比于 update 的版本控制，K8s 的 patch 机制则显得更加简单。当用户对某个资源对象提交一个 patch 请求时，kube-apiserver 不会考虑版本问题，而是“无脑”地接受用户的请求（只要请求发送的 patch 内容合法），也就是将 patch 打到对象上、同时更新版本号。不过，patch 的复杂点在于，目前 K8s 提供了 4 种 patch 策略：json patch、merge patch、strategic merge patch、apply patch（从 K8s 1.14 支持 server-side apply 开始）。通过 kubectl patch -h 命令我们也可以看到这个策略选项（默认采用 strategic）： $ kubectl patch -h ... --type='strategic': The type of patch being provided; one of [json merge strategic]篇幅限制这里暂不对每个策略做详细的介绍了，我们就以一个简单的例子来看一下它们的差异性。如果针对一个已有的 Deployment 对象，假设 template 中已经有了一个名为 app 的容器：如果要在其中新增一个 nginx 容器，如何 patch 更新？如果要修改 app 容器的镜像，如何 patch 更新？json patch（RFC 6902）新增容器： kubectl patch deployment/foo --type='json' -p \ '[{"op":"add","path":"/spec/template/spec/containers/1","value":{"name":"nginx","image":"nginx:alpine"}}]'修改已有容器 image： kubectl patch deployment/foo --type='json' -p \ '[{"op":"replace","path":"/spec/template/spec/containers/0/image","value":"app-image:v2"}]'可以看到，在 json patch 中我们要指定操作类型，比如 add 新增还是 replace 替换，另外在修改 containers 列表时要通过元素序号来指定容器。这样一来，如果我们 patch 之前这个对象已经被其他人修改了，那么我们的 patch 有可能产生非预期的后果。比如在执行 app 容器镜像更新时，我们指定的序号是 0，但此时 containers 列表中第一个位置被插入了另一个容器，则更新的镜像就被错误地插入到这个非预期的容器中。 merge patch（RFC 7386）merge patch 无法单独更新一个列表中的某个元素，因此不管我们是要在 containers 里新增容器、还是修改已有容器的 image、env 等字段，都要用整个 containers 列表来提交 patch： kubectl patch deployment/foo --type='merge' -p \ '{"spec":{"template":{"spec":{"containers":[{"name":"app","image":"app-image:v2"},{"name":"nginx","image":"nginx:alpline"}]}}}}'显然，这个策略并不适合我们对一些列表深层的字段做更新，更适用于大片段的覆盖更新。不过对于 labels/annotations 这些 map 类型的元素更新，merge patch 是可以单独指定 key-value 操作的，相比于 json patch 方便一些，写起来也更加直观： kubectl patch deployment/foo --type='merge' -p '{"metadata":{"labels":{"test-key":"foo"}}}'strategic merge patch这种 patch 策略并没有一个通用的 RFC 标准，而是 K8s 独有的，不过相比前两种而言却更为强大的。我们先从 K8s 源码看起，在 K8s 原生资源的数据结构定义中额外定义了一些的策略注解。比如以下这个截取了 podSpec 中针对 containers 列表的定义，参考 Github： // ...// +patchMergeKey=name// +patchStrategy=mergeContainers []Container json:"containers" patchStrategy:"merge" patchMergeKey:"name" protobuf:"bytes,2,rep,name=containers"可以看到其中有两个关键信息：patchStrategy:"merge" patchMergeKey:"name" 。这就代表了，containers 列表使用 strategic merge patch 策略更新时，会把下面每个元素中的 name 字段看作 key。简单来说，在我们 patch 更新 containers 不再需要指定下标序号了，而是指定 name 来修改，K8s 会把 name 作为 key 来计算 merge。比如针对以下的 patch 操作： kubectl patch deployment/foo -p \ '{"spec":{"template":{"spec":{"containers":[{"name":"nginx","image":"nginx:mainline"}]}}}}'如果 K8s 发现当前 containers 中已经有名字为 nginx 的容器，则只会把 image 更新上去；而如果当前 containers 中没有 nginx 容器，K8s 会把这个容器插入 containers 列表。此外还要说明的是，目前 strategic 策略只能用于原生 K8s 资源以及 Aggregated API 方式的自定义资源，对于 CRD 定义的资源对象，是无法使用的。这很好理解，因为 kube-apiserver 无法得知 CRD 资源的结构和 merge 策略。如果用 kubectl patch 命令更新一个 CR，则默认会采用 merge patch 的策略来操作。 kubectl 封装了解完了 K8s 的基础更新机制，我们再次回到最初的问题上。为什么用户修改 YAML 文件后无法直接调用 update 接口更新，却可以通过 kubectl apply 命令更新呢？其实 kubectl 为了给命令行用户提供良好的交互体感，设计了较为复杂的内部执行逻辑，诸如 apply、edit 这些常用操作其实背后并非对应一次简单的 update 请求。毕竟 update 是有版本控制的，如果发生了更新冲突对于普通用户并不友好。以下简略介绍下 kubectl 几种更新操作的逻辑，有兴趣可以看一下 kubectl 封装的源码。 apply在使用默认参数执行 apply 时，触发的是 client-side apply。kubectl 逻辑如下：首先解析用户提交的数据（YAML/JSON）为一个对象 A；然后调用 Get 接口从 K8s 中查询这个资源对象：如果查询结果不存在，kubectl 将本次用户提交的数据记录到对象 A 的 annotation 中（key 为 kubectl.kubernetes.io/last-applied-configuration），最后将对象 A提交给 K8s 创建；如果查询到 K8s 中已有这个资源，假设为对象 B：1. kubectl 尝试从对象 B 的 annotation 中取出 kubectl.kubernetes.io/last-applied-configuration 的值（对应了上一次 apply 提交的内容）；2. kubectl 根据前一次 apply 的内容和本次 apply 的内容计算出 diff（默认为 strategic merge patch 格式，如果非原生资源则采用 merge patch）；3. 将 diff 中添加本次的 kubectl.kubernetes.io/last-applied-configuration annotation，最后用 patch 请求提交给 K8s 做更新。这里只是一个大致的流程梳理，真实的逻辑会更复杂一些，而从 K8s 1.14 之后也支持了 server-side apply，有兴趣的同学可以看一下源码实现。 editkubectl edit 逻辑上更简单一些。在用户执行命令之后，kubectl 从 K8s 中查到当前的资源对象，并打开一个命令行编辑器（默认用 vi）为用户提供编辑界面。当用户修改完成、保存退出时，kubectl 并非直接把修改后的对象提交 update（避免 Conflict，如果用户修改的过程中资源对象又被更新），而是会把修改后的对象和初始拿到的对象计算 diff，最后将 diff 内容用 patch 请求提交给 K8s。总结看了上述的介绍，大家应该对 K8s 更新机制有了一个初步的了解了。接下来想一想，既然 K8s 提供了两种更新方式，我们在不同的场景下怎么选择 update 或 patch 来使用呢？这里我们的建议是：如果要更新的字段只有我们自己会修改（比如我们有一些自定义标签，并写了 operator 来管理），则使用 patch 是最简单的方式；如果要更新的字段可能会被其他方修改（比如我们修改的 replicas 字段，可能有一些其他组件比如 HPA 也会做修改），则建议使用 update 来更新，避免出现互相覆盖。最终我们的客户改为基于 get 到的对象做修改后提交 update，终于成功触发了 Advanced StatefulSet 的原地升级。此外，我们也欢迎和鼓励更多的同学参与到 OpenKruise 社区中，共同合作打造一款面向规模化场景、高性能的应用交付解决方案。（欢迎加入钉钉交流群：23330762）课程推荐为了更多开发者能够享受到 Serverless 带来的红利，这一次，我们集结了 10+ 位阿里巴巴 Serverless 领域技术专家，打造出最适合开发者入门的 Serverless 公开课，让你即学即用，轻松拥抱云计算的新范式——Serverless。点击即可免费观看课程：https://developer.aliyun.com/learning/roadmap/serverless 作者 | 酒祝阿里云技术专家原文地址https://my.oschina.net/u/3874284/blog/4298407

优惠码优惠个人页面-阿里云开发者社区

个人介绍

擅长的技术

10分钟让你彻底了解 Java 8 的 Lambda、函数式接口、Stream 用法和原理

官宣！ASF官方正式宣布Apache Hudi成为顶级项目

关于C#委托三种调用的分享

实战| 配置DataDog监控Apache Hudi应用指标

理解 K8s 资源更新机制，从一个 OpenKruise 用户疑问开始

10分钟让你彻底了解 Java 8 的 Lambda、函数式接口、Stream 用法和原理

官宣！ASF官方正式宣布Apache Hudi成为顶级项目

关于C#委托三种调用的分享

实战| 配置DataDog监控Apache Hudi应用指标

理解 K8s 资源更新机制，从一个 OpenKruise 用户疑问开始

重学 Java 设计模式：实战单例模式

关于sql String类型的日期数据如何进行比较查询

C# 数据操作系列 - 19 FreeSql 入坑介绍

像宝石一样的Java原子类

《机器学习Python实现_09_01_决策树_ID3与C4.5》

一个茴字有三种写法——吐槽C#9.0的Records

.net core kafka 入门实例一篇看懂

一文带你学会国产加密算法SM4的java实现方案

C#枚举高级战术

你应该知道的Python3.6、3.7、3.8新特性

把99%的程序员烤得外焦里嫩的JavaScript面试题

Nacos+Spring Cloud Gateway动态路由配置

【Java8新特性】还没搞懂函数式接口？赶快过来看看吧！

【Java8新特性】Lambda表达式基础语法，都在这儿了！！

Linux Mutex机制分析

优惠码优惠个人页面-阿里云开发者社区

个人介绍

擅长的技术

10分钟让你彻底了解 Java 8 的 Lambda、函数式接口、Stream 用法和原理

官宣！ASF官方正式宣布Apache Hudi成为顶级项目

关于C#委托三种调用的分享

实战| 配置DataDog监控Apache Hudi应用指标

理解 K8s 资源更新机制，从一个 OpenKruise 用户疑问开始

10分钟让你彻底了解 Java 8 的 Lambda、函数式接口、Stream 用法和原理

官宣！ASF官方正式宣布Apache Hudi成为顶级项目

关于C#委托三种调用的分享

实战| 配置DataDog监控Apache Hudi应用指标

理解 K8s 资源更新机制，从一个 OpenKruise 用户疑问开始

重学 Java 设计模式：实战单例模式

关于sql String类型的日期数据如何进行比较查询

C# 数据操作系列 - 19 FreeSql 入坑介绍

像宝石一样的Java原子类

《机器学习Python实现_09_01_决策树_ID3与C4.5》

一个茴字有三种写法——吐槽C#9.0的Records

.net core kafka 入门实例 一篇看懂

一文带你学会国产加密算法SM4的java实现方案

C#枚举高级战术

你应该知道的Python3.6、3.7、3.8新特性

把99%的程序员烤得外焦里嫩的JavaScript面试题

Nacos+Spring Cloud Gateway动态路由配置

【Java8新特性】还没搞懂函数式接口？赶快过来看看吧！

【Java8新特性】Lambda表达式基础语法，都在这儿了！！

Linux Mutex机制分析

.net core kafka 入门实例一篇看懂