eureka

前面我们已经学习过 Spring Cloud Config 了： Spring Cloud 系列之 Config 配置中心（一） Spring Cloud 系列之 Config 配置中心（二） Spring Cloud 系列之 Config 配置中心（三） 它提供了配置中心的功能，但是需要配合 git、svn 或外部存储（例如各种数据库），且需要配合 Spring Cloud Bus 《Spring Cloud 系列之 Bus 消息总线》 实现配置刷新。 前面的课程中我们也学习了 Spring Cloud Consul，当时讲解了它作为注册中心的使用方案，且作为 Spring Cloud 官方推荐替换 Eureka 注册中心的方案。既然使用了 Consul，就可以使用 Consul 提供的配置中心功能，并且不需要额外的 git 、svn、数据库等配合，且无需配合 Bus 即可实现配置刷新。 Spring Cloud 官方声明 Consul 可以作为 Spring Cloud Config 配置中心的替代方案。 官方文档：https://cloud.spring.io/spring-cloud-static/spring-cloud-consul/2.2.2.RELEASE/reference/html/#spring-cloud-consul-config 关于 Consul

微服务确实是行业的一个趋势，我自己也在把一些项目往微服务架构迁移。玩微服务架构配置中心是一个绕不过去的东西，有很多大牌的可以选，比如spring-cloud-config，apoll，disconf等等。而我为什么还要造一个轮子呢？一来这些都不是.net实现的，我就想试试用.net core实现一个，而且他们也对.net不太友好，也只有apoll提供了官方的.net客户端。二来这些组件都太重量级了，比如apoll，光跑起来就要部署多个节点（admin,portal,meta sevice）还要依赖eureka。很多旧的项目往微服务迁移的时候并不是一下次全部调整完成的，可能是一步步来的，比如先把所有的服务都容器化，并没有使用微服务全家桶。而且有的项目也不需要微服务全家桶，毕竟微服务不是银弹，很多项目单体结构就足够了，有些项目传统的SOA架构也可以了。（唠叨一句，那种毫无流量毫无并发的项目，几人几天就搞完的强上微服务真的好吗？）但是这些项目也可能是分布式的，容器化部署的，那么这些项目我觉得也是需要配置中心的，因为在分布式、容器化环境下更改配置实在是太麻烦了。可以说配置中心并不是微服务独有的。基于以上原因我提炼了一些配置中心必备的功能，做的尽量简单（陋），开发了AgileConfig，为.net core的生态尽一份绵薄之力。 Github求star： AgileConfig

一、快速了解Raft算法 Raft 适用于一个管理日志一致性的协议，相比于 Paxos 协议 Raft 更易于理解和去实现它。 为了提高理解性，Raft 将一致性算法分为了几个部分，包括领导选取（leader selection）、日志复制（log replication）、安全（safety），并且使用了更强的一致性来减少了必须需要考虑的状态。 相比Paxos，Raft算法理解起来更加直观。 Raft算法将Server划分为3种状态，或者也可以称作角色： Leader 负责Client交互和log复制，同一时刻系统中最多存在1个。 Follower 被动响应请求RPC，从不主动发起请求RPC。 Candidate 一种临时的角色，只存在于leader的选举阶段，某个节点想要变成leader，那么就发起投票请求，同时自己变成candidate。如果选举成功，则变为candidate，否则退回为follower 状态或者说角色的流转如下： 在Raft中，问题分解为：领导选取、日志复制、安全和成员变化。 复制状态机通过复制日志来实现： 日志：每台机器保存一份日志，日志来自于客户端的请求，包含一系列的命令 状态机：状态机会按顺序执行这些命令 一致性模型：分布式环境下，保证多机的日志是一致的，这样回放到状态机中的状态是一致的 Raft算法选主流程 Raft中有Term的概念

联席作者：吴毅挺 任浩军 张彬彬 廖梦鸽 张金星 胡振建 郑重鸣谢：Nacos - 彦林，Spring Cloud Alibab - 小马哥、落夜，Nacos 社区 - 张龙（pader）、春少（chuntaojun） 前言 在高速发展的时候，公司规模越来越大，老师人数越来越多，这时候公司不能铺太多人去做运营与服务，必须提高每个人效，这就需要技术驱动。因此掌门教育转变成一家技术驱动型的公司，如果被迫成为一家靠资金驱动的公司就活不下去了。 -- 张翼（掌门教育创始人兼 CEO） 掌门教育自 2014 年正式转型在线教育以来，秉承“让教育共享智能，让学习高效快乐”的宗旨和愿景，经历云计算、大数据、人工智能、 AR / VR / MR 以及现今最火的 5G ，一直坚持用科技赋能教育。掌门教育的业务近几年得到了快速发展，特别是今年的疫情，使在线教育成为了新的风口，也给掌门教育新的机遇。 随着业务规模进一步扩大，流量进一步暴增，微服务数目进一步增长，使老的微服务体系所采用的注册中心 Eureka 不堪重负，同时 Spring Cloud 体系已经演进到第二代，第一代的 Eureka 注册中心已经不大适合现在的业务逻辑和规模，同时它目前被 Spring Cloud 官方置于维护模式，将不再向前发展。如何选择一个更为优秀和适用的注册中心，这个课题就摆在了掌门人的面前。经过对 Alibaba

前言 近年来，微服务架构（ Microservices Architecture ）已经成为一种主流的软件开发方法论，它把一种特定的软件应用设计方法描述为能够独立部署的服务套件。所谓微服务( Microservices ），就是一些具有足够小的力度、能够相互协作且自治的服务体系。每个微服务都比较简单 仅关注于完成一个功能并能很好地完成该功能，而这里的功能代表的是一种业务能力。构建微服务体系需要一套完整的方法论和工程实践，而微服务架构的提出代表的就是实现微服务体系的架构模式，即为我们提供了这些方法论和工程实践 从这个角度讲 微服务架构需要我们理解、学习并应用到日常开发过程中去。 成为一名架构师几乎是每个程序员的梦想。而微服务架构则是当今架构领域最受关注的话题。掌握微服务架构技术栈相关技能,是从一名普通程序员到资深架构师的必经之路。 今天楼主给大家带来的一篇关于微服务相关的电子书资源，介绍了关于微服务架构、Spring Boot、Spring Cloud、Docker方面的内容。 1.根据Spring Boot、Spring Cloud、Docker等技术性搭建微保障体系。 2.精简而详细的经典案例展现保持分布式架构的详细宏伟蓝图。 3.融合业务流程情景，根据全方位实例得出专用工具在搭建分布式架构中的工程项目实战演练。

Nacos是什么？ nacos 是微服务架构中的一种注册中心，与之相同的还有其他注册中心：Eureka（Apache产品） nacos属于阿里巴巴开源项目，具有比Eureka更好的功能性 Nacos的特点： 当消费方从nacos注册中心获取过一次生产方提供的服务后，下次就不需要nacos也能获取生产方的这个服务 但是没经过nacos获取过的服务是不能的 这点相比Eureka比较友好，Eureka需要每次获取服务都经过注册中心 目录 Nacos安装（Windows） Nacos账号修改 Nacos集群-Windows Nacos安装（Windows） 中文文档： http://dubbo.apache.org/zh-cn/docs/user/references/registry/nacos.html git下载： http://https://github.com/alibaba/nacos 解压安装，解压到合适的目录（路径不包含中文） 通过 /bin/目录下的 startup.cmd 启动即可 通过 shutdown.cmd 关闭或直接关闭运行窗口 初次使用： 成功启动nacos服务后，浏览器访问：localhost:8848/nacos（8848为默认端口） 当出现以下画面登录即可，初始的默认用户名：nacos，密码：nacos Nacos账号修改 默认的初始账户为 nacos

1：架构图 2：ZuulServlet Zuul的核心是一系列的filters，Zuul大部分功能都是通过过滤器来实现的 1：ZuulServlet是Zuul的核心类，用来调度不同阶段的filters，处理请求，并处理异常等，路径是/zuul，可以使用zuul.servlet-path属性更改此路径 2：功能类似于SpringMvc的DispatcherServlet，所有的Request都要经过它的处理 3：里面有三个核心方法：preRoute(),route(), postRoute() 4：ZuulServlet会把具体的执行交给ZuulRunner去做，ZuulServlet是单例，因此ZuulRunner也仅有一个实例 5：Zuul的过滤器之间没有直接的相互通信，它们之间通过一个RequestContext的静态类来进行数据传递的。RequestContext类中有ThreadLocal变量来记录每个Request所需要传递的数据，ZuulRunner会初始化RequestContext 6：ZuulRunner直接将执行逻辑交由FilterProcessor处理，FilterProcessor也是单例，其功能就是依据filterType执行filter的处理逻辑，大致过程如下： （1）根据Type获取所有输入该Type的filter （2

Dubbo（来自于阿里巴巴） Dubbo是一个分布式服务框架，致力于提供高性能和透明化的PRC远程调用服务调用方案。 Dubbo的的特点 通过spring配置的方式即可完成服务化，对于应用无入侵。（SpringCloud有一定的入侵） 通过maven的install &deploy命令把interface和Model层发布到仓库中，服务调用方只需要依赖interface和model层即可。 通过zookeeper设置达到注册服务和心跳检测，通过gateWay前置网关（Clound使用Zuul实现负载均衡将请求转向Eureka服务器）隔绝外部直接调用原子服务的风险 SpringBoot中使用Dubbo 引入依赖 < ! -- dubbo依赖 -- > < dependency > < groupId > com . alibaba < / groupId > < artifactId > dubbo < / artifactId > < version > 2.6 .6 < / version > < / dependency > < dependency > < groupId > org . apache . curator < / groupId > < artifactId > curator - framework < / artifactId > < version >

一、Feign简介 Feign是Netflix开源的声明式的HTTP客户端，只需要声明一个接口，Feign可以自动帮我们构造请求地址。 （简单来说，Feign可帮助我们更加便捷，优雅的调用服务之间的HTTP API），另外SpringCloud对Feign进行了增强，是Feign支持SpringMVC注解，并整和了Ribbon和Eureka，从而让Feign使用更加便捷。 二、基于Feign的服务调用 （1）pom依赖 <!-- 声明式Http客户端 --> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> </dependency> （2）在内容中心微服务启动类添加Feign的支持， 通过@EnableFeignClients主机诶开启Spring Cloud Feign的支持功能： @SpringBootApplication @EnableFeignClients //开启Feign支持 public class ContentCenterApplication { public static void main(String[] args) { SpringApplication.run

前言 上一篇【 .Net Core微服务入门全纪录（一）——项目搭建 】讲到要做到服务的灵活伸缩，那么需要有一种机制来实现它，这个机制就是服务注册与发现。当然这也并不是必要的，如果你的服务实例很少，并且很稳定，那么就没有必要使用服务注册与发现。 服务注册与发现 服务注册：简单理解，就是有一个注册中心，我们的每个服务实例启动时，都去注册中心注册一下，告诉注册中心我的地址，端口等信息。同样的服务实例要删除时，去注册中心删除一下，注册中心负责维护这些服务实例的信息。 服务发现：既然注册中心维护了各个服务实例的信息，那么客户端通过注册中心就很容易发现服务的变化了。 有了服务注册与发现，客户端就不用再去配置各个服务实例的地址，改为从注册中心统一获取。 那注册中心又是怎么保证每个地址的可用状态呢，假如某个实例挂了怎么办呢？原则上挂掉的实例不应该被客户端获取到，所以就要提到：健康检查 。 健康检查：每个服务都需要提供一个用于健康检查的接口，该接口不具备业务功能。服务注册时把这个接口的地址也告诉注册中心，注册中心会定时调用这个接口来检测服务是否正常，如果不正常，则将它移除，这样就保证了服务的可用性。 常见注册中心有 Consul、ZooKeeper、etcd、Eureka。 Consul Consul官网： https://www.consul.io/ Consul的主要功能有服务注册与发现