Spring Cloud

前言 时间过得飞快，一代又一代就这么成长了起来，曾经的95后备受争议，如今的95后进入社会，扮演者各行角色，成为了行业顶梁柱，今天，要分享的是自己的成长经历。今年24岁，毕业之后进入一家小型的互联网公司工作，名字就不说了，算是熟知的，在这家公司呆了两年，直至今年才有了跳槽的想法。 每个人都拥有大厂梦，在小公司待久了，感觉人会荒废掉，太轻松，没有压迫感。在众多大厂中，最终选择了腾讯音乐。“年轻、活力、富有激情”是我听到的最多对它的形容词，所以毅然决然，希望自己能够在这个舞台上展示出自己。 以下分享这次面试腾讯音乐的面试题，另外还对自己的面试做了一些总结，总结里含有一些学习方法和资料，需要的朋友可以后台私信电子书免费领取哦！ 腾讯三面斩获Offer，定级T2-1（技术题，不含HR面） 一面（一小时二十分钟） 一面是一个电话面试，下午6点左右特地找了一个地方电话面试，6点准时电话就过来了，不得不说，这方面还是专业的，时间有点远了，依稀记得一些题目。。。 1、从简历项⽬目中选⼀一个项⽬目，说说你在其中遇到了了什什么重⼤大挑战？以及你的解决问题的思路路？ 2、⼀一段代码要执⾏行行多个redis命令，不不加锁的情况下如何保证原⼦子性？ 3、谈谈数据结构，⽐比如⼆二叉树、红⿊黑树 4、说说B-tree、B+tree的区别和使⽤用场景 5、mysql哪个版本哪个存储引擎的索引使⽤用的B+tree

导读：2020 年 8 月 18 日，首届云原生微服务大会于线上召开，会议首日，阿里云资深技术专家、CNCF TOC 李响 Keynote 演讲中正式发布了《 2020 年微服务领域开源数字化报告》。 微服务体系就像是一剂催化剂，可以加速数据和业务结合的过程，更好地提升生产力，从而实现业务的提升。本项目旨在通过建立一份建立在微服务领域的相对完整、可以反复进行推演的数据报告（报告、数据、算法均开源），分析微服务框架项目以及 Spring Cloud 项目的 GitHub 开发者行为日志，通过多维度数据分析的视角，来观察微服务领域的开源现状、进展趋势、演化特征等问题。 本报告根据 2020 年 1 月到 6 月的 GitHub 日志进行统计。值得一提的是，报告显示 Apache Dubbo 作为中国本土开源的项目，在微服务框架中排名第 5，全球排名跻身 693；Spring 社区第一个国产 Spring Cloud 项目 Spring Cloud Alibaba 作为开源的微服务全家桶，在 Spring Cloud 榜单中居于榜首。 关键词：微服务、开源、行为数据、GitHub 背景 随着业务的扩张，单体应用架构的开发、部署和运维都会越来越慢，越来越复杂，甚至在单体架构应用开发中敏捷模式无法施展开。基于此，具有更高独立性、可用性和弹性的微服务应运而生。从结构上看

CountDownLatch见名思义，即倒计时器，是多线程并发控制中非常有用的工具类，它可以控制线程等待，直到倒计时器归0再继续执行。 给你出个题，控制5个线程执行完后主线徎再往下执行，并统计5个线程的所耗时间。当然我们可以通过join的形式完成这道题，但如果我说统计100个1000个线程呢？难道要写1000个join等待吗？这显然是不现实的。 废话少说，我们来做一个例子看看上面的题怎么实现，并理解倒计时器。 首先通过new CountDownLatch(5)约定了倒计时器的数量，在这里也是线程的数量，每个线程执行完后再对倒计时器-1。countDown()方法即是对倒计时器-1，这个方法需要放在finally中，一定要保证在每个线程中得到释放，不然子线程如果因为某种原因报错倒计时器永远不会清0，则会导报主线程会一直等待。 await()方法即是主线程阻塞等待倒计器归0后再继续往下执行，当然await可以带时间进去，等待多久时间后不管倒计时器有没有归0主线程继续往下执行。 如上面的例子所示，我们输出了倒计时器最后的数字0，表示倒计时器归0了，也输出了从开始到结束所花费的时间。从这个例子可以完全理解倒计时器的含义，这个工具类在实际开发经常有用到，也很好用。 推荐去我的博客阅读更多： 1. Java JVM、集合、多线程、新特性系列教程 2. Spring MVC、Spring

Eureka的自我保护机制：默认情况下EurekaClient定时向EurekaServer端发送心跳包，如果EurekaServer在一定时间内没有收到EurekaClient发送的心跳包，便会直接从服务注册列表中剔除该服务(默认90S)，但是在短时间丢失大量的服务实例心跳，这时候EurekaServer会开启自我保护机制，不会剔除该服务。 Ribbon本地负载均衡算法实现方式：总请求数%服务器数量得到实际下标服务器位置。 服务雪崩解决方法：服务降级、服务熔断、服务隔离 服务降级分为：超时降级、失败次数降级、故障降级、限流降级。 超时降级：也就是大部分人网上说的，再高并发情况下，防止用户一直等待，直接返回一个友好提示给客户端。 失败次数降级： 主要是一些不稳定的API，当失败调用次数达到一定阀值自动降级，同样要使用异步机制探测回复情况 。 故障降级： 如要调用的远程服务挂掉了（网络故障、DNS故障、HTTP服务返回错误的状态码和RPC服务抛出异常），则可以直接降级 。降级后的处理方案有：默认值（比如库存服务挂了，返回默认现货）、兜底数据（比如广告挂了，返回提前准备好的一些静态页面）、缓存（之前暂存的一些缓存数据）。 限流降级： 当触发了限流超额时，可以使用暂时屏蔽的方式来进行短暂的屏蔽。当我们去秒杀或者抢购一些限购商品时，此时可能会因为访问量太大而导致系统崩溃

1. springCloud 项目启动工程，redis 集群连接报错： Caused by: redis.clients.jedis.exceptions.JedisDataException: ERR This instance has cluster support disabled 2. 解决：在reids 安装服务器上找到配置文件：redis.conf。 放开一个被注释掉的配置，开启集群模式： 原来： # cluster-enabled yes 改为： cluster-enabled yes 3. 重启工程，一切正常。 来源： oschina 链接： https://my.oschina.net/u/4302796/blog/4281070

项目简介 JNPF 是种专为 提高开发效率 而生的 低代码二次开发框架 以及 基于 代码生成器 的java开发平台。 为简单的增删改查、复杂的 表单、 简单的事务操作提供了完全自动化的 开发平台 。 能大幅降低开发和沟通成本，简化开发流程，缩短开发周期。 适合中小型前后端分离的项目，尤其是互联网创业项目和企业自用项目。 通过自动化 开发 ，前端可以定制任何 业务 、任何 流程 ！ 项目特色 在线解析 拖拽式的表单设计器，快速设计使用 自动生成 表单代码 ，清晰可读 易扩展 自动生成三层架构的完整项目和代码 自动生成 多层次 代码， 代码结构清晰 自动 生成java页面和移动端平台代码 对于前端 主体框架采用jQuery, 极大地简化了JavaScript 编程 UI层使用 bootstrap框架，使得web开发更加便捷 APP端使用当前最流行的Vue.js框架和H5页面 APP的UI层使用uni.app，跨多端的开发小程序 对于后端 后端框架SpringBoot的核心就是简化配置，快速开发 SpringCloud是一套目前完整的微服务解决框架 数据库框架采用Mybatis，支持定制化SQL 支持 Mysql,Sqlserver,Orcal等主流数据库的数据支持兼容 自主研发的代码生成器介绍 本平台采用Velocity（vm）模板引擎来进行代码生成器模板的开发，集成了前后端模板

之前公司用了springcloud的gateway.被一个伙伴留下了一堆的坑,没办法只能从头梳理. 第一步就是确定架构, gateway+consul+springboot 第二步就是确定一个flag 要解决哪些问题 1.解决灰度负载均衡策略问题:如何配置,支持哪些配置 2.解决ip名单和限流的问题:如何配置,支持哪些配置 3.解决路由重写的问题: 将msg服务,stats服务和action服务整合到business 4.解决consul摘机后服务列表不更新的问题 第三步就是开始官方文档的解读 我承认这篇博客不是一个好博客,因为不够亲民. 主要写下来就是给自己留个笔记罢了.谢谢!!!! 官方文档地址: https://docs.spring.io/spring-cloud-gateway/docs/2.2.5.RELEASE/reference/html/ 1. How to Include Spring Cloud Gateway 这个自己百度吧,一堆堆的 简单来说里面有个警告: 就是用了netty的思想,有些东西吧不好使.悠着点. 2. Glossary Route: 路由 Predicate:断言 Filter:过滤器 3. How It Works Clients make requests to Spring Cloud Gateway. If the Gateway

故事背景 前阵子，有位朋友在微信上问我数据被删了能不能恢复，我问了下原因，居然是因为一个配置项惹的祸。 故事细节 在 Spring Boot 中使用 jpa 来操作数据库，jpa 就不做详细的介绍了，相信大家都有所了解或者也用过。 在 jpa 中有一个配置项，可以让程序在启动的时候自动初始化表结构或者更新表结构的功能。听上去很不错，非常实用。 其实这是一个非常危险的功能，个人觉得不应该提供这种功能，只要留了口子就有可能会出问题。 这个配置就是： spring.jpa.hibernate.ddl-auto create（ 危险系数 2 颗星 ） 应用启动的时候，如果数据库中没有对应的表，就会自动根据实体类的结构创建一个表结构。如果表已经存在了就会将表中的数据清空。 create-drop（ 危险系数 3 颗星 ） 应用启动的时候，如果数据库中没有对应的表，就会自动根据实体类的结构创建一个表结构。如果表已经存在了就会将表中的数据清空。 程序停止的时候会将数据库中所有表删除掉。 update（ 危险系数 1 颗星 ） 应用启动的时候，如果数据库中没有对应的表，就会自动根据实体类的结构创建一个表结构。如果表已经存在了就会判断有没有新增字段或者修改长度之类的，如果有则会更新表结构，不会影响数据。 validate（ 危险系数 0 颗星 ） validate 不会更新和删除表或者数据

前言 随着技术日新月异的发展，最近几年微服务和分布式技术成为主流。每一个好的解决方案不一定是直接设计出来的，但每一个优秀的架构都必须承受得住业务的考验和需求驱动的积累。最初我们开发系统都是在单个的应用上进行开发、测试、部署和运维等。每次新的需求迭代都将可能涉及到整个系统的修改，尤其是庞大而臃肿的业务系统需要进行大量的数据增删改查操作，开发起来变得非常麻烦。为了应对更高的并发和业务需求，解决单个应用的缺点，把庞大复杂的单体应用按照业务拆分成多个子业务模块，可进行垂直拆分或水平拆分，从而达到更高效的开发、更好的管理和维护的目的，这就是所谓的分布式系统。 一、单体架构是什么？ 1.1 定义 一个归档包（可以是JAR、WAR、EAR或其它归档格式）包含所有功能的应用程序，通常称为单体应用。而架构单体应用的方法论，就是单体应用架构。 1.2 单体应用举例 单体应用集成了前端页面和后端接口服务及业务逻辑和数据操作于一体的单个完整系统，Struts1、Struts2及SSH、SSM架构的系统等，单个应用囊括了所有业务模块。 1.3 单体架构示意图 1.4 单体应用优缺点 1.4.1 优点 易于集中式开发、测试、管理、部署。 无需考虑跨语言。 能避免功能重复开发（相对分布式）。 1.4.2 缺点 团队合作困难 代码的维护、重构、部署都比较难。 稳定性、可用性（停机维护）、扩展性不高。

在一个实际的大型系统中，微服务架构可能由成百上千个服务组成，我们发布一个系统如果都单纯的通过打包上传，再发布，工作量无疑是巨大的，也是不可取的，前面我们知道了可以通过 Jenkins 帮我们自动化完成发布任务。 但是，我们知道一个 Java 应用其实是比较占用资源的，每个服务都发布到物理宿主机上面，资源开销也是巨大的，而且每扩展一台服务器，都需要重复部署相同的软件，这种方式显然是不可取的。 容器技术的出现带给了我们新的思路，我们将服务打包成镜像，放到容器中，通过容器来运行我们的服务，这样我们可以很方便进行分布式的管理，同样的服务也可以很方便进行水平扩展。 Docker 是容器技术方便的佼佼者，它是一个开源容器。而 Kubernetes（以下简称 K8S），是一个分布式集群方案的平台，它天生就是和 Docker 一对，通过 K8S 和 Docker 的配合，我们很容易搭建分布式集群环境。 下面，我们就来看看 K8S 和 Docker 的吸引之处。 集群环境搭建 本文用一台虚拟机模拟集群环境。 操作系统：CentOS7 64位 配置：内存2GB，硬盘40GB。 注：真正的分布式环境搭建方案类似，可以参考博文： Kubernetes学习2——集群部署与搭建》 。 下面开始搭建集群环境。 1. 关闭防火墙：</ 来源： oschina 链接： https://my.oschina.net