2016年伊始，Docker无比兴盛，如今Kubernetes万人瞩目。在这个无比需要创新与速度的时代，由容器、微服务、DevOps构成的云原生席卷整个IT界。在近期举办的QCon全球软件开发大会上，个推应用平台基础架构高级研发工程师王志豪，基于他在基础架构方面多年的经验，分享了《个推基于Docker和Kubernetes的微服务实践》。

个推应用平台基础架构高级研发工程师王志豪

一、微服务化

微服务架构

微服务是将单一的应用程序拆分成多个微小的服务，各个小服务之间松耦合，高内聚，每个小的服务可以单独进行开发，不依赖于具体的编程语言，也可以使用不同的数据存储技术，各个服务可以独立部署，拥有各自的进程，相互之间通过轻量化的机制进行通信(如基于HTTP的API接口)，所有的服务共同实现具体的业务功能。

客户端与服务端通信有2种方式，第一种是客户端直接与各个微服务进行通信，这样的架构有4个缺点：

（1）多次服务请求，效率低；

（2）对外暴露服务接口；

（3）接口协议无法统一；

（4）客户端代码复杂，服务端升级困难。

第二种方式是由API网关统一代理各个服务，对外提供统一的接口协议，该架构有3 个优势：

（1）封装服务接口细节，减少通信次数；

（2）统一通信协议，减少客户端代码耦合；

（3）统一鉴权，流控，防***；

在该架构下，网关也有可能成为系统瓶颈。

相应地，这2种架构也带来了2种服务注册发现的方式，第一种是客户端通过向服务的注册中心查询微服务的地址与其通信，第二种是增加统一的API网关来查询。前者会增加客户端的复杂度，开发成本高，第二种操作会显得更加简洁，因此我们在实践的时候选择了第二种架构方式。

微服务数量增加以后，服务之间的调用关系易产生耦合，甚至出现循环调用的情况，最好的应对方法是对服务进行分层，即将相互依赖的服务通过消息队列等技术进行异步解耦，减少服务间的依赖。

服务分层

微服务的具体实践

1.技术选型

在实践中，我们的API Gateway使用的是OpenResty, OpenResty基于Nginx并扩展了对Lua的支持，可构建高并发的Web服务。我们通过HTTP接口实现客户端通信，数据基本封装成JSON格式，服务间的通信接口也是基于HTTP，并利用消息队列进行异步解耦；至于服务注册发现，我们使用的是Consul；我们选择了Lua（扩展API Gateway的功能），Node.js（用于开发后端服务），Java（用于密集计算和与大数据通信的场景）作为主要的开发语言。

2.具体实现过程

在实践过程中，我们使用Lua开发了自己的微服务框架——WebLua，其封装服务之间的通信协议和访问外部资源（如Mysql、Redis等）的方法和依赖，同时提供了应用插槽。我们可以将每一个APP看成一个功能模块，每个APP都需要插到WebLua中才能运行。WebLua可以方便地将模块进行组合，既可以一个APP运行一个微服务，也可以多个APP一起对外提供服务。如此，开发者只需关注业务APP开发，很大程度上提高了开发效率。上图右侧是具体的代码目录结构，每个APP可分为Action，Page，Data三层，Action层在请求处理前后进行拦截，可做某些特殊处理，如请求前进行权限校验等；Page层主要对请求的参数进行解析和校验；Data层负责具体业务处理，同时提供了Shell脚本，可实现APP打包和部署安装。

二、 API网关

在架构中一个重要角色就是API网关，下面来做一个介绍。

从上面的对比图中可以看到，左侧是没有API Gateway的，很多的模块如Auth，Logging等，这些代码都需要自己去实现，造成了模块的重复建设，同时侵入了服务，功能扩展比较困难；右侧的图是使用了API Gateway之后的架构图，所有通用模块均在API Gateway实现，维护简单，一处建设，各处受益。在这种情况下，对API Gateway也提出了更高要求——其功能必须可以很方便地扩展。

为了实现这样的API网关，我们基于 OpenResty，借鉴了Kong和Orange的插件机制，通过插件来扩展API网关功能。

从上面的API Gateway架构图中可以看到，网关安装诸多插件，每个插件会在请求的一个或多个阶段发挥作用。插件配置会在Consul上更新，实时生效，插件规则可灵活配置。在操作中，我们为插件开发者提供了更多的自由，开发者可以自己定义格式。

三、容器化

在微服务落地实践时我们选择了Docker，下面将详细介绍个推基于Docker的实践。

首先网络组件选择的是Calico，服务注册发现和配置管理选择的是Consul。Consul-Template可实时监测Consul配置和服务的变化。

个推镜像体系是以CentOS为基础系统镜像，安装OpenResty，Nodejs，JDK，由此得到环境镜像，再在这个基础上安装微服务框架，获得Gorp镜像。再在这个基础上安装具体应用服务，得到应用服务镜像。

服务注册发现和配置更新流程

在API网关中，服务注册通过Consul-Agent来实现，配置更新通过Consul-Template实现。Consul-Template主要更新3类配置，包括：Services：代理的所有微服务的服务地址；Products：简言之即请求到微服务的映射表，如左上所示，所有请求都有统一个规范，从Host中可以获取Prod，从URI中可以获取APP，这 2个信息可将请求动态路由到具体服务；Nging-Conf：产品的Nginx配置。

应用服务容器，服务注册的方式跟API网关一致。首先，服务通过容器内部运行的Consul Agent将服务注册到Consul上，其次通过Consul-Template来监测观察 Consul上配置的变化，并更新配置文件。OpenResty或者WebNode配置的更新是直接覆盖相应的配置文件，然后重启对应的服务。

上图是个推基于Docker的集群架构，从中可看到，Docker集群包括3个节点，整个微服务分为3层，最上层是API Gateway，中间是业务层，最下层是一些多产品公用的基础的微服务。

四、Kubernetes实践

微服务虽然有很多好处，但也带来了很多问题，其中一个就是运维复杂。以前运维只需要面对一个单体应用即可，现在可能面临的是几十甚至上百的微服务。在这种情况下，我们需要借助Kubernetes来解决问题。Kubernetes是Google开源的一个容器编排工具，可用于协助管理容器。

一开始，我们将容器向Kubernetes集群迁移时，没做任何改变，只是采用Pod将所有的服务体系在Kubernetes集群运行。但随着深入使用Kubernetes，我们对微服务做了一些改变。

1.首先我们换成用Deployment的方式来部署服务，Deployment会保证服务时刻有一定的副本存活，提高了服务稳定性。

2.其次，我们使用了Service，它可以代理Pod实现负载的均衡。

3. Kube-DNS可以将Service名解析成具体的ClusterIP，并且当Service没有删除重建时，其ClusterIP不变，如此DNS解析的缓存就不存在失效问题。基于Kube-DNS和Service的特性，后续我们改造了服务注册发现体系。

上图是我们当前的服务部署方式，Pod用Deployment的方式创建，用Service来进行代理。

在实践过程中，我们还遇到了另一个问题，即配置管理问题。

（1）微服务化后配置文件多而分散；

（2）不同环境之间有很多不必要的差异，如数据库名；

（3）在很多不同环境中，相同的配置项暴露给测试和运维；

（4）没有版本控制，回滚比较麻烦；

（5）基于Consul的Web UI无法对非法的输入进行校验。

针对这些问题我们做了以下调整：

（1） 统一不同环境间不必要的差异；

（2） 对配置文件进行模板化，只暴露差异部分，同时可实现不同配置文件集中配置；

（3）基于Consul开发配置中心，对产品配置集中管理；对输入进行合法性校验；增加版本控制，方便回滚。

配置中心流程图

关于日志服务，我们在应用容器中集成了Fluent-Bit，配置了2个输入源，TCP和tail， 输出也有2个，一个是Elasticsearch，所有的日志都会上传到ES通过Kibana展示查询，另一个是日志审计服务，有些需要进行审计的操作日志会发送到日志审计服务进行进一步的分析处理。

微服务数量增加以后，请求链路可能延长，开发者在追踪问题和排查性能瓶颈时会很不方便，因此我们引入了Zipkin，其主要用于分布式链路追踪，在API Gateway实现了一个插件进行Span收集，后端服务则通过开源的中间件来实现。

上图是个推目前的整体架构图，最底层是K8S集群，上面部署了Kube-DNS，Consul用于服务注册发现和配置管理，再者是我们分层的微服务体系，右侧是一些辅助的管理系统。

五、总结

上述是个推基于Docker和Kubernetes的整个微服务实践过程，我们在实践微服务过程中做了9件重要的事情，简化了操作流程，提高了工作效率。个推设计实现了自己的微服务框架，完成微服务的容器化部署，自研API网关，并基于Consul的服务注册和配置管理，使用Kubernetes对容器进行编排，基于Service和Kube-DNS对服务注册和发现体系进行改造，搭建了自己的配置中心，优化了日志服务，实现了Zipkin链路追踪。