MeteorCat

前面比较长时间篇幅去说明 Description, 主要开始对开源项目的复杂性有基础认识, 可以看到开源项目当中做了大量妥协和扩展, 导致有时候很简单的功能都要为了扩展而写的很复杂. 这还仅仅是作为很小的组件就要这么多依赖类, 其他的网络|文件|Actor库依赖更加庞大, 所以需要总结适合自己理解方法 这里回过头来说明配置 Configuration 类的相关工具类: org.apache.flink.configuration.WritableConfig org.apache.flink.configuration.ReadableConfig org.apache.flink.configuration.ConfigOption org.apache.flink.configuration.ConfigOptions: 主要对之前的 ConfigOption 进行构建的 Builder 上个篇章已经说明 ConfigOption 是作为 Configuration 单独配置存放内部集合中, 而 ConfigOptions 就是相当于创建器: // 这里引用官方文档的构建器例子 // simple string-valued option with a default value ConfigOption<String> tempDirs = ConfigOptions .key("tmp.dir") .stringType() .defaultValue("/tmp"); // simple integer-valued option with a default value ConfigOption<Integer> parallelism = ConfigOptions .key("application.parallelism") .intType() .defaultValue(100); // option of list of integers with a default value ConfigOption<Integer> parallelism = ConfigOptions .

接下来我们想看下 POM 的 modules 节点上面的子模块, 首先 flink-annotations 可以先排除, 里面基本都是一些实验性注解和版本信息, 不过如果参与开源开发的话这个功能就比较有用. 可以学习下 FlinkVersion 版本文件设计, 这个文件在其他面向对象编程语言都能改动下就能使用(建议学习) 那么可以参照官方文档的例子来一步步解构内部源码: // pojo class WordWithCount public class WordWithCount { public String word; public int count; public WordWithCount() {} public WordWithCount(String word, int count) { this.word = word; this.count = count; } } // main method StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); DataStreamSource<String> text = env.socketTextStream(host, port); DataStream<WordWithCount> windowCounts = text .flatMap( (FlatMapFunction<String, String>) (line, collector) -> Arrays.stream(line.split("\\s")).forEach(collector::collect) ).returns(String.class) .

我个人对 akka/pekko 这类 Java-Actor 库十分喜爱, 所以在日常当中也会去为这类 Java 方案做推广; 虽然直接调用内部库函数方法就能满足日常使用, 但是作为后续扩展当中直接声明裸写是不符合工程化规范, 后续多人维护麻烦也挺多的. 如果2-3人的时候可能还不太明显, 随便架个 pom.xml 单项目管理也没什么问题, 但业务扩展出来的时候就很麻烦; 这里说下工作当中可能遇到的问题, 以下就是工作当中实际遇到: 1. 项目刚开始立项国内平台, 直接简单引入 pekko+msgpack 搭建服务端协议 2. 客户端调通之后开始编写业务逻辑, 然后开始跑运营流程追加功能业务 3. 底层依赖没有做封装和业务抽离, 所以直接在内部改动些底层功能, 实际上这时候还没问题 4. 海外需要构建个版本低于国内版本, 这是否问题就开始发作, 出现版本底层割裂问题 5. 国内版本在v1.2的时候底层函数改动参数变动, 但海外版本v1.0依赖这个函数而不依赖逻辑改动 (比如抽奖函数两边最开始一致, 但底层函数更新要求传递随机种子 seed 值, 国内版本已经更新而国外版本不需要更新避免干扰到其他用到函数) ------------------------ 从这里开始就是版本管理崩溃的前兆 ------------------- 6. 虽然这次靠着直接复制底层功能类, 手动修改函数调用方法处理完成, 但是结果终归是好的, 可以满足业务正常运行 7. 原先网络库采用 websocket 做传输, 现在为了底层性能需求需要改动成 tcp|udp 8. 第三方库引入又对两个版本产生巨大差异, 海外版本可能落后两个大版本, 但是内部业务还是要维持更新 9. 国内v2.0大版本更新了, 但是海外依旧保持v1.2版本, 这时候运营要求把v2.0国内某些功能业务移动海外v1.2 10. 最可怕的事情就发生了, 底层有着大量没有同步更新导致两边版本底层可能完全对不上, 只能人肉比对版本然后修改变动 11. 随着这种差异版本对比越来越多, 后续版本合并越来越困难, 两个版本不断人肉比对修改第三方引用和调用方式差别越来越大 12.