用“外部架构”来解决平台能力

一旦内部架构已经建立，架构师就需要关注组成他们微服务架构的外部架构的功能。外部架构的一个关键组成部分是引入企业服务总线（ESB）或类似的中介引擎，它们将会帮忙把历史数据和服务与微服务架构连接起来。中介层也将使企业可以维护自己的标准，同时让别人可以在相应的生态系统里管理他们自己的。

使用服务注册中心可以支持依赖管理、影响分析、微服务和API的发现功能。这也可以把服务和API的组合流水线化，并把微服务连线到服务经纪人或枢纽。任何微服务架构都应该支持创建RESTful API，这将有助于在企业开发应用软件时定制资源模型和应用逻辑。

先设计API，再实现微服务，然后通过API将它提供出去，要注意提供出去的是API而不是微服务。要坚持这样的原则。各家企业都想要解决的另一个共同需求是微服务的安全问题。在一个典型的单体应用程序中，企业将使用底层存储库或用户存储区来生成来自旧架构的安全层所需要的信息。在微服务架构中，企业可以利用在业界广泛采用的API安全标准，比如OAuth2和OpenID Connect等，去实现对边缘模块的安全层，包括微服务架构中的API。

在所有这些能力中，最重要的也是真正有助于解决微服务架构复杂性的是使用企业级的底层平台，它可以提供丰富的功能来管理可扩展性、可用性和性能。这是因为把一个单体应用分解成微服务并不意味着一个简化了的环境或服务。可以肯定的是在应用层面，企业本质上是在处理几个微服务，这远比一个单一的复杂的应用更简单。然而，作为一个整体的构建却是相当地艰巨。

事实上，微服务架构的复杂度可能更大，因为我们当需要考虑其他方面时，比如向一个进程发起一次单向调用这不算复杂，但微服务之间是需要相互调用的。这在本质上意味着，系统的复杂性已经变成了所谓的“外部架构”，这通常由API网关、服务路由、发现、消息通道和依赖管理等组成。

因为内部架构现在已经极其简单，它只包含用来构建一个微服务架构的基础和运行时，架构师将会发现现在微服务架构已经有了一个干净的服务层。我们需要更多地关注外部架构，以解决大家所共同面临的复杂性。如图1所示，有一些常见的切实的场景需要解决。

外部架构将需要一个API网关，以帮助它对内对外提供业务API的能力。通常，大家会使用API管理平台来管理这方面的外部架构。这对于那些正在构建Web应用程序、移动应用程序和物联网解决方案等的用户来说，把这些基于微服务架构的服务能力提供给他们是非常必要的。

图1

一旦微服务到位，就会出现某种形式的服务路由，通过API发过来的业务请求将被路由到相关服务集群或服务。在微服务内部，会有以分担负载为目的的多个实例。因此，有必要进行某种形式的负载均衡。

此外，微服务之间也有相关性。例如，如果微服务A对微服务B有依赖，它将在运行时调用微服务B。服务注册中心可以让微服务发现后台服务节点，所以它可以解决这个需求。服务注册中心还将管理API和服务依赖关系，以及其他资产，包括策略。

接下来，微服务架构外部架构需要一定的信息传递渠道，这基本上形成了一层，允许微服务内部的交互，并且该层还把微服务架构连接到旧的系统。此外，这一层也有助于建立微服务之间通信（微整合）通道，并且这样的通道应该是轻量级的协议，比如HTTP、MQTT等等。

当微服务之间相互通信时，需要有某种形式的身份验证和授权。使用单体的应用程序时这是不必要的，因为有一个直接的过程调用。相比之下使用微服务时，这些就转化成了网络调用。最后，诊断和监控都是需要考虑的关键方面，以找出由每个微服务处理的请求类型。这将有助于企业扩展单个微服务的规模。