Ethereum for decentralized applications

位置

2018年5月第18期技术雷达,技术象限,建议评估(最新版技术雷达已经发布,点击这里下载

标签

Blockchain, DApps, Decentralized Applications, Ethereum

目标受众

区块链产品经理、架构师、开发人员

关注问题

区块链技术起源于比特币,由于天生具备数字货币的特质,这项技术在 Fintech 领域受到广泛关注,尤其获得了金融服务业的青睐。不过,区块链技术在以太坊(Ethereum)的拓展下,已经具备开发各种应用的能力,这些部署在区块链上通常含有内部代币激励并且开源的应用被称之为去中心化应用(Decentralized Application, DApp),DApp 就像现在的应用一样,能够惠及人们生活的方方面面,同时融入区块链的独特优势。

解决方案

以太坊是一个部署和运行 DApp 的后端程序——智能合约(Smart Contracts)的去中心化平台。它提供了专门面向合约的编程语言 Solidity 和运行合约的虚拟机(EVM)实现,得益于其周边的开源生态,很多开源工具,如Truffle, Ganache, MetaMask, MyEtherWallet 也让编写和部署智能合约变得更加方便。同时,以太坊还维护了多条测试链,如:Ropsten, Kovan 和 Rinbkey 辅助开发者测试合约,从而减少部署到主网的风险。

解读

以太坊的强大之处在于它不仅内置了可用于转账的以太币,还围绕以太币构建了部署和运行智能合约的去中心化平台。智能合约就是一个“高度权威”的中间机构,任何人都可以利用智能合约定下“如果…那么…”的交易条款,然后把交易中的钱财用以太币的形式存入其中。一旦预设条件满足,合约就会自动执行,比如:把合约中的以太币打给交易的某一方。

有了智能合约,我们甚至可以在一个没有淘宝这种电商平台的情况下,和陌生的个体商户做买卖!

商家发布了一个买卖合约。合约里说(详细见下图):

  1. 商家有一件商品价值1块钱,顾客想要购买,需要往合约里存入1块钱
  2. 商家确认合约里有1块钱之后就会发货
  3. 然后顾客确认收货之后,合约自动把这1块钱打给商家

如果你以为这就能达成交易,就too young too simple。 因为客户往合约里存入1块钱之后,如果商家没有发货,那么合约中规定的流程就没法继续下去,顾客也没法从合约中取出这1块钱。所以只要顾客不傻,他就不会打进去这1块钱,这次交易不可能完成。

商家可以这样改良买卖合约。合约里说(详细见下图):

  1. 商家先往合约里存入1块钱,证明自己有价值1块钱的商品
  2. 顾客想要购买,需要得往合约里存入2块钱(想想为什么不能是1块钱?)
  3. 商家确认合约里有3块钱之后就会发货
  4. 然后顾客确认收货之后,合约自动把3块钱中的2块钱打给商家
  5. 合约剩余的1块钱还给顾客

通过这个例子,我们很惊奇地发现,在智能合约的辅助下,两个陌生人在没有中间人担保的情况下也可以完成一笔买卖的。

相关Blip

延展阅读

支持工具

Share

Service mesh 服务网格 | 雷达哔哔哔

位置

2018年11月第19期技术雷达,技术象限,建议评估。(最新版技术雷达已经发布,点击这里下载

标签

Microservices,linkerd,Istio

目标受众

系统架构师、开发人员

关注问题

目前的微服务架构大多基于类似于Spring Cloud全家桶的框架构建,尽管这样可以基本满足构建微服务系统架构在技术上的一些基础需求,例如常见的服务发现、配置管理、熔断、跟踪,安全等。但是也同样也带来了一些限制和成本,例如对于代码的侵入性较强、编程语言绑定、学习成本高等。

解决方案

将解决分布式架构下安全、熔断、限流、降级、服务发现、调用链分布式跟踪等功能从业务服务中彻底分离,打包放到Sidecar(边车)中,并挂接到服务上,实现业务逻辑部分与微服务技术架构部分的完全解耦。

解读

近几年微服务热度不减,而构建微服务架构一般要解决两个问题,一个是业务服务划分的问题,一个就是微服务基础技术架构的问题。

在技术架构层面,目前业界可选的通用方案也不多。在Java阵营目前相对主流的方案就是基于Spring Boot+Spring Cloud+Kubernetes来构建微服务基础架构,并辅以ELK,Zipkin,Swagger,Prometheus,Grafana等工具做一些运维监控的工作。

这样虽然可以满足我们在微服务架构(本质上就是一个松耦合的分布式架构)上的一些技术要求,但是也同样也带来了一些新的问题,例如上文提到的代码侵入性强,耦合高,开源框架拼接导致的技术学习成本高,协调配合需要打磨等。

Service Mesh(服务网格)的产生就是为了解决这个问题,而遵循的还是软件行业那句古老的谚语:

“任何软件工程遇到的问题都可以通过增加一个中间层来解决”

Service Mesh就是添加了这么一个中间层,并给他起了个形象的名字:Sidecar。

图片来源于架构之路微信公众号,请参见延展阅读

区分出了这个Sidecar(边车),我们的服务就将精力更多的专注于自身的业务本身。而微服务架构下服务间通讯涉及的所有脏活儿、累活儿就都交给Sidecar去处理。Sidecar和服务是松耦合的,可以挂接上去,也可以分离开。只要接口匹配,对于业务服务完全无侵入,无语言绑定。

Sidecar就像一个一个“助理”一样兢兢业业,而服务则享受老板的待遇,什么事只需要跟Sidecar交代一下,其他就不用管了,而Sidecar也只能通过其他服务的Sidecar与服务交互。 Sidecar之间相互通信,就形成了一张“网格”,这也是服务网格名字的寓意。

图片来源于架构之路微信公众号,请参见延展阅读

是的,Service Mesh添加的这一新的层次,就是我们一直在苦苦追寻的“微服务基础设施层”。这层的沉淀和浮现,让程序员的关注层次又上升了一个抽象,离业务也更近了一步。

顺手抛出个观点:软件开发的演进就是我们程序员所写的程序逐渐靠近业务本身的过程。

其他该抽象的抽象,该沉淀的沉淀:包括操作系统,编译器,开发语言,声明式编程,DSL,各种框架工具,ServiceMesh都是在做这些非业务部分的抽象和沉淀而已。

那再下一步会是什么?按照我上面的观点,目前来看一个很有竞争力的选手就是Serverless architecture,以后我们有机会再聊:)

相关Blip

延展阅读

支持工具

Share

Event streaming as the source of truth——历史永铭记、时间任穿梭 | 雷达哔哔哔

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(第十九期雷达已发布,可至官网下载

一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第六篇,依然关注架构,Blip是Event streaming as the source of truth

位置

2018年5月第18期技术雷达,技术象限,建议评估

标签

Kafka,Event Sourcing,ETL,Integration

目标受众

系统架构师

关注问题

在以微服务架构为代表、分布式系统架构越来越成为主流的当下,“如何保证不同限界上下文中数据的一致性”一直是系统架构设计上的一个主要挑战。尤其是在只留存数据最终镜像(Snapshot)的数据持久化方案下。有没有一种方案可以让数据同步变得简单、可靠且可溯源可重建?这一直是系统架构师在思考和追寻的。

解决方案

将事件(Event)作为主数据源(Single source of truth),在上下文内则可以直接使用事件溯源(Event Sourcing)获取领域对象的最新数据快照,对外则可以直接使用类似于Kafka的工具通过事件的传递和广播进行不同上下文间的同样基于事件溯源(Event Sourcing)的数据同步和转换(ETL)。

解读

可能很多同学看到上述的问题描述和解决方案后,还没看到这就儿就已经走了……

这其实也可以理解,太多术语让人不知所云。什么Event、Sourcing、Source of Truth、Snapshot,感觉这些词就是为了架构师彰显身份创造的……

其实吧,很简单,我们做个比喻大家就都清楚了。就拿大家熟悉的Git举例子,Git就是一个就是基于事件(Commit)和事件溯源(Commit Chain)的好例子:

假设你有一份你的代码(数据),我有一份我的代码(数据),两份代码处理不同的事情。突然有一天我发现你的代码(数据)其中有一块我也能用,在通过一通“亲切友好”的沟(暴)通(揍)后,我把你的最新代码直接拷贝过来,放到了我的代码库里,并定时拷贝这块最新的代码过来,这就叫做同步(Synchronizing)。

后来我发现你的代码和我的代码还有一些不匹配,很多逻辑我并不用,只需要很少一部分,而且还得修改一下才能与我的代码对接,这就叫做ETL(Extract-Transform-Load)。

作为一个有追求的程序员,我为这个拷贝转换的过程(ETL)写了个程序,每天早上7点工作前自动完成。但是这就引入了一个新的问题,这个程序经常出问题(不要问我为什么……),导致我的代码(数据)和你的最新代码(数据)不一致,我需要知道我最新的代码是哪一次同步的、是否完整,以及如何重新同步代码到最新,这个过程就叫溯源(Sourcing)和重建(Rebuild)。

随着我同步的代码(数据)越来越多,如何保证这些来自不同源的代码(数据)始终保持时间一致性,可溯源,可重建就慢慢成为一件比较难的事情,也就是我上面提到的这个Blip关注的问题。

在代码拷贝这个场景里,Git给我们提供了另一种解决问题的思路。即我们不再保存我们的代码在某一个时间点的完整代码即代码镜像(Snapshot),而只是保存Commit信息,而一个Commit可以理解成就是一个事件(Event)。当我们需要最新代码的时候,不是从代码库里直接复制出最新的完整的代码版本,而是通过Commit链,从头开始将一个一个Commmit Apply到一起,最终形成了代码最新的样子,这个过程就叫做事件溯源(Event Souring),这样我们不仅记录了某个时刻的数据,而且记录了整个历史!

Event streaming as the source of truth,所描述的就是将这种基于Event存储方案应用于我们的系统数据管理,即用存储Event来代替存储数据现状快照,这样我们就可以基于Event和Event Souring处理数据的同时,大大简化和增强不同上下文数据同步的能力。

也就具备了Git般的威力,可以在数据的历史中穿梭,可以基于某个时间点做不同数据源的一致性同步,可以溯源,可以回滚,可以重建。而数据同步也会像Fork,Fetch,Merge一样简单。

相关Blip

支持工具

延展阅读


更多精彩洞见,请关注微信公众号:思特沃克

Share

Autonomous bubble pattern | 雷达哔哔哔

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(第十九期雷达已发布,可至官网下载

一直以来,我们都未对每一个Blip做进一步的解读,而这次决定尝试一个新的专栏——《雷达哔哔哔》,由作者根据自己实践与理解,对雷达中部分条目作出解析,致力于用一篇篇短小精悍的文字,帮助读者加深对雷达的理解。

今天是《雷达哔哔哔》的第四篇,依然关注架构,Blip是Autonomous bubble pattern

位置

2018年5月第18期技术雷达,技术象限,建议试验

标签

遗留系统、DDD、Bounded Context、ACL、Eric Evans

目标受众

系统架构师

关注问题

如何在遗留系统上继续保持构建新功能的能力,不受自身的限制与拖累,可以采用全新的架构甚至工程方法,同时保持相对独立的快速演进?

解决方案:

将新的功能和能力封装到新的独立上下文中,建立独立且完全自主控制的数据存储,采用同步的机制保证与其他上下文的数据一致性,形成完整独立的Autonomous bubble,用同步复杂性换取上下文完整性。

解读

之前在介绍Architectural fitness function时,我们谈到无论一个系统初建时多么新潮且纯粹,都会随着时间的洗礼,慢慢成熟,慢慢衰老,就像我在《技术的一生》中描述的场景一样。

碰到这种情况,我们通常会首先想到推倒重建,希望可以重回初生时的美好。但往往斥重金重建系统、短暂享受重获新生的喜悦之后,依然无法逃离时间和需求的侵浊,再一次走向衰老,成为另一个崭新的遗留系统。

有没有两全其美的方法,既能保持对于遗留系统足够敬畏,不用花费大量成本冒风险重建;又能应用新的技术和架构甚至工程方法为系统构建新的功能和能力,在老树上开出“新花”?

我们发现DDD(Domain-Driven Design)的作者Eric Evans早在2012年就提出的一种叫做Autonomous bubble pattern(自治气泡模式)的模式,对于解决这样的问题越来越有其用武之地。

这种模式乍一看,并无新奇之处,无非就是为新的功能或是应用创建一个新的限界上下文(Bounded Context),在新的上下文里采用全新的设计,并通过Anticorruption Layer(ACL:防腐层)匹配旧的遗留系统而已,常见的应用场景就像Eric Evans在视频中展示的一样:

但Eric Evans提出的Autonomous bubble pattern并不止于此。 精妙之处在于,他提出了另一种看似更复杂的解决方式,即为新的上下文提供完整的数据存储能力。并通过同步(Synchronizing)的方式保持新的上下文与遗留系统中的数据一致性,如下图。

Eric Evans在视频中也坦言,这种方式相比与第一个方案会更加“昂贵”,需要一些额外的工作来处理开发者们最为头疼的“同步”问题。

但我们认为由此带来的“上下文自主性”和“对于开发摩擦力(development friction)的减少”,是迈向现代化甚至未来架构的第一步,也是重要且勇敢的一步。

支持工具:

DDD

延展阅读:


更多精彩洞见,请关注微信公众号:思特沃克

Share

技术雷达第十九期正式发布,用百余个条目更新你的技能图谱!

ThoughtWorks每年都会出品两期技术雷达,这是一份关于技术趋势的报告,由ThoughtWorks 技术战略委员会(TAB)经由多番正式讨论给出,它以独特的雷达形式对各类最新技术的成熟度进行评估并给出建议,为从程序员到CTO的利益相关者提供参考。

它比那些我们能在市面上见到的其他技术行情和预测报告更加具体、更具可操作性,因为它不仅涉及到新技术大趋势,更有细致到类库和工具的推荐和评论,因此更容易落地。经过半年的追踪与沉淀,ThoughtWorks TAB(ThoughtWorks技术咨询委员会)根据我们在多个行业中的实践案例,为技术者产出了第十九期技术雷达,对百余个技术条目进行分析,阐述它们目前的成熟度,并提供了相应的技术选型建议。

本期主题

粘性十足的云平台

云提供商知道他们正在严峻的市场中进行竞争。为了获胜,他们需要吸引用户注册并长期留住他们。因此,为了保持竞争力,他们在新增产品特性上你争我抢,使得彼此不相上下。这一点可以从本期雷达试验环中以下云提供商的排名看出: AWS、 Google Cloud Platform 和 Azure 。然而,一旦用户注册,这些云提供商就倾向于与用户建立尽可能高的粘性,以阻止他们使用其他提供商的服务。这通常表现为其云服务会与其服务和工具套件紧密集成。用户只有继续使用其云服务,才能获得更好的开发者体验。通常在用户决定是否将其部分或全部工作负载移动到另一朵云上,或发现云服务的使用和账单多到失控时,就能明显感觉到这种粘性。我们鼓励客户使用 架构适应度函数度量成本 的技术来监控运维成本,并将其作为衡量云供应商粘性的指标。或者使用Kubernetes和容器,并通过运用基础设施即代码来提升工作负载的可移植性,降低切换到另一个云提供商的成本。在本期雷达中,我们还会介绍两个新的云基础设施自动化工具:Terragrunt和Pulumi。虽然我们支持通过粘性的高低来评估云提供商的新产品,但提醒你不要落入只使用通用云服务功能的陷阱。根据我们的经验,创建和维护与云无关的抽象层的开销,会超出退出某个特定云提供商的花费。

挥之不去的企业级应用反模式

无论技术如何快速变化,一些企业仍然想方设法地重新实现过去的反模式。雷达中的许多暂缓条目都在揭穿一些“新瓶装旧酒”的老把戏。比如:用Kafka重新创建ESB的反模式、分层式微服务架构、Data-hungry packages、过度庞大的API网关、Low-code 平台和一些其他有害的旧实践。一如既往的根本问题,是如何在隔离和耦合之间取得平衡:我们隔离组件,使其在技术角度便于管理。但是我们也需要协调组件,使其有助于解决业务问题。这就产生了某种形式的耦合。因此,上述旧模式就不断重新冒出来。新的架构和工具为解决这些问题提供了适当的方法,但这需要刻意去理解如何正确地使用它们,而不仅仅是使用崭新的技术去重新实现旧模式。

持之以恒的工程实践

随着技术创新步伐加快,新技术的发展呈现出一种从爆发到沉淀不断循环的模式。每当能够颠覆我们对软件开发固有认知的新技术出现时,都会引起业界的争相追捧,容器化、响应式前端和机器学习都是很好的例子。这时技术处在爆发阶段。然而,只有在明确如何与长期以来的工程实践(持续交付、测试、协作等)相结合之后,新技术才能真正的发挥功效,并进入沉淀阶段,为下一次爆发性扩张打下坚实的基础。在沉淀阶段,我们尝试在新技术的背景下应用实践,比如进行全面的自动化测试以及创建脚本代替重复操作,通常也会创造出新的开发工具。虽然表面看来技术创新是行业发展的唯一驱动力,但事实上,创新与持之以恒的工程实践相结合才是我们不断进步的基础。

速度 = 距离 / 时间

通常,我们会选取本期雷达中部分共性条目的精彩集锦展现在雷达主题中,但本主题涉及自技术雷达诞生以来出现过的所有条目。我们发现(并通过一些调研证明)雷达条目停留在雷达上的时间正在缩减。当我们在10年前启动技术雷达时,如果某个条目在雷达上的位置不再移动,它依然会保留两期(大约一年)时间,之后才会自动移出雷达。然而正如标题中的公式所说,速度 = 距离 / 时间: 软件开发生态系统中的变化一直在持续加速。在时间保持不变(依然是每年发布两次)的前提下,雷达中技术创新所跨越的距离明显地增大了。这为精明的读者提供了显著的证据:技术变革的步伐正在不断加快。我们不仅看到雷达中的各个象限在加速变化,也看到了客户对新兴的及多样化的技术选择所表现出的兴趣。因此我们将改变传统的默认模式:雷达不再默认保留其上的条目,它们是否出现在雷达上完全取决于它们当前的价值。我们在深思熟虑后做出了这项改变,并认为只有这样才能更好地跟上技术生态系统中前所未有的狂热变化节奏。

象限亮点抢先看

Event Storming(事件风暴)

快速市场响应能力是组织进行微服务转型的主要驱动之一。然而只有沿长期业务领域边界对服务(及其支持团队)进行清晰划分时,这种期望才可能实现。否则,现实需求只有在跨组织和跨服务的通力合作才下能完成,这自然会在规划产品路线图时产生冲突。良好的领域模型设计是解决此问题的方案,事件风暴(EVENT STORMING)也迅速成为我们最喜爱的方法之一,它使我们能够迅速识别问题领域中的关键概念,并用最好的方式与各方利益相关人制定解决方案。

Microservice Envy

微服务已成为现代云计算系统中的领先的架构模式,但我们依旧认为团队在使用该架构时应谨慎。 MICROSERVICE ENVY特指那些盲目追赶微服务潮流的现象,很多团队在实践微服务时并没有简化其系统架构,大多数的实践方案只是将一些简单的服务聚合在一起而已。目前,Kubernetes等平台简化了复杂的微服务系统的部署问题,其他服务提供商们也正在推进他们的微服务治理方案,这些强大的工具都可能裹挟团队走上微服务之路。 但请千万谨记,微服务是通过开发复杂度来换取运维复杂度,并需要自动化测试、持续交付和DevOps文化提供坚实的支撑。

Observability as Code(可观测性即代码)

可观测性是运转分布式系统与微服务架构必不可少的一部分。我们依赖不同的系统输出来推断分布式组件的内部状态,比如分布式追踪、日志聚合、系统指标等,进而诊断问题所在,并找到根本原因。可观测性生态系统的一个重要方面就是监控——可视化以及分析系统的输出——并且在检测到异常时报警。传统的监控报警配置,都是通过图形界面的操作完成。这种方法导致控制面板页的配置不可重复,从而无法持续测试和调整报警,来避免报警疲劳或错过重要的报警,进而偏离组织的最佳实践。我们强烈建议使用代码来配置可观测性生态系统,称为可观测性即代码(OBSERVABILITY AS CODE),并且采取基础设施即代码的方式搭建其基础设施。因此,在选择提供可观测性的工具时,要选择支持通过代码版本控制进行配置,并能通过基础设施持续交付流水线执行API或命令行的产品。可观测性即代码,是基础设施即代码中经常被遗漏的一部分,我们认为这一点非常重要,需要明确指出。

Four key metrics(四个关键指标)

2014年首次发布的DevOps状态报告指出,高效团队创造了高效的组织。最近,该报告背后的团队编写了Accelerate一书,描述了他们在报告中使用的科学方法。两份材料的核心点都支持了软件交付性能的四个关键指标(FOUR KEY METRICS):前置时间,部署频率,平均恢复时间(MTTR)和变更失败百分比。作为帮助许多组织转型的咨询公司,反复使用这些指标测量,可以帮助组织确定他们是否在提高整体效能。每个指标都创造了一个良性循环,并使团队专注于持续改进:缩短交付周期,减少浪费的活动,从而使你可以更频繁地部署;部署频率迫使你的团队改进他们的实践和自动化流程;通过更好的实践,自动化和监控可以提高你从故障中恢复的速度,从而降低故障频率。

Run cost as architecture fitness function(架构适应度函数)

随着软件架构及其业务的演进,我们理应密切关注应用的运行成本,但发现并非所有的组织都如此。尤其是在使用无服务器架构时,开发者们认为无服务器架构会更便宜,因为他们只需按消耗的计算时间付费。然而几家主要的云服务提供商在热门的无服务器函数上定价十分精明,虽然无服务器在快速迭代上很有优势,但与专属云(或内部私有云)相比,它的开销可能随着使用量迅速增长。我们建议团队将应用的运行成本纳入架构适应度函数(RUN COST AS ARCHITECTURE FITNESS FUNCTION)来考量,这意味着:追踪并权衡应用的运行成本与交付价值;当它们之间产生较大出入时,就需要考虑改进软件架构了。

Debezium

DEBEZIUM是一个change data capture (CDC)平台,可以将数据库的变更以流的形式传入 Kafka 主题中。CDC是一种流行的技术,具有多个使用场景,包括将数据复制到其他数据库中,为分析系统提供数据,从单块系统中提取微服务,以及令缓存数据无效等。我们一直在寻找这个领域的工具或平台(包括在之前的技术雷达中讨论过的 Bottled Water),而Debezium 是一个极佳的选择。它使用了基于日志的CDC方法,意味着能以对数据库日志文件的变更进行响应的方式进行工作。Debezium使用了Kafka连接,这使得它具有高度的容量伸缩性,以及对故障的系统韧性。它拥有包括Postgres、Mysql和MongoDB在内的多个数据库的CDC连接器。目前,我们正在一些项目上使用该平台,并取得了很好的效果。

Quorum

在区块链技术领域,Ethereum(以太坊)是一个领先的开发者生态系统。我们看到了一些新兴的解决方案,它们旨在将Ethereum这项技术传播到一些企业环境中。这些企业通常需要网络权限和交易隐私管理,另外还需要更高的吞吐量和更低的延迟。 QUORUM 就是其中的一个解 决方案。Quorum最初由J.P. Morgan开发,其定位是“企业版的Ethereum”。与创建了新的以太坊虚拟机(EVM)的Hyperledger Burrow 节点不同,Quorum的代码源自以太坊官方客户端的一个分支,所以能与以太坊一起进化。在保留了以太坊账本的大多数功能的前提下,Quorum将共识协议从工作量证明机制更改为更高效的协议,并增加了私有交易支持。使用Quorum,开发人员可以使用他们的以太坊知识来构建企业级的区块链应用,这些知识包括 Solidity语言和 Truffle 合约。然而根据我们的经验,Quorum还没有为应用于企业做好充足的准备;比如:它缺乏针对私有合约的访问控制机制,无法用于负载均衡,并且只支持部分数据库。所有的这些限制都为用户的部署与设计带来显著的负担。我们建议在使用Quorum的时候保持警惕,同时密切关注它的后续发展。

IPFS

在多数情况下,区块链不适合存储 blob 文件 (例如:图像,音频),当人们开发 DApp 时,一种选择是将blob文件存放在一些链下的集中式数据存储中,这种做法通常会导致信任缺失,另一种选择是将它们存储在星际文件系统 IPFS上,这是一种内容可寻址、版本化、点对点的文件系统。它旨在高效地分发大规模数据,并能阻止任何中心化机构删除数据,文件存储在不需要相互信任的对等节点上。IPFS 保存文件的每一个版本,这样你将永远不会丢失重要文件,我们将IPFS视为区块链技术的好的补充。除了区块链应用程序外,IPFS还有一个愿景是对现有的网络基础设施进行去中心化重塑。

Resin.io

RESIN.IO 是一个物联网(IoT)平台。虽然只做把容器部署到设备中这一件事,但它做得很好。开发人员使用一个软件即服务( SaaS)的门户来管理设备,并为这些设备分发由 Dockerfile 定义的应用。该平台可以为多种硬件类型构建容器,并通过无线的方式部署容器镜像。Resin.io 使用balena 来管理容器。而balena是一个基于 Mobby 框架的容器引擎,由Docker 出品。该平台仍在开发中,有些功能尚需完善,也缺少一些特性(比如与私有容器注册服务协同工作)。但是目前的特性集(包括从 Web 门户使用 ssh 访问一 个设备上的容器)表明它的未来充满希望。

Knative

作为应用开发者,我们喜欢专心解决核心业务问题,而让底层平台来处理那些枯燥且困难的任务(如部署、容量伸缩及应用程序管理)。虽然无服务器架构往这个方向迈出了一步,然而大多数流行的产品都会与某个专有实现绑在一起。而这意味着供应商绑定。KNATIVE试图以开源无服务器平台的方式来解决此问题。它良好地集成了流行的Kubernetes生态系统。利用 Knative ,可以对随时请求的计算进行建模(其间可以从一些框架中进行选择,如 Ruby on Rails、Django和Spring 等),可以订阅、交付和管理事件,可以集成用户所熟悉的 CI和CD 工具,可以从源代码构建出容器。该平台提供一组中间件组件,来构建以源代码为中心且基于容器(能够实现资源伸缩性)的应用。这使得它成为一个颇有吸引力的平台,当有无服务器需求时,值得对其进行评估。

Apache Atlas

随着企业数据需求的不断增长和多样化,对元数据管理的需求也在不断地增长。APACHE ATLAS 是一款用于满足企业数据治理需求的元数据管理框架。Atlas支持元数据类型建模、数据资产分类、数据来源追踪和数据发现。但是,在搭建元数据管理平台的时候,我们也必须小心避免重蹈主数据管理的覆辙。

Cypress

运行端到端测试时经常会遇到一些棘手的问题,比如运行时间过长,测试过于零碎,还需要修复无头模式下运行的测试所导致的 CI 失败。我们的团队借助 CYPRESS 很好地解决了性能差、响应时间长、资源加载慢等常见问题。Cypress 是一款很有用的工具,可以帮助开发者构建端到端测试,还可以将所有测试步骤保存为 MP4 视频,便于检查错误。

VS Live Share

VISUAL STUDIO CODE 是微软推出的免费 IDE 编辑器,可以跨平台使用。我们曾用它同时进行前端 React、TypeScript 和后端 GoLang 的开发,而无需在不同的编辑器之间切换,体验很好。 Visual Studio Code 中的工具、语言支持和扩展插件数量都在迅猛增长,也越来越好用。我们要特别推荐在实时协作及远程结对编程时使用 VS Live Share 。固然微软或 Jetbrains 成熟的 IDE 对使用静态类型语言(如 Java 、 .NET 或 C++ )的复杂项目支持得更好,但我们也发现 Visual Studio Code 正逐渐成为基础设施开发组和前端开发组的首选工具。

Stanford CoreNLP

越来越多的项目需要处理非结构化的数据,而从文本中提取出有意义的业务信息是一项关键技术。 STANFORD CORENLP 是一组基于 Java 的自然语言处理(NLP)工具集,支持英语、汉语和阿拉伯语等多种语言的命名实体识别、关系抽取、情感分析与文本分类,也提供了用于标记语料库和训练模型的工具。 Stanford CoreNLP 协助我们使用NLP 领域的最新研究成果来解决各种业务问题。

LocalStack

使用云服务时面对的一个挑战是如何在本地进行开发和测试。 LOCALSTACK 为 AWS 解决了这个问题。它提供了各种 AWS 服务的本地 测试替身 实现,包括 S3 、 Kinesis 、Dynamodb 和 Lambda 等。它基于现有的最佳工具如Kinesalite 、 Dynalite 、 Moto 等构建,并增加了进程隔离与错误注入的功能。 LocalStack 的使用很简单,并附带了一个简单的 JUnit 运行器以及 JUnit 5扩展。我们在一些项目中使用过 LocalStack ,并对它印象深刻。

Bitrise

构建、测试和部署移动应用,尤其是由一条流水线从代码仓库打通到应用商店的时候,会涉及许多复杂的步骤。虽然这些步骤可以由脚本或普通 CI/CD 工具提供的流水线自动完成,但对于专注移动应用开发,而不需要与后端的构建流水线做集成的小组来说,使用专用工具可以降低复杂度和维护开销。 BITRISE 配置简单,并预置了一组完整的步骤,可以满足绝大多数移动应用开发所需。

PredictionIO

PREDICTIONIO 是开源的机器学习服务框架。无论是普通开发者还是数据科学家,都可以利用它创建用于预测的智能应用。和所有其他智能应用类似,PredictionIO 由三个部分组成:数据收集和存储、模型训练以及模型部署和服务暴露。开发者只需要基于它提供的相应接口实现数据处理逻辑、模型算法和预测逻辑,无需在诸如存储数据以及训练模型之类的事情上投入额外精力。从我们的经验来看,在不要求高并发处理的情况下,PredictionIO 能支持不同大小的数据集。大多数时候我们使用 PredictionIO 来为中小企业构建预测类智能服务,或者在构建复杂定制化预测引擎的过程中进行概念验证。

Q#

量子计算目前已经可供测试,但何时真正到来尚未明确。在硬件到位之前,我们已经可以通过语言和模拟器来实验和学习它。尽管IBM等公司已经取得了不错的进展,我们对微软在 Q# 语言及其模拟器(本地32量子比特,Azure云上40量子比特)方面的工作更加关注。如果你想开始了解这项编程的前景,请查看他们在 GitHub 上的范例。

MockK

MOCKK 是用 Kotlin 编写的模拟库。它的核心理念是像 Coroutines 和 Lambda 表达式一样,为 Kotlin 提供一等公民级别的语言特性支持。不同于 Mockito 或PowerMock 的蹩脚封装,作为原生的开发库,它能帮助开发团队在测试 Kotlin 应用时编写干净、简洁的代码。

WebFlux

Spring Framework 5 已发布一年有余,它采用了响应式流 —— 一套非阻塞背压(backpressure)式异步流式处理标准。在传统的 Spring MVC 模块之外,WEBFLUX 为在 Spring 生态下编写 Web 应用提供了一个响应式替代品。经过一系列应用的试用,WebFlux 给我们的团队留下了深刻的印象,并汇报说这种响应式(函数式)实现增强了代码的可读性和系统的吞吐量。但他们也确实注意到,采用 WebFlux 需要在思维方式上做出一些重大转变,建议在WebFlux vs. Spring MVC 的技术选型中考虑这一点。

Jepsen

随着 微服务 架构越来越多地被采用,相比以前,我们构建了更多的分布式应用程序。尽管解耦架构带来了许多好处,但证明整个系统正确性所需的工作量和复杂程度正急剧增加。 JEPSEN 提供了许多我们所需要的工具,来帮助我们验证协调任务调度程序的正确性,测试分布式数据库的最终一致性、 线性一致性 ( Linearizability)和 可串行性(Serializability)。我们在一些项目中使用了 Jepsen,令人惊喜的是,我们可以测试驱动配置,注入和修复故障,验证系统恢复后的状态。


以上是我们在最新一卷技术雷达中随机摘取的几个Blip,欲获取整版技术雷达,请点击技术雷达官方网站进行下载!

Share