Corda – 为了商业而设计的区块链平台

位置

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

标签

Blockchain,DLT

目标受众

区块链架构师,开发人员

关注问题

区块链技术允许不同组织之间直接达成没有中间人参与的交易,这大大提高了交易的效率。但是“传统”区块链平台要求所有用户复制所有交易,这带来了大量的重复和浪费,性能很难满足现实商业世界的要求,另外,尽管有加密技术存在,大家依然担心数据的隐私性是否能够得到足够保证。

解决方案

Corda 在继承了区块链点对点网络的基础上,将网络区分为不同的兼容区(compatility zone),每个兼容区内可以部署不同的智能合约(smart contract),同时辅以可插拔的共识机制(pluggable consensus),以便针对不同类型的应用对共识算法进行优化。同时,在交易数据的存储上,作为联盟链的 Corda 采用了每个节点只需存储与自己参与或需要知道的数据,全网共识由兼容区内的公证人(Notary)节点集群来保证。

解读

随着区块链热度的逐渐消退,公众对于区块链技术的看法逐渐趋于理性,依然对区块链技术保持热忱的人们开始思考区块链究竟能带来怎样的商业价值,这就要求各大区块链平台针对普及区块链遇到的阻力提供解决方案。Corda 作为其中的一员,将关注点投入在如下几个方面:

  • 隐私性(privacy)
  • 交易可终结性(transaction finality)
  • 参与方身份认证(legally identified parties)
  • 可扩展性(ability to scale)
  • 开发者效率和企业级集成(developer productivity and enterprise integration)

隐私性

将我所有的交易数据发布到所有节点(包括竞争对手)?任何一位企业管理者在听到这样的提案时都没法坦然接受这样的技术“革命”吧?更何况很多行业还面临着合规性审计的压力。

Corda 选择只让交易相关方存储交易数据。如何阻止“双花”(double spend)?交给公证人节点吧。

交易可终结性

什么?我付了钱还要等6个区块才能确认交易达成?还会分叉?那交易到底是发生了还是没发生?我的交易是薛定谔的猫吗?

别担心,Corda 将网络分为不同的兼容区,并允许在每个兼容区内自主配置共识算法,以帮助兼容区内的节点以最快速度达成共识。

参与方身份认证

公有链每个客户端和节点都不需要使用物理世界中真实存在的身份进行交易,而对于真实商业世界中的交易,我的交易对手方对我考虑一笔交易至关重要。Corda 作为联盟链,使用业界已经比较成熟的 X509 证书为每个节点提供身份。

可扩展性

区块链平台主要的性能瓶颈在于处理每笔交易并达成共识的过程中,这里存在着巨大的网络开销和计算工作。

Corda 根据承载业务的不同将网络划分为不同的兼容区,每个兼容区内节点数量更少,性能要求更低;同时,Corda 选择将达成共识的职责与账本层解耦,由公证人节点负责达成共识;每个兼容区可以根据节点数量和所承载的业务自主选择更佳合适的共识算法,让 Corda 可以满足真实商业需求的性能需求。

开发者效率和企业级集成

Corda 选择了已经发展成熟 JVM 平台以及 Kotlin 语言作为开发工具,关系型数据库作为数据存储。大部分企业的 IT 部门早已经在这些领域驾轻就熟,大大降低了企业拥抱新技术的技术切换成本。

相关 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

ArchUnit

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(参考阅读:解读技术雷达的正确姿势

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

今天是《雷达哔哔哔》的第三篇,依然关注架构,Blip是ArchUnit

位置

2018年11月第19期技术雷达,工具象限,建议试验

目标受众:

系统架构师,技术管理者,开发人员

关注问题:

  • 如何在Java系统架构下,应用架构适应度函数(Architectural fitness function)来驱动架构演进?
  • 如何在Java系统架构下,做系统演进后架构守护,减缓系统再次腐化?

解读:

在上一期我们介绍了架构适应度函数(Architectural fitness function),也提到了ArchUnit,这期就来详细介绍一下。

ArchUnit是用来检查架构特征的Java测试库,比如包与类的依赖关系、注解、甚至是调用层级一致性。它可以附加在现有的测试方案中,以单元测试的方式运行,但目前只能用于Java架构。

ArchUnit测试套件可以合并到持续集成环境及部署流水线中,使我们可以更容易地利用架构适应度函数实现演进式架构。我们来看看ArchUnit都能做些什么:

  • Package Dependency Checks

  • Class Dependency Checks

  • Class and Package Containment Checks

  • Inheritance Checks

  • Annotation Checks

  • Layer Checks

  • Cycle Checks

想要了解更多,可以移步【官方用户指南】

最后不得不说一下,架构优劣不取决于是否遵循某一个标准,而是应该取决于能否支撑业务的需要。约束越强,灵活度越低,架构就会越加僵硬,缺少适应性,产生冗余。

所以工具本身只是赋予了我们约束架构的能力。但是能否正确地使用这种能力通过Fitness Function和演进式架构来促进架构对于业务的匹配度和适应度;还是截然相反的错误地滥用这种能力成为所谓的管理手段或是技术上的噱头,最终导致系统架构僵化,无法支撑业务需要,决定权还是在我们架构师手中。

不要过度神话工具,也不要让工具替我们背锅,工具只是工具,工具本身没有对错。

工具:

ArchUnit

延展阅读:

👇👇👇订阅最新期技术雷达

Share

Lightweight Architecture Decision Records | 雷达哔哔哔

写在前面

ThoughtWorks每年都会出品两期技术雷达,这是一份关于科技行业的技术趋势报告,在四个象限:技术、平台、工具以及语言和框架对每一个条目(Blip)做采用、试验、评估、暂缓的建议。(参考阅读:解读技术雷达的正确姿势

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

今天是《雷达哔哔哔》的第一篇,Blip是Lightweight Architecture Decision Records

位置

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

目标受众:

  • 系统架构师,技术管理者,开发设计人员

关注问题:

  • 传统的重文档编写维护量大,随着业务发展,很难保持同步
  • 在一些敏捷项目中,随着关键文档的缺失、项目Knowledge及决策丢失导致长生命周期的项目知识传递问题

解决方案:

  • 使用“ Lightweight Architecture Decision Records”(轻量级架构决策记录)来记录项目的重要决策,并将其与代码等其他项目资产一样,纳入到版本控制系统之中。

解读:

“项目要不要写文档”一直是一个很有争议的问题。在过去,项目一般都要写众多的文档,类似于需求说明书、概要设计、详细设计、数据库设计、等balabala设计……而这些文档的作用往往只是为了【过评审】或是【招投标】,写文档的形式也更多是简单的复制粘贴。

项目拿下了,过审了,一旦开动起来,文档反而就被束之高阁,再也无人过问了。

很多人没日没夜地写着千篇一律的文档、文档、文档……终于有一天,盼来了敏捷,并看到了敏捷宣言中硕大的一句:

(敏捷宣言)

唉呀妈呀,终于见到了亲人,从此高举着敏捷的大旗,与文档势不两立。

再有人敢提起写文档,就把早已准备好的“敏捷大棒”从身后掏出来,劈头就是一棒槌……

不得不说,敏捷又一次背了口黑锅。敏捷宣言所推崇的并不是简单的不写文档,而是认为之前那种写文档的方式根本没有体现出其应有的价值。还 不如代码写的漂亮些,测试写的完备些,让代码和测试成为真正有价值的活文档。

而这,相对于简单的复制粘贴攒文档,对于团队的要求反而更高了。

世间万物,物极必反。

随着时间的推移,再好的敏捷团队也会出现知识流失的问题,尽管有着完备的测试和易读的代码,但这些毕竟过于细节,无法快速还原当时设计或重构时的所有上下文。

所以技术雷达推荐使用“ Lightweight Architecture Decision Records”来记录项目的重要决策,相比于传统文档,它最大的特点就是轻量(Lightweight),关注于创造价值而不是遵循流程。 让我们看个ADR的模板:

(ADR Template)

同时技术雷达也建议我们不要将ADR束之高阁、放到Wiki或是文档库中。而是随着代码放到Git或其他版本控制工具里,这样既可以保持最大程度与代码同步,又能跟踪Decision的变更历史。

推荐的Adr-Tools工具,可以帮助我们更容易的做到这些。

相关Blip及延展阅读:

工具:

GitHub – npryce/adr-tools: Command-line tools for working with Architecture Decision Records

Share

一个AR Tech Radar的诞生

什么是AR Tech Radar

技术雷达是ThoughtWorks每年出品两期的技术趋势报告,一般来说大家看到的雷达都是文档形式,其中有一张技术全景图,以及每个技术点的成熟度分析。而AR技术雷达就是在原始文档的基础上,利用AR技术将其立体化呈现,并在其中添加互动元素。

为什么要做AR Tech Radar

  1. 技术雷达一直以来都是文档的形式呈现,如果能通过包含在内的最新技术呈现出来,岂不是更能体现技术雷达的意义。同时也能增加技术雷达的交互和科技感。
  2. XR Community作为AR/VR等技术的探索者,AR技术雷达是我们社区内部产品的第一步尝试。
  3. 我们也不知道为什么,就是想做AR Tech Radar。

AR Tech Radar的技术选型

目前市面上能做AR的技术有很多,基本上每家大公司都有自己的AR技术。为什么我们会选择ARKit呢?(ARKit是苹果做AR软件开发的一个工具,使开发者能为iOS设备开发增强现实应用。)

之所以选择ARKit一个很重要的原因就是懒,只想选一个学习成本比较低的技术。

其实AR技术强依赖于承载它的硬件,所以选择AR技术其实就是在选择硬件平台。我们期望能使用一个广泛的平台,让AR技术雷达被更多的人接触到。目前AR硬件平台使用最广泛,也最容易让用户接触到的就是iOS,所以我们选择了ARKit。

其中还有一些其他的人气技术,比如:

  • ARCore,它是Google推出的运行在Android上的技术,但目前只有几款顶配的Android手机可以运行。
  • Hololens,它是微软的AR眼镜,购买成本较高,很难被普通用户接触到。
  • Unity,它支持iOS和Android跨平台。

那为什么我们没有选择在unity上进行AR开发,让它同时支持iOS和android呢?一个原因是ARKit和ARCore是才出来的新技术,它在unity上的兼容性和使用上肯定有很多未知的坑,我们期望使用比较稳定的平台。另外一个原因是,我们期望尝试用原生开发,以便更深刻的体验AR开发的过程。今后我们会尝试使用例如unity等工具进行开发,然后和原生开发做一个对比。

如何开发AR Tech Radar

准备

ARKit是苹果的技术,语言首选是Swift。 硬件需要支持ARKit的一台Mac和一部iOS设备。因为ARKit不支持模拟器运行,所以必须使用真机进行全程的开发调试。 开发软件是Xcode。

前期构想

做AR开发需要有两部分准备,一部分是本身的编程,另外一部分就是3D建模和空间相关的知识。编程不必多说,只要会Swift就能开始。3D建模不是我们的长项,所以前期我们做了很多调查,比如自己使用3D建模软件做一个雷达模型,或者去购买别人做好的雷达模型,或者外包给第三方公司做一个3D模型,再或者找会3D建模的同学加入我们。

但这些方案都被我们否决了,原因有很多,比如我们的经费有限,不能支持我们去找外包,也没有现成的模型给我们购买。而自己去学习3D建模的学习时间也长,同时也没找到会3D建模的同学。

因此我们决定用ARKit支持的形状来组合一个雷达。

我们曾经设想过很多次AR技术雷达应该长什么样。

比如罗马斗兽场的样子,让技术每层递进。

或者是一个圆球,人站在球里面,被周围的技术包围,大概像这样:

再或者,它应该是一个立在你面前的展台,技术雷达就摆在用户面前,大概像这样:

最终这些想法都被我们暂时搁置了,最主要的原因是我们没有能力和人手去实现那些炫酷的样子,并且我们觉得技术雷达就应该用它最朴素的样子展示给大家,应该被大家关注的是技术雷达的内容,而不是这个3D物体。所以最终我们决定用一个圆饼来展示技术雷达。

开发

首先,3D建模不是我们的长项,所以我们选用了ARKit支持的基本形状来组合出一个技术雷达的大饼。因此,我们使用了一个圆柱体和三个圆管,如下图。正中间是一个圆柱,用三个圆管把圆柱包围起来,就形成了雷达圆饼。

接着,为了让整个雷达看起来更立体,我们使用了圆球来作为每个技术的标示点,同时让标题浮在圆球的正上方。如下图。

我才不会告诉你,每个技术标示点在第一版的设计中是圆锥形的,看起来像雷达上的一坨坨屎。请看下图。

然后就是添加交互,让用户在点击某一个圆球的时候弹出它的具体阐述。就像下图一样。我们在圆球的正上方弹出一个半透明白板,并把标题和内容放在上面。 白板上的字不同于圆球上的标题,它是印在平面上的,而不像标题是3D立体的。因为大段的文字不适合全部做成3D立体的字,这对资源的消耗和3D的计算是很大的。所以我们利用3D纹理贴图,把文字描述贴到了白板上。

数据

最后就是如何添加数据,我们希望这个AR技术雷达能运用到每一年的技术雷达,这就要求我们添加进去的数据是支持更新的。

所以我们使用了一个单独的文件来存储每一期的所有技术,文件内容包含了所有技术相关的信息,比如名字、详细介绍、它所处的象限、它的分类等等。

这样的好处就是下一次的雷达技术出来之后,我们只需要更新这个独立的文件就可以看到最新的AR技术雷达了。

3D开发过程中遇到的困难与趣事

遇到的第一个奇葩事件就是,第一次我们添加了一个物体,可是在摄像头里面怎么都找不到,后来我们无意中把镜头对着天空突然发现那个物体在空中飘着。原因就是ARKit世界里面的尺寸是和现实世界一样的,单位是米,而我们的离地高度设的是3米,因此它就跑到空中去了。

另一个和这个是相似的,我们加了一个圆管放在地上,可是在地上怎么也找不到那个圆管。后来我们才发现,我们的圆管的尺寸太大了,把我们全部包在圆管里面了。

第三个有意思的事情是,我们添加了一个平面,上面写了一些东西,可是我们在镜头里面却怎么也找不到这个平面。通过各种debug和调查研究,才发现,我们在平面的背面,原来对于没有厚度的平面,只能在正面才能看得见。

还有一个比较棘手的问题就是,比如有些物体需要旋转两个90度再加上一些变换才能达到我们想要的位置。这对空间想象能力的要求就比较高,我们尝试了很多种旋转和变换,才最终找到了想要的位置。

未来的发展

我们期望AR技术雷达能发展成为每次技术雷达发布的官方AR应用,通过不同的途径和不同的体验让更多的人了解技术雷达,让人们能和技术雷达有一些有意义的互动。

所以未来我们期望能不断完善AR技术雷达,让它成为一个炫酷的、交互式很强的应用。

打开脑洞想象一下,通过使用AR技术雷达,你不仅可以看到每次更新的新技术、还能够通过一些交互直观的看到它的历史轨迹、应用场景以及具体实践,是不是一件很酷的事情?


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

Share