张逸说

出口成张,逸派胡言

0%

我们的产品需要对来自不同数据源的大数据进行采集,从数据源的多样化以及处理数据的低延迟与可伸缩角度考虑,需要选择适合项目的大数据流处理平台。我最初列出的候选平台包括Flume、Flink、Kafka Streaming以及Spark Streaming。然而对产品架构而言,这个技术选型的决策可谓举足轻重,倘若选择不当,可能会导致较大的修改成本,须得慎之又慎。

我除了在项目中曾经使用过Flume、Kafka以及Spark Streaming之外,对其余平台并不甚了解。即便是用过的这几个平台,也了解得比较肤浅。因此我查阅了这些平台的官方文档以及相关文章,偶然发现有Janakiram在2016年7月8日发表在The New Stack网站上的这篇文章All the Apache Streaming Projects: An Exploratory Guid,全(jian)面(dan)介绍了目前在Apache下主流的流处理项目,具有一定参考价值。因此摘译过来,以飧读者。

最近几年,数据的生成、消费、处理以及分析的速度惊人地增长,社交媒体、物联网、游戏等领域产生的数据都需要以接近实时的速度处理和分析数据。这直接催生了流数据的处理范式。从Kafka到Beam,即使是在Apache基金下,已有多个流处理项目运用于不同的业务场景。

阅读全文 »

边界通过限界上下文来确定,这在领域驱动设计中具有非凡的意义。对应于通用语言,限界上下文是语言的边界,对于领域模型,限界上下文是模型的边界,二者对应于问题空间(Problem Space)的界定。对于系统的架构,限界上下文还确定了应用边界和技术边界,进而帮助我们确定整个系统及各个限界上下文的解决方案。可以说,限界上下文是连接问题空间与解决方案空间的重要桥梁。

那么,限界上下文所界定的边界,究竟是逻辑边界,还是物理边界?这并没有定论,需得依据不同场景而做出不同的决策。

阅读全文 »

响应式编程在前端开发以及Android开发中有颇多运用,然而它的非阻塞异步编程模型以及对消息流的处理模式也在后端得到越来越多的应用。除了Netflix的OSS中大量使用了响应式编程之外,最近阿里也提出Dubbo 3.0版本将全面拥抱响应式编程。

我之前针对某些项目需求也给出了响应式编程的方案,较好地解决了并行编程与异步编程的问题。不过在深入了解响应式编程之后,我也给出了自己的一些实践总结。

响应式编程并非银弹

响应式编程并非银弹。事实上在软件领域,Brooks提出的“没有银弹”一说或许将永远生效。当我们在选择使用响应式编程时,一定要明确它的适用场景,主要包括:

  • 处理由用户或其他系统发起的事件,如鼠标点击、键盘按键或者物联网设备等无时无刻都在发射信号的情况
  • 处理磁盘或网络等高延迟的IO数据,且保证这些IO操作是异步的
  • 业务的处理流程是流式的,且需要高响应的非阻塞操作

除此之外,我们当然也可以利用一些响应式编程框架如Rx,简化并发编程与数据流操作的实现。诸如RxJava就提供非常完整的工厂方法,可以将非响应式编程的Iterable、Array以及与响应式编程有一定相关性的Future、Callable转换为Observable或Flowable。

阅读全文 »

由于Scala本身属于JVM下的语言,因此它能够较好地与Java项目融合在一起。在Scala中调用Java库,基本上与在Java中调用Java库的方式是相同的(反过来则未必,必将Java没有Scala中独有的语法糖)。因此,在Scala中可以非常方便地调用Spring Cloud,使其支持Spring Cloud提供的微服务基础设施,例如Eureka、Feign以及Spring Boot等。

不过仍然有几点需要注意,这些方面包括:

  • Maven依赖
  • Spring的语法
  • Json的序列化
阅读全文 »

作为一名程序员,又或者IT工作者,拼搏在技术快速变迁的大潮流中,其实是一种幸运,毕竟我们无需陷入重复的枯燥生活之中。然而要跟上技术发展的脚步,真的太累了,就怕步伐太慢,一不留神你就落伍了。

或许有所谓通才与全才,又有那种最强大脑的天才们学什么都很快,除此之外,如我们这般的普通人,知识无涯生却有涯,就得聪明地利用有限的时间学习真正有用的。这种所谓“有用”,就是指学习之后能够给你贴上明显标签的那类知识。“标签”是一种信号,更像是某种声望。就是当团队面临对应问题时,人们会一拍脑袋首先想到你的那种声望。

阅读全文 »