前言

• 在上一篇文章优雅的使用Prometheus Operator中我们搭建起来了监控的基础堆栈。下来我们来监控我们的业务服务。
• 监控这个SpringCloud的java微服务的方式有很多，比如说基于eureka的服务型和基于kubernetes的endpoints的注解服务发现。

阅读全文

前言

在前面我们搭建起来了eureka,和配置中心，基于这两者我们就能愉快的写业务代码了。这章节我们看下怎么业务服务和业务服务直接如何完成调用。

阅读全文

前言

Zipkin是一个开放源代码分布式的跟踪系统，每个服务向zipkin报告计时数据，zipkin会根据调用关系通过Zipkin UI生成依赖关系图。简单的来说就是个http服务器 它支持多种后端存储（“cassandra”,“mysql”,“elasticsearch”）持久化客户端推送过来的数据.

阅读全文

前言

在分布式系统中，我们的配置管理起来是很麻烦的一件事儿，特别是在如果没有配置中心的时候。在我们java开发中，一般而言会将敏感配置信息（如DB的user，password），数据库的地址，redis地址等等， 一系列配置信息和项目代码解耦，根据每个环境单独配置，这样一来是方便不需要改代码，也不需要在项目中冗余多份，二来是更加的安全。那么分离之后我们将面临的问题是怎么读取这个配置文件：

阅读全文

前言

eureka 在springcloud体系中，主要实现一个注册中心的角色，所有的服务都将注册到eureke中，调用用者将从这里通过名称获取到对应的服务的IP集合列表。 作为一个分布式系统eureka在CAP中，选中了AP，优先保证可用性，放弃了强一致性，这样设计也符合注册中心的需要。 当发生网络分区故障（15分钟内超过85%的节点都没有正常的心跳），eureka会启用注册保护，即维持住当前心跳虽然失败的服务列表，并不进行删除。并能正常的提供查询服务（虽然不是最新）和注册服务（即不会同步到其他eureka节点），当网络恢复时，eureka会正确的同步信息，和恢复删除过期节点信息。

阅读全文

在https://qingmu.io/2019/08/06/Run-Spring-Cloud-Gateway-on-kubernetes/文章中，我们搭建好了基本的网关的架子。这篇文章中 我们继续剩下的部分，将网关和部署到k8s中，并结合Ingress完成域名访问我们的网关，通过Secret完成网关HTTPS的安全加密。

阅读全文

前言

[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，快速完成业务所需要的功能效果。

阅读全文

前言

• 前后花了两周多个时间完成了 Spring Boot 1.5.6.RELEASE & Spring Cloud Dalston.SR4 升级到 Spring Boot 2.0.6.RELEASE & Spring Cloud Finchley.SR2 & spring-cloud-netflix 2.0.2.RELEASE 的工作。
• 总结一下遇到的一些问题

阅读全文

目标

• 扩展ribbon完成灰度调用
• 完成对zuul的支持
• 完成服务间调用的支持
• 实战，解决在开发环境，进行开发中的测试,DEBUG.在微服务的模式下,需要在开发者的机器启动大量服务， 启动大量的服务需要大量的内存和大量的时间，在我们时间的项目开发中，在16G的机器上甚至无法进行调 和测试相关工作。

阅读全文