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

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

Architectural fitness function,架构你好我也好

写在前面

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

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

今天是《雷达哔哔哔》的第二篇,依然关注架构,Blip是Architectural fitness function

位置

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

目标受众:

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

关注问题:

技术架构腐化带来系统响应度降低,可维护性下降,技术债缠身。而盲目优化或是单纯的技术驱动的架构优化又常常偏离初衷,容易造成过度优化,不但没有解决之前的问题,还会引入新的问题。那如何度量技术架构的好与坏?如何拿捏技术架构演进的度?如何用目标驱动的方式做技术架构的持续演进?如何衡量技术架构演进的成果?如何进行架构守护?

解决方案:

通过识别架构演进度量指标,编写Architectural fitness function(适应度函数),以此量化及可视化系统架构演进效果,并通过持续反馈不断调整技术架构演进方向,避免架构演进脱离初始目标。

解读:

Architectural fitness function(适应度函数)借鉴自进化计算,被用来衡量方案对满足目标的适合度。

当定义演进式算法时,算法设计者会寻求更优解,而适应度函数则定义了在此上下文中“更优”的含义。

将适应度函数应用于软件架构,则为系统的架构演进提供了一个度量的目标,开启了“【目标(测试)驱动架构演进】”的新时代。 记住,如果你无法为系统演进、架构升级优化定义出度量的Metrics,并通过Fitness Function写一个测试来驱动和可视化你的架构演进成果。那就表明你还没有想清楚架构演进要解决的问题,就先不要开始!

《演进式架构》一书定义了架构适应度函数的概念,为衡量架构特征提供了一个客观全面的方法,包括已有的验证标准,比如单元测试、业务指标、监控等等。

感兴趣的可以了解一下。

工具:

ArchUnit:一个可以测试Java系统架构本身的测试工具,例如所有的Service只能被Controller或是Service调用的测试如下:

延展阅读


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

Share

2017年11月期技术雷达正式发布!

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

技术雷达的内容来自于 ThoughtWorks 的观察、对话以及在应对最令客户棘手的业务挑战时所沉淀下的一线经验,其中既包含现有技术,也包含新兴技术。技术雷达报告使用可视化的方式将技术趋势分为四组,分别涵盖技术、平台、工具和语言与框架,每个领域又进一步细分为暂缓、评估、试验或采用。


本期四大主题

崛起的中国开源软件市场

星星之火,已成燎原之势!在态度和政策发生转变之后,包括阿里巴巴和百度在内的众多大型中国企业正在积极发布开源框架、工具和平台。中国软件生态正伴随着经济扩张而加速成长。从这个巨大而繁荣的软件市场向 GitHub 等开源网站发布的开源项目的数量必将持续增多,质量也将持续提高。中国企业为何热衷于将他们的众多资产开源出来?与硅谷等其他活跃的软件市场一样,各个企业对开发人员的争夺十分激烈。紧紧提升薪酬水平是不够的,让聪明的开发者一起在最前沿的开源软件上共事才能够持续激励他们,这是一个放之四海而皆准的通则。我们预期主要的开源创意会继续保持 README 文件中先有中文版后有英文版的趋势。

容器编排首选Kubernetes

Kubernetes 及其在许多项目中逐渐增强的主导性推动了大量雷达条目的更新,以及更多的讨论。似乎软件开发生态系统正在 Kubernetes 及其相关工具的周边稳定发展,以解决有关部署、规模化和容器操作这些常见问题。诸如 GKE,Kops 和 Sonobuoy 这些雷达条目提供了托管平台服务和工具,以改善采用和运行 Kubernetes 的整体体验。事实上,它具备用一个调度单元来运行多个容器的能力,可以让服务网格(service mesh)和能够实现端点安全的 sidecar 得以实现。 Kubernetes已经成为容器的默认操作系统——许多云提供商已经利用其开放的模块化架构来采用和运行Kubernetes,而它的工具则可以利用其自身开放的API来访问诸如负载、集群、配置和存储等功能。我们看到更多的产品正在把Kubernetes作为一个生态系统来使用,使其成为继微服务和容器之后的下一个抽象层次。更多迹象表明,尽管面临分布式系统固有的复杂性,开发人员仍然可以成功地驾驭现代的架构风格。

成为新常态的云技术

本期技术雷达讨论中的另一个普遍性话题,无疑是近期的“多云”天气。 随着云提供商的技术能力越来越强大,且可以提供同样好用的功能,公有云正在成为许多组织中新的默认选择。当启动新项目时,许多公司已经不再问“为什么放在云端?”,而是问“为什么不放在云端?”。 诚然,某些类型的软件仍然要在公司内部私有地部署,但随着价格的下降和功能的扩展,云原生(cloud-native)开发的可行性越来越高。尽管主要的云解决方案提供商提供的基本功能都很相似,但它们也都提供了一些独特的产品特性,以针对特定类型的解决方案来实现差异化。因此,我们看到一些公司通过“多云”(Polycloud)策略来同时使用几个不同的云提供商,从中分别挑选最能满足其客户需求的平台专业能力。

各方对区块链的信任稳步增强

尽管加密货币市场仍然处于混沌状态,我们的许多客户已经开始尝试利用基于区块链的解决方案来处理分布式账本和智能合约的需求。雷达中的一些条目展示了区块链相关技术运用的成熟度,它们使用各种新技术和编程语言并以一些有趣的方式来实现智能合约。区块链解决了“分布式信任”与“共享且不可篡改的账本”这些老大难问题。如今,许多公司正致力于增强其用户对将区块链作为系统的底层实现机制的信心。许多行业存在着明显的“分布式信任”问题,我们期待区块链技术能持续找出解决这些问题的方法。


部分亮点预览

技术篇:

DesignOps:受DevOps运动的启发,包含一系列实践和文化转变的DesignOps横空出世。它可以帮助组织不断重新设计产品,而不在质量、服务一致性和团队的自主性上妥协。 DesignOps提倡创建并不断演进设计的基础,最大限度降低创造新的UI概念及其变体的工作量,并与最终用户建立快速可靠的反馈机制。使用DesignOps,设计正在从一种具体的实践演变成每个人工作内容的一部分。

Chaos Engineering:在早期的技术雷达中,我们讨论了Netflix的Chaos Monkey。Chaos Monkey可以随机终止生产系统中的运行实例,并对结果进行度量,从而帮助验证系统在运行时对生产中断的应对能力。今天,人们有了一个新兴术语来描述这一技术的广泛应用:混沌工程。在生产环境的分布式系统中运行这些实验,可以帮助我们建立系统在动荡环境下依旧能够按预期工作的信心。如果想要更好地理解这个技术方向,请参阅混沌工程原理。

Service Mesh:现在越来越多的大型组织在向更加自组织的团队结构转型,这些团队拥有并运营自己的微服务,但他们如何在不依赖集中式托管的基础架构下,确保服务之间必要的一致性与兼容性呢?为了确保服务之间的有效协作,即使是自组织的微服务也需要与一些组织标准对齐。服务啮合在服务发现、安全、跟踪、监控与故障处理方面提供了一致性,且不需要像API网关或ESB这样的共享资产。服务啮合的一个典型实现包含轻量级反向代理进程,这些进程可能伴随每个服务进程一起被部署在单独的容器中。反向代理会和服务注册表、身份提供者和日志聚合器等进行通信。通过该代理的共享实现(而非共享的运行时实例),我们可以获得服务的互操作性和可观测性。一段时间以来,我们一直主张去中心化的微服务管理方法,也很高兴看到服务啮合这种一致性模式的出现。随着 linkerd 和 Istio 等开源项目的成熟,服务啮合的实现将更加容易。

平台篇:

TensorFlow Serving:机器学习模型已经开始渗入到日常的商业应用中。 当有足够的训练数据可用时,这些算法可以解决那些以前可能需要复杂的统计模型或试探法的问题。 随着机器学习从试验性使用转向生产环境,需要一种可靠的方式来托管和部署这些可远程访问的模型,并能随着消费者数量的增加而进行扩展。TensorFlow Serving 通过将远程gRPC接口暴露给一个被导出来的模型,解决了上述部分问题。这允许以多种方式部署训练完成的模型。TensorFlow Serving 也接受一系列的模型来整合持续的训练更新。其作者维护了一个Dockerfile来简化部署过程。 据推测,gRPC 的选择应与 TensorFlow 执行模型保持一致。 但是,我们通常都会对需要代码生成和本地绑定的协议保持警惕。

LoRaWAN:LoRaWAN是一种低功耗广域网,专为低功耗、远距离和低比特率的通信场景而设计。它提供了边缘设备与网关设备之间的通信能力,能够通过后者将数据转发至应用程序或者后台服务。LoRaWAN通常用于分布式传感器组或物联网这些必须具备长电池寿命和远距离通信能力特点的设备上。它解决了在使用一般的WiFi进行低功耗广域网通信时的两个关键问题:通信距离和功耗。LoRaWAN已有若干实现,其中值得注意的是一个免费的开源实现——The Things Network。

Language Server Protocol:那些大型 IDE 的威力很大程度上源于利用源代码分析出的抽象语法树(AST)来进一步分析和操作源代码的能力,比如代码补全,调用分析和重构。语言服务器将这种能力提取到单独的进程中,从而让任意文本编辑器都可以通过 API 来使用 AST。微软从他们的 OmniSharp 和 TypeScript 服务器项目中,提炼并引领了”语言服务器协议”(Language Server Protocol, LSP)的拟定。编辑器只要使用 LSP 协议就可用于任何具备 LSP 兼容服务器的编程语言。这意味着我们可以继续使用自己喜爱的编辑器,同时也不必放弃各种编程语言的高级编辑功能——这对于很多 Emacs 瘾君子来说尤其利好。

工具篇:

Gopass:gopass是一个基于GPG和Git的团队密码管理解决方案。它的前身是pass,并在此基础上增加了诸如多用户密码管理、层级式密码存储、交互式查找、基于时间的一次性密码(TOTP),以及二进制存储格式等功能。由于它的存储格式与pass基本兼容,因此可以直接从pass迁移过来。这意味着只需调用一次存储密钥就能将其集成到迁移的整备工作流中。

Jupyter:过去几年间,我们注意到分析笔记本应用(analytics notebooks)的流行度在持续上升。这些应用都是从 Mathematica 应用中获得灵感,能够将文本、数据可视化和代码活灵活现地融入到一个具备计算能力的文档中。在上个版本的技术雷达中我们所提到的基于Clojure 的GorillaREPL,就属于此类工具。但随着人们对机器学习的兴趣不断增加,以及该领域中的从业者们逐渐将Python作为首选编程语言,大家开始集中关注Python分析笔记本了。其中 Jupyter 看起来在ThougthWorks团队中格外引入注目。

Rendertron:JavaScript Web 富应用的一个老问题是如何使这些页面的动态渲染部分可供搜索引擎检索。为此开发人员采用了各种各样的技巧,包括使用 React.js 的服务端渲染,外部服务或预渲染内容。现在谷歌 Chrome 新的 headless 模式又贡献了一个新的技巧—— Rendertron,即 Chrome的headless 渲染解决方案。它在一个 Docker 容器中封装了一个 headless 的 Chrome 实例,可以作为独立的HTTP服务器来部署。无法渲染JavaScript的爬虫机器人可以被路由到此服务器来进行渲染。 虽然开发人员也可以部署自己的 headless Chrome代理并配置相关的路由机制,但 Rendertron 简化了配置和部署过程,并提供了令爬虫机器人进行检测和路由的中间件示例代码。

语言&框架:

Gobot:Go语言能够被编译为裸片上运行的目标程序,这使得嵌入式系统开发领域对它的兴趣与日俱增 。GoBot是一个用于机器人、物理计算和物联网(IoT)的框架,它基于Go语言编写,并且支持多个平台。我们在一个对实时性响应没有要求的实验性机器人项目中使用了GoBot,并且用GoBot创建了开源的软件驱动。GoBot的HTTP API使其与移动设备的集成十分容易,从而能创建更丰富的应用。

Solidity:智能合约编程需要一种比交易处理脚本更具表现力的语言。在众多为智能合约设计的新编程语言中,Solidity是最受欢迎的。这是一种面向合约的静态类型语言,其语法类似于JavaScript。 它抽象了智能合约中自我实现的业务逻辑。围绕Solidity的工具链也在快速成长。如今,Solidity是Ethereum平台的首选编程语言。

CSS-in-JS:CSS-in-JS是一种用JavaScript编写CSS样式的技术,通过鼓励采用一种通用模式,编写样式以及应用样式的JavaScript组件,使样式和逻辑的关注点得到统一。该领域中的新秀——诸如JSS,emotion和styled-components,依靠工具来将CSS-in-JS代码转化成独立的CSS样式表,从而适合在浏览器里运行。这是在JavaScript中编写CSS的第二代方法,与以前的方法不同,它不依赖于内联样式,这意味着它能支持所有CSS特性,使用npm生态共享CSS以及跨平台使用组件。我们的团队发现styled-components很适合像React.js这样基于组件的框架,并且可以使用jest-styled-components做CSS的单元测试。这是个新兴的领域且变化迅速。用该方法时,在浏览器里人工调试生成的class名称会需要费些功夫,并且可能不适用于那些前端架构不支持重用组件并需要全局样式的项目。

以上是我们在最新一卷技术雷达中随机摘取的几个Blips,欲获取整版技术雷达,请点击这里

Share