去哪儿旅行微服务架构实践_去哪儿旅行账号限流

今天我带来的主题是去哪儿旅行微服务架构实践。我将从以下几个方面进行介绍：

1. 背景介绍

2. 微服务架构模式的最佳实践

3. 微服务开发效率的提升实践

4. 微服务治理的实践

5. ServiceMesh 尝试

一、背景介绍

首先介绍一下去哪儿网的业务。去哪儿网是一个典型的在线旅游平台，它上面的业务繁多，有机票、酒店、度假、火车票、汽车票等等。

这些业务都有不同的业务流程，其中机票的标准化和线上化是最高的，但是像酒店这样的业务，在线化和标准化就比较低，同样的名字可能是不一样的酒店。这些业务在从商品、库存到整个交易过程其实都是不一样的，所以这些业务从背后来看还是相对比较复杂的。

我们为什么要选择微服务，其实有以下几个方面的原因。第一个就是业务逐渐复杂，最早去哪儿网其实只有机票的比价，而且是一个搜索比价，是没有交易环节的。后来业务扩展就慢慢地发展出来了包含机票、酒店、火车票、度假、汽车票等等其他的业务。

所以业务是逐渐复杂的一个过程，那按照康威定律大家都知道，业务变化了之后，组织结构要进行相应的调整，组织架构其实也会跟着相应的膨胀，膨胀也会带来协作上和分工上的一定损耗，这也是我们要选择微服务的原因之一。

第三个就是开发效率的低下，我们之前开发的时候大部分都是以最早的模式，也就是通过 HTTP 协议，加上 JSON 这样的数据结构，然后使用 Nginx 作为网关，把服务治理的这些动作全部耦合在业务代码里面，比如重试的逻辑等等。这样的话就会导致我们每一个服务做对应开发的时候，都需要重复性地去考虑这些问题，开发效率相对就会比较低下。

第四个就是服务质量是比较失控的，因为这些服务质量很难能在统一的一个地方去得到比较有效、及时地处理，就像刚才说的治理的逻辑其实是放在了业务代码里面，有一些治理逻辑可能会放在 Nginx 里面，但是 Nginx 是一个大统一的网关，这就意味着当我们想要去对它进行修改的时候，其实是需要非常谨慎的，这就面临了一个运维和开发诉求不对等的问题。使用微服务我们认为是可以比较有效地解决这些问题的。

接着介绍一下我们去哪儿网的在线数据。我们现在的应用数据是这样的：活跃的、在线跑着的应用大概有 3000 多个；提供了 18,000 多个 Dubbo 的 RPC 服务接口；有超过 3500 个 HTTP 域名；13,000 多个 MQ 的主题；公司内部大概有 5 种语言的技术栈，当然主要是以 Java 和 Node 为主。

二、微服务架构模式的最佳实践

接下来介绍一下架构模式，架构模式里面有几个方面不同的范畴。

1. 服务发现模式

第一个就是服务发现的模式，服务发现里面其实有三种模式，这三种模式对应不同的适用场景会有不同的效果。

直联模式，客户端从注册中心发现服务端的列表并缓存在本地，这种模式适合于语言统一的这种内网通信，为什么呢？因为直连模式里面大部分 RPC 采用的这样的模式，主要是比较简单、高效，而且在统一语言的内网通信里面，这种服务端的实例的变更通知是比较简单的。

代理模式，服务端注册到网关上，客户端对一个服务端其实是无感知的，这种模式比较适合于外网服务，为什么呢？是因为当你的服务端变更的时候，客户端其实是不需要去感知，也不需要对此进行任何变更，这样对外网来说，其实用户侧的设备是不需要去关注信息的，这样通知起来就比较简单。但是它也会面临一个问题，它会多一跳的通信，从性能或者效率上来说，肯定是不如直连模式的。

最后一个就是边车模式，Sidecar 去负责注册和发现，应用程序是无感知的，这种比较适合于多语言、多协议的这种内网通信，它其实跟直连模式相对来说是比较相似的，但是它其实是由边车的模式替代了业务程序里面混入的这种基础功能，所以简单来看其实就是直连模式里面把公共的基础设施的逻辑下沉到了边车里面。这样的话边车就可以统一地配合我们的灰度发布或者是其他的热更新的机制，能够做到比较容易地去对这些边车进行升级。

2. 服务通信模式

接下来我们说一下服务通信的模式，服务通信模式里面主要有两种，大家其实日常里面比较经常会碰到就是同步的编程模式，这种模式比较简单易懂，非常符合人类的思考习惯，它比较适用于时间比较敏感的、吞吐量也比较小的这种场景。但是这种通信的方式在吞吐量比较大、QPS 比较高的场景里面就会有一系列的问题，比如说可能会把你的资源耗尽，但其实这些资源都处于等待中。比如我们在 Java 里面可能会有线程池的资源，使用起来其实是比较低效的。然后在异步的这种场景里面，它其实比较适用于高吞吐、削峰填谷的作用。

其实这里面会有几种，从我们的实践上来看的话，比如说搜索系统它其实是一个非常高并发的场景，其实对于这种高吞吐的场景下是必须要用异步的，不然的话其实资源的损耗是非常高的，我们在某些系统上做过改造，由原来的同步改为异步的话，基本上可以节省掉 80% 左右的机器的资源。除此之外，交易系统的事件驱动也是比较适合异步的一个场景，因为交易系统的事件其实是非常关键的，但是它又不能每个人都去通知，因为很多人都需要关注这个事件，这个时候利用 MQ 等方式去做这种事件的驱动是比较合适的。

封装异步 HttpClient

在异步的这个场景里面，去哪儿网其实做了一些内部的支持，比如说我们封装了异步的 HttpClient，把公司内部其他的组件类似于 QTrace，还有一些其他基础的监控、日志等等之类的组件都做了统一的封装埋点。