2016年伊始，Docker无比兴盛，如今Kubernetes万人瞩目。在这个无比需要创新与速度的时代，由容器、微服务、DevOps构成的云原生席卷整个IT界。在近期举办的QCon全球软件开发大会上，个推应用平台基础架构高级研发工程师王志豪，基于他在基础架构方面多年的经验，分享了《个推基于Docker和Kubernetes的微服务实践》。
个推应用平台基础架构高级研发工程师王志豪
是将单一的应用程序拆分成多个微小的服务，各个小服务之间松耦合，高内聚，每个小的服务可以单独进行开发，不依赖于具体的编程语言，也可以使用不同的数据存储技术，各个服务可以独立部署，拥有各自的进程，相互之间通过轻量化的机制进行通信(如基于HTTP的API接口)，所有的服务共同实现具体的业务功能。
客户端与服务端通信有2种方式，第一种是客户端直接与各个微服务进行通信，这样的架构有4个缺点：
（1）多次服务请求，效率低；
（2）对外暴露服务接口；
（3）接口协议无法统一；
（4）客户端代码复杂，服务端升级困难。
第二种方式是由API网关统一代理各个服务，对外提供统一的接口协议，该架构有3 个优势：
（1）封装服务接口细节，减少通信次数；
（2）统一通信协议，减少客户端代码耦合；
（3）统一鉴权，流控，防***；
在该架构下，网关也有可能成为系统瓶颈。
相应地，这2种架构也带来了2种服务注册发现的方式，第一种是客户端通过向服务的注册中心查询微服务的地址与其通信，第二种是增加统一的API网关来查询。前者会增加客户端的复杂度，开发成本高，第二种操作会显得更加简洁，因此我们在实践的时候选择了第二种架构方式。
微服务数量增加以后，服务之间的调用关系易产生耦合，甚至出现循环调用的情况，最好的应对方法是对服务进行分层，即将相互依赖的服务通过消息队列等技术进行异步解耦，减少服务间的依赖。
服务分层
在实践中，我们的API Gateway使用的是OpenResty, OpenResty基于Nginx并扩展了对Lua的支持，可构建高并发的Web服务。我们通过HTTP接口实现客户端通信，数据基本封装成JSON格式，服务间的通信接口也是基于HTTP，并利用消息队列进行异步解耦；至于服务注册发现，我们使用的是Consul；我们选择了Lua（扩展API Gateway的功能），Node.null
