微服务基础架构的 5 个关键问题

作者介绍：

杨波，微服务技术专家，曾主导了拍拍贷微服务架构体系建设。任职携程技术研发总监期间，主导了携程大规模 SOP 体系建设，也是极客时间「微服务架构实战160讲」课程讲师。

一、OAuth2 的四种模式该如何选择？

OAuth2 协议主要规范了四种授权模式，在实际应用中选型的时候，我们主要通过如下三个维度进行考虑：

第一方还是第三方应用？

所谓第一方应用就是你足够信任的组织开发的应用，例如淘宝 App 是淘宝自己开发的，对它的授权方式是淘宝充分信任的，可以认为是第一方应用。所谓的第三方应用就是你并不信任的组织开发的应用，例如某第三方公司基于淘宝开放 API 开发的 App，淘宝并不信任这个应用，那么它就是第三方应用。

谁拥有访问令牌？

授予访问令牌表示授予客户应用一种权限，能够去访问受保护的资源。如果你授权机器去访问资源，不需要用户的参与，那么就采用客户端凭证模式(Client Credentials Grant)。如果需要用户参与授权，那么还要继续看客户类型。

哪种客户应用类型？

• Web 服务器端应用，客户应用住在 Web 服务器上，使用授权码模式(Authorization Code Grant)。

• 单页 SPA 应用，整个 Web 应用都住在前端浏览器中，对于第一方应用，可以使用用户名密码模式(Resource Owner Credentials Grant)；对于第三方应用，使用简化模式(Implicit Grant)。

• 原生 Native 应用，对于第一方的无线原生应用，可以使用用户名密码模式；第三方的原生应用应该使用授权码模式，注意要使用原生浏览器，而不是使用嵌入式的浏览器。

戳此试看「微服务安全架构与实战」

二、如何理解 Apollo 配置中心的架构？

在 2018 年度最受欢迎开源软件评选中，携程开源配置中心 Apollo 名列 Top20 之内，这一方面说明 Apollo 解决了微服务应用配置复杂的一大痛点，同时也说明社区对微服务需要集中配置的普遍认同。Apollo 配置中心架构相对复杂，但理解其架构对正确部署和使用 Apollo 非常重要，Apollo 本身采用微服务架构，使用了服务发现和软负载等分布式技术，它的核心组件和服务发现机制如下：

• Client&ConfigService：Apollo 客户端 Client 通过 ConfigService 感知并获取实时配置。两者的发现机制是，ConfigService 启动时首先注册到 Eureka，Client 再通过 MetaServer(相当于 Eureka Proxy)获取 ConfigService 的地址列表，并通过客户端软负载的方式连接 ConfigService。这个连接采用 long pulling 方式，支持 ConfigService 实时推送数据到 Client，且 Client 会定期重连获取配置，实现推拉结合效果。

• Portal&AdminService:Portal 是给用户使用的配置管理(添加、修改和发布等)界面，AdminService 是实际操作配置的接口服务。两者的服务发现机制是，AdminService 启动时首先注册到 Eureka，Portal 再通过 MetaServer(Eureka Proxy)获取 AdminService 的地址列表，并通过客户端软负载的方式调用 AdminService。

• Eureka&MetaServer：Apollo 采用 Eureka 做服务发现。在服务提供端，ConfigService 和 AdminService 启动时会自动注册到 Eureka。服务消费端比较复杂，首先，Apollo 引入 MetaServer 以屏蔽 Eureka 服务发现接口的复杂性，简化多语言客户端接入，MetaServer 相当于是 Eureka Proxy；其次，MetaServer 无状态以集群方式部署，需要前置 Nginx 做负载均衡；最后，Client 和 Portal 通过 Nginx->MetaServer->Eureka 方式间接发现目标服务。

戳此试看「微服务配置中心Apollo架构与实战」

三、微服务网关 Zuul 承担哪些核心职责？

网关在微服务基础架构中承担重要职责，这些职责一般是非业务性的，称为跨横切面职责(cross-cutting concerns)，包括：

1. 单点入口：企业内部的系统虽然是由诸多微服务组成，但是对于外部的客户端来说，这些内部细节可能会不断变化，应该被隐藏，即网关为外部客户隐藏内部实现细节，提供单一抽象入口。另外，通过引入网关这层抽象，让内外两边不强耦合，可以相互独立变化。

2. 路由转发：由于外部客户端看到的是单点入口，而内部是复杂的微服务系统，当请求进入的时候，网关需要将请求按照某种规则(例如根据请求 path)定位并转发到内部具体的微服务，即网关要承担路由转发的职责。

3. 限流熔断：面对外部的突发流量(比如双十一促销)，网关需要有限流和熔断的能力，保护后台服务不被突发流量冲垮。

4. 日志监控：网关是外部流量到内部系统的集中入口点，非常适合收集访问日志，对流量进行集中监控。

5. 安全认证：同样由于集中入口点的特性，网关非常适合承担集中安全认证、防爬虫防攻击等职责。

Zuul 是经过 Netflix 大规模微服务落地验证，后被 Pivotal 进一步封装推广的一款生产级的微服务网关，通过 Zuul 特有的可插拔过滤器(pluggable filter)机制，可以很方便地实现上述职责。

戳此试看「微服务网关Zuul架构与实战」

四、如何使用 CAT 进行微服务调用链埋点？

对一个分布式微服务系统进行埋点，为了将端到端的调用链串起来，一些关键的地方需要埋点：

• 网关的入口和出口：网关是外部客户接入内部系统的集中入口，适合采用 CAT 进行集中埋点，在请求进入的地方需要埋点，按照 CAT 的术语，这个地方产生的叫 Root Transaction，表示整个调用链的启动，在调用后台服务的地方也需要埋点，同时注意需要将 CAT 调用链上下文(CAT Context)向后台传递(一般以 HTTP Header 方式)。

• 后台服务的入口和出口：在每个后台服务的入口点，都需要用 CAT 埋点，注意在入口埋点时需要先恢复 CAT 调用链上下文，这样上下游调用链才能串联起来。在每个服务的出口点(如果有对其它服务进行调用的话)，同样需要用 CAT 进行埋点，同样也要向后传递 CAT 调用链上下文。

上述埋点应该尽量集中封装，提供封装好的框架给业务方直接用，降低业务方接入 CAT 的复杂性，尽量避免业务方直接埋点。

戳此试看「微服务调用链监控CAT架构与实战」

五、Hystrix 的线程和信号量隔离的优劣以及试用场景

信号量隔离，优点是轻量，无额外开销，不足是不支持任务排队和主动超时，不支持异步调用，适用于：

• 受信客户：比如内部服务调用我们一般认为是受信的，而第三方服务我们不确定其性能，一般认为是不信的。

• 高扇出：所谓高扇出就是一个服务要调用很多(几十甚至上百个)其它服务，网关就是这种场景，需要调用很多后台服务，如果每个后台服务调用都用一个线程池隔离，开销就非常大，所以适合信号量隔离。

• 高频高速调用：例如对于缓存的访问，一般是高速高频，适合用信号量这种轻量隔离机制。

线程池隔离，优点是支持排队和超时，也支持异步调用，不足是线程调用会产生额外的开销，适用于：

• 不受信客户：比如调用第三方服务，可能很慢，可以用线程池隔离。

• 有限扇出：如果内部服务调用扇出是有限的，一般不超过十个，可以考虑用线程池隔离。

戳此试看「微服务容错限流Hystrix架构与实战」