Spring Cloud

一、什么是CAP？ CAP示意图 Consistency (一致性)： “all nodes see the same data at the same time”,即更新操作成功并返回客户端后，所有节点在同一时间的数据完全一致，这就是分布式的一致性。一致性的问题在并发系统中不可避免，对于客户端来说，一致性指的是并发访问时更新过的数据如何获取的问题。从服务端来看，则是更新如何复制分布到整个系统，以保证数据最终一致。 Availability (可用性): 可用性指“Reads and writes always succeed”，即服务一直可用，而且是正常响应时间。好的可用性主要是指系统能够很好的为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。 Partition Tolerance (分区容错性): 即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。分区容错性要求能够使应用虽然是一个分布式系统，而看上去却好像是在一个可以运转正常的整体。比如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，对于用户而言并没有什么体验上的影响。 二、取舍策略 取舍策略图 CAP三个特性只能满足其中两个，那么取舍的策略就共有三种： CA without P： 如果不要求P（不允许分区），则C（强一致性）和A

1、单体应用的缺点 1）部署效率低下 2）协作开发成本高 3）系统高可用性能差 4）线上发布变慢 2、微服务的简单介绍 2.1）将一个单一应用程序，按照业务拆分呢为一组小型服务. 2.2）每个服务只做一件事，每个服务运行在自己的进程中 2.3）服务之间通过轻量级的通信机制(httprestapi) 2.4）每个服务都能够独立的部署 2.5）每个服务甚至可以拥有自己的数据库 2.6）微服务以及微服务架构的是二个完全不同的概念。微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把一个一个的微服务组合管理起来，对外提供一套完整的服务 3、微服务的优点 ①：每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应用，可能改几行代码需要了解整个系统) ②：开发简单，一个服务只干一个事情。（加入你做支付服务，你只要了解支付相关代码就可以了） ③：微服务能够被2-5个人的小团队开发，提高效率（你应该可以想象我们那时的状况。如果一次上线超过五个人参与的话，就会经常出现各种问题：有的人忘记提交代码、有的人忘记打包、有的人忘记修改工程依赖到最新版本。一次上线过程需要反复确认，耗费了大量精力，严重影响了整体的开发和部署效率。） ④：服务松耦合，每个服务都能够开发部署。 ⑤：前后段分离,作为java开发人员，我们只要关系后端接口的安全性以及性能，不要去关注页面的人机交互

2018 年夏天 国内微服务开源 领域，迎来了一位新成员。此后，在构建微服务注册中心和配置中心的过程中，国内开发者多了一个可信赖的选项。 Nacos 是阿里巴巴开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台( 官方网站 )，它凝聚了阿里巴巴十多年来在超大规模注册和配置上的最佳实践，可以用在微服务场景作为服务注册中心、配置中心等核心场景中，和阿里的其他微服务开源项目一样，Nacos 也是始于阿里，成长于社区的典型。 为什么要开源 Nacos ？ 在大规模服务发现和服务治理领域，现有的开源解决方案并非已经非常完美，阿里巴巴从 IOE 集中式应用架构升级为互联网分布式服务化架构的演进过程中，积累了大量有关服务注册和服务配置的实践经验，而这些经验是可以在各个行业大规模复用。除此之外，更重要的是，希望和社区开发者共同发展，让 Nacos 可以帮助国内企业更自由的构建基于云原生应用的动态服务发现、配置和服务管理。 相比其他服务注册和配置中心开源方案，Nacos 的起步虽然晚了点，但除了注册和配置中心的功能外，他还提供了动态服务发现、服务共享与管理的功能，在大规模场景下具备更优秀的性能，在易用性上更便捷，分布式部署上更灵活。例如和 Consul / Eureka / Zookeeper 相比：（内容摘自 《主流微服务注册中心浅析和对比》 ） Nacos Consul

上一篇文章讲的是mysql的基本操作，这一篇会有一点难以理解，本节主要内容mysql视图，存储过程，函数，事务，触发器，以及动态执行sql 视图view 视图是一个虚拟表，其内容由查询定义。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并不在数据库中以存储的数据值集形式存在。行和列数据来自由定义视图的查询所引用的表，并且在引用视图时动态生成。对其中所引用的基础表来说，视图的作用类似于筛选。定义视图的筛选可以来自当前或其它数据库的一个或多个表，或者其它视图。通过视图进行查询没有任何限制，通过它们进行数据修改时的限制也很少。视图是存储在数据库中的查询的SQL 语句，它主要出于两种原因：安全原因， 视图可以隐藏一些数据。 1、创建视图 --格式：CREATE VIEW 视图名称 AS SQL语句 CREATE VIEW v1 AS SELET nid, name FROM tab1 WHERE nid > 4 2、删除视图 --格式：DROP VIEW 视图名称 DROP VIEW v1 3、修改视图 -- 格式：ALTER VIEW 视图名称 AS SQL语句 ALTER VIEW v1 AS SELET A.nid,B. NAME FROM tab1 LEFT JOIN B ON A.id = B.nid LEFT JOIN C ON A.id = C.nid

但作为面试者，想进入BAT并成长为一名高级Java工程师却没那么容易。 虽然面试者具备了一定的工作年限要求，也长期使用Java语言进行开发，但面试时，面对刨根问底的提问，经常感觉get不到面试官的点，自己回答的也是马马虎虎，甚至无法完整描述自己开发过的系统或者使用过的技术， 因此也就很难得到满意的面试结果。 过完年就是金三银四，2021不会比2020好过，过一年有很多小伙伴在面试中屡屡碰壁，不是基本功不扎实就是遇到一些平时没怎么接触过问题还失败告终。 今天在这特地整理了一份阿里，美团，京东，拼多多，蚂蚁金服等大厂Java岗面试必备清单！ 注意： 由于篇幅原因，在这只展示了目录和内容截图， 有需要这份大厂Java后端面试清单的（以及更多学习资料），可以免费分享给大家一起学习，转发后转发后添加小编vx：mxzFAFAFA即可免费获取！！！ JVM专题 作为Java从业者，在找工作的时候，一定会被问及关于 JVM 相关的知识。 JVM 知识的掌握程度，在很多面试官眼里是候选人技术深度的一个重要评判标准。 如果连JVM都回答不好，大厂一面基本也就凉凉！ 在这里我们将详细地整理常见的 JVM 面试题目，并给出标准答案， 提供给大家学习参考。 内容展示 Java并发/多线程专题 从事 Java开发的小伙伴们会发现 Java 多线程和并发无论是工作或者是面试都绕不开的话题

简介： 本文介绍了微服务治理下金丝雀发布的能力，解决了发布期间少量流量验证新功能的问题。 很多互联网公司在半夜发布的另外一个重要原因是不具备可灰度能力，新版本存在 bug 或者其它原因会影响线上的客户，无奈之下只能选择在半夜进行发布来减少影响面。 我们知道默认情况下，无论是 Kubernetes 还是 ECS，新老版本都存在的情况下会根据特定的负载均衡算法随机地路由到不同的实例上，随机意味着出问题也会随机出现。我们需要一套动态路由来完成灰度发布的解决方案。 在 RPC 领域，我们称灰度发布为动态路由，动态路由的意思是指流量可以动态地路由到指定的实例上。 动态路由场景 动态路由是微服务里非常核心的功能，流量动态路由意味着可以做非常多的事情。由此衍生出各个场景: 金丝雀发布：只有满足特定规则(比如 Query Parameter、HEADER、COOKIE 中某些 KEY 满足一些条件)或者是固定流量比例的流量才会进入新版本，其它流量都路由到老版本上。 同机房优先路由：当公司规模扩大之后，应用会跨机房部署来达到高可用的目的。由于异地跨机房调用出现的网络延迟问题，需要确保服务消费方能优先调用相同机房的服务消费方，这就需要同机房优先路由的能力。 标签路由：金丝雀发布的新场景。金丝雀发布一般只有新和老两个版本，标签路由可以在线上部署多个版本，每个版本都对于一个标签。 全链路灰度

主要错误： Failed to configure a DataSource: 'url' attribute is not specified and no embedded datasource could be configured. 未能配置数据源:未指定“url”属性，也无法配置嵌入式数据源。 Error starting ApplicationContext . To display the conditions report re - run your application with 'debug' enabled . 2019 - 06 - 03 09 : 47 : 45.300 ERROR 23160 -- - [ //加入Java开发交流君样：756584822一起吹水聊天 main ] o . s . b . d . LoggingFailureAnalysisReporter : * * * * * * * * * * * * * * * * * * * * * * * * * * * APPLICATION FAILED TO START * * * * * * * * * * * * * * * * * * * * * * * * * * * Description : Failed to configure a DataSource : 'url'

我们的系统肯定有些线程为了保证业务需要是要常驻后台的，一般它们不会自己终止，需要我们通过手动来终止它们。我们知道启动一个线程是start方法，自然有一个对应的终止线程的stop方法，通过stop方法可以很快速、方便地终止一个线程，我们来看看stop的源代码。 通过注解@Deprecated看出stop方法被标为废弃的方法，jdk在以后的版本中可能被移除，不建议大家使用这种API。 那为什么这么好的一个方法怎么不推荐使用，还要标注为废弃呢？ 假设有这样的一个业务场景，一个线程正在处理一个复杂的业务流程，突然间线程被调用stop而意外终止，这个业务数据还有可能是一致的吗？这样是肯定会出问题的，stop会释放锁并强制终止线程，造成执行一半的线程终止，带来的后果也是可想而知的，这就是为什么jdk不推荐使用stop终止线程的方法的原因，因为它很暴力会带来数据不一致性的问题。 正因为stop方法太过暴力，所以一般不推荐使用，除非你非常清楚你自己的业务场景，用stop终止不会给你的业务带来影响。 说了这么多，那如何优雅地终止一个线程呢？看看下面的程序。 其实也不难，只需要添加一个变量，判断这个变量在某个值的时候就退出循环，这时候每个循环为一个整合不被强行终止就不会影响单个业务的执行结果。 推荐去我的博客阅读更多： 1. Java JVM、集合、多线程、新特性系列教程 2. Spring MVC

作者 | 张裕 编辑 | 雅纯 来源| 阿里巴巴云原生公众号 什么是云原生 DevOps 点击查看视频： https://v.qq.com/x/page/u3220cutt7v.html 我们先通过上面一个简短视频和下面两张图，来了解什么是云原生 DevOps，它和 DevOps 有什么不同。 上图是一个大排档，图中的大厨在非常努力的去切、炒、制作各种美食，并将它卖出去。从原材料的采购到加工到销售到售后，都是一两个人完成。这是非常典型的 DevOps 场景，团队搞定端到端的所有的事情。这种情况，当厨师水平比较高、销售能力比较强的时候，可以做到高效率、低浪费。但存在的问题是，想要规模化会很难。因为它的流程都是非标准的，需要厨师有很强的个人能力。 我们再看上面这张南京大排档的图，虽然名字里有大排档，但它显然不是我们上面说的大排档。我们随便走进任何一家南京大排档，都可以发现，南京大排档的厨师，可以专注在为客户提供更好的菜品上，研发试验新菜品，并通过小批量的用户来尝试和推广。无论是用户量增加或减少，都能很快的去适应。店铺扩张也可以很快。这种我们可以理解为云原生 DevOps。 那究竟什么是云原生 DevOps 呢？我们认为：云原生 DevOps 是充分利用云原生基础设施，基于微服务/无服务架构体系和开源标准，语言和框架无关，具备持续交付和智能自运维能力，从而做到比传统 DevOps

一 配置中心介绍 1 微服务架构下关于配置文件的问题 a 配置文件相对分散 在一个微服务架构下，配置文件会随着微服务的增多变的越来越多，而且分散在各个微服务中，不好统一配置和管理。 b 配置文件无法区分环境 微服务项目可能会有多个环境，例如：测试环境、预发布环境、生产环境。每一个环境所使用的配置理论上都是不同的，一旦需要修改，就需要我们去各个微服务下手动维护，这比较困难。 c 配置文件无法实时更新 我们修改了配置文件之后，必须重新启动微服务才能使配置生效，这对一个正在运行的项目来说非常不友好。 2 配置中心的思路 首先把项目中各种配置全部都放到一个集中的地方进行统一管理，并提供一套标准的接口。 服务需要获取配置的时候，就来配置中心的接口拉取自己的配置。 配置中心参数有更新时，能够通知到微服务实时同步最新的配置信息，使之动态更新。 二 常见配置中心 1 Apollo Apollo是由携程开源的分布式配置中心。特点有很多，比如：配置更新之后可以实时生效，支持灰度发布功能，并且能对所有的配置进行版本管理、操作审计等功能，提供开放平台API。并且资料也写的很详细。 2 Disconf Disconf是由百度开源的分布式配置中心。基于Zookeeper实现配置变更后实时通知和生效。 3 SpringCloud Config Spring Cloud的配置中心组件。和Spring无缝集成