张逸说

出口成张,逸派胡言

0%

在我们的数据平台产品中,为了简化开发,对Flink做了一层封装,定义了JobFlow的抽象。一个Job其实就是Flink的一个作业,每个Job可以定义多个Flow,一个Flow可以理解为是Flink的一个DataStream,利用Job传递的StreamExecutionEnvironment可以在Flow中添加包括SourceSink的多个算子。

Job与Flow之间的关系可以利用自定义的@JobFlow注解进行配置,如此就可以在执行抽象的AbstractJobrun()方法时,利用反射获得该Job下的所有Flow,遍历执行每个Flow的run()方法。在Flow的run()方法中,才会真正根据StreamExecutionEnvironment执行多个算子。

Flink为了保证计算的稳定性,提供了不同的重启策略。例如,当我们将重启策略设置为失败率(failure-rate)时,如果执行的任务出错次数达到了失败率配置的要求,Flink的Worker节点的TaskManager就会重启。如果超过重启次数,Task Manager就会停止运行。

阅读全文 »

不出意外,《解构领域驱动设计》再次延期,完全符合一般软件开发的惯例。

我来汇报一下本书临近出版的一条时间线。

5月31日,出版社编辑刘雅思同学告知我本书正式申领到书号,标志着本书正式发稿完毕。这个流程是必走的,否则就别想通过正规出版社出版了。之后的流程就是排版。 因为书的内容非常多,排版花费了不少时间。

阅读全文 »

领域驱动设计的社区主流声音是划分问题空间(Problem Space)与解空间(Solution Space)。整个问题空间实际上就是团队开发的目标系统对应的领域,这实际上也是业务架构要描述的目标。领域驱动设计解决大规模问题空间的方法或模式是引入子领域(Subdomain)。

根据价值高低的不同,子领域分为核心子领域、支撑子领域和通用子领域。若将其引入到业务架构,似乎可以根据价值高低建立不同的服务层,例如:

  • 核心子领域:产品服务层,体现为子领域专用的产品服务
  • 支撑子领域:能力服务层,体现为跨子领域复用的能力服务
  • 通用子领域:基础服务层,体现为与领域无关的基础服务

不同的层次代表了复用的粒度和水平。基础服务层因为与领域无关,它复用的范围更广泛,对应为业务架构中的支撑业务(支撑部门提供的职能),如财务体系、人力资源体系、行政体系、采购体系等。原则上,任何企业都需要这些支撑业务,而与企业从事的领域方向无关。引入领域驱动设计的概念,我将其纳入到通用子领域的范畴。

阅读全文 »

DDD的作用范围主要还是针对系统级的分析、架构与设计,在更高的层面上,即将问题空间扩大到超过系统范围,变成企业或组织范围之后,DDD的模式就显得捉襟见肘了。此时,可以考虑引入企业架构的思想,尤其是业务架构的内容,给了DDD很好的补充,又或者说,将企业架构与DDD融合起来,就能真正串联起战略和战术设计了。

为什么在传统企业中,DDD开始得到了许多企业的追捧?不仅仅是微服务的原因,就我个人不成熟的判断,应该是数字化转型开始倒逼着传统企业的IT部门开始接纳了DDD这一方法体系。

阅读全文 »