云原生时代（三）：微服务、API管理与集成

上文我们主要介绍了DevOps与CI/CD，第三部分我们来讲云原生的核心概念-微服务。

什么是微服务

微服务（Microservice）概念最早出现于2012年，2015年以后受到越来越多的关注，并且逐渐开始流行开来。其中著名技术大神Martin Fowler功不可没，他于2014年发表的一篇博客《Microservices: a definition of this new architectural term》（微服务：新技术架构的定义）清晰的定义和阐述了微服务概念。

“要开始解释什么是微服务之前，先了解单体（Monolithic）应用是很有用的：作为一整个单元构建的应用程序。企业应用由三个重要部分组成：客户端界面（由HTML、Javascript组成，使用浏览器访问）、数据库、服务端程序。服务端程序处理HTTP请求、执行业务逻辑、检索并更新数据库中的数据、选择和填充HTML视图发送给客户端。这个服务端程序是一个单一结构也即一个整体，系统中的任何修改都将导致服务端重新编译和布署一个新版本。

这样一个单体应用很自然的被构建成为一个系统，虽然可以使用开发语言的基本特性把应用封装成类、函数、命名空间，但是业务中所有请求都要在单一的进程中处理完成，在某些场景中，你可以在开发人员的笔记本电脑中运行和测试，并且通过布署通道将测试通过的程序布署到生产环境中，你还可以水平扩展，利用负载均衡将实例布署到多台服务器中。

的确，单体应用也非常成功，但是越来越多的人感觉到了不妥，特别是应用程序被发布到云的时候，变更周期被捆绑在一起-对应用程序一小部分所做的变更，都需要重新编译和部署整个应用。随着时间的推移，软件开发者很难保持一个好的模块架构，使得单个模块的变更不会影响到其它模块，而且扩展时也只能进行整体扩展，而不能根据需求进行部分扩展。”-- Martin Fowler

下图是传统单体应用的技术及对应的组织架构，Martin Fowler称之为大家已熟知的Siloed Architectures-烟囱式（也称为谷仓）架构。

综上，传统的单体应用有很大的局限性，应用程序随着业务需求的迭代、功能的追加扩展，最终成为一个庞然大物。单体应用的局限性大体包括以下几方面：

• 复杂性高：业务规模和团队规模发展的一定阶段，模块耦合严重，代码难以理解，质量变差

• 交付效率低：构建和部署耗时长，难以定位问题，开发效率低，全量部署耗时长、影响范围广、风险大，发布频次低

• 伸缩性差：单体只能按整体横向扩展，无法分模块垂直扩展

• 可靠性差：一个bug有可能引起整个应用的崩溃

• 阻碍技术创新：受技术栈限制，团队成员使用同一框架和语言

解决这一问题的银弹就是微服务。

“微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API)。这些服务要基于业务场景，并使用自动化布署工具进行独立的发布。可以有一个非常轻量级的集中式管理来协调这些服务，可以使用不同的语言来编写服务，也可以使用不同的数据存储。”-- Martin Fowler

微服务架构将单体应用，按照业务领域拆分为多个高内聚低耦合的小型服务，每个服务运行在独立进程，由不同的团队开发和维护，服务间采用轻量级通信机制，如HTTP RESTful API，独立自动部署，可以采用不同的语言及存储方式。微服务体现去中心化、天然分布式，是中台战略落地到IT系统的具体实现方式的技术架构，用来解决企业业务快速发展与创新时面临的系统弹性可扩展、敏捷迭代、技术驱动业务创新等难题。

下图左边是传统的单体应用，右边是微服务模式，图中每种颜色代表一种可拆分的微服务应用。

一个比较形象的例子是装配式建筑。传统建筑（单体应用）的施工周期（开发时间）很长，往往依赖于建筑公司（开发团队）的能力和水平，修建完成后难以搬迁和复用，而装配式建筑（微服务）的梁、板、柱、墙等构件（单个服务）可以事先批量化的在工厂（容器）生产，而在建造过程中，我们可以把构件想象成一块块乐高积木，在施工现场只需把它们拼合在一起，大大提升了施工进度和建筑质量。

微服务的特征包括：

• 小：粒度小，专注于一件事

• 独：单独的进程。微服务不等于组件，服务是可以直接使用的商品，组件是待加工的原材料

• 轻：轻量级通信机制，通常是HTTP Restful的接口。此处区别于传统的SOA（面向服务的架构）

• 松：松耦合，可以独立部署。每个微服务可以独立编译、独立部署、独立运行

微服务架构的好处是：

• 易于开发与维护：微服务相对小，易于理解

• 独立部署：一个微服务的修改不需要协调其它服务

• 伸缩性强：每个服务都可按硬件资源的需求进行独立扩容

• 与组织结构相匹配：微服务架构可以更好将架构和组织相匹配，每个团队独立负责某些服务，获得更高的生产力

• 技术异构性：使用最适合该服务的技术，降低尝试新技术的成本

• 企业环境下的特殊要求：去中心化和集中管控/治理的平衡，分布式数据库和企业闭环数据模型的平衡

微服务的实践有两个重要问题：什么时候选择微服务架构，以及颗粒度如何拆分，与经验和实际情况息息相关。

上图来自Martin Fowler另一篇叫《 微服务进阶 》的文章，揭示了生产率和复杂度的一个关系。在复杂度较小时采用单体应用的生产率更高，复杂度到了一定规模时，单体应用的生产率开始急剧下降，这时对其进行微服务化的拆分才是合算的。

我个人建议是除非在可见的将来，复杂度都不会显著提高的情况下，才选择单体应用，否则其它时候都应提前为微服务架构做好设计和准备。

微服务基础设施及案例

下图是一个典型的微服务技术架构图。

微服务架构最常见、最广泛使用的框架是基于Java的Spring Cloud（集成了上图里的Netflix OSS技术栈），提供了服务发现、负载均衡、故障转移、动态扩展和数据分区等功能，已经成为微服务的最佳实践。

但是Spring Cloud构建在Java虚拟机之上，不能满足高并发下的性能要求，所以许多开源产品层出不穷，其中也包括中国互联网企业所贡献的微服务框架，例如华为的ServiceComb、阿里的Dubbo等等。

下面我们举一个例子。传统的电商的技术架构如下图所示，这是一个单体应用。

所带来的常见问题包括：

• 不同客户端产品之间，例如小程序、App、网站端有许多相同业务逻辑的重复代码，每个产品都要各自维护一份代码，修改的时候所有地方要一起修改。

• 单个应用经常需要给其他应用提供接口，渐渐地越来越复杂，包含了很多本来不属于它的逻辑，代码变得臃肿，功能边界模糊。

• 系统代码耦合性高，相互之间逻辑复杂，一旦出现开发离职的情况，继任者需要花很长时间review代码，才有可能搞清楚整体架构和逻辑关系。

• 多个应用使用一个数据库，依赖性严重，很难重构和优化。所有应用都在一个数据库上操作，数据库很容易出现性能瓶颈。同时数据库成为单点，出现意外整个系统都会受到影响。

• 即使只改动一个小功能，也需要整个应用一起发布，发布流程繁琐、上线时间长。并且很容易出现一个小bug影响整个系统，每次发布都是胆战心惊，很容易出现开发、运维和测试之间的矛盾。

下面我们用微服务重构整个系统：

改造之后，去除了大量冗余代码，系统复用性得到提升；不同的团队专注于不同的微服务，代码和工程质量得到保证；数据库不再存在单点问题，系统健壮性得以提升；前后端分离，业务逻辑更加清晰；降低了系统耦合性，不同的微服务可以分开部署上线，相互之间并不影响。

组织挑战、康威定律与蜂群理论

请注意，微服务理念不仅反映了技术架构的变化，也反映了组织内部沟通结构为了应对更加灵活、快速、碎片化的需求和环境而变化的结果。例如 液态组织 就是组织形态应对当前市场环境快速变化的一种输出形式，但实际应该如何构建？

曾经有一张非常有名的组织架构图，如下图所示。

对一家企业来说，能一步步不断发展壮大，进入一个领域就能迅速突破，这其中的根本核心必然是组织模式。在粗放发展的年代，很少有企业强调内部效率，组织模式绝大部分都类似单体应用，按照职能划分的方式进行管理，从而创造了无数的烟囱/谷仓。

我在 我的知识星球 里提出过企业级产品设计所面临的重要挑战，其中一个问题是：

• 版本。企业级产品现在经常涉及多个平台和不同的版本，例如Web、PC、App、钉钉、企业微信、微信小程序、飞书的版本等等，第一会面临重复开发的问题，第二业务逻辑非常复杂，很容易造成产品逻辑和体验的不统一，以及不同版本产品之间逻辑的缺失。例如登录和注册微信小程序可能用的是手机号，而通过邮件注册需要使用的却是邮箱。如何设计一套比较好的产品流程和组织架构，来保证统一完善的产品逻辑及用户体验？

是的，这不仅仅是产品和技术问题，还是组织问题。现在越来越多的企业意识到了最大的挑战在于组织内部，无论是增长黑客还是MVP的理念都需要快速灵活的机制来配合。为什么有的组织效率高、能力强，能及时响应客户的需求和环境变化？

新的组织设计理念认为传统的烟囱形式会成为创建有效增长和盈利途径的障碍，需要解构组织孤岛，采用跨职能组织的形式以支持增长。企业组织设计是非常专业的领域，有许多文章讨论，例如《 战胜组织孤岛的战略之路 》，本文不延伸讨论。

我们可以看到单体应用和职能组织，微服务与跨职能组织，在形式上是高度相似的，这引申出微服务背后的理论基础。

“当希望把一个大型应用拆分成多个部分时，管理层通常将重点放在技术层面。而如果组织架构还按UI团队、服务端逻辑团队和数据库团队的标准设立，甚至一个非常简单的变更都将导致跨团队间的项目协作，从而耗费时间和预算审批。一个高效的团队会针对这种情况进行优化，关注它们所涉及的应用逻辑，并从中做出更好的选择。换句话说，逻辑无处不在。这是康威定律的一个实例。”-- Martin Fowler

设计系统的架构受制于产生这些设计的组织的沟通结构（Organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations）-- Melvyn Conway, 1967

康威定律可谓软件架构设计中的第一定律，本质是对商业世界的规律总结，但是因为投稿到编程相关的杂志，后经过《人月神话》这本软件界圣经的引用，并命名为康威定律（Conway's law），因此得以推广。

只通过简单的描述可能无法理解康威定律的精髓所在，原文中康威定律可总结为四项：

• 第一定律 组织沟通方式会通过系统设计表达出来（Communication dictates design）

• 第二定律 时间再多一件事情也不可能做的完美，但总有时间做完一件事情（There is never enough time to do something right, but there is always enough time to do it over）

• 第三定律 线型系统和线型组织架构间有潜在的异质同态特性（There is a homomorphism from the linear graph of a system to the linear graph of its design organization）

• 第四定律 大的系统组织总是比小系统更倾向于分解（The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems）

例如微服务的团队间应该是inter-operate，not integrate（互操作、不集成）。inter-operate是定义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合变弱，跨系统的沟通成本也就能减低。

康威定律可以上升到哲学的高度进行讨论，但是过于复杂。简言之，微服务架构与组织模式互相决定和影响，协同才能发挥出最大价值。

凯文·凯利在《失控》中提出了著名的“蜂群理论”，利用蜂巢思维比喻人类的协作带来的群体智慧：依靠成千上万个发条一起驱动一个并行的系统，进行生产，进行自维持。蜂巢思维就是“群体思维”（Collective consciousness）。作为“超级有机体”的蜂群，被称为“分布式系统”，是以生物逻辑建立起来的群集模型。 由此形成的蜂巢思维这四个理念至关重要：

1）去中心化。几乎所有的团队都直接接触用户与市场，因此所有的团队都将围绕市场格局而变，充分重视第一线的敏感度与直觉，从而做到真正的应时而动；

2）分布式。与垂直型集团组织不同，这个形态打破单一的行业垂直细分格局。在这种多维度矩阵式结构中，拥有更加专注的功能型团队，可建立起一个紧密围绕具体客户与市场的服务体系；

3）强化合作。从控制权、所有权的角度来说，这些组织单元是分离的，因而要建立起一种横向合作的文化，打破物理团队，提倡交流、合作，整体核心竞争力的提升；

4）适应变化。市场在不断变化，但因所有的团队都直接接触用户与市场，因此无论个人还是团队，都将不断的学习和进化。

微服务理念对应的组织模式包括蜂巢型组织，它具有突出的稳定性和抗弯曲能力，特点是：

• 跨组织：它不一定是一个独立的法人实体，而是为了特定目标或项目形成的联盟

• 相对统一：蜂巢组织不是一成不变的，当市场需求或组织目标发生变化时立即变化

• 分享性：它改变了传统的等级分明的金字塔结构，允许信息横向传递与交流，使信息利用更为充分及时

在这样一个以蜂巢为理念搭建的企业圈层里面，各个独立团队能够得到更好的协助与支撑，不断扩大视野，提高眼界，掌握话语权，团队成员也会更有归属感。这样的团队乃至蜂巢本身，也一定会更有活力和变革力，更加能适应市场的变化。蜂巢型组织有四个突出特点，所谓活系统的特质也正是由此而来：没有强制性的中心控制；次级单位具有自治的特质；次级单位之间彼此高度连接；点对点间的影响通过网络形成了非线性因果关系。

蜂巢型组织的典型案例之一是华为。除了组织架构去中心化的管理模式之外，华为的著名的轮值CEO制度正是由此而来，华为有三位轮值CEO，每六个月轮换一次，这体现了依靠集体民主决策而非一人独裁的理念。

再例如国美蜂巢式组织变革的实践是将由四个大区管辖54个分公司，调整为七个大区直接管辖200家分公司的结构，即将原来二级市场里的146家分公司独立出来，直接划归大区管辖，而原来四个大区变成七个大区。实践证明，组织扁平化是国美提升供应链效率，提升消费者消费体验的重要战略。

国外著名的代表案例是微服务先驱Netflix。Netflix是一家技术强大的互联网公司，但是它却没有CTO职位，产品团队和技术团队(包括UI前端工程团队、Discovery搜索工程团队和Platform平台团队等)全部汇报首席产品CPO，产品驱动是该公司的核心文化要素之一，Netflix称其为BusDevOps组织架构。

在整个系列第二部分中，我们介绍了DevOps，现在我们可以理解，DevOps是配合微服务的理念组织构建团队协作的方式，各团队可以独立开发，测试、发布和迭代各自的微服务，互不干扰，沟通协调成本小。全部业务、研发和运维围绕产品开展工作，统一目标，大家都是产品驱动，分别服务于内外不同客户，避免技术驱动 vs 业务驱动的陷阱。

在某些文章中，认为微服务的切割应该按照组织架构来划分，我反而觉得应该按微服务的分割方式来划分组织架构， 因为归根结底，组织架构应该为业务服务，而不是业务为组织服务 ，组织需要贯彻执行微服务的理念，就必须由微服务驱动组织业务的不断迭代演进。

微服务与中台

可能有人会问，中台的目标不也是为了解决企业内部业务系统烟囱林立，数据孤岛严重，各自为战，缺乏复用性，所以要充分提取业务共性，从而及时应对需求变化，听起来和微服务的目标和理念非常相似，那它们之间有什么异同呢？

来自阿里官方的定义，“企业中台就是，将企业的核心能力随着业务不断发展以数字化形式沉淀到平台，形成以服务为中心，由业务中台和数据中台构建起数据闭环运转的运营体系，供企业更高效的进行业务探索和创新，实现以数字化资产的形态构建企业核心差异化竞争力。”

中台架构，简单地说，就是企业级能力的复用，一种方法论，企业治理思想。

微服务，是可独立开发、维护、部署的小型业务单元，是一种技术架构方式。

所以中台并不是微服务，中台是一种企业治理思想和方法论，偏向于宏观，微服务是技术架构方式，偏向于微观。而中台化的落地，离不开使用微服务架构。

中台强调核心基础能力的建设，基础能力以原子服务的形式来建设，并通过将原子服务产品化，支撑业务端各种场景的快速迭代和创新；原子服务和微服务所倡导的服务自闭环思想不谋而合，使得微服务成为实现原子服务的合适架构。

支撑业务场景的应用也是通过服务来实现，其生命周期随业务变化需要非常灵活的调整，这也和微服务强调的快速迭代高度一致，所以业务应用服务也适合通过微服务来实现。

API管理与API集成

下面我们讲讲微服务相关的两个具体领域，API管理与API集成。

1、全生命周期API管理

上文提到微服务各个服务对外都是以Restful API形式提供服务。再加上企业越来越多地使用云服务，各种云服务也提供了众多API。

这就导致企业拥有的API越来越多，那就当然需要有一个系统把这些API统一管理起来。同时，如果能够顺便把这些API的权限认证、安全审计等等机制也一并统一了，那就更好了，这样其它系统调用起来就方便多了。能管了以后，当然又会冒出来更多的想法。比如，能不能改一下原有API的格式内容？能不能把两个API合成一个API？能不能让一个API直接调用另一个API？能不能把这些API的调用自动化串起来？

简单来说，API管理就是解决以上这些问题的。我们来看看Gartner全生命周期API管理领域魔力象限，许多巨头都在里面。值得注意的是，Google之所以排名第一，是因为它在2016年用6.5亿美元收购了刚上市一年左右的Apigee。

2、API网关：微服务基础设施

全生命周期API管理里一个细分的领域是API网关（API Gateway），它是微服务1.0时代最重要的基础设施。

API网关顾名思义，是出现在系统边界上的一个面向API的、串行集中式的强管控服务，这里的边界是企业IT系统的边界，主要起到隔离外部访问与内部系统的作用，并处理常见的南北向流量。在微服务概念的流行之前，API网关的实体就已经诞生了，例如银行、证券等领域常见的前置机系统，它也是解决访问认证、报文转换、访问统计等问题的。

API网关的流行，源于近几年来，移动应用与企业间互联需求的兴起。移动应用、企业互联，使得后台服务支持的对象，从以前单一的Web应用，扩展到多种使用场景，且每种使用场景对后台服务的要求都不尽相同。这不仅增加了后台服务的响应量，还增加了后台服务的复杂性。随着微服务架构概念的提出，API网关成为了微服务架构的标配组件。

API网关作为企业能力开放的一个门户，除了具备基本的请求转发、协议转换、路由等功能，以及高性能和高稳定性外，还需具备良好的扩展性，已便于网关能力的不断增强。在网关实施过程中，要规划好网关层与服务层的交互方式，尽量使得网关层与服务层解耦，便于各个团队工作的独立性。另外，在API的管理上，需要提供API全生命周期的发布、配置、鉴权、流控、监控等配套的管理功能。

例如Uber，在传统的单体架构遇到越来越大挑战的时候，决定改变自己的架构，效仿亚马逊、Netflix、Twitter等其他超级增长公司，将其整体架构拆分为多个代码库，以形成一个微服务架构。其主要变化是引入了API网关，所有的司机和乘客都是通过这个网关连接的。从API网关，所有的内部点都连接在一起，如乘客管理、司机管理、行程管理等。每个单元是单独的可部署单元，执行单独的功能。例如：如果你想在账单微服务中更改任何内容，那么只需部署账单微服务，而不必部署其他服务。所有的功能都是单独扩展的，即每个特征之间的相互依赖被移除。

API网关带来的的好处包括：

• 网关层对外部和内部进行了隔离，保障了后台服务的安全性

• 对外访问控制由网络层面转换成了运维层面，减少变更的流程和错误成本

• 减少客户端与服务的耦合，服务可以独立发展。通过网关层来做映射

• 通过网关层聚合，减少外部访问的频次，提升访问效率

• 节约后端服务开发成本，减少上线风险

• 为服务熔断，灰度发布，线上测试提供简单方案。

• 便于扩展

API网关常见的解决方案包括Spring Cloud Gateway、Zuul、Tyk以及下文要介绍的Kong。

3、Kong：API网关独角兽

Kong是我去年起就在关注的一家公司，它的创业历程非常有意思。“Kong的创始人Augusto Marietti（简称Aghi）出生在罗马，因为意大利创业环境很弱，在2009年飞来了旧金山。Aghi刚来就参加了一个早期创业者的小聚会，聚会上参加的人不多，但现在都是如雷贯耳的名字：Uber的创始人Travis，Airbnb的CEO Brian，Dropbox的CEO Drew和Box的CEO Aaron。Aghi当时为了省钱，借住在Uber创始人Travis家，每天睡沙发。

后来Travis搬了家，Aghi又去了当时只有十多个人的Airbnb办公室里借住，当时的Airbnb虽然Bug很多，但订单量一天天疯涨。在Travis的帮助下拿到天使投资后，Aghi做了一个把云端的组件连接起来的PaaS公司，一做就是五六年。由于时机不对，公司濒临破产，Aghi告诉团队，这么多年公司写了很多小功能，现在可以把代码开放出去，放在网上看看有没有人用，给社区做点贡献。没想到这看似濒死的挣扎，却给公司带来了巨大的转机。

后来，公司关于API管理的代码模块，在GitHub上被疯狂下载，Kong也接到客户要求，希望购买相应的付费企业版。Kong敏锐地发现了这个大机会，迅速转型成了一个开源软件公司。”如果在CSDN博客上搜索，关于Kong开源版本的教程比比皆是。这是一个成功的开源软件商业化的案例，听起来经历和Docker非常相似。

Kong成长的大背景是软件开发技术正在经历革命性变化，全球5000强公司都在转向新的分布式软件架构，因为现代应用程序需要有高度可扩展性、跨平台支持以及处理实时数据流的能力。IDC预计，到2022年90%的应用程序将采用微服务架构和第三方代码，35%的生产应用程序将诞生于云端。由于容器和敏捷方法的采用，预计2018-2023年间将诞生5亿个新应用程序。

同时开源软件初期具有的优势也在逐渐显现。Kong本身基于开源的Openresty（Nginx+lua），但比Nginx提供了更简单的配置方式，数据采用了Apache Cassandra/PostgreSQL存储，由于底层使用Nginx，所以性能比基于Java的Spring Cloud Gateway及Zuul更为出色。Kong另外一个非常诱人的地方就是提供了大量的插件来扩展应用，通过设置不同的插件可以为服务提供各种增强的功能。Kong默认插件包括：身份认证、安全、流量控制、分析监控、转换等等。

Kong提供开源的Kong Gateway和商业版Kong Enterprise两个产品。例如在插件功能上，商业版本提供更多的选择。

Kong通过云原生、混合和本地部署无缝连接API和微服务，便于程序员开发可扩展的微服务应用，推动业务增长。凭借高性能的开源内核和AI技术以及机器学习，Kong将实现全方位的服务生命周期管理，覆盖前期到后期全过程，帮助客户搭建和管理创新产品及服务。它服务于全球5000强企业，帮助程序员更方便地开发和管理高性能、可扩展的微服务应用，推动业务增长。

从业务和融资上来讲，2018年，Kong订单大幅增加，公司员工数翻倍，已服务超过100家企业客户，包括雅虎日本、法拉利、SoulCycle、WeWork等，开源软件下载量超过5400万次，收入为500万美元。2019年，Kong完成了Index Ventures领投，GGV纪源资本、World InnovationLab跟投，老股东Andreessen Horowitz、Charles Rivers Ventures追加的4300万美元C轮融资，至此Kong累计融资共计7100万美元。

4、RapidAPI：全球最大API市场

和Kong紧密相关的另外一家企业是 RapidAPI ，2017年，Kong的母公司Mashape将其API市场业务与RapidAPI合并，从而组成了世界上最大的API市场。

市场研究机构Ovum Research曾经表示，API经济在迅迅猛发展，到2018年将成为产值高达2.2万亿美元的市场。合并后，RapidAPI成为了这个市场的主要提供商之一。

RapidAPI的首席执行官吉纳在宣布合并的博文中表示，“软件相互连接起来后，其功效就要大得多。不妨想一想。你使用Facebook登录到某个游戏应用程序，就能看到玩游戏的所有朋友。当亚马逊的购买门户网站与仓库存货连接起来后，你就能实时获得发货估计日期。如果你在订购机票呢？已经在你的谷歌日历中预定了航班。”吉诺补充道，API正是让那些连接成为可能的秘诀。“它们让不同的软件得以彼此联系，共享信息，并且简化我们的生活。”

吉纳在博文中表示这只是开了个头。API正在迅速发展，打开之前紧闭的许多大门。使用API，开发人员就有可能从任何地方来访问服务，比如IBM公司的超级计算机和谷歌的机器学习模型，这就意味着他们能够充分利用比以前处理的任何资源丰富得多的资源。

吉纳说：“我们想要让广大开发人员更容易寻找、测试和连接API。我们的计划始终未变，那就是将世界上的所有API统统集中到一个地方。将Mashape API市场合并到RapidAPI让我们离实现这个目标比以往更近了一步。现在我们每月总共有370000名开发人员在调用3000亿次API。也就是说，每秒的API调用超过100000次。”

RapidAPI的市场里包括各种各样类型的API，例如天气、体育、科技、通讯、图像处理等等，例如获取新闻信息、实时体育比赛比分、天气信息，甚至还包括新冠病毒API分类。

开发商可以自由的为自己的API接口定价，下图是Twilio SMS接口的报价方案。

2019年，RapidAPI完成了由微软领投、A16Z等跟投的2500万美元B轮融资，历史累计融资达到3750万美元。RapidAPI表示，它将利用这笔新筹集的资金扩大其API市场规模，并推动其新发布的RapidAPI for Teams产品。它是一个自助服务平台，使开发人员能够发布，管理和协调API和微服务，这些是用于构建现代应用程序的常用组件。

5、Mulesoft：API集成/iPaaS/API管理领头羊

1）从SOA讲起

讲API管理之前，我们得先来说说前文提到过的SOA（Service-Oriented Architecture，面向服务的架构）。

简单地说，一个企业建设了许多业务系统，每个系统都拥有自己的数据，那么如何将这些分散各处的数据打通，从而可以进一步加以利用呢？

这就涉及到企业应用集成（EAI，Enterprise Application Integration）这个领域了。

传统上，企业应用集成很多是利用ETL（Extract-Transform-Load，抽取转换加载）工具，把不同系统里的数据经过抽取、过滤、转换，最终导入到一个集中的数据仓库里，然后再做整合应用。但是这种做法也存在很多问题。

一是只认数据，没有脑子。在数据汇集的过程中，只能针对数据格式本身进行一些处理，很难利用业务系统原有的业务逻辑。

二是随着各个系统数据体量越来越大，把所有系统的数据都汇到一个数据仓库里就变得越来越困难。

为了解决这样的问题，SOA应运而生，就是企业中每个系统都对外发布自己的服务，那么系统之间的集成，就可以通过调用对应系统的服务来解决了。

但是，随着企业拥有的系统越来越多，这种系统之间相互调用服务接口的集成方式又遇到了新麻烦。

可能每两个系统之间都需要相互调用服务，这最终就会演变成一个复杂的蜘蛛网结构，使得整个集成变得越来越脆弱，难以维护。

为了解决这个新问题，ESB（Enterprise Service Bus，企业服务总线）的概念被提出来了，就是把每个系统的服务接口都对接到ESB上，这样在系统集成的时候，只需要跟总线打交道，而不再需要直接跟所有其它系统打交道了，从而大大简化了集成的复杂度。

2）Mulesoft

2018年3月，美国SaaS巨头Salesforce花费65亿美元收购iPaaS代表企业Mulesoft，Mulesoft于2017年在纽交所上市，市值约30亿美元。Mulesoft的核心产品是企业软件集成平台Anypoint Platform（旧称Mule ESB），客户可以在Anypoint上集成所有业务系统的服务，实现本地系统与云、以及云与云服务的集成。Anypoint Platform/Mule ESB是世界上使用最广泛的开源ESB产品，已拥有超过数百万的下载量，以及来自世界各地数十万个开发人员，财富500强中35%的企业、全球10大银行中的5家均使用了该平台。

尽管只有一个产品，但从Gartner的划分标准来看，Mulesoft同时踩在了两个领域里：全生命周期API管理和企业集成平台即服务（iPaaS，Enterprise Integration Platform as a Service）。

Mule ESB同时包括开源和商业版本，在各个技术论坛上遍布其技术教程。

Mulesoft的成长历程非常具有参考意义，他们瞄准了一个有7000亿美元空间的市场，目标是解决一个十分困难的IT问题-集成。在摸索过程中Mulesoft不断优化其产品形态和销售方式，例如针对大客户需要的不仅是平台提供的通用功能，还需要更复杂的综合服务。于是MuleSoft把他们的销售方式从出售可靠的集成功能，变成了向高级管理人员出售提升企业连接能力的愿景和相应的解决方案，客单价也从10-30000美元提升到了500万美元。

3）应用场景与案例

Mule ESB的常见应用场景例如：

• 旧系统改造，开放系统的服务能力。举个例子，企业有一个电商系统，需要调用SAP ERP的订单接口来创建订单，这个时候需要将SAP的订单服务暴露成流行的Restful API，以方便电商系统调用。使用Mule ESB可以轻松实现。

• 系统集成。企业之间的数据交换，竟然有一半以上是文件的形态进行的，这在互联网思维普及的今天，是不容易想象的。在10年前，企业间交换数据采用文件形态的比重占60%，当时普遍认为这个比重会迅速下降，最终以接口服务形态进行交换的比重会占绝大多数。然而10年后直至今天，采用文件形态的依然占51%的比重。其实仔细想想，也不无合理。两个对等企业之间，行业上下游多个企业之间，不同系统之间的进行数据交换，采用文件的形式，可能是最简单便捷的方式。举个例子，很多系统之间数据交互可能还是用FTP目录。尤其是企业跟企业之间的数据交互，比如，A企业丢一个EDI文件到B企业的FTP目录，然后B企业会从FTP目录下载解析并放置到数据库。这个场景用Mule ESB实现也很方便。

4）Salesforce为什么收购Mulesoft

Salesforce最初为中小企业提供SaaS的CRM，而随着大客户越来越多，定制化、个性化的需求也越来强烈，所以就需要提供PaaS平台解决个性化、定制化的问题。

而这个定制化，最开始只是以Salesforce为核心的功能延伸及简单扩展，而随着个性化需求的不断深入，这种定制已经逐步演变为更大规模的多个骨干数据源之间的数据集成与交换，Salesforce可能只是多个数据源之一。

所以也可以说，数据集成是PaaS平台的上层建筑，Salesforce需要帮助客户解决整合不同数据源所带来的挑战。

收购之后，Salesforce会将MuleSoft植入进Salesforce Integration Cloud，从而帮助客户连接多个数据源，并计划在之后推出集成云。

所以，可以看出Salesforce其实更在乎的是集成（Integration）这个词。

5）iPaaS、API管理与API集成

iPaaS的集成不光是针对云服务，也包括本地系统，这样就解决了混合云模式下的集成问题。iPaaS集成的范畴，除了API接口之外，一般还会包括更多种类的协议（比如FTP、数据库），也包括对于文件数据的集成。

从这个角度来理解，API管理更关注API的治理与整合，iPaaS关注更大范畴的集成，包含API集成的概念。

6）SOA、ESB与微服务的关系

微服务架构和SOA架构非常类似，微服务是SOA的升华，只不过微服务架构强调的是“业务需要彻底的组件化及服务化”，原单个业务系统会被拆分为多个可以独立开发、设计、部署运行的小应用，这些小应用间通过服务化完成交互和集成。

ESB是一种集中式服务治理的架构，看上去微服务中不需要ESB，Martin Fowler也不赞同在微服务架构中继续用ESB。

我们下面要介绍到的下一代微服务架构核心- 服务网格，则可以视为分布式的ESB 。

微服务2.0：服务网格与Serverless

1、服务网格

微服务当前遇到的挑战包括：

• 技术门槛高：开发团队在实施微服务的过程中，除了基础的服务发现、配置中心和鉴权管理之外，团队在服务治理层面面临了诸多的挑战，包括负载均衡、熔断降级、灰度发布、故障切换、分布式跟踪等，这对开发团队提出了非常高的技术要求。

• 代码侵入性强：Spring Cloud、Dubbo等主流的微服务框架都对业务代码有一定的侵入性，技术升级替换成本高，导致开发团队配合意愿低，微服务落地困难。

为了解决上述问题，号称微服务2.0的服务网格（Service Mesh）应运而生。服务网格这个词最早由著名开源服务网格项目Linkerd所在的Buoyant公司CEO William Morgan所提出。按照他的定义，服务网格是一个软件基础设施层，用于控制和监视微服务应用程序中的内部、服务到服务的流量。

Sidecar是服务网格中的核心组成部分，可以看到，上图中每一个微服务都配备了一个Sidecar。此时用户只需要关心业务逻辑，而不用关心服务治理等非业务功能，非业务功能都由Sidecar负责，接管对应服务的入流量和出流量，并将微服务架构中的服务订阅、服务发现、熔断、限流等功能从服务中抽离到Sidecar中。

服务网格和API网关是两个联系非常紧密的概念，它们的用途既不同，但是在某些方面又相互重叠。在某种程度上，我们可以认为服务网格是一个 分布式的、微观层面的API网关 ，解决微服务服务发现、负债均衡、流量控制等需求。在具体用途上，API网关处理的是所谓南北向流量即内外部请求；而服务网格处理的是东西向流量即内部服务相互间的访问。想深入了解两者区别的读者可以详细阅读《 Service Mesh和API Gateway关系深度探讨 》这篇文章。

服务网格相关的著名项目包括Linkerd、Envoy和最受欢迎的服务网格框架Istio。Kong也于2019年发布了基于Envoy的开源服务网格产品Kuma。

下图是CNCF Landscape里服务网格分类所罗列的项目，其中Linkerd正由CNCF进行孵化。

2、Serverless

Serverless（无服务器架构）这个概念在2012年时便已经存在，比微服务和服务网格的概念出现都要早，但是直到微服务概念大红大紫之后，Serverless才重新又被人们所关注。

Serverless是一种构建和管理基于微服务架构的完整流程，它与传统架构的不同之处在于，完全由第三方管理，由事件触发，存在于无状态、暂存的计算容器内。Serverless相关的重要概念包括FaaS（Functions as a Service，函数即服务）。开发者把函数上传到云厂商的FaaS平台，函数只在被请求时才实例化运行，然后被销毁，其它时候不占用任何服务器资源，完全实现按需使用，大幅度降低了服务器占用和成本。

Serverless通常适用于实时性要求不高、无状态的场景，例如突发事件处理、数据统计分析、视频解码、离线批量计算等等，像AWS FaaS平台Lambda限制用户功能必须在15分钟内完成。

相较服务网格，Serverless概念更为超前，虽然AWS Lambda、阿里云等许多平台都已经提供对其的支持，但是目前仍处于发展早期，无论是成熟项目数量和企业应用程度都相对有限。

微服务 vs 宏服务：新的抉择

最近，Uber支付体验平台的工程经理Gergely Orosz发布推文表示他们的架构方向已经发生了变化。

“声明一下，在Uber，我们正将许多微服务转移到@copyconstruct所称的Macroservices宏服务（大小适中的服务）。

确切地说，B/C测试和维护成千上万的微服务不仅很难——它可能会带来更多的长期麻烦，而不是解决短期问题。

微服务确实可以帮助团队在早期快速推进。

等你意识到服务越少越好时，已为时已晚。你需要解决很多服务的“困难”部分。

我们在不断增加更多的服务，但也在停止使用服务，并且会更慎重的思考新的服务。“

全部的上下文可以在 这里 阅读。有一篇英文文献中这样描述Macroservices宏服务：宏服务应该定义为运行2-20个单独服务的应用程序体系结构，每个服务代表一个中等大小的代码库，可处理业务中定义明确的部分。宏服务的关键是拆分服务，最大程度地从拆分中获得收益，同时最大程度地降低运行多个服务的开销。通俗点讲，宏服务介于单体服务到微服务之间，关注的不再是某一个细节点，而是一个业务点。

实际上，宏服务目前的定义并不清晰，影响和实践相当有限，也并非比微服务更优的解决方案，本质还是不同企业和团队在架构演进中对于系统复杂性的不同度量。

总结

微服务的理念不同的团队有不同的实践，例如微服务如何拆分、组织架构如何搭建、技术栈如何选择。

我们理解，微服务是云原生的核心，后面要介绍到的容器（Docker）和Kubernetes是实现的技术方法和手段，DevOps是配合的文化和研发流程，但是微服务带来的启发，更多是思维方式上的转变。

从下一部分开始，我们将分两期介绍两大核心技术：Docker和Kubernetes。

下一期内容为《云原生时代（四）： 容器与Docker 》

参考文档：

本文的部分内容参考或者引用以下文章，在此表示感谢，如果有涉及知识产权的问题，请联系我及时修改。

“中台不就是微服务吗？有啥区别？”

火热的云原生到底是什么？一文了解云原生四要素！

大神告诉你如何理解微服务框架

Service Mesh 和 API Gateway 关系深度探讨

一文详解微服务架构

Martin Fowler关于微服务的原文翻译（一）

微服务架构的理论基础 - 康威定律

A text interpretation of the cloud native (rpm)

走访了十几家美国企业服务公司，我们写下了这篇万字文章 | GGV投资笔记第一期

从Uber微服务看最佳实践如何炼成？

Mashape 和 RapidAPI 合并，组成全球最大的应用编程接口（API）集市！

放弃微服务，改用宏服务，Uber 这波什么操作？

腾讯大牛深入浅出详解云原生

Service Mesh 和 API Gateway 关系深度探讨

【零壹视界】从Salesforce收购Mulesoft说起，白话讲讲企业数据交换

EnjoyingSoft之Mule ESB开发教程第一篇：初识Mule ESB