Docker 部署 Spring Cloud 项目详细步骤

作者 | boonya

链接 | blogcsdnnet/u011508407

准备工作

JDK18、Docker1121、CentOS70

（1）到Oracle官网下载好 jdk-8u181-linux-x64targz 备用 （2）卸载系统自带的java

（3）安装jdk

（4）配置环境变量

找到：export PATH USER LOGNAME MAIL HOSTNAME HISTSIZE HISTCONTROL 这一行，并在其下面一行添加如下内容：

使环境变量生效

测试安装

（1） 查看内核版本(Docker需要64位版本，同时内核版本在310以上，如果版本低于310，需要升级内核)

（2） 更新yum包：

（3） 添加yum仓库：

（4） 安装Docker

（5） 启动Docker

（6）配置docker远程访问

执行命令编辑文件

找到这一行

改为

修改完成后保存并重启Docker

测试访问 >

 一套好的日志分析系统可以详细记录系统的运行情况，方便我们定位分析系统性能瓶颈、查找定位系统问题。上一篇说明了日志的多种业务场景以及日志记录的实现方式，那么日志记录下来，相关人员就需要对日志数据进行处理与分析，基于E(ElasticSearch)L(Logstash)K(Kibana)组合的日志分析系统可以说是目前各家公司普遍的首选方案。

  作为微服务集群，必须要考虑当微服务访问量暴增时的高并发场景，此时系统的日志数据同样是爆发式增长，我们需要通过消息队列做流量削峰处理，Logstash官方提供Redis、Kafka、RabbitMQ等输入插件。Redis虽然可以用作消息队列，但其各项功能显示不如单一实现的消息队列，所以通常情况下并不使用它的消息队列功能；Kafka的性能要优于RabbitMQ，通常在日志采集，数据采集时使用较多，所以这里我们采用Kafka实现消息队列功能。
  ELK日志分析系统中，数据传输、数据保存、数据展示、流量削峰功能都有了，还少一个组件，就是日志数据的采集，虽然log4j2可以将日志数据发送到Kafka，甚至可以将日志直接输入到Logstash，但是基于系统设计解耦的考虑，业务系统运行不会影响到日志分析系统，同时日志分析系统也不会影响到业务系统，所以，业务只需将日志记录下来，然后由日志分析系统去采集分析即可，Filebeat是ELK日志系统中常用的日志采集器，它是 Elastic Stack 的一部分，因此能够与 Logstash、Elasticsearch 和 Kibana 无缝协作。

软件下载：

  因经常遇到在内网搭建环境的问题，所以这里习惯使用下载软件包的方式进行安装，虽没有使用Yum、Docker等安装方便，但是可以对软件目录、配置信息等有更深的了解，在后续采用Yum、Docker等方式安装时，也能清楚安装了哪些东西，安装配置的文件是怎样的，即使出现问题，也可以快速的定位解决。

Elastic Stack全家桶下载主页： >1、保存用户信息 到 服务器内存,用于会话保持

2、jsessionId存储到浏览器的cookie里，登录后每次访问都要 带上这个，与用户信息绑定,如果jsessionId被人**,容易遭受csrf 跨域攻击。

3、如果登录用户过多, 服务内保存的session信息 占用内存较大

由于项目组件的变大，往往会把 应用部署多份，再用nginx 做负载均衡，提高系统的并发量。

这时 由服务器来 存储session 就会出现出现问题：

接下来就引入了 分布式session的 方案：

不讲 session信息存储在 服务器内部,引入第三方中间件如redis,mongodb,将session统一放到 第三方中间件这里，然后 再统一从 这取。

因为在微服务应用中,网关是 系统 所有流量的入口。在网关中 进行权限校验，理论上是可行的。

当请求携带登录返回的token时, 请求网关, 由网关来 向认证服务器 发起 校验token 的请求。

但是这样还有一个很重要的问题, 就是下游服务 不做权限校验的话，那么 下游服务 的接口 就完全相当于裸奔的, 别人知道下游服务的接口地址，就可以直接调用, 非常的危险。

所以，在这种方案中,一般 还会加上ip白名单校验, 下游服务 只允许 网关 发过来的请求,其他 来源不明的请求,直接在防火墙 拦截调。以保证, 下游服务的接口 只能网关转发过来并且 是 网关鉴权通过的。

理论上 网关 服务器是不需要进行权限校验的，因为 zuul 服务器没有接口， 不需要从 网关 调用业务接口，网关 只做简单的路由工作。下游系统在获取到 token 后，通过 过滤器把 token 发到认证服务器校验该 token 是否有效，如果认证服务器校验通过就会携带 这个 token 相关的验证信息传回给下游系统，下游系统根据这个返回结果就知道该 token 具 有的权限是什么了。

这种方式 不会有 接口裸奔的风险, 也不用加ip白名单校验,更可以 进行方法级别的校验,粒度更细。

不管 是只在网关层做权限校验,还是只在下游服务做权限校验,在oauth20的权限校验模型中, 所有 校验token的过程,都需要与 认证服务器 进行一次 交互, 这点 不太好,多了一次 网络请求。

---