微服务基础架构的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\u0026amp;ConfigService：Apollo客户端Client通过ConfigService感知并获取实时配置。两者的发现机制是，ConfigService启动时首先注册到Eureka，Client再通过MetaServer(相当于Eureka Proxy)获取ConfigService的地址列表，并通过客户端软负载的方式连接ConfigService。这个连接采用long pulling方式，支持ConfigService实时推送数据到Client，且Client会定期重连获取配置，实现推拉结合效果。
• Portal\u0026amp;AdminService:Portal是给用户使用的配置管理(添加、修改和发布等)界面，AdminService是实际操作配置的接口服务。两者的服务发现机制是，AdminService启动时首先注册到Eureka，Portal再通过MetaServer(Eureka Proxy)获取AdminService的地址列表，并通过客户端软负载的方式调用AdminService。
• Eureka\u0026amp;MetaServer：Apollo采用Eureka做服务发现。在服务提供端，ConfigService和AdminService启动时会自动注册到Eureka。服务消费端比较复杂，首先，Apollo引入MetaServer以屏蔽Eureka服务发现接口的复杂性，简化多语言客户端接入，MetaServer相当于是Eureka Proxy；其次，MetaServer无状态以集群方式部署，需要前置Nginx做负载均衡；最后，Client和Portal通过Nginx-\u0026gt;MetaServer-\u0026gt;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架构与实战」