前言

[https://github.com/spring-cloud/spring-cloud-gateway](Spring Cloud Gateway)是Spring Cloud官方推出的一个网关项目，主要是基于reactor-netty实现。网关在微服务系统主要充当了一个入口"门"的作用，所有的IN/OUT都需要经过这一道门，才能访问到微服务池子中的功能api。 这样的设计方便了我们对业务功能的保护api资源的保护，我们可以在这里灵活的控制对外开放的API集合，而这些API集合就构成了我们的"系统"。

我们还可以方便的在这里完成鉴权，如果是非法用户之间在这里干掉，从而避免了对业务的调用。

还可以对参数进行转换，比如从调用者带过来的是一个JWT我们可以解析这个Token，得到诸如currentUserId，租户id，username，等等一些列参数后，再往后传递到具体的微服务上。

这里只是一些常用功能的列举，本质上来说呢，他就是一组Filters，我们可以通过扩展它的Filter，快速完成业务所需要的功能效果。

这里我们已v1.14.4的源代码为基础。 首先需要下载kubernetesv1.14.4到本地，并导入到goland，方便我们进行改。

像elasticsearch这种应用属于重度依赖IO，依赖磁盘，对磁盘敏感的应用，如果采用分布式文件系统（NFS/GlusterFS等）来进行数据的存储，对ES的性能会造成很大的影响。 elasticsearch是具有状态的应用，我们可以采用两种方式部署，STS+LocalPV 或者是Deployment+NodeSelector+HostPath 的方式进行部署，本质上来说两者区别不大。

前言

本章节讨论

1. 我们的git服务器gitlab应该部署在企业内网，还是部署在公网如阿里云上，各自利弊。
2. 我们的代码仓库如何划分比较好。

一下是一个典型的java微服务项目的代码调用结构，分层次的目的在于解耦合，内聚变化，减少重复代码。

为了达到解开的目的我们会采用Pojos来对每层之间的输入输出进行隔离，以期望，如，对视图的改动，格式化，等等不会对业务产生太大影响，为此我们会产生以下对象：

• VO（View Object） 视图对象，他用于展示业务数据的封装格式，常常和视图一一对应。

• QMO（Query Model Object） 查询模型对象。顾名思义，用于查询结构的封装载体

• DTO（Data Transfer Object） DTO对象，即一个数据载体的封装格式。

• DO（Domain Object）领域模型对象，也叫Entity实体对象，这里是我们对业务的模型的抽象模型，映射现实业务中的实体。

• PO（Persistent Object） PO对象，即持久化对象，用户解耦存储和业务直接的关系。实际开发中有了ORM之后，可直接用DO/Entity代替。和存储的（表结构，Document）等格式一一对应。

有了这些对象的基本概念我们就可以对代码结构进行分层，完整的结构如图：

前言

在上一篇中我们完成了kubernetes的高可用集群的搭建，但我们搭建出来的集群状态均显示都是Not Ready，这背后的原因是由于我们的 集群网络并没打通，本文我们将接着上文继续往下中，完成我们的集群网络插件的安装与部署。

1
2
3
4
5
6
7

➜  kubectl get cs
NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok                  
scheduler            Healthy   ok                  
etcd-1               Healthy   {"health":"true"}   
etcd-2               Healthy   {"health":"true"}   
etcd-0               Healthy   {"health":"true"}  

kubernetes的基本概念

写在前面的话

整个安装过程中尽量不要出现写死的IP的情况出现，尽量全部使用域名代替IP。 网上大量的人使用KeepAlive+VIP的形式完成高可用，这个方式有两个不好的地方： 其一，受限于使用者的网络，无法适用于SDN网络，比如Aliyun的VPC。 其二，虽然是高可用的，但是流量还是单点的，所有node的的网络I/O都会高度集中于一台机器上（VIP)。 本文的高可用可通用于任何云上的SDN环境和自建机房环境，如阿里云的VPC环境中。

前言

最近花了一段时间完成了从zuul迁移到Spring Cloud Gateway的工作，记录一下遇到的一个问题。

前言

Java与Docker的结合，虽然更好的解决了application的封装问题。但也存在着不兼容，比如Java并不能自动的发现Docker设置的内存限制,CPU限制。 这将导致JVM不能稳定服务业务！容器会杀死你JVM进程，而健康检查又将拉起你的JVM进程，进而导致你监控你的pod一天重启次数甚至能达到几百次。 我们希望当Java进程运行在容器中时，java能够自动识别到容器限制，获取到正确的内存和CPU信息，而不用每次都需要在kubernetes的yaml描述文件中显示的配置完容器，还需要配置JVM参数。 使用JVM MaxRAM参数或者解锁实验特性的JVM参数，我们可以解决这个问题。