Layered Microservices Architecture

位置

2018年11月第19期技术雷达(点击此处下载)技术象限,建议暂缓

标签

Microservices,Architecture,Anti-pattern

目标受众

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

关注问题

构建微服务架构首当其冲要解决的问题,就是业务服务如何划分的问题。我们发现很多组织在技术快速发展的今天,仍然会重蹈过去的覆辙,对于服务按照以前的多层架构的分层方式进行划分。这样的架构不但没有尝到微服务所带来的独立交付业务价值的甜头,还要承受微服务所引入的运维复杂度。

解决方案

按照业务能力(business capabilities)而非技术能力来划分团队和服务。

解读

对于N年前的多层架构来说,层往往是按照技术能力来划分的。以最典型的三层架构为例,包含用户界面层、业务逻辑层和数据访问层,分别由擅长前端、后台和数据库的团队来维护。每一层可以部署在不同的服务器上,构成了分布式系统的雏形。

但这样的架构很快就会出现问题。因为用户访问的是业务功能,不是上述某一个特定的层,所以用户的每一次访问都会贯穿这三层服务。任何一层出现问题,都会导致这次访问失败。而每当新的功能需要交付时,都必然要修改和重新部署所有的层次。

我们常用切蛋糕来举例子。分层架构就像是横切蛋糕,切下来的每一块都只是那一层的原材料,可能是奶油,可能是水果,也可能是慕斯。但每一块都不是完整的蛋糕(业务功能)。只有纵切蛋糕,奶油水果慕斯蛋糕一应俱全,才是用户真正想要的东西。所以我们都是纵切,切出来的每一块蛋糕都是可以分给别人吃的(独立交付的单元)。

微服务架构正是基于此诞生的。它打破了传统多层架构的束缚,以业务能力而非技术能力来划分服务和组件。比如在电商系统里常见的微服务可能包括商品服务、订单服务、支付服务等,而在传统多层架构下这些只是业务逻辑层和数据访问层的一部分内容。微服务和传统多层架构对于服务的划分,是正交的。

随着近年来的飞速发展,微服务已经逐渐成为主流架构。但无论技术如何快速变化,一些企业仍然想方设法地重新实现过去的反模式。分层式微服务架构(Layered Microservices Architecture)就是这样一种反模式。它打着微服务的旗号,但仍然按照技术能力来划分服务。比如用户体验API、进程API或系统API等。这导致任何有价值的业务变更,都需要缓慢而昂贵的多团队合作。微服务独立演进、独立交付、快速响应变化的好处一个也体会不到。

之所以陷入这样的误区,还是康威定律在背后起着作用。因为组织仍然按照技术能力而不是业务能力来划分团队,那么步入以技术能力来划分服务的歧途也就在所难免了。

因此在最新的第19期ThoughtWorks技术雷达中,分层式微服务架构首次入选,并进入“暂缓”行列。我们强烈建议组织评估这种分层方式带来的影响,我们更推荐根据业务能力来划分服务和团队。

注意,这里的分层(layered)特指按照技术能力来划分微服务,会导致教条式的逐层调用。它并不代表按照业务划分的微服务之间,根据不同服务的职责所划分的层次。比如,有些服务负责具体的业务能力,有些服务则会将不同业务服务组合起来,并提供一个对调用端更加友好的接口,我们常常称之为Composer或Orchestrator。这样的“分层”属于categorized,不是layered。

相关Blip

Share

为什么微服务从未被技术雷达“采纳”?

如今,微服务在许多组织中发挥着重要作用。自从James Lewis和Martin Fowler发表了那篇开创性的文章后,微服务也随之声名鹊起。此后,Sam Newman也撰写了相关著作并举办了许多讲座,ThoughtWorks、Netflix和Google的人,还有许多其他组织和个人也纷纷发表文章,进一步推动了微服务的发展势头。微服务很快就进入了ThoughtWorks技术雷达的Trial(试验)环,但一直以来,微服务都未进入Adopt(采纳)环。这篇文章便是想探讨一下,为什么微服务一直没有为技术雷达所“采纳”。

Adopt环有意把标准设置得很高

首先,一起回想一下雷达上“试验”环和“采纳”环的定义。“试验”意味着相应技术已经可以供企业在自己的系统中进行尝试。表示我们在已经或多或少地将该技术投入生产,而且相信该技术是稳定的,知道如何以及在何处使用该技术。而进入雷达“采纳”环意味着,我们认为在适用的情况下这种技术是首选解决方案。例如,对于数据库,Neo4J就是一种进入了“采纳”环的图形数据库。这并不意味着所有数据都应该放入图形数据库中,而是意味着当你想使用图形数据库,Neo4J就是理想之选。

考虑到上述定义,我们为何不将微服务或微服务架构放入“采纳”环?毕竟,微服务经常作为各种会议和文章热议的话题,也有越来越多的组织正在转向采用这种架构风格,ThoughtWorks团队已经成功地将微服务用于许多项目。

我们未将微服务放入Adopt环,有多种原因。一部分原因在于“采纳”环的定义,另一部分原因则在于微服务本身。我们先从技术雷达的特定问题谈起。

将某种技术放入“采纳”环是一种非常强烈的表态。我们不希望在考虑做出这种建议时,存在太多让我们举棋不定的因素。将某种技术放入“采纳”环意味着,我们确信对于一些显而易见的情况来说,采用这种技术是正确的选择。在考虑微服务时,虽然它有一些明显的优点,但同时存在成本问题。对成本与效益的权衡因组织而异;组织的成熟度、领域和其他因素可能会影响可用的开发资源。从这个方面来讲,我们不能做出采用微服务的建议,技术雷达对于“采纳”的定义不应当模棱两可。

更重要的是,另一方面,将某种技术放入“采纳”环就要求,这项技术应该可以在各种成熟度范围内的客户和一般企业之中普遍采用。例如,如果某种技术适用于初创企业,但不适用于大型企业,就不应该放入“采纳”环,一个突出的例子是技术公司广泛应用的分布式版本控制系统。我们没有将这种系统纳入到“采纳”环,因为当时许多企业仍在努力采用基本的源控制。我们认为从一无所有到分布式版本控制的飞跃太大了,不能做出采用该系统的强烈建议。我们最终还是将Github放入了Adopt环中,但那是几年之后了。

并非所有组织都适合采用微服务

最后,正如Martin Fowler在一篇关于微服务的文章中所指出的,在考虑采用微服务之前,需要在持续交付和基础设施自动化实践等方面达到一定的成熟度(也许不需要太高)。然而,对于许多组织而言,要达到这种成熟度仍然力所难及。微服务会增加操作负担,因为有更多东西需要监控和生成警报,还有更多东西需要部署。在这方面,全面的自动化和持续交付实践至关重要。

此外,微服务架构还具有一些在单体式应用程序中完全不可能出现的错误模式。微服务系统本质上是分布式的,业务流程通常通过多项微服务的交互来完成。在单体式应用程序中,这些业务流程通常在同一流程边界内执行,从而可以执行传统事务并能确保全部执行或全部不执行。虽然我们可以为所有这些问题提供解决方案,但不可忽视的是,微服务方法确实会引入这些问题并需要处理。因此,需要在微服务方法增加的灵活性和单体式方法的简单性之间进行权衡(这种权衡很常见),尤其是在单体式应用程序结构完善的情况下,从灵活性中获益不多的应用程序不适宜采用微服务架构。

微服务架构的关键设计决策是在服务之间设置边界。虽然有界上下文肯定能为设置适当边界位置提供有效指导,但是仍然存在选择,而选择错误会使系统变得更复杂。对于某个新领域而言,边界的设定会比较模糊,因此在未进一步明确领域和适当上下文之前,有理由暂不开始采用微服务架构。

微服务对企业来说仍然非常重要!

现在,你可能想知道我们为什么推荐微服务架构,或者我们是否仍然推荐此架构。灵活性、独立的可扩展性、不断演进的特性、强大的封装仍然是微服务不可不说的优点。这些优点已经在其他文章中进行了详尽的阐述。我们仍然坚定使用微服务架构,以扩展我们对这种架构的理解,并继续探索解决本文所提到问题的工具和方法。实际上,来自ThoughtWorks的Zhamak Dehghani最近发表了一篇关于将单体式应用程序分解为微服务的文章。但是,该方法的成本和缺点以及执行该方法所需达到的组织成熟度水平正是微服务很可能永远无法进入“采纳”环的原因。

本文翻译自ThoughtWorks全球首席技术官Rebecca Pasrsons的《Microservices in Adopt?》一文。Rebecca将在3月15日来到技术雷达十周年峰会现场,与众位国际软件巨匠一同讲述技术领域的十年趋势变革。现在购买可享受限时七折票!

 

Share

Quorum-企业级分布式账本和智能合约平台

位置

2018年11月第19期技术雷达(可点击下载)平台象限,建议评估

标签

Blockchain, DLT, Ethereum, Quorum

目标受众

区块链架构师与开发者

关注问题

以Ethereum为代表的公有链平台工作于信任度较低的public internet,一般采用PoW/PoS等效率较低的共识机制。而企业业务环境下一般有更高的信任度,对网络许可管理、交易的隐私性以及吞吐量/延迟也有更高的要求。因此联盟链和公有链相比有完全不同的设计关注点。

解决方案

Quorum是由摩根大通开发的企业级区块链平台,它从以太坊的官方客户端fork出代码并对部分模块重新设计实现。通过添加交易隐私、节点许可管理等特性,将Ethereum原有的共识算法替换成可选的Raft/IBFT协议,Quorum可以在适配Ethereum开发工具链的同时,更好地服务于企业联盟链场景。

解读

在区块链行业中,Ethereum有较高的知名度和生态成熟度,被很多人当成区块链/去中心化应用开发的首选平台。然而Ethereum是针对公有链进行设计,虽然可以单独部署私有网络,但很多特点不适合企业联盟链场景。因此一些团队选择基于Ethereum开发适合企业的区块链平台,从而充分利用Ethereum在社区和工具链等方面的优势。

Quorum的代码fork自Ethereum官方EVM(Ethereum Virtual Machine)之一go-ethereum,并跟进主要release的更新。而Quorum对Ethereum主要在以下方面进行了改进:

  • 交易隐私性

在公有链中,所有交易都是公开可见的,任何人都可以查看Ethereum主网络历史某个区块的交易。这种透明性也是公有链的特性之一,很多团队基于区块链的这一特性开发出公证/鉴证等服务。然而在企业对企业的交易环境中,很多时候需要保证交易的隐私性。即使在一个企业联盟内部,交易也只对发起的双方可见。Quorum对此添加了私有交易的支持。

Quorum会将需要保证隐私性的交易标记为私有事务,其事务管理器会将交易内容载荷加密后进行替换。其他的Quorum节点接受到交易时只能看到被加密过后的内容,而只有这次交易的参与者才能用自己的秘钥解密私有事务,并将其存储在本地的私有状态数据库中。

  • 节点许可管理

在公有链中,任何人都可以运行全节点进行挖矿,成为公有链网络的一部分。这种基于完全去中心化的设计方式跟企业业务有较大差异。在企业联盟中,所有成员的身份都是已知的,节点的分布往往基于实际的商业规则进行考量。此外联盟链需要相应的机制,对成员节点的加入、维护、退出等进行许可管理。

每个Quorum节点可以通过维护一份permissioned-nodes列表来组件一个许可网络。该列表中维护了传入/传出节点的白名单,并配置相应的IP/端口/公钥地址。

  • 共识协议

公有链处于信任度较低的公有因特网中,且成员加入不需许可,往往面临女巫攻击的风险;此外公有链往往会设计相应的经济机制用于激励参与挖矿记账的矿工。基于博弈的共识类协议(PoW/PoS等)应运而生。此类协议可以很好的解决公有链的问题,但在性能、效率方面有很多限制。

在联盟链中所有成员身份已知节点数量有限,一般不会受到女巫攻击威胁;且成员间通过商业达成合作,不需要设置挖矿激励。因此可以采用更高效率的共识协议。Quorum替换掉了Ethereum原有的共识协议,并支持可选的Raft/ Istanbul BFT协议,更具灵活性。

总结

Quorum为以太坊开发者提供了一个平台,可以用Solidity/Truffle等熟悉的工具链构建一个企业联盟链。虽然在我们的实践中,该平台仍存在一些缺陷,成熟度有待提升。但我们建议区块链架构师和开发者将该平台放到自己的评估备选中,持续观察。

相关Blip

Share

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

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