eureka

随着互联网的发展，微服务的使用是必然的，现在微服务在每个企业中都是必须的。 微服务架构并不是一种新的方法，多年来，它的核心思想一直以SOA（面向服务的体系结构），Web服务以及模块化和分层架构的形式存在。 其实在未来几年中，微服务架构将快发展到更高的水平，单体应用将只被用来进行原型设计。那么，试问谁不想在互联网时代拥有一个模块化、高性能并且易于扩展的应用程序呢？ 那么，你对微服务架构了解多少呢？ 今天LZ在逛Github上面的刷到了四份微服务架构笔记， 每一份都有将近86.9K的点赞，真的是很不错， 都是层层递进的讲解了一下微服务架构，所以就整理了一下，本着好东西都要分享的原则，给小伙伴们展示一下： 需要以上四份微服务架构笔记的小伙伴可以一键三连后加文末扫码即可免费领取~ 微服务架构笔记学习目录大纲（还是很形象的）： Day1 微服务架构基础+服务+注册中心 毫无疑问，无论学习什么，都要先对这个知识点有一个清楚的认知，至少是要知道它是做什么的？什么时候会用到？它的优势和劣势？等等都是需要知道的。所以笔记一，就是从基础开始的： 1 微服务基础知识 2 SpringCloud概述 3 案例措建 4 服务注册Eureka基础 5 服务注册Eureka高级 6 Eureka替换方案Consul 7 服务调用Ribbon入门 8 服务调用Ribbon高级 Day2 微服务架构笔记服务调用

Spring Cloud Alibaba | Nacos服务注册与发现 Springboot: 2.1.6.RELEASE SpringCloud: Greenwich.SR1 如无特殊说明，本系列文章全采用以上版本 [TOC] 上一篇 《Spring Cloud Alibaba | Nacos服务中心初探》 我们聊了什么是Nacos以及Nacos如何搭建，这一篇我们接着聊Nacos如何简单使用。 首先，Nacos是一个服务注册和服务发现的注册中心，在Spring Cloud中，可以替代Eureka的功能，我们先聊一下Nacos如何和Spring Cloud集成做一个注册中心。 整体流程为： 先启动注册中心Nacos 启动服务的提供者将提供服务，并将服务注册到注册中心Nacos上 启动服务的消费者，在Nacos中找到服务并完成消费 1. 服务提供者 新建一个producer的项目，项目依赖如下： 1.1 pom.xml项目依赖 <?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

Zuul简介： Zuul是Netflix开源的微服务网关，它可以和Eureka、Ribbon、Hystrix等组件配合使用。Zuul的核心是一系列的过滤器，这些过滤器可以完成以下功能 身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求 审查与监控：在边缘位置追踪有意义的数据和统计结果，从而带来精确的生产试图 动态路由：动态地将请求路由到不同的后端集群 压力测试：逐渐增加只想集群的流量，以了解性能 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求 静态响应处理：在边缘位置直接建立部份响应，从而避免其转发到内部集群 多区域弹性：跨越AWS Region进行请求路由，旨在实现ELB（Elastic Load Balancing）使用的多样化，以及让系统的边缘更贴近系统的使用者 为什么使用微服务网关： 客户端会多次请求不同的微服务，增加了客户端的复杂性 存在跨域请求，在一定场景下处理相对复杂 认证复杂，每个服务都需要独立认证 难以重构，随着项目的迭代，可能需要重新划分微服务 某些微服务可能使用了防火墙/浏览器不友好的协议，直接访问会有一定的困难 微服务网关的优点： 易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析 易于认证。可在微服务网关上进行认证，然后再将请求转发到后端的微服务，从而无需在每个微服务中进行认证

Eureka\Consul\Zookeeper异同 Eureka由于有自我保护机制，属于AP范畴。 组件名 语言 CAP 服务健康检查 对外暴露接口 SpringCloud集成 Eureka Java AP 可配支持 Http 已集成 Consul Go CP 支持 HTTP/DNS 已集成 Zookeeper Java CP 支持 客户端 已集成 CAP理论参考： http://www.ruanyifeng.com/blog/2018/07/cap.html C: Consistency 强一致性 A： Availability 可用性 P: Partition toterance 分区容错性 CAP理论关注粒度是数据，而不是整体系统设计的策略 CAP理论的核心是：一个分布式系统不可能同时满足一致性，可用性和分区容错性这三个需求，因此根据CAP原理将NoSQL数据库分成了满足CA原则，满足CP原则和满足AP原则三大类 CA 单点集群，满足一致性，可用性的系统，通常在可扩展上不太强大 CP 满足一致性，分区容错性的系统，通常性能不是特别高 AP 满足可用性，分区容错性的系统，通常可能对一致性要求低一些。 来源： oschina 链接： https://my.oschina.net/u/1020373/blog/4767804

最近发现SpringCloud构建微服务架构中，网上很多只是用到了SpringBoot2.x之前的版本，显然使用SpringBoot2.x之后构建，网上的资料会给初学者带来很多不方便，而且没有多大的参考价值，所以，这里将使用SpringBoot2.0.0版本，构建SpringCloud Eureka服务治理。 服务治理分了两部分：注册中心和服务提供者 工具环境：IntelliJ IDEA 一、搭建注册中心 1、打开IDEA，File->new->Project->maven... 如上图所示，这一步很重要，因为创建maven项目可以有很多种方式，如果构建简单的项目，可以选择快速maven，但是SpringCloud Eureka肯定必须要选择那个webapp项目，不然的话，结果出来会无法正常访问Spring Eureka页面。创建项目的后续操作这里不详细述说，相信很多玩过maven项目的都会。 2、配置pom文件，导入相关包 <!-- SpringBoot 2.0.0 依赖 --> < parent > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-parent </ artifactId > < version > 2.0.0.RELEASE </

开场白 当项目拆分成多个微服务时，这个时候多个服务就需要进行管理，服务提供者把服务注册上去，其他消费者就可以进行调用了，当有新的服务注册上来,客户端会定时拉去服务列表跟 本地存在的服务列表对比，进行服务列表的更新，当有服务下线，也会更新列表,服务提供者和消费者是动作的主要发起者，eureka注册中心是处理请求的接收者,可以先从eureka客户端作为入口研究,看看主动发起者是怎样和注册中心完成通信的。 源码分析 1、EnableDiscoveryClientImportSelector加载启动类的所有元数据信息 2、加载所有jar自动配置类并去掉重复的类,然后就是类的自动装配 3、DiscoveryClient是EurekaClien的默认实现类，这个类是单例，并且实现了EurekaClient和LookupService 4、DiscoveryClient类里面有个定时任务初始化的方法，这个方法里面的逻辑还是比较复杂的，第一个是每隔30s定时获取最新的服务列表；第二个是每隔30s定时续约服务；第三个是首先周期注册服务，然后每隔30s定时刷新防踢，注册服务。 5、DiscoveryClient里面通过client调用远程服务进行服务续约，注册是同样的原理。 总结 一、eureka客户端做了下面几件事情： 1、定时获取服务最新列表 2、定时续约注册的服务 3、注册服务到注册中 4

好长时间没发文了，最近着实是有点忙，当爹的第 43 天，身心疲惫。这又赶上年底，公司冲 KPI 强制技术部加班到十点，晚上孩子隔两三个小时一醒，基本没睡囫囵觉的机会，天天处于迷糊的状态，孩子还时不时起一些奇奇怪怪的疹子，总让人担惊受怕的。 本就不多的写文章时间又被无限分割，哎~ 打工人真是太难了。 本来不知道写点啥，正好手头有个新项目试着用阿里的 Seata 中间件做分布式事务，那就做一个实践分享吧！ 介绍 Seata 之前在简单回顾一下分布式事务的基本概念。 分布式事务的产生 我们先看看百度上对于分布式事务的定义：分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 额~ 有点抽象，简单的画个图好理解一下，拿下单减库存、扣余额来说举例： 当系统的体量很小时，单体架构完全可以满足现有业务需求，所有的业务共用一个数据库，整个下单流程或许只用在一个方法里同一个事务下操作数据库即可。此时做到所有操作要么全部提交 或 要么全部回滚很容易。 分库分表、SOA 可随着业务量的不断增长，单体架构渐渐扛不住巨大的流量，此时就需要对数据库、表做 分库分表 处理，将应用 SOA 服务化拆分。也就产生了订单中心、用户中心、库存中心等，由此带来的问题就是业务间相互隔离，每个业务都维护着自己的数据库，数据的交换只能进行 RPC 调用。

联席作者：谢璐 谢庆芳 伊安娜 任浩军<br />郑重鸣谢：Nacos - 彦林，Spring Cloud Alibaba - 小马哥、洛夜，Nacos 社区 - 张龙（pader）、春少（chuntaojun） 相关文章推荐： 掌门教育微服务体系 Solar | 阿里巴巴 Nacos 企业级落地上篇 掌门教育微服务体系 Solar | 阿里巴巴 Nacos 企业级落地中篇 前言 在高速发展的时候，公司规模越来越大，老师人数越来越多，这时候公司不能铺太多人去做运营与服务，必须提高每个人效，这就需要技术驱动。因此掌门教育转变成一家技术驱动型的公司，如果被迫成为一家靠资金驱动的公司就活不下去了。 -- 张翼（掌门教育创始人兼CEO） 掌门教育自2014年正式转型在线教育以来，秉承“让教育共享智能，让学习高效快乐”的宗旨和愿景，经历云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ，一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展，特别是今年的疫情，使在线教育成为了新的风口，也给掌门教育新的机遇。 随着业务规模进一步扩大，流量进一步暴增，微服务数目进一步增长，使老的微服务体系所采用的注册中心 Eureka 不堪重负，同时 Spring Cloud 体系已经演进到第二代，第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模，同时它目前被

前言 最近参加了几场 Java 面试，发现大多数的微服务实践还是 Eureka 偏多，鉴于笔者的单位选型 Consul，这里对 Consul 做简单总结。 该篇是 Docker 实战系列的第三篇。传送门: Docker 实战之 MySQL 主从复制 Docker 实战之 Redis-Cluster 集群 为什么选 Consul？ 首先 Consul 有以下几个关键特性: 服务发现：支持服务发现。你可以通过 DNS 或 HTTP 的方式获取服务信息。 健康检查：支持健康检查。可以提供与给定服务相关联的任何数量的健康检查（如 web 状态码或 cpu 使用率）。 K/V 存储：键/值对存储。你可用通过 consul 存储如动态配置之类的相关信息。 多数据中心：支持多数据中心，开箱即用。 WEB-UI：支持 WEB-UI。点点点，你就能够了解你的服务现在的运行情况，一目了然，对开发运维是非常友好的。 作为高频的提问方式，面试官永远从十万个为什么开始。但是最为程序员，还是需要 知其然，知其所以然 。以下是几个常用的服务发现组件的对比。 服务发现组件的选型主要从以下几个方面进行。CAP 理论、一致性算法、多数据中心、健康检查、是否支持 k8s 等。 1. CAP 一致性的强制数据统一要求，必然会导致在更新数据时部分节点处于被锁定状态，此时不可对外提供服务，影响了服务的可用性。 2.

本文节选自我开源的 JavaGuide ： https://github.com/Snailclimb/JavaGuide （Github标星92k+!一份涵盖大部分 Java 程序员所需要掌握的核心知识。准备 Java 面试，首选 JavaGuide！） 经历过技术面试的小伙伴想必对这个两个概念已经再熟悉不过了！ Guide哥当年参加面试的时候，不夸张地说，只要问到分布式相关的内容，面试官几乎是必定会问这两个分布式相关的理论。 并且，这两个理论也可以说是小伙伴们学习分布式相关内容的基础了！ 因此，小伙伴们非常非常有必要将这理论搞懂，并且能够用自己的理解给别人讲出来。 这篇文章我会站在自己的角度对这两个概念进行解读！ 个人能力有限。如果文章有任何需要改善和完善的地方，欢迎在评论区指出，共同进步！——爱你们的Guide哥 CAP理论 CAP 理论/定理 起源于 2000年，由加州大学伯克利分校的Eric Brewer教授在分布式计算原理研讨会（PODC）上提出，因此 CAP定理又被称作 布鲁尔定理（Brewer’s theorem） 2年后，麻省理工学院的Seth Gilbert和Nancy Lynch 发表了布鲁尔猜想的证明，CAP理论正式成为分布式领域的定理。 简介 CAP 也就是 Consistency（一致性） 、 Availability（可用性） 、 Partition