不少企业正着手将原本的整体式应用程序转化为微服务架构。在这种新的模式之下，应用程序由一系列通过API实现通信的细粒度服务构成。微服务架构有望加快开发、创新与云扩展速度，带来更好的基础设施优化效果，并极大减轻开发人员的日常负担。也正因为如此，这种新模式甫一出现就得到了技术行业的普遍关注。

但是，这并不是说微服务策略实现起来就很容易（如果大家正在推进这方面工作，就会发现这其实非常困难）。企业当中往往有多个从事着不同事务、不同项目的不同部门，而且其地理位置甚至都不在同一处。在这样的背景下，我们该如何真正从微服务架构当中受益？

在本文当中，我们将解释成功的微服务方案为什么必须配合专门的基础设施以实现服务的构建与管理，如何通过API共享服务访问，以及为什么需要对管辖范围之外的共享API进行管理。此外，我们还将介绍Istio这个用于支持微服务管理的开源项目，以及这项技术如何帮助我们控制微服务普及给整个组织带来的潜在混乱难题。

利用API作为通信合约

各项协作服务之间通过API进行相互通信。简而言之，API代表的是软件与软件之间的对话方式。API定义了服务提供程序与服务使用程序之间的通信合约。当然，您是否将提供程序及消费程序定义为“服务”或者“应用”其实并不重要，真正重要的是API确实定义着双方如何发出请求以及接收响应。

目前，最常见的API技术实现方式当数通过HTTP/1发送并接收JSON RESTful消息。当然，API也可以采用HTTP/2或者TCP，并使用gRPC、GraphQL、jsonRPC或者其他数据与消息表示形式。虽然API多种多样，但它们只是在具体范式方面略有差异，本质作用并无区别。

在把应用程序“拆分”成通过API相互通信的一组服务时，就会引发一系列新的问题：如何管理这些相互依赖的服务，以及各服务之间的通信内容？随着服务集或者实例数量的增加，服务管理问题也开始变得愈发严重。

举例来说，使用微服务进行业务构建时，首先需要考虑的一大要点就是如何保护微服务之间的往来流量。保障通信安全的一种常见方法，就是采用互传输层安全（mTLS），用以确保交互中两个对等方能够相互认证。身份验证一旦完成，大家就可以根据TLS证书所断言的调用方身份，在接收请求的服务上执行授权决策。但是，如果我们一共只有两项服务，那么这项重要功能确实非常简单易行；但随着服务数量的增加，事情会变得越来越复杂、越来越困难。为了缓解问题，我们可能需要尝试使用客户端库。

但现实情况是，服务往往由各种语言开发而成：Java、C#、Python、Golang或者Node.js等等。如果需要使用这五种不同语言独立实现的服务集，那么策略的应用与适配将变得极为困难。复杂性增长的同时，我们显然需要一套更好的模型，用以管理基础设施并控制其中可能出现的混乱状况。

走入Service Mesh 的世界

“微服务架构”这个术语指代的是一种常规模式，而Service Mesh则代表着实现该模式的一种特定方法。Service Mesh提供一种透明且具备语言中立性的方式，帮助我们灵活、轻松且自动实现应用程序网络功能。

简而言之，Service Mesh的意义在于解决服务网格的连接、保护、控制与观察等现实问题。Service Mesh能够处理服务到服务间的交互，包括负载均衡、服务到服务身份验证、服务发现、路由以及策略实施等任务。

Istio是一个专门提供Service Mesh的开源项目，得到谷歌、IBM、红帽、Lyft、思科等公司的支持，并被eBay、Autotrader、Trulia、Continental以及惠普等企业应用于实际生产当中。

Istio旨在帮助用户实现对网格内各项服务的连接、保护、控制以及观察等操作。

连接：Istio帮助我们以智能方式控制服务之间的流量与API调用；服务通信名称连接至其从属服务，且在目标服务所有可用运行时实例之间实现负载自动均衡。另外，重试、断路、金丝雀测试发布等操作也全部实现了自动化处理，并针对当前网格进行配置。

保护：Istio通过托管形式的身份验证、授权以及加密等机制自动对服务间通信内容加以保护。每项服务都具有一个由X.509证书声明的身份，该身份将自动设置完成并用于实现双向（相互）传输层安全（TLS），用以授权并加密所有API交换内容。

控制：Istio能够实现跨服务策略应用（例如路由、速率限制以及配额等）与实施。入站与出站通信皆在控制范围之内，甚至包括发送至外部系统的请求。

观察：Istio可通过对服务的自动跟踪与操作日志记录确保运营可见性。

在微服务系统中采用Istio等Service Mesh的目的，在于为一组紧密互通的系统提供更好的安全性、更高的可靠性、更低的成本、更强大的可扩展能力以及更出色的弹性水平。

一窥服务网格

这里我们假定存在某一应用程序，用于为零售商提供定制化库存管理功能，其中包含以下几种彼此协作的相关服务：

Service Mesh中定义的策略，可能负责指示定价服务只能对其数据存储进行出站调用，而产品服务则可调用位置、库存与定价服务，但除此之外无法进行任何其他调用。

如果团队利用Kubernetes作为这些服务的基础平台，则Kubernetes能够确保及时停止服务中的不正常实例并启动新的实例。而Service Mesh则负责确保新的实例仍由同一组策略加以控制。

与网格外的消费程序共享API

Service Mesh通常主要关注组成应用程序的所有不同服务之间相互通信的管理与控制问题。当然，我们也可以定义一个Istio网关以接收入站请求。但这还不够，我们也有必要将服务使用程序的请求纳入网格当中，同时着手管理出站请求（可能是SaaS CRM系统，也可能是其他外部管理服务）。

这里我们回到示例当中：产品服务需要接受来自客户端的入站请求，例如运行在无数智能手机上的应用程序。但是，产品服务可能需要根据发起调用的用户身份对具体操作行为做出调整。手机上的应用程序利用“产品API”（由产品服务公开的通信合约）发送请求。此外，产品服务可能还需要接入Salesforce系统。

对于那些来自与网格内服务明确分离的外部系统的入站请求，我们应如何加以保护、控制与管理？（「明确分离」这类示例可能包括第三方应用程序，甚至是同一企业内不同业务部门或团队的请求。这些分离系统本身的要求与服务间通信要求往往存在巨大差异。）

对于外部或移动客户端，我们不能仅依靠TLS证书来声明入站请求的身份。虽然应用程序开发商也会将客户端证书置备于移动应用当中，但在大多数情况下，客户端并不具备可用的传输级安全机制。当然，客户端也可以使用其他形式的身份声明，具体取决于消息级别的安全性与签名机制，例如自签名JWT等。

通常，系统可能还需要验证人类用户的身份。虽然在Service Mesh当中，服务身份就是唯一身份；但对于来自移动应用程序、信息亭或者Web应用程序的请求，人类用户身份往往同样重要。一般来讲，这种身份验证无法单凭X.509证书完成，而需要使用能够声明用户身份信息的令牌（例如OAuth）来实现。

外部消费程序的速率限制也各有不同，具体可能取决于消费方应用程序（或者「客户端」）开发商的选择。例如，合作伙伴构建的客户端应用可能要求获取更高的权限与更可观的交易配额。这些限制通常用于支持业务需求，或者用于保护整体系统而非单一服务。

可能需要根据客户端用例或者用户的身份，对初始API请求及响应做出修改或过滤。例如，轻量级客户端可能需要压缩数据格式以替代JSON。或者，客户端可能需要获取JSON的筛选视图，即返回其中的一部分字段，并省略其他字段。

这些不同的要求往往实际出现在不同的外部开发应用当中，同时直接关联到那些与目标服务明确分离的任意客户端或者服务消费程序。对于由开发人员在服务开发团队之内构建的客户端，我们一般没必要对其请求做出验证与限制；毕竟一旦客户端应用（或者消费服务）出现行为异常，API发布团队可以立即通知其内部合作伙伴，并由客户端应用开发团队对其加以修复。但对于外部合作伙伴开发的客户端，我们必须对其请求做出更多验证，因为我们不可能像联系内部同事那样轻松与对方工程师建立沟通渠道。这就需要采取更严格的管理策略，也正是API管理方案最重要的起效场景之一。

API管理——API共享的基础

对微服务进行共享，意味着需要将其公开为API，以供服务构建团队之外的开发人员使用。在小型团队之外共享的微服务API必须接受管理。在这方面，API管理基础设施（例如Google Cloud提供的Apigee API管理平台）能够帮助我们满足外部系统发送来的请求中的不同要求。此外，Apigee还支持将Istio作为API网关或者执行点。API管理方案使我们能够：

通过面向外部核心应用开发团队的开发人员发布API实现API共享。这些外部开发人员需要获取API访问授权，同时了解如何利用这些API构建自己的应用程序与客户端。核心应用团队则需要一种行之有效的方法，用以区分由不同开发人员构建的客户端，甚至是区分由同一位开发人员构建的多种客户端。这一切都将通过开发者门户实现，并允许开发人员为各API建立自注册与自置凭证机制。

通过将API视为“数字产品”以实现产品生产。这意味着：

将相关API收集到一个统一的消费单元之内，以实现发布与共享。

将可能具有不同来源的互补API划分在同一组内，同时规范这些API的安全性要求（速率限制、安全凭证、消息签名等）。

将SOAP转换为JSON，从而将缓存或者验证逻辑打包在“裸机”或者原生内部API中，旨在实现API现代化。

可直接实现API货币化，例如向开发人员收取入站流量费用。

报告使用趋势、流量拆分、延迟以及用户体验。这意味着API产品团队能够将相关见解反馈至API的设计当中，将API作为数字产品进行迭代，从而最大程度提高业务价值。此功能建立在分析子系统的可扩展性基础之上。

将API管理与服务管理进行比较

服务管理与API管理并不是同一回事。一家典型的大规模信息驱动企业往往需要提供数千项服务，并通过API将其中数百项服务共享给外部人员。服务管理与API管理分别负责满足以下不同领域中的实际需求：

一家成熟的企业可能要求实现以下目标：

所有服务都应得到管理；各服务将具有统一的合并日志记录、跟踪、mTLS以及重试策略，且通过松散管理的API实现服务访问。

所有在初始所有域之外进行共享的API必须接受管理。团队之外的开发人员可以查看这些API、请求对其进行访问并获取凭证。外部开发人员所开发的应用程序则应受到更为严格的控制与限制。另外，通过分析相关数据指导共享API的修改，并及时发布通报。

但是，Istio等Service Mesh与Apigee等API管理平台之间，也确实存在着一定的功能逻辑交集。

Istio与Apigee都：

对请求实施管理策略（速率限制、配额以及令牌验证）。

能够基于请求中的数据执行请求路由。

收集日志记录信息以提高可观察性。

利用通信代理实现上述控制能力。

但是，这两套系统在本质上针对的是不同类型的需求。服务管理主要面向由彼此之间紧密或松散联系的开发团队所构建的各项服务，其中包括各服务之间的某些通信——例如服务间TLS实施、自动证书提供、速率限制或者路由功能。

在另一方面，API管理则主要面向核心团队之外的共享API管理。这里所说的之外，可能是团队中职能差异较大的成员、公司内其他部门的员工，或者是来自其他企业的开发人员。无论如何，API使用方与API提供方之间都存在着明显的分离关系，因此需要对API进行更为严格的管理。

尽管从技术层面看确有相似之处，但二者的要求却相去甚远。特别是随着所管理服务数量的增加以及发布团队之外共享API规模的提升，企业可能需要专用的基础设施以管理每一项服务与API。

惠普公司如何管理微服务

惠普公司专门面向消费者与企业客户提供各类打印解决方案，其已经在各内部核心部门之间建立起核心服务共享体系，包括身份管理与内容管理机制。

惠普公司卓越技术专家兼平台架构师Galo Gimenez-Palop表示，之所以决定迁移至微服务架构，主要是考虑到公司业务对于高速迁移能力的迫切需求。由于不少大规模团队需要立足各自职能范围参与应用开发，这就要求公司必须协调好其中的同步与沟通工作。

Gimenez-Palop在采访中表示，“我们以前主要使用持续集成流水线，整个过程一般需要几个小时。而且由于存在大量的依赖关系，因此只能以手动方式确定某些尝试到底是取得了进展，还是一直在原地踏步。”

考虑到这种现实需求，惠普公司自然将目光投向承诺带来更快开发速度的微服务架构身上。利用微服务架构（与Kubernetes容器编排方案相配合，能够显著加快团队在应用程序构建与部署方面的速度表现），各个规模较小的开发团队只需要关注自己负责的小型代码库，且不同服务各自独立生产，从而显著减少对其他团队的依赖。正如Gimenez-Palop所强调，“谁构建，谁运行。”

但是，从整体式应用程序过渡至分布式微服务架构，也确实给惠普带来了不少挑战——特别是快速增长的微服务数量问题。Gimenez-Palop指出，从编排难题到服务发现挑战，到修改服务依赖项带来的功能破坏，到“策略推广”，再到保障新版本服务与其他服务的集成能力等等，整个过程可谓是困难重重。

Gimenez-Palop提到，“我们要如何确定某个团队会在何时修改某项服务的某个版本？很难，这极大提升了集成测试的执行难度。因为现在，每发布一项服务，就需要与其他一系列服务共同进行集成测试，否则将无法预测新服务上线后给生产体系带来的实际影响。”

他还补充道，“一旦开始使用微服务，大家会发现整个体系很容易陷入复杂而混乱的泥潭。”

事实证明，惠普的Istio的帮助下逐步走出了这片泥潭。通过在微服务的连接、保护、监控与管理等层面提供标准化方法，Istio简化了微服务通信的复杂性。而作为实现服务对服务控制与可靠性的重要平台，Istio也高效完成了应用层的负载均衡、路由与服务身份验证等任务。

在惠普公司内部，他们通过向团队内、企业中以及外部合作伙伴与开发人员公开API的形式，实现了与其他各业务部门的微服务核心服务共享。

但在将微服务作为API进行公开时，又需要配合API管理以保护系统安全，从而轻松在企业内部与外部开发人员之间实现微服务价值扩展。惠普公司为此引入了Apigee平台，从而获得了理想的安全性、可见性与可控制性。
Gimenez-Palop总结道，“我们可以与API的使用方签订书面合约，我们可以了解这些使用方如何使用不同服务的API。我们也可以将授权、身份验证以及有效负载检查等策略统一起来。”

有可能单独使用服务管理吗？

随着服务在企业中变得越来越普遍、越来越细化，通过专用Service Mesh基础设施建立标准化服务管理制度也开始成为一种必需。

但是，单凭Service Mesh就够了吗？具体视情况而定。如果所有相互协作的服务是在同一所有域内（例如由公司内的工程总监一手掌控）构建及管理的，且很少通过公开API与外部人员（及其团队）进行访问共享，那么Istio这类Service Mesh已经基本可以满足要求。毕竟服务的受众都是内部人员，而且不同服务之间也没有明显的分离状态。

但如果服务以可消费形式的外部API进行公开，那么无疑应该引入API管理以作为服务管理的良好补充。

二者结合，效果更好

微服务确实是个好主意，但成功的微服务实施方法要求我们正确引入用于构建并管理这些服务的工具与基础设施。通过API共享的服务必须受到严格保护，公开于所有域之外的API同样需要管理。我们需要在所有域内与域外之间划下明确的界线，并借此判断需要对哪些API调用活动给予关注、而哪些不太需要。

Service Mesh与API管理是一对互补的好兄弟，能够通过协作解决与服务及API相关的多种不同问题。二者虽然都使用通信代理，也具有相似的功能，但所有域的差异成为双方最核心的区别。而且，对大多数企业而言，将二者加以结合能够带来更好的管理效果。

原文链接：
Google Cloud：Got microservices? Service mesh management might not be enough

创作场景

谷歌：走向微服务新时代啦？单凭 Service Mesh 管理可能还不够