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

如今,微服务在许多组织中发挥着重要作用。自从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

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