微服务基础架构的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架构与实战」

你可能感兴趣的:(微服务基础架构的5个关键问题)