在 AWS 有个传统，就是在各种官方大会上面发布新服务来「助兴」。在刚刚[1]落幕不久的 AWS 2019 纽约峰会（AWS New York Summit 2019）上，就正式发布了几个服务。
除了已经试用很久的 AWS Cloud Development Kid（AWS CDK）之外，还有一个 AWS EventBridge 服务，尤其值得关注。这个名字有点奇怪的新服务，被云研发咨询师 Jared Short 称赞为「自 AWS Lambda 之后最大新闻」（The biggest thing since AWS Lambda itself）。
这篇文章就来详细聊下这个服务的来龙去脉，以及它对于 AWS 生态体系的重要意义。
从「软件工程」说起
在企业级软件市场工作过的朋友一定都会记得被 UML 支配的恐惧。
我到现在都还能想起当年在大学里学习软件工程相关的课程时，电脑上跑着学校花了大价钱购买许可的 Rational Rose 软件，用来做软件的对象建模和架构设计。软件的各种设计细节都必须在设计上体现，事无巨细，几乎就差具体把代码写出来了。
这也难怪，那个时候的文化就是软件「工程」，真真切切地把软件当做一个工程来做。既然是工程，那人类就很轻车熟路了：先做规划，再做设计，确定预算，评估工期，购买材料，然后按部就班实施就行了。在软件还不足够软，而网络连通度也还不足的时代，大家确实也是这么做的。
通常来说整个软件工程的过程是稳当的，做出来的软件也是稳当的。需求并不会经常变化，因为软件一旦发布了之后，通常就会被烧制到各种硬件上（比如 Windows 系统光盘），或者安装和部署到成千上万的客户处（比如各种 ERP），这意味着改变很难应用到已经发布的软件上，就算想要应用，整个过程也是按季度，甚至按年来计算。
产品的演化很难，所以大家就把精力都用到了如何提升软件的内部效率上。
企业服务总线
提升效率有很多条路，但那个时代的思潮是中心化的。换句话说，就是企业软件的架构师们认为在企业这样一个环境设定下，业务不会特别复杂。只要有一个足够厉害的「中心大脑」，就可以为每个部门去做好细致的指导、规划和审计。这也很自然，因为本来当时的企业就是高度中心化的，这种思考方式只是顺应了现实。
架构师们开始从中心化审视企业软件的效率瓶颈和浪费。他们发现，主要的问题在通讯上。
企业通常是由非常多的软件模块组成，这些模块之间相关都需要沟通。A 需要跟 X 沟通，B 也需要跟 X 沟通，C 可能需要跟 Y 沟通……就这样形成了一个复杂的网络。如果有五个模块需要跟 X 模块通讯，而他们分别去研发这个通讯的功能，中间就会产生很多的浪费。而且，每次 X 模块升级的时候，都会需要顾虑到这几个模块。唔，这肯定不行吧？
要提高效率，最简单粗暴的方式就是搞分工、加抽象。既然通讯这件大家都要做，那就专门搞出一个「沟通部」，专门负责梳理和执行各个模块间的沟通。这个部门做的事情大概和秦始皇差不多：统一模块间沟通的语言。所有的沟通都要通过这个沟通部来进行，由沟通部来做沟通语言的转换。
1967 年，一位叫做 Melvin Conway 的程序员发现：软件研发团队是什么结构，做出来的软件就会是什么结构。我们把这个观点称之为「康威定律」（Conway’s Law）。既然企业的结构是中心化的，那么做出来的软件也就必然会体现出中心化的形态。
这就是企业服务总线（Enterprise Service Bus，下简称 ESB）的来源。名字中的「企业」，来自它主要服务有多模块沟通需求的企业市场；「服务」，因为软件模块一旦可以独立运作，它就是一个完整的服务；「总线」，因为它就像是电气设计中常见的总线，所有的线都接在它上面，所有的通讯都要依靠它。
乍一眼看上去，这好像是一个完美的解决方案，但如果按照今天的眼光来看，很容易就可以发现问题。
首先，「总线」这个设定，很容易就会让人联想到「单失效点」的问题。因为所有的通讯都要依靠它，所以，一旦它出现了问题，或者产生瓶颈，所有模块就都没办法沟通了。
其次，这种中心化的体系，对「总线」的要求非常高。总线负责翻译所有的业务语言，就意味着它跟几乎所有模块都产生了耦合。这种耦合带来的结果就是任何时候业务需要调整和修改，都需要去跟总线去交涉。总线有自己的研发进度和计划，而这个计划可能和模块研发团队的计划是不匹配的，这时候就会出现双方「互等」的情况。
更重要的是，越来越软的软件，和越来越网络化的资源，使得中心化的设计变得非常困难。
给软件开发正名的「敏捷方法」
1999 年，一本叫做《教堂与集市》（The Cathedral and the Bazzar ）的奇书横空出世，探讨了当时的两股完全相悖的思潮。
一个是「教堂派」，就是我们前面提到的，提倡提前设计，做好规划，中心化管理，尝试人为地保证运转效率的企业软件世界，它就像教堂一样归整，制度森严，责任明确。
另一个则是「集市派」，代表是 Linux 之等等开源软件，组织结构松散，有理念但是没有规章，人来人往，见缝插针，就像一个喧闹的集市，没有固定摊位，大家各取所需，自由发展。
虽然，二者都取得了足够的成就，但如果我们仔细看，就会发现开源软件这种模式似乎更顺应未来的趋势。软件变得越来越复杂之后，几乎没有谁能够完全掌握它的方方面面，很难去做出非常细致有效的指挥。
后来的事情我们都知道了。
2001 年，一群德高望重的软件工程师聚集在滑雪圣地，美国犹他州的雪鸟区（Snowbird），签署了《敏捷宣言》，开启了「敏捷软件开发方法」的时代。敏捷开发方法的主旨很简单，就是希望能够形成软件开发的「普适价值观」。这个价值观更看重人、沟通、可用的软件和响应变化，而相对来说弱化流程、工具、文档和计划。
这基本上标识着软件开发从此有了自己专属的方法论，而不用再去借助「工程」来做比喻，或者简单地代之以「脑力劳动」。软件开发从此之后就是软件开发，它不是工程，没有砖瓦水泥和现实世界的严苛限制，也不是完全抽象的脑力劳动。这些比喻都不够贴切，我们要重新、从头来认识这件事。
子曰：「必也正名乎！」就是这个道理，事物一旦有了名号，划定了边界，就有了讨论的基础，发展就会变得很快。
在这个方法论的指导下，UML 被替换成了用户历程、用户故事和在线 API 手册。ESB 没有了 Bus，只留下了 Service，回归了面向服务的架构（Service-Oriented Architecture，简称 SOA）。后来，大服务又进一步地被拆分、演化成了微服务（Microservices）——这又是另一个故事了。
不论如何，我们可以看到，ESB 这种做法似乎是日薄西山了。敏捷研发方法出现之后，企业软件研发也开始流行小而美，自己自足的玩法。就像一个大都会或者集市，它允许一些鱼龙混杂，允许一些低效，但是至少不需要一个大脑随时照看，可以很容易响应变化，弹性十足。
不过，话又要说回来。有些事情，就跟天下大势一样，合久必分，分久必合。当微服务和去中心化及其流行的时候，有些架构师又会想起中心化的一些好处。
中心化的还魂夜
最近几年，中国兴起了一个叫做「中台」的概念，我们可以看到一些端倪。虽然我跟不同的人聊中台的时候大概聊出来两百多种各式各样的定义，但是从中台概念创始者阿里巴巴官方的《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》一书中，我们不难看出，「中台」其实糅合了两个东西。
一个是它在尝试落实领域驱动设计（Domain-Driven Design）之中的「领域层」的概念。在这个意义上，「中」指的是「中间」。按照领域驱动设计的划分逻辑，基建层之上是中间的领域层，捕捉非常稳固的领域逻辑，然后再上层是自由组合的应用[2]。
另一个则是类似 ESB 中总线的存在，在这里的「中」指的是「中心」。康威定律在这里又大显光芒。既然中台展示出了中心化的模式，那么对应的团队肯定逃不掉会变成一个类似的结构。果不其然，中台的现实化身，就是一个叫做「共享业务事业部」的组织。
从理论上分析，中台似乎可以降低很多重复劳动，甚至有时候人们会期待用它来打破「部门墙」，让信息可以更好地流动，但和 ESB 一样，我们仍然需要抛出几个问题。
在业务如此复杂的今天，「超级大脑」是否真的能设计规划好每个业务线？无数的订单都从一个共享的、统一的订单服务来走，我们怎么确保它们相互之间不影响，不造成单点失效的问题？不同前端应用提出来的需求，再加上中台自身的需求，怎么来划分优先级？中台掌控了所有核心业务，也就掌握了核心权力，那么需要响应变化的时候，是由现在已经没有太大话语权但离客户最近的前端来发起，还是由掌权的中台来发起？甚至更深一层的，前端团队现在都不承载业务了，而中台则承载了所有业务，那这个会计怎么来做，绩效怎么来评判？
看来有了「中台」这个新的包装，很多原来 ESB 的问题，还是没解决。
亚马逊的去中心化策略
同样是电商行业，亚马逊在「怎么高速扩张并且保持高效」这件事情上走了一条完全不同的道路。
早在 2002 年，亚马逊 CEO 贝索斯（Jeff Bezos）就提出了著名的《杰夫 · 贝索斯命令》（Jeff Bezos Manadate）。其中的重点有如下几条：
- 服务的 API 化。所有的团队都必须把自己的数据和职能通过 API 暴露出来。
- API 的独占化。所有的团队沟通必须通过公开的 API 沟通，其他的沟通形式，比如直接读取对方数据库，邮件分享链接，都不允许。
- API 的外化。所有的服务都必须在设计阶段就考虑到如何开放给公司外部的用户使用。
- 除了上面几个要求之外，团队享有足够的自由度，用什么语言来写，什么网络协议，都无所谓。
做不到这几条的，就会被直接干掉。由于所有的命令都围绕在 API 这个点上，所以这个严格的命令有时候也被人称作「人形 API 命令」（The Human API Mandate）。
毫无疑问，这在一开始的时候会带来各种不方便。
想想吧，原来要找谁加一个功能，可能就线下聊一下，最多发个邮件，然后这件事就完了。现在，团队需要把「增加新功能」这个职能，做成一个 API，而需求团队则需要调用这个 API，填入相关信息，然后才能做到。就算是做 API 吧，如果不考虑外化的问题，那么什么登录、审核、防攻击之类的，都不需要呀，但是现在要考虑外化的问题了，这些就都要考虑了，而且还得很严肃地考虑。
当然，今天我们一眼就看出来，这就是 SOA 或者微服务所推崇的服务化。在《互联网思维的公司》（The Connected Company）一书中，作者们把这种结构称之为「团组」（podular，即 pod + modular，pod 指非正式的有着共同目标的小团队），把由团组组成的高度自治的组织称之为「合弄制」（Holacracy）组织。
这些团组各自负责自己的模块，每个模块高度独立，形成了一个个的服务，功能公开暴露成 API，就像一个黑盒子。使用者不用管盒子内部怎么实现的，只需要按照 API 调用即可。再加上本身在设计时已经考虑外化问题，所以服务稍做小小的改动，就能直接拿出去对公众提供服务，甚至可以产生收入。
对于一个已经完整 API 化的服务来说，它的使用情况，创造的价值，很容易就能体现出来。作为一个管理者，只需要用创造的价值或者用量这一个永恒不变的标准来判断团队的成绩。由于团队只对 API 负责，内部享有极大的自主权，所以也会催生出很多创新。这种创新和对价值的追求是团队自然而然就回去做的，不需要一个「超级大脑」，也无需太多上层干预。
这个思想也带到了 AWS 上。
AWS 的服务，功能和对应的文档、帮助通常都写得很详细，这就是因为很多时候这些文档在服务设计之初就已经在写了。甚至有可能有些服务在初期的时候实现的非常潦草，但只要接口设计好了，按规矩执行操作，就没有问题。
很多 AWS 的高阶服务是建立在自家基建服务之上。这主要有两个原因。第一是因为基建服务所提供的功能都通过 API 暴露出来，调用起来非常方便。其次则是因为所需要的能力，自家的基建服务已经覆盖，而且有很高的性价比。
团队冲着创造更高收入或者价值来确立自己在这个体系内的存活，性价比就会不断地提高，从而提升在市场上的竞争力。而因为一开始 API 就已经外化，所以对于内部的调用者来说，这个服务和外部采购的服务其实是对等的。更重要的是，对内部的调用者来说，这些服务并不会提供任何额外的附加功能，内外都是一视同仁，甚至可能内外部用户看到的技术文档都完全一致。
比如，亚马逊曾经就 Aurora 数据库发表过公开的论文，如果有人愿意，完全可以在 AWS 的基建上再搭一个一模一样的 Aurora 服务出来——甚至如果能通过各种技术和运营优化把成本将到比原版更低，就可以去跟原版去正面竞争。能做到这一点，也是得益于服务化和 API 化，使得即便是 AWS 官方的应用层服务，也不依赖什么黑盒和特殊机制[3]。
要做到这种程度的公开和透明，前提是服务必须高度自治，只有这样，才有不断迭代发展的动机。这种动机如此强烈，使得服务不可能在那苦等一个「超级大脑」来做战略规划和拍优先级，所以在 AWS 的层面上，并不存在 ESB 和中台的概念。
我们可以在很多地方看到缺乏「超级大脑」所带来的不和谐。比如说，有可能两个服务提供了非常类似的功能，形成了内部竞争。再比如说，同样一个配置项，在不同的服务使用了不同的名字。甚至有可能两个服务的管理界面或者 API 设计上，我们会看到一些样式或者文案上的微妙差异。
这些都是选择了「集市派」路线之后必然会出现的情况。往好的方向说， 我们把这叫做「多样性」，反过来说，这必然会造成一些浪费和低效。好处是，用这样一点浪费和低效，换取了更好的响应变化和演变进化的能力。
不可避免的中心
集市是分散而自治的，集市中的每个商铺都会自己确定自己的商品、价格，如果需要什么快递、金融，就会有新的快递服务和金融服务自然出现，不需要太多干预，但是，它也不可能是完全没有中心的。
比如，大家要相互交易，必须使用货币，那么这个货币自然是需要一个中心化的组织来进行背书。再比如，大家可能都会使用自来水、电，这些通常也会由一个组织来统一提供，而不是各自分散去做。也就是说，中心化是不可能完全避免的。
那么，这里就出来了一个问题：如果我们大方向上希望能走集市派、服务化、响应变化的路线，但是又需要解决不可避免存在的中心问题，应该怎么办？
看到这个问题，直觉第一反应就是让这个中心变得极具弹性，可以很容易地进行横向扩展。现在有了虚拟化和云的存在，这一点变得很容易。
可光有弹性还是不够的，服务与服务之间的「频率」可能是不一样的。比如，用户要从银行 A 跨行转账给银行 B，银行 A 很快就发出了转账请求，但是银行 B 要花 1 分钟才能处理这个转账请求，那么这个请求就会一直阻塞在那里，请求多了，很容易就会碰到天花板。所以，除了要有弹性，我们还必须在设计的时候，就考虑到把所有经过中心的通讯都异步化。
技术问题上面两条已经可以解决，后面就要解决业务问题。
为了避免中心变成一个业务和创新的瓶颈，我们需要让中心尽量地「去业务化」。一旦中心不承担任何业务职能，它就变成了一个非常通用而中性的「线路」。这种线路是很容易被替换的，所以不用担心业务的创新和迭代速度受制于中心的发展速度，也不用担心需要维护一个巨大的业务团队在中心来了解各个对接服务的业务。
这额外还带来一个好处，就是不管是负责中心的团队，还是负责服务的团队，业绩都非常好计算。有流量顺利经过了中心，中心团队就得分。服务通过 API 顺利地执行了业务，服务团队就得分。
弹性、异步、去业务化，这几点加起来，我们其实很容易就能看出结果其实就是我们常见的「消息队列」服务。正因为在服务化的场景下，也有中心化的需求，所以不但有很多消息队列的开源软件，AWS 这样的云厂商也提供了各种消息队列服务来解决不同类别的问题。
细数一下，我们会发现 Amazon SQS、Amazon CloudWatch Events、Amazon Kinesis 等服务其实都是这样的消息队列。那么，这最新推出的 EventBridge 和这些服务有什么不同，值得被称作「Lambda 之后最大新闻」？
AWS 风味的「中台」
使用我们前面提到的几个消息队列服务，其实我们已经可以在技术层面做到相当完善的中心化模块，或者中台，但 EventBridge 的出现，仍然弥补了 AWS 在这个层面的一块缺失。
EventBridge 和前面提到的几个消息队列服务最大的差别，就在于它的除了可以作为内部的消息队列来使用，还可以面对外部 SaaS 服务做对接。
EventBridge 服务有接近 10 个「首发合作伙伴」，其中包括了客服界常用的 Zendesk、云监控服务 Datadog 和安全运维服务 PagerDuty 等等。这种服务上新的模式，和其他很多传统 AWS 服务不太一样，反而是更像 Marketplace，与紧密联系的合作伙伴携手推出服务。
这也很正常，因为如果仅仅是 AWS 体系内部的消息队列，那么已经有多个服务可以不同程度的支持，但是对于外部服务的集成，对 AWS 来说倒是头一次。
有了 EventBridge，可以说整个服务生态的想象就被大大拓宽了。
比如，当用户在 Zendesk 上提交一个工单，这个工单会以消息的形式传递给 EventBridge 里面的消息总线，然后这个消息可能会被传递到 SageMaker 进行情感分析以确定优先级权重，然后累积到 Kinesis Firehose 进行批量归档以备后续统计分析。
再比如，Datadog 监测到我们的产品核心业务 KPI 在大量增长，超过服务优良度的阈值的时候，则发一条信息到总线，然后触发一些自动操作，并作记录归档，通知运维人员之类。
对于 PagerDuty，在它发现问题的时候，可以在自动触发处理的同时发一条信息到总线，然后通过 AWS Lambda，再转发给 Zendesk，在 Zendesk 上创建一个对应的工单，方便把各种自动检测到的和客户提出的问题进行汇总分析。
上面只是几个简单的例子，但是这个模式的潜力是无穷的。当 EventBridge 接入了各种各样的财务、HR、广告、智能聊天机器人、人脸识别……等等 SaaS 服务，那么一个真正的「中台」就形成了。各种 SaaS 服务都通过一条松耦合的纽带连接起来，相互打通。由于纽带本身不介入业务，对于用户来说捆绑效应很低，免除了后顾之忧。
当然，即便没有 EventBridge，利用现有的 AWS 服务，也是完全可以做到这种消息总线的模式，但是 EventBridge 有以下两个额外的好处。
首先，它是全托管的服务。我们都知道全托管意味着不用去管任何基建、弹性的问题，但在消息总线这个事情上，全托管的意义更重大一些。
因为要跟很多外部 SaaS 服务对接，如果不是官方层面的对接，就意味着用户要自己去维护这样的格式转换并且随时需要去准备更新对接的格式，还需要了解 SaaS 服务潜在的各种问题并作出正确应对。确保这个对接的安全性更是一个大问题。这个对于大部分公司来说是完全没有必要做的与核心业务无关的事情，在 EventBridge 这边，直接就由官方去解决了。
此外，托管也意味着弹性的问题也解决了。用户几乎不用去管扩容和收缩的问题，只需要直接使用即可，非常简便。
除了托管之外，EventBridge 还有一个好处，就是它是一个完全、纯粹地按量收费的无服务器类服务。它只看消息数量，没有任何其他费用。这个收费方式和 CloudWatch Events 是一样的——实际上 EventBridge 被一些技术博主称之为「CloudWatch Events 2.0」，因为除了收费方式相同之外，实际上 EventBridge 直接继承了 CloudWatch Events 的 SDK 和命令行接口。
总的来说，EventBridge 的出现看上去只是对原来的消息队列做了很多减法和简化，但用户集成和对接各种内外部服务的难度大幅降低，自然会促成用户形成适合自己的消息总线模式。这和 AWS Cloud Development Kit 带来的好处是类似的，虽然功能上 CDK 能做到的 CloudFormation 都能做到，但是因为 CDK 极大地简化了写 CloudFormation 模板的难度，那么就会吸引更多人去尝试，这也就推动了用户更好地采纳「架构即代码」「样的优秀模式。
开放和被集成的时代
最近，微软以 10 亿美元投资 OpenAI 的故事上了新闻。在发布会上，有中国的记者问微软 Azure AI 的负责人 Eric Boyd：「微软是否有自己的 AI 中台？」这个颇具中国特色的问题难倒了 Eric Boyd。
如前面所说，在中国之外，并没有「中台」这个概念。当谈论企业内部的业务平台时，大家会说领域层、应用层，或者服务化、微服务、应用服务，甚至会说 ESB 和总线。当谈论企业外部的生态整合时，大家会说服务集成、服务治理，以及统筹解决方案。
与上面提到的概念不同的是，人们在说起中台的时候，通常会有一些额外的诉求，比如提效、去重，再比如统一划分和管理。而这些诉求，在很多公司，会通过服务之间的自由竞争，以及诸如数据湖这样的松散解决方案来解决。
不同的文化和管理诉求会形成不同的软件，这个无可厚非，只是我们应该警惕一种情况：一个看似完善中台产品，提供了五花八门的业务职能，还有非常傻瓜化的操作，效率高，价格低，而且所有的服务都由单个供应商来提供。这意味着客户在利用中台产品便利性的同时，与这个供应商高度捆绑，再也分不开了。
一个优秀的中台（或者平台），应该是技术中立，而且足够开放、包容的。拿一句热门的话来说，它应该等着「被集成」。围绕客户核心业务诉求的功能，应该既支持专业的第一和第三方供应商提供，也支持用户自研。不管是谁来提供，都应该可以通过这个中台进行方便的数据收集和置换，而中台自己则不插手实际业务，让专业的人做专业的事情，也让服务可以更快速地迭代。
EventBridge 就是这样一个服务，它的潜力和想象空间是无限的的。期待这个服务在中国区域正式上线，携手各行业和领域中的优秀和成熟的服务，助力客户打造一个完整、可控、高效的「中台」。
原创文章，作者：奋斗，如若转载，请注明出处：https://blog.ytso.com/292831.html