Spring Cloud

从毕业到现在已经快4年啦，一直在Java的WEB开发行业混迹。我不是牛人，但是自我感觉还算是个合格的程序员，有必要写下自己将近4年来的经历，给自我以提示，给刚入行的朋友提供点参考。 貌似这一点适应的行业最广，但是我可以很肯定的说：当你从事web开发一年后，重新找工作时，才会真实的感受到这句话。 工作第一年，往往是什么都充满新鲜感，什么都学习，冲劲十足的一年；WEB行业知识更新特别快，今天一个框架的新版本，明天又是另一个新框架，有时往往根据项目的需要来不断学习新东西；所有，很多时候感觉，自己用过的东西真多呀！但是真正深入研究的东西却不多。 面试，是跳槽后第一个需要面对的问题；而且不同公司面试的着重点不同；但是却有一个共同点：Java基础是必考的。工作第一年，可能问你String对象创建的理解，常用的框架是什么等等；工作第二年，就问你Java内存分配机制是什么，类是如何加载的等等；第三年，就问你常用的设计模式是什么，你在工作中充当什么角色，怎么独立完成一个模块等等； 可以看出------这是一个典型的程序员的成长过程： 使用Java---->深入理解Java积累经验------>独立设计分析能力------>独当一面的多面手！ 因此，必须学习： 列举一些技术 比如对集合类，并发包，IO/NIO，JVM，内存模型，泛型，异常，反射，等有深入了解，最好是看过源码了解底层的设计

Spring Cloud 版本重大变革，变更了版本号的命名方式。 旧版命名方式看这篇： Spring Cloud 多版本怎么选择？ 从 Spring Cloud 2020.0.0-M1 开始，Spring Cloud 废除了这种英国伦敦地铁站的命名方式，而使用了全新的 "日历化" 版本命名方式。 官宣如下： https://spring.io/blog/2020/04/17/spring-cloud-2020-0-0-m1-released 什么是日历化版本？ 英文名称：Calendar Versioning 日历化版本不是基于任意的数字，而是基于项目的发布日期的版本控制约定，随着时间的推移，版本会越来越好。 这种基于日期的版本命名方式被称为 “日历化版本”（Calendar Versioning）， 或者可以简称 CalVer。 详细的介绍参考： https://calver.org/ 我们来看下 Spring Cloud 是如何开始使用日历化版本的。 Spring Cloud 使用了 YYYY.MINOR.MICRO 的命名规则： YYYY ：表示 4 位年份； MINOR ：代表一个递增的数字，每年以 0 开始递增； MICRO ：代表版本号后缀，就和之前使用的 .0 类似于 .RELEASE 一样， .2 类似于 .SR2 。 预发布版本的后缀分隔符也从 . 变更为 -

一. 首先安装rabbitmq-management 这里用的是rabbitmq的docker镜像，我们可以在 Docker Hub 中搜索rabbitmq, 找到最新的版本安装 sudo docker run -d --hostname my-rabbit --name rabbit -p 15672:15672 -p 5672:5672 rabbitmq:3.7.8-management 安装之后使用 docker ps -a 检查下, rabbitmq的镜像是否启动, 正常启动状态如下: 通过 http://192.168.12.12:15672 , 访问到rabbitmq的管理端, 默认账户/密码是: guest/guest 二. Spring Cloud Stream与RabbitMQ集成 引入依赖 <!-- Spring Cloud Stream RabbitMQ --> < dependency > < groupId > org.springframework.cloud </ groupId > < artifactId > spring-cloud-starter-stream-rabbit </ artifactId > </ dependency > 创建消息接受类 @Component @Slf4j @EnableBinding ( Processor .

在 上一章 的学习中，我们知道了微服务的基本概念，知道怎么基于Ribbon+restTemplate的方式实现服务调用，接着上篇博客，我们学习怎么基于Feign实现服务调用，请先学习上篇博客，然后再学习本篇博客 Feign是一个声明式的web service客户端，它使得编写web service客户端更为容易。创建接口，为接口添加注解，即可使用Feign。Feign可以使用Feign注解或者JAX-RS注解，还支持热插拔的编码器和解码器。 环境准备： JDK 1.8 SpringBoot2.2.1 SpringCloud(Hoxton.SR6) Maven 3.2+ 开发工具 IntelliJ IDEA smartGit 创建一个SpringBoot Initialize项目，详情可以参考我之前博客： SpringBoot系列之快速创建项目教程 port: 8083 spring: application: name: feign-service-consumer eureka: client: service-url: defaultZone: http://localhost:8761/eureka/ healthcheck: enabled: false instance: status-page-url-path: http://localhost:8761

问题起源 使用SpringCloud构建项目时，使用Swagger生成相应的接口文档是推荐的选项，Swagger能够提供页面访问，直接在网页上调试后端系统的接口， 非常方便。最近却遇到了一个有点困惑的问题，演示接口示例如下（原有功能接口带有业务实现逻辑，这里简化了接口）： /** * @description: 演示类 * @author: Huang Ying **/ @Api(tags = "演示类") @RestController @Slf4j public class DemoController { @ApiOperation(value = "测试接口") @ApiImplicitParams({ @ApiImplicitParam(name = "uid", value = "用户ID", paramType = "query", dataType = "Long") }) @RequestMapping(value = "/api/json/demo", method = RequestMethod.GET) public String auth(@RequestParam(value = "uid") Long uid) { System.out.println(uid); return "the uid: " + uid; } }

微服务测试的痛点与挑战 这张图可以形象地展示单体服务和微服务的对比，单体应用就像左边巨大的集装箱，软件模块和应用都包括其中；而微服务就像是由一个小集装箱组成，微小的服务组成一个庞大、完整的系统。单体服务是一个大而全的应用体，而微服务由拆分成出来的很多小服务来组成一个庞大而完整的系统。 微服务是一种架构模式，是面向服务型架构 SOA 的一种变体，提倡将单一应用程序逐渐还原划分成小的服务，服务间互相协调、互相配合，为用户提供最终价值。微服务架构风格就是一些小而自治的服务协同工作形成松耦合的系统。另外，我们需要尽量避免一个统一的、集中式的服务管理机制，对具体的一个服务而言，应该根据上下文选择合适的语言工具对其进行构建。 结合下方的这张图，我们可以理解微服务构建的核心其实是中间领域的业务逻辑，围绕着这个领域业务逻辑，会有一些微服务去进行拆分构建。 微服务具有专注、自治、独立进程、独立部署和技术异构的特点，即每个服务只限定于特定的业务而专注做一件事情，每个服务承担的是单一职责，但是它也需要达到一定规模能够完整的处理特定的领域业务。很多人都会被微服务的“微”这个词所误导，认为微服务就是要拆分的越小越好。但是其实为了“微”而将同一领域的业务拆分到不同的服务，只会徒劳增加软件的复杂度和维护困难。 我们可以围绕应用的业务能力进行分组，每个小组的开发组人员开发微服务的技术可以不受限制

原因 body大小超过nginx设置的默认值 解决办法 修改nginx.conf，加入如下内容： client_max_body_size 20M; 注： 在http{ }中设置，控制全局nginx所有请求报文大小； 在server{ }中设置，控制该server的所有请求报文大小； 在location{ }中设置，控制满足该路由规则的请求报文大小。 如果有php的话，同时修改php.ini内的上传限制upload_max_filesize = 20M 来源： oschina 链接： https://my.oschina.net/u/4263893/blog/4423736

占坑 springboot1.5.9升级springboot2.0.5 此升级只适应于参考(本公司暂时正常运行) 原文链接 官网翻译 spring-cloud 组件 springboot 版本 <version>2.0.5.RELEASE</version> springcloud 版本 <version>Finchley.RELEASE</version> eureka-server 替换 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId> </dependency> eureka-client 替换 2.0.X guava scope 为runtime 项目引用不到 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId> </dependency> <dependency> <groupId>com.google.guava</groupId> <artifactId>guava<

项目地址 https://github.com/yinjihuan/kitty-cloud 前言 Kitty Cloud 开源后有以为朋友在 GitHub 上给我提了一个 issues，问为什么项目中要同时集成 Feign 和 Dubbo 两个框架来调用服务。今天就来聊一聊这个问题，然后讲下在 Kitty Cloud 中如何切换使用两种调用方式。 为什么要支持两种协议？ 关于支持两种协议，我这个是一个开源项目，主要还是为了让使用者有更多的选择。当然框架本身不是我开发的，我只是使用者而已。 一种协议更统一化，两种协议混着用也不是不可以，具体还是看实际需求。比如你们内部有个 ID 分发的服务，调用量很高，就是对性能有这极致的要求。那么这个场景你就可以用 Rpc 来代替 Http 了。其他的正常使用 Http 协议就行，特殊场景的就用 Rpc 协议，互补而已。 用 Http 最好的点在于简单，传输内容就是文本，调试什么的都很方便。比如我要单独测试某个服务的接口，直接 PostMan 上调用这个 Http 接口就可以了，或者用 Swagger。 如果是 Dubbo 的 Rpc, 我可能需要用 telnet 来调用。 还有就是网关层的转发，如果是 Http 协议，直接转发过去了。如果是 Rpc 协议，网关内部需要转特殊处理，当然目前也有支持 Rpc 的网关。如果我们是两种协议

实用 本书除了 讲解Spring的理论知识外，还在每个知识点上辅以大量的实战案例，使理论可以联系实际，具备更强的可操作性。 简明 目录标注有“新功能” “实战”“难点”及“重点'等标识， 方便读者做好知识点的归纳和总结。 官方 以Spring官方文档和Spring框架源码为主要参考依据， 确保知识点的准确性。 自Spring诞生以来，以Spring技术栈为核心的企业级应用开发方式深入人心，已经成为Java EE开发的最佳实践。随着Spring 5版本的发布，Spring 自身也发生了巨大的变革。本书力求全面介绍Spring框架，涵盖了Spring 核心、测试、数据访问、Web开发、响应式编程、系统集成及微服务等方面在内的共26章的内容，可以说是Spring技术的“百科全书”。同时，本书基于Spring 5版本来编写，除了涉及Spring 5版本的新特性外，还介绍了REST服务、响应式Web开发、微服务设计、Spring Boot, Spring Cloud等方面的前瞻技术。而且除了讲解Spring的理论知识外，还在每个知识点上辅以大量的代码案例，使理论可以联系实际，具备更强的可操作性。 本书特色 本书具有以下特色。 (1)全面:本书全面介绍Spring框架，涵盖了Spring核心、测试、数据访问、系统集成、Web开发、响应式编程及微服务等方面在内的共26章的内容