单机阶段 垂直业务阶段 soa阶段（有可重用的服务代码 通用服务》esb》 微服务阶段 优点：业务更细 整体小 cpu/io密集型有各自的服务 缺点：运维 持续集成 http 数据一致性的问题 soa --信息孤岛 重用 微服务 解耦 spring cloud 微服务的规范 ibm ip 阿里云 ...
转载
2021-08-09 00:47:00
88阅读
2评论
随着微服务的大范围应用，服务发现这个词也变的越来越火热。下面这篇文章，就会对服务发现这个概念进行介绍，介绍主要包含三部分，服务发现的
在java开发中，有一些这样的场景：
项目中加入了某些jar包，编译时也没有错，但运行时就报错了，
找不到类——这其实就涉及到java中面向接口编程。
&nb
原创
2016-10-11 12:05:45
1824阅读
服务发现在微服务架构里，服务之间经常进行通信，服务发现就是解决不同服务之间通信的问题。比如一个nginx的pod，要访问一个mysql服务，就需要知道mysql服务的ip和port，获取ip和port的过程就是服务发现。1.环境变量Pod创建的时候，服务的ip和port会以环境变量的形式注入到pod里，比如pod创建时有一个redis-master服务，服务ip地址是10.4.82.11，port
原创
2021-03-09 11:23:50
667阅读
序言 每次启动prometheus都要启动好长的时间，说好的容器秒启动呢。。啊呸，骗子。。。容器的秒启动只不过容器启动了，而真正提供服务的还是里面的进程，所以呢，实际上并不是秒启动。。。 服务发现，好像用zk的比较多，不要问我为什么不用etcd，就是这么任性，就想用consul。使用consul进行服务发现 1、运行consul容器 默认显示的结果如下（浏览器访问8500端
原创
2021-03-09 20:48:49
327阅读
导航:这里主要是列出一个prometheus一些系统的学习过程，最后按照章节顺序查看，由于写作该文档
Prometheus服务发现 目标列表和关联标签都是采用手动服务发现的方式。不难看出，在繁杂的工作中维护一长串主机列表并不是一个可扩展的任务（HUP的Prometheus服务器也不是每次都可以优雅地启动）。尤其对于大多数环境的动态特性，以及被监控主机、应用程序和服务的规模来说，这种局限性更为明显。因
转载
2020-09-18 10:51:00
205阅读
2评论
服务发现@EnableDiscoveryClient
服务发现在api 管理中是一个比较重要的东西，krakend目前已经支持了多种模式的服务发现 etcd dns （consul，或者其他的） static （默认的） eureka （社区的） 说明 配置都是比较简单的，同时官方文档也提供了相关的说明 参考资料 https://www.krakend
原创
2021-07-15 14:05:08
193阅读
目录背景定义概念服务提供者服务消费者服务中介服务依赖服务配置重加载服务管理后台服务发现的特性高可用注册查找服务中介redis作为服务中介服务提供者进程如果被kill -9暴力杀死，不能主动调用srem命令怎么办？服务保活检查机制服务列表变动时如何通知消
Prometheus添加被监控端支持两种方式：•静态配置：手动配置•服务发现：动态发现需要监控的Target实例 支持服务发现的来源：•azure_sd_configs•consul_sd_configs•dns_sd_configs•ec2_sd_configs•openstack_sd_conf ...
转载
2021-08-01 23:05:00
139阅读
2评论
1.kubernetes本身监控
node资源使用率：监控整个生产环境中的几十、几百甚至上千的node
node数量：只要能监控到node,就能监控到它的数量了，一个node，能运行多少Pods是需要根据资源现状来分析的。
pode数量：每个pode都相当于一个实例instance。
资源对象：pod、services、delployment、job 这些资源状态
pod监控
pod数量（每个项目
原创
2021-11-05 16:28:42
455阅读
左边是一个host，这个host上面运行了不同的进程，一个是消费者的逻辑，业务代码分离开来，它们两个是独立的进程，可以独立的升级和维护，这样我的业务逻辑只关注自己的业务逻辑，我们可以通过某些业务逻辑去访问服务的时候，这些请求全部转发到LB，然后由LB将这个请求转发出去，这个是我们推崇的模式。......
1.父工程<?xml version="1.0" encoding="UTF-8"?><project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org
原创
2022-04-16 09:13:52
47阅读
为何使用服务发现我们假设您正在编写某些代码，这些代码调用了有 REST API 或 Thrift API
的服务。为了发送一个请求，您的代码需要知道服务实例的网络位置（ IP
地址与端口）。在运行于物理硬件上的传统应用中，服务实例的网络位置是相对静态的。例如，您的代码可以从偶尔更新的配置文件中读取网络位置。然而，在现代基于云的微服务应用中，这是一个更难解决的问题，如图 4-1 所示。服务实例具
原创
2021-03-30 21:52:14
1112阅读
服务发现为何使用服务发现我们假设您正在编写某些代码，这些代码调用了有 REST API 或 Thrift API 的服务。为了发送一个请求，您的代码需要知道服务实例的网络位置（ IP 地址与端口）。在运行于物理硬件上的传统应用中，服务实例的网络位置是相对静态的。例如，您的代码可以从偶尔更新的配置文件中读取网络位置。然而，在现代基于云的微服务应用中，这是一个更难解决的问题，如图 4-1 所示。服务实例具有动态分配的网络位置。此外，由于自动扩缩、故障与升级，整组服务实例会动态变更。因此，您的客户
原创
2021-07-26 11:34:07
187阅读
1.在每个服务启动时会向服务发现中心上报自己的网络位置，这样在服务发现中心内部会形成一个服务注册表，服务注册表是服务发现的核心部分，是包含所有服务实例的网络地址的数据库。2.所有服务实例内部都会包含服务发现客户端，服务发现客户端会定期从服务发现中心同步服务发现注册表，并缓存在客户
原创
2022-03-08 17:29:11
79阅读
服务发现为何使用服务发现我们假设您正在编写某些代码，这些代码调用了有 REST API 或 Thrift API 的服务。为了发送一个请求，您的代码需要知道服务实例的网络位置（ IP 地址与端口）。在运行于物理硬件上的传统应用中，服务实例的网络位置是相对静态的。例如，您的代码可以从偶尔更新的配置文件中读取网络位置。然而，在现代基于云的微服务应用中，
原创
2022-02-09 11:03:23
84阅读
原文地址：https://microservices.io/patterns/server-side-discovery.html服务之间需要互相调用，在单体架构中，服务之间的互相调用直接通过编程语言层面的方法调用就搞定了。在传统的分布式应用的部署中，服务地址和端口是固定并且提前预知的，所以只需要简单的HTTP/REST调用或者其他的RPC机制直接调用即可。但是在当下的云原生微服务体系中，微服务大
翻译
2021-03-16 10:06:35
406阅读
