Kong环境搭建(一)

Kong是一个云原生、快速、可扩展的一个分布式微服务抽象层(API网关)

Kong是一个运行在Nginx中的Lua应用程序，由Lua - Nginx模块实现。Kong与OpenResty一起发布，而不是使用这个模块编译Nginx, OpenResty已经包含了lua- Nginx模块。OpenResty不是Nginx的分支，而是扩展其功能的一组模块。

Kong可以通过Dockers、kubernetes、安装包、源码等方式进行安装，这里我们主要采用Docker进行安装配置。所以事先请自行安装Docker环境，具体可参照Docker官网说明： https://docsdockercom/install/linux/docker-ce/centos/

Kong对外提供了两种端口，一种是Admin Api提供RestFul接口用于管理Services、routes、plugins等配置信息，一种是前端代理的接口。如上面配置的8001和8444、8000和8443分别对应Admin Api和Proxy Request使用的端口。

这里使用Mockbin API进行测试，他是一个"echo"类型的公共站点，将返回和请求一致的响应。

key-auth插件用于处理认证，表示只有携带的有 正确的key 的请求才会被代理到后端的service，否则将被kong 拒绝 。

报错提示：在请求中没有找到key。

现在一聊到容器技术，大家就默认是指 Docker 了。但事实上，在 Docker 出现之前，PaaS社区早就有容器技术了，以 Cloud Foundry、OpenShift 为代表的就是当时的主流。

那为啥最终还是 Docker 火起来了呢？

因为传统的PaaS技术虽然也可以一键将本地应用部署到云上，并且也是采用隔离环境（容器）的形式去部署，但是其兼容性非常的不好。因为其主要原理就是将本地应用程序和启停脚本一同打包，然后上传到云服务器上，然后再在云服务器里通过脚本启动这个应用程序。

这样的做法，看起来很理想。但是在实际情况下，由于本地与云端的环境差异，导致上传到云端的应用经常各种报错、运行不起来，需要各种修改配置和参数来做兼容。甚至在项目迭代过程中不同的版本代码都需要重新去做适配，非常耗费精力。

然而 Docker 却通过一个小创新完美的解决了这个问题。在 Docker 的方案中，它不仅打包了本地应用程序，而且还将本地环境（操作系统的一部分）也打包了，组成一个叫做「 Docker镜像 」的文件包。所以这个「 Docker镜像 」就包含了应用运行所需的全部依赖，我们可以直接基于这个「 Docker镜像 」在本地进行开发与测试，完成之后，再直接将这个「 Docker镜像 」一键上传到云端运行即可。

Docker 实现了本地与云端的环境完全一致，做到了真正的一次开发随处运行。

一、容器到底是什么？

容器到底是什么呢？也许对于容器不太了解，但我们对虚拟机熟悉啊，那么我们就先来看一下容器与虚拟机的对比区别：

上图的左侧是虚拟机的原理，右侧是Docker容器的原理。

虚拟机是在宿主机上基于 Hypervisor 软件虚拟出一套操作系统所需的硬件设备，再在这些虚拟硬件上安装操作系统 Guest OS，然后不同的应用程序就可以运行在不同的 Guest OS 上，应用之间也就相互独立、资源隔离了，但是由于需要 Hypervisor 来创建虚拟机，且每个虚拟机里需要完整的运行一套操作系统 Guest OS，因此这个方式会带来很多额外资源的开销。

而 Docker容器 中却没有 Hypervisor 这一层，虽然它需要在宿主机中运行 Docker Engine，但它的原理却完全不同于 Hypervisor，它并没有虚拟出硬件设备，更没有独立部署全套的操作系统 Guest OS。

Docker容器没有那么复杂的实现原理，它其实就是一个普通进程而已，只不过它是一种经过特殊处理过的普通进程。

我们启动容器的时候（docker run …），Docker Engine 只不过是启动了一个进程，这个进程就运行着我们容器里的应用。但 Docker Engine 对这个进程做了一些特殊处理，通过这些特殊处理之后，这个进程所看到的外部环境就不再是宿主机的那个环境了（它看不到宿主机中的其它进程了，以为自己是当前操作系统唯一一个进程），并且 Docker Engine 还对这个进程所使用得资源进行了限制，防止它对宿主机资源的无限使用。

那 Docker Engine 具体是做了哪些特殊处理才有这么神奇的效果呢？

二、容器是如何做到资源隔离和限制的？

Docker容器对这个进程的隔离主要采用2个技术点：

弄清楚了这两个技术点对理解容器的原理非常重要，它们是容器技术的核心。

下面来详细解释一下：

三、容器的镜像是什么？

一个基础的容器镜像其实就是一个 rootfs，它包含操作系统的文件系统（文件和目录），但并不包含操作系统的内核。

rootfs 是在容器里根目录上挂载的一个全新的文件系统，此文件系统与宿主机的文件系统无关，是一个完全独立的，用于给容器进行提供环境的文件系统。

对于一个Docker容器而言，需要基于 pivot_root 指令，将容器内的系统根目录切换到rootfs上，这样，有了这个 rootfs，容器就能够为进程构建出一个完整的文件系统，且实现了与宿主机的环境隔离，也正是有了rootfs，才能实现基于容器的本地应用与云端应用运行环境的一致。

另外，为了方便镜像的复用，Docker 在镜像中引入了层（Layer）的概念，可以将不同的镜像一层一层的迭在一起。这样，如果我们要做一个新的镜像，就可以基于之前已经做好的某个镜像的基础上继续做。

如上图，这个例子中最底层是操作系统引导，往上一层就是基础镜像层（Linux的文件系统），再往上就是我们需要的各种应用镜像，Docker 会把这些镜像联合挂载在一个挂载点上，这些镜像层都是只读的。只有最上面的容器层是可读可写的。

这种分层的方案其实是基于 联合文件系统UnionFS（Union File System）的技术实现的。它可以将不同的目录全部挂载在同一个目录下。举个例子，假如有文件夹 test1 和 test2 ，这两个文件夹里面的文件 有相同的，也有不同的。然后我们可以采用联合挂载的方式，将这两个文件夹挂载到 test3 上，那么 test3 目录里就有了 test1 和 test2 的所有文件（相同的文件有去重，不同的文件都保留）。

这个原理应用在Docker镜像中，比如有2个同学，同学A已经做好了一个基于Linux的Java环境的镜像，同学S想搭建一个Java Web环境，那么他就不必再去做Java环境的镜像了，可以直接基于同学A的镜像在上面增加Tomcat后生成新镜像即可。

以上，就是对微服务架构之「 容器技术 」的一些思考。

码字不易啊，喜欢的话不妨转发朋友，或点击文章右下角的“在看”吧。

在开发中大型的JavaEE项目时，前后端分离的框架逐渐成为业界的主流，传统的单机部署前后端在同一个项目中的工程项目越来越少。这类JavaWeb项目的后端通常都采用微服务的架构，后端会被分解为诸多个小项目，然后使用bbozookeeper或者springCloud来构建微服务，前端则会是一个单独的项目，前台的请求通过微服务来调用。但是，不同与传统的web项目，这类前后端分离的项目如何在开发中部署和运行呢？

当前后端分离时，后端项目一定会被加载到tomcat的webapp目录下面，但是前端的资源院该如何被访问到呢？这里以tomcat这个中间件为例，探讨在开发这类项目的时候，如何让前后端分离的项目部署并且运行起来，即后端项目部署在tomcat之后如何在运行时访问静态资源（非上线部署）。

主要有两种方案：1在本地通过Nginx来处理这些静态资源。2、将静态资源统一放入一个javaweb应用中，并将自动生成的war包随后端项目一期丢入tomcat。下面详细介绍

一、使用Nginx来访问静态资源。

在本地安装nginx并且修改nginxconf，修改相关配置，将web访问的端口的资源进行更改，配置如下：

server{listen80;server_namelocalhost;charsetutf-8;#aess_loglogs/hostaesslogmain;

location/{proxy_passtomcat_pool;proxy_redirectoff;

proxy_set_headerHOST$host;

proxy_set_headerX-Real-IP$remote_addr;

proxy_set_headerX-Forwarded-For$proxy_add_x_forwarded_for;

client_max_body_size10m;

client_body_buffer_size128k;

proxy_connect_timeout90;

proxy_send_timeout90;

proxy_read_timeout90;

proxy_buffer_size4k;

proxy_buffers432k;

proxy_busy_buffers_size64k;

proxy_temp_file_write_size64k;

}

location~(html|htm|gif|jpg|jpeg|bmp|png|ico|txt|js|css|woff|woff2|ttf|eot|map)${

rootD:Workspacesesop-html;indexindexhtml;

}

listen对象改为你本地的tomcat访问端口，最下面location中的root改为你前端项目中静态资源的位置，这样就可以实现只部署后端的项目就能访问前端的页面了。

二、将前端项目转换为动态的web项目，随后端项目一起丢入tomcat

这个方案省去了在本地安装和配置nginx，但是也只适用于开发阶段项目的部署运行和调试，真正在生产环境通常前后端项目会部署在不同的服务器。

如果是IntellijIdea,在导入前端项目之后，右键项目addframeworksupport-->webapplication，这时将会把前端项目转换为一个javaweb项目，然后将静态资源放在生成的web目录下即可。

如果是eclipse，可以新建一个javaweb项目然后将静态资源放入web或者webcontent目录下，或者直接先导入前端项目，然后通过projectfacts将项目转换为dynamicweb项目并勾选js等相关配置。

然后，运行项目时把后端的war包和前端的war包一同添加到deployment中运行即可。