eureka

一：Ribbon是什么？ 　　 Ribbon是Netflix发布的开源项目，主要功能是提供客户端的软件负载均衡算法，将Netflix的中间层服务连接在一起。Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等。简单的说，就是在配置文件中列出Load Balancer（简称LB）后面所有的机器，Ribbon会自动的帮助你基于某种规则（如简单轮询，随即连接等）去连接这些机器。我们也很容易使用Ribbon实现自定义的负载均衡算法。 二:LB方案分类　　 　　目前主流的LB方案可分成两类：一种是集中式LB, 即在服务的消费方和提供方之间使用独立的LB设施(可以是硬件，如F5, 也可以是软件，如nginx), 由该设施负责把访问请求通过某种策略转发至服务的提供方；另一种是进程内LB，将LB逻辑集成到消费方，消费方从服务注册中心获知有哪些地址可用，然后自己再从这些地址中选择出一个合适的服务器。Ribbon就属于后者，它只是一个类库，集成于消费方进程，消费方通过它来获取到服务提供方的地址。 三：Ribbon的主要组件与工作流程 　　Ribbon的核心组件(均为接口类型)有以下几个： 　　ServerList:用于获取地址列表。它既可以是静态的(提供一组固定的地址)，也可以是动态的(从注册中心中定期查询地址列表)。 　　ServerListFilter

SpringCloud 微服务概述 什么是微服务 目前的微服务并没有一个统一的标准，一般是以业务来划分 将传统的一站式应用，拆分成一个个的服务，彻底去耦合，一个微服务就是单功能业务，只做一件事。 与微服务相对的叫巨石 微服务与微服务架构 微服务是一种架构模式或者一种架构风格，提倡将单一应用程序划分成一组小的服务==独立部署==，服务之间相互配合、相互协调，每个服务运行于自己的==进程==中。 服务与服务间采用轻量级通讯，如HTTP的RESTful API等 避免统一的、集中式的服务管理机制 微服务的优缺点 优点 每个服务足够内聚，足够小，比较容易聚焦 开发简单且效率高，一个服务只做一件事情 开发团队小，一般2-5人足以（当然按实际为准） 微服务是松耦合的，无论开发还是部署都可以独立完成 微服务能用不同的语言开发 易于和第三方集成，微服务允许容易且灵活的自动集成部署（持续集成工具有Jenkins,Hudson,bamboo等） 微服务易于被开发人员理解，修改和维护，这样可以使小团队更加关注自己的工作成果，而无需一定要通过合作才能体现价值 微服务允许你融合最新的技术 ==微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面组件融合==。 ==每个微服务都可以有自己的存储能力，数据库可自有也可以统一，十分灵活==。 缺点 开发人员要处理分布式系统的复杂性 多服务运维难度

springboot和springmvc的区别 spring boot 内嵌tomcat，Jetty和Undertow容器，可以直接运行起来，不在再做部署； spring boot 自动配置，减少了xml文件的大量配置；降低了项目搭建的复杂度 Spring MVC是基于 Servlet 的一个 MVC 框架 主要解决 WEB 开发的问题，因为 Spring 的配置非常复杂，各种XML、 JavaConfig、hin处理起来比较繁琐。于是为了简化开发者的使用，从而创造性地推出了Spring boot，约定优于配置，简化了spring的配置流程。 Spring 是一个“引擎”； Spring MVC 是基于Spring的一个 MVC 框架 ； Spring Boot 是基于Spring4的条件注册的一套快速开发整合包。 springboot热部署的两种方式 SpringBoot 1.3后才拥有SpringBoot devtools热部署 　　①：spring-boot-devtools ②：Spring Loaded 　　方式一： 　　　　在项目的pom文件中添加依赖: 1 <!--热部署jar--> 2 <dependency> 3 <groupId>org.springframework.boot</groupId> 4 <artifactId>spring-boot

#官方教程 http://projects.spring.io/spring-cloud/ guide https://github.com/spring-guides 伪官方教程 https://springcloud.cc https://legacy.gitbook.com/book/eacdy/spring-cloud-book/details Actuator https://blog.csdn.net/alinyua/article/details/80009435 management.endpoints.web.exposure.include="*" 或者 "hystrix.stream" 包含采集的数据. 健康检查 配置法: management: health: solr: enabled: false db: enabled: false elasticsearch: enabled: false jms: enabled: false mail: enabled: false mongo: enabled: false rabbit: enabled: false redis: enabled: false 代码 /** 系统有以下项： * rabbitHealthIndicator * diskSpaceHealthIndicator *

服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供 REST API 的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。 Spring Cloud Netflix 中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。 路由在微服务体系结构的一个组成部分。例如，/可以映射到您的Web应用程序， /api/users 映射到用户服务，并将 /api/shop 映射到商店服务。 Zuul 是 Netflix 的基于 JVM 的路由器和服务器端负载均衡器。 Netflix使用Zuul进行以下操作： 认证 洞察 压力测试 金丝雀测试 动态路由 服务迁移 负载脱落 安全 静态响应处理 主动/主动流量管理 Zuul 的规则引擎允许基本上写任何JVM语言编写规则和过滤器，内置 Java 和 Groovy 。 什么是服务网关 服务网关 = 路由转发 + 过滤器 1、路由转发：接收一切外界请求，转发到后端的微服务上去； 2、过滤器：在服务网关中可以完成一系列的横切功能，例如权限校验、限流以及监控等，这些都可以通过过滤器完成（其实路由转发也是通过过滤器实现的）。 为什么需要服务网关 上述所说的横切功能（以权限校验为例）可以写在三个位置：

[toc] 1.环境介绍 好了，不知不觉中我们已经来到了最后一篇文章，也来到了最一个工程"mirco-service-zuul"，zuul是一个服务网关，虽然现在spring也出了spring cloud gateway，相信有很多之前就使用spring cloud的公司依然使用的是zuul；看完这六篇文章相信有点基础的小伙伴们应该能自己做点东西了，当然spring cloud这个系列远远还没有说完，后面我计划在春节前后开源一个最小化的微服务手脚架项目，使用spring cloud来做实战演练。 2.api网关服务 2.1 创建工程 因为api网关是一个比较独立的东西，基本不需要对原有的工程进行改造。 配置文件中加入 server: port: 5001 spring: application: name: service-gateway-zuul zuul: routes: baidu: url: http://www.baidu.com path: /api/** 为启动文件加入@EnableZuulProxy注解 启动服务，访问 http://localhost:5001/api/，你会看到页面重定向到百度了。那么我们zuul的配置就完了。 2.2 api网关服务化 主要是配置文件的改动，改动后的<b>application.yml</b>配置文件如下 server:

　　zuul作为网关组件，主要用来管理api请求接口(统一对外暴露，负载均衡)，身份认证，流量监控等。它是通过servlet来实现的，核心是一系列过滤器，可以在请求的发起跟相应返回阶段进行一系列的处理。 ------------------------------------------------------------------------------------------------------------------------ 原理简介 ： 　　过滤器分类： 　　　　PRE过滤器：在请求路由到具体的服务之前执行，可以用作安全验证，例如身份验证，参数验证等； 　　　　ROUTING过滤器：用于将请求路由到具体的微服务实例，默认情况下使用http client进行网络请求； 　　　　POST过滤器：在请求被路由到微服务后执行，一般用作收集统计信息，及将响应传输到客户端； 　　　　ERROR过滤器：在其他过滤器发生错误时执行； 　　zuul采用了动态读取、编译和运行这些过滤器。过滤器之间不能直接通信，而是通过RequestContext对象共享数据，每个请求都会创建一个RequestContext对象。zuul请求的生命周期如图： 　　request请求进入zuul网关后，先进入pre 类别的过滤器，进行一系列验证操作或判断，然后交给routing filter进行路由转发

1. 导语 近期公司孵化了一个互联网产品，随着业务发展，产品运营后用户数据量（过亿）、业务数据量（过100亿）较大，技术团队配合产品、运营快速定制化开发， 还要考虑产品涉及的资金安全、消息的及时性、业务的制动化处理，我们选择鸿鹄cloud分布式云架构平台作为公司产品核心企业架构。 2. 产品平台规划 微服务注册中心（分布式集群部署）、微服务配置中心（分布式集群部署）、服务网关平台（分布式集群部署）、 微服务监控平台、SSO单点登录平台（分布式集群部署）、微服务相关组件（分布式集群部署）、后台管理平台、 定时调度平台（按照业务分库、分表部署）、业务微服务（分布式集群部署、超过20个微服务）、MQ消息中间件业务平台（分布式集群部署） MySql主从、读写分离（高可用部署）、Redis分布式缓存（高可用） 3. 源码结构： commonservice 通用服务：对spring Cloud组件的使用&封装，是一套完整的针对于分布式微服务云架构的解决方案 Component 通用组件：对系统常用组件的封装，包括对象存储包、工具包、缓存包、MQ相关、API调用包的封装等。 SAAS微服务 SAAS服务：针对通用业务如：会员、消息、支付等 快速开发管理平台 企业级快速开发平台，封装了用户、角色、权限、数据字典、菜单、日志、机构、部门等管理功能，针对于业务服务做了统一管理。 4. 分布式、微服务

Eureka 系列（02）Eureka 一致性协议 Eureka 是由 Netflix 基于 AP 模型的服务发现中间件，包括服务发现服务器和客户端的。相关文档推荐：一是 Spring Cloud Eureka 官网 ，二是 Eureka源码解析 。 本系列源码分析基于 spring-cloud-starter-netflix-eureka-2.1.1.RELEASE 和 Eureka-1.9.8。 [TOC] 0. Spring Cloud 系列目录 - Eureka 篇 1. 服务发现方案对比 1.1 技术选型 <center><b>表1：Spring Cloud 服务发现方案对比</b></center> 技术选型 CAP模型 适用规模(建议) 控制台管理 社区活跃度 Eureka AP <30k 支持 低 Zookeeper CP <20k 不支持 中 Consul AP <5k 支持 高 Nacos AP/CP 100k+ 支持 靠大家啦☺ 注： 以上数据来源于 小马哥技术周报 。 1.2 数据模型 <center><b>表2：Spring Cloud 服务发现数据模型</b></center> 框架 集群(框架) 服务应用 服务集群 服务实例 租约管理 Spring-Cloud -- (serviceId) -- ServiceInstance -- Nacos

 我的博客： 程序员笑笑生 ,欢迎浏览博客！  近年来，随着互联网公司自身的业务体系越来越大，系统复杂度越来越高，导致我们不得不将服务进行拆分，微服务的概念也是迅速在互联网发酵。我们也迫切的需要一套框架、一个生态系统能够健全、稳定的为我们解决问题。本章就简单的介绍一下微服务的概念，以及Spring Cloud的生态组件。 一、微服务架构简介  微服务架构风格是将单体应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务之间通过轻量级的通讯机制(通常是HTTP资源api).。每一个服务是围绕这个业务能力构建，并且可以独立的部署、可独立扩展。不同的服务可以使用不同的语言来编写，也可以使用不同的数据存储。总结如下： 服务功能单一 可独立部署、独立扩展 可跨语言编程 服务间良好的通信机制  在 https://spring.io/ 官方网站介绍Spring Cloud时，以图的方式展现了微服的架构图：图中包含了网关，各个微服务单元，服务注册，服务配置等   二、SpingCloud 简介  在微服务的发展过程中，随着分布式水平的提高，系统会变得越来越复杂，系统发生的错误率随着系统的复杂性呈指数型增长、因此微服务也出现了反对的声音，认为微服务增加了系统的维护、部署难度、导致一些功能模块和代码很难反复的使用。有没有一种框架可以尽可能的解决上述的问题呢。有，就是Spring