狂神视频地址
- 1.回顾
- - 1.1回顾学习路线
  - 1.2鸡汤
  - 1.3回顾Spring
- 2.SpringBoot阶段开发
- - 2.1什么是SpringBoot
  - 2.2.SpringBoot 阶段
- 3.微服务
- - 3.1什么是微服务
  - 3.2开发演变
  - 3.3如何构建微服务
- 4.第一个SpringBoot程序
- - 4.1修改启动时的Logo
  - 4.2Idea 创建SpringBoot项目
- 5.SpringBoot 自动装配原理
- 6.Yml
- - 6.1 yml 语法
  - 6.2.yml 直接注入匹配值
  - 6.3JSR303数据校验
  - 6.4.多环境配置及配置文件位置
- 7.web开发探究
- - 7.1静态资源导入探究
  - 7.2首页如何定制
  - 7.3Thymeleaf使用
  - 7.4Thymeleaf 遍历
  - 7.5Thymeleaf 练习
- 8.使用国际化
- 9.整合JDBC
- 10.整合Druid
- 11.整合Mybatis
- 12.整合Swagger
- 13.任务
- - 13.1异步任务
  - 13.2邮件任务
  - 13.3定时任务
- 14.分布式
- - 14.1什么是分布式系统/li>
  - 14.2什么是RPC/li>
  - 14.3如何给老婆解释什么是RPC
  - 14.4什么是Dubbo
  - 14.5什么是zookeeper
  - 14.6安装dubbo-admin

狂神视频地址

https://www.bilibili.com/video/BV1PE411i7CVpm_id_from=333.999.0.0

1.回顾

1.1回顾学习路线

javase：OOP
mysql：持久化
html+css+Jquery+框架：视图
javaweb：独立开发mvc三层架构的网站：原始
SSM：框架：简化了开发流程：配置也开始较为复杂；
war：tomcat 运行
Spring再简化：Spring Boot；jar ：内嵌tomcat；微服务架构！
服务越来越多：Spring Cloud 整理服务

1.2鸡汤

培训讲师
（面向面试培训，叫你如何使用，快速上手！）

做教育的
如何学习新东西，如何持续学习，如果关注这个行业！
知道这个东西的来龙去脉，历史，理论；（用来做什么么用

程序 = 数据结构+算法（集合框架）；（程序猿）

程序 = 面向对象+框架；（码农）

1.3回顾Spring

什么是Spring /strong>
Spring 是一个开源框架，2003年兴起的一个轻量级java 开发框架，Rod Johnson（音乐学的博士，本科不是计算机，头发挺多的）
Spring 是为了解决企业级应用开发的复杂性而创建，简化开发

Spring是如何简化开发的/strong>

基于POJO的轻量级和最小侵入性编程，所有的东西都是bean
通过IOC、和依赖注入（DI）和面向接口实现松耦合
基于切面（AOP）和惯例进行声明式编程
通过切面和模板减少样式代码，RedisTemplate

2.SpringBoot阶段开发

2.1什么是SpringBoot

过javawed的就知道，开发一个web应用，从最初开始接触Servlet结合tomcat 。跑出一个hello world程序，是要经历特别多的步骤；后面就用来Spring MVC框架，到现在的Spring Boot，过一两年可能又会有其他框架出现；有经历过框架的不断演进，然后自己开发项目所有的技术也在不断的变化、改造吗/p>

什么是Spring Boot呢是一个javawevb的开发框架，和SpringMVC类似，对比其他javaweb框架的好处，官方说是“简化开发”，约定大于配置，能迅速的开发web应用，几行代码开发一个http接口。
所有的技术框架的发展似乎都遵循了一条主线规律：从一个复杂应用场景衍生一种规范框架，人们只需要进行各种配置而不需要自己去实现它，这时候强大的配置功能成了优点；发展到一定程度之后，人们根据实际生产应用情况，选取其中实用功能和设计精华，重构出一些轻量级的框架；之后为了提高开发效率，嫌弃原先的各类配置过于麻烦，于是开始提倡“约定大于配置”，进而衍生出一些一站式的解决方案。

是的这就是Java企业级应用->J2EE->spring->springboot的过程。

随着 Spring 不断的发展，涉及的领域越来越多，项目整合开发需要配合各种各样的文件，慢慢变得不那么易用简单，违背了最初的理念，甚至人称配置地狱。Spring Boot 正是在这样的一个背景下被抽象出来的开发框架，目的为了让大家更容易的使用 Spring 、更容易的集成各种常用的中间件、开源软件；

Spring Boot 基于 Spring 开发，Spirng Boot 本身并不提供 Spring 框架的核心特性以及扩展功能，只是用于快速、敏捷地开发新一代基于 Spring 框架的应用程序。也就是说，它并不是用来替代 Spring 的解决方案，而是和 Spring 框架紧密结合用于提升 Spring 开发者体验的工具。Spring Boot 以约定大于配置的核心思想，默认帮我们进行了很多设置，多数 Spring Boot 应用只需要很少的 Spring 配置。同时它集成了大量常用的第三方库配置（例如 Redis、MongoDB、Jpa、RabbitMQ、Quartz 等等），Spring Boot 应用中这些第三方库几乎可以零配置的开箱即用。
简单来说就是SpringBoot其实不是什么新的框架，它默认配置了很多框架的使用方式，就像maven整合了所有的jar包，spring boot整合了所有的框架。

Spring Boot 出生名门（Spring已经很火了），从一开始就站在一个比较高的起点，又经过这几年的发展，生态足够完善，Spring Boot 已经当之无愧成为 Java 领域最热门的技术。

Spring Boot的主要优点：
1.为所有Spring开发者更快的入门
2.开箱即用，提供各种默认配置来简化项目配置
3.内嵌式容器简化Web项目
4.没有冗余代码生成和XML配置的要求

2.2.SpringBoot 阶段

SpringBoot 简化Spring的，和Spring本质上是一样的。

是什么
配置如何编写 yml
自动装配原理（最核心）
集成web开发（拦截器，登录认证，增删改查）
集成数据库（druid）
分布式开发：Dubbo+zookeeper（必须掌握）
swagger：接口文档
任务调度
SpringSecurity ： Shiro（安全框架），全程横切进去（AOP）

3.微服务

3.1什么是微服务

“微服务架构（Microservice Architecture）”一词在过去几年里广泛的传播，它用于描述一种设计应用程序的特别方式，作为一套独立可部署的服务。目前，这种架构方式还没有准确的定义，但是在围绕业务能力的组织、自动部署（automated deployment）、端智能（intelligence in the endpoints）、语言和数据的分散控制，却有着某种共同的特征。
“微服务（Microservices）”——只不过在满大街充斥的软件架构中的一新名词而已。尽管我们非常鄙视这样的东西，但是这玩意所描述的软件风格，越来越引起我们的注意。在过去几年里，我们发现越来越多的项目开始使用这种风格，以至于我们身边的同事在构建企业级应用时，把它理所当然的认为这是一种默认开发形式。然而，很不幸，微服务风格是什么，应该怎么开发，关于这样的理论描述却很难找到。
简而言之，微服务架构风格，就像是把一个单独的应用程序开发为一套小服务，每个小服务运行在自己的进程中，并使用轻量级机制通信，通常是 HTTP API。这些服务围绕业务能力来构建，并通过完全自动化部署机制来独立部署。这些服务使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。
在开始介绍微服务风格（microservice style）前，比较一下整体风格（monolithic style）是很有帮助的：一个完整应用程序（monolithic application）构建成一个单独的单元。企业级应用通常被构建成三个主要部分：客户端用户界面（由运行在客户机器上的浏览器的 HTML 页面、Javascript 组成）、数据库（由许多的表构成一个通用的、相互关联的数据管理系统）、服务端应用。服务端应用处理 HTTP 请求，执行领域逻辑（domain logic），检索并更新数据库中的数据，使用适当的 HTML 视图发送给浏览器。服务端应用是完整的，是一个单独的的逻辑执行。任何对系统的改变都涉及到重新构建和部署一个新版本的服务端应用程序。
这样的整体服务（monolithic server）是一种构建系统很自然的方式。虽然你可以利用开发语基础特性把应用程序划分成类、函数、命名空间，但所有你处理请求的逻辑都运行在一个单独的进程中。在某些场景中，开发者可以在的笔计本上开发、测试应用，然后利用部署通道来保证经过正常测试的变更，发布到产品中。你也可以使用横向扩展，通过负载均衡将多个应用部署到多台服务器上。
整体应用程序（Monolithic applications）相当成功，但是越来越多的人感觉到有点不妥，特别是在云中部署时。变更发布周期被绑定了——只是变更应用程序的一小部分，却要求整个重新构建和部署。随着时间的推移，很难再保持一个好的模块化结构，使得一个模块的变更很难不影响到其它模块。扩展就需要整个应用程序的扩展，而不能进行部分扩展。

微服务（microservice ）的划分方法不同，它倾向围绕业务功能的组织来分割服务。这些服务实现商业领域的软件，包括用户界面，持久化存储，任何的外部协作。因此，团队是跨职能的（cross-functional），包含开发过程所要求的所有技能：用户体验（user-experience）、数据库（database）和项目管理（project management）。

微服务音分散数据现任意味着管理数据更新。处理数据更新的常用方法是使用事务来保证不同的资源修改数据库的一致性。这种方法通常在整体架构中使用。

使用事务是因为它能够帮助处理一至性问题，但对时间的消耗是严重的，这给跨服务操作带来难题。分布式事务非常难以实施，因此微服务架构强调服务间事务的协调，并清楚的认识一致性只能是最终一致性以及通过补偿运算处理问题。

选择处理不一致问题对于开发团队来说是新的挑战，但是也是一个常见的业务实践模式。通常业务上允许一定的不一致以满足快速响应的需求，但同时也采用一些恢复的进程来处理这种错误。当业务上处理强一致性消耗比处理错误的消耗少时，这种付出是值的的。

基础设施自动化
基础设施自动化技术在过去几年中得到了长足的发展：云计算，特别是AWS的发展，减少了构建、发布、运维微服务的复杂性。

许多使用微服务架构的产品或者系统，它们的团队拥有丰富的持集部署以及它的前任持续集成的经验。团队使用这种方式构建软件致使更广泛的依赖基础设施自动化技术。下图说明这种构建的流程：

容错性设计
使用服务作为组件的一个结果在于应用需要有能容忍服务的故障的设计。任务服务可能因为供应商的不可靠而故障，客户端需要尽可能的优化这种场景的响应。跟整体构架相比，这是一个缺点，因为它带来的额外的复杂性。这将让微服务团队时刻的想到服务故障的情况下用户的体验。Netflix 的Simian Army可以为每个应用的服务及数据中心提供日常故障检测和恢复。

这种产品中的自动化测试可以让大部分的运维团队正常的上下班。这并不意味着整体构架的应用没有这么精巧的监控配置，只是在我们的经验中它并不常见。

由于服务可以随时故障，快速故障检测，乃至，自动恢复变更非常重要。微服务应用把实时的监控放在应用的各个阶段中，检测构架元素（每秒数据库的接收的请求数）和业务相关的指标（把分钟接收的定单数）。监控系统可以提供一种早期故障告警系统，让开发团队跟进并调查。
对于微服务框架来说，这相当重要，因为微服务相互的通信可能导致紧急意外行为。许多专家车称赞这种紧急事件的价值，但事实是这种紧急行为有时是灾难。监控是至关重要的，它能快速发现这种紧急不良行为，让我们迅速修复它。

整体架构，跟微服务一样，在构建时是通明的，实情上，它们就是这样子的。它们不同之处在于，你需要清楚的认识到不同进程间运行的服务是不相关的。库对于同一进程是透明的，也因此不那么重要了。

微服务团队期望清楚的监控和记录每个服务的配置，比如使用仪表盘显示上/下线状态、各种运维和业务相关的指标。对断路器（circuit breaker）状态、目前的吞吐量和时延细节，我们也会经常遇到。

设计改进
微服务实践者，通常有不断改进设计的背景，他们把服务分解成进一步的工具。这些工具可以让应用开发者在不改变速度情况下，控制都他们的应用的需求变更。变更控制不意味首减少变更，而是使用适当的方式和工具，让它更加频繁，至少，很好让它变得可控。

不论如何，当你试图软件系统拆分成组件时，你将面临着如何拆分的问题。那么我们的决定拆分我们应用的原则是什么呢要的因素，组件可以被独立替换和更新的，这意味着我们寻找的关键在于，我们要想象着重写一个组件而不影响它们之前的协作关系。事实上，许多的微服务小组给它进一步的预期：服务应该能够报废的，而不是要长久的发展的。

Guardian网站就是这方面的一个优秀的例子，它初期被设计和构建成一个整体架构，但它已经向微服务的发展了。整体构架仍然是它网站的核心，但是他们使用微服务来增加那些使用整体架构API的新特性。这种方法增加这些临时的特性非常方便，比如运动新闻的特稿。这样站点的一个部分可以使用快速的开发语言迅速整合起来，当它过时后可以一次性移除。我们发现一家金融机构用相似的方法增加新的市场营销活动，数周或者几个月后把它撤销。

可代替是模块化开发中的一个特例，它是用模块来应对需要变更的。你希望让变更是相同模块，相同周期中进行变化而已。系统的某些很小做变更部分，也应该放在不同的服务中，这样它们更容易让它们消亡。如果你发现两个服务一直重复的变更时，这就是一个要合并它们的信号了。

把组件改成服务，增加了细化发布计划的一个机会。整体构架的任务变更需要整个应用的完整的构建和发布。然而，使用微服务，你只需要发布你要修改的服务就可以了。这将简化和加速你的发布周期。缺点是你需要为一个变更服务发布可能中断用户的体验而担心。传统的集成方法是使用版本来处理这些问题，但是微服务版本仅是最后的通告手段。我们需要在设计服务时尽可能的容忍供应商的变更，以避免提供多个版本。

微服务是未来吗/strong>

我们写这篇文章的主要目的在于解释微服务的主要思想和原则。但是发时间做这事的时候，我们清醒的认识到微服务构架风格是一个非常重要的想法：一个值得企业应用中认真考虑的东西。我们最近使用这种风格构建了几个系统，认识那些也使用和喜欢这种方法的爱好者。

我们认识的使用这种方式的先行者，包含亚马逊、Netflix、The Guardian、The UK Government Digital Service、realestate.com.au、Forward和comparethemarket.com。2013看的巡回会议充满了向正在想成为微服务一分子的公司，包含Travis CI。此外，大量的组件正在从事我们认为是微服务的事，只是没有使用微服务的名字而已。（通常，它们被打上SOA的标签，尽管，我们认为SOA有许多不同的地方。）

尽管有这些积极的经验，然后，我们也不急于确认微服务是未来软件架构方向。至今为止，我们的经验与整体风格的应该中相比出来的是有优势的，但是我们意识知这样的事实，我们并没有足够的时间来证明我们的论证。

你所使用的架构通常是你开发出来后，使用的几年的实际成果。我们看到这些工程是在一个优秀的团队，带着对模块化的强烈追求，使用在过去几年中已经衰退的整体架构构建出来的。许多人相信，这种衰退不太可能与微服务有关，因为服务边界是清晰的并且很难再完善的。然而，当我们还没看到足够多的系统运行足够长时间时，我们不能肯定微服务构架是成熟的。

当然，还有原因就是，有人期望微服务构架不够成熟。在组件化方面的任何努力，其成功都依赖于软件如何拆分成适合的组件。指出组件化的准确边界应该在那，这是非常困难的。改良设计要承认边界的权益困境和因此带来的易于重构的重要性。但是当你的组件是被远程通信的服务时，重构比进程内的库又要困难的多。服务边界上的代码迁移是困难的，任务接口的变更需要参与者的共同协作，向后兼容的层次需要被增加，测试也变更更加复杂。

另一个问题在于，如果组件并没有清晰的划分，你的工作的复杂性将从组件内部转向组件间的关系。做这事不仅要围绕着复杂，它也要面对着不清晰和更难控制的地方。很容易想到，当你在一个小的、简单的组件内找东西，总比在没有关系的混乱的服务间要容易。

最后，团队技能也是重要的因素。新的技术倾向于被掌握更多的技能的团队使用。但是掌握多技能的团队中使用的技巧在较少技能的团队中并不是必需的。我们发现大量的少技能的团队构建混乱的整合构架，但是它要发时间去证明使用微服务在这种情况下会发生什么。一个糟糕的团队通常开发糟糕的系统：很难说，微服务在这种情况下是否能帮助它们，还是破坏它们。

一个理性的争议在于，我们听说，你不应该从微服务构架开始做。最好从整体构架开发，做模块化开发，然后当整体构架出现问题是再把模块化拆分成服务。（尽管这种建议不是好主意，因为一个好的进程内接口并不是一个好的服务接口。）

因此我们持这种谨慎的乐观。到目前为止，我们还没有足够认识，关于微构架能否被大范围的推广。我们不能肯定的说，我们要终结什么，但是软件开发的挑战在于你只能在不完整的信息中决定你目前要处理的问题。

微服务系统多大/strong>
尽管“微服务”一词在架构风格中越来越流行，它的名字很不辛让人关注它的服务大小，以及对“微”这个组成的争议。在我们与微服务实践者的谈话中，我们发现了服务的大小范围。被报道的最大团队遵循亚马逊Tow Pizaa团队理念（比如，一个团队吃两个比萨就可以了。），这意味着不超过20号（一打）人。我们发现最小配置是半打的团队支撑起一打的服务。

这也引发这样的考虑：规模为一个服务一打人到一个服务一个人的团队打上微服务的标签。此刻我们认为，它们是一样的，但是随着对这种风格的深入研究，也存在我们改变我们的想法的可能。

微服务与SOA
当前我们谈到微服务时，通常会问，这是不是我们20年前讨论的面向服务架构（SOA）。这是一个很好的观点，因为微服务风格也SOA所提倡的一些优势非常相似。尽管如此，问题在于SOA意味的太多不同的东西了，因此通常时候我们谈的所谓“SOA”时，它与我们谈论的风格不一至，因为它通常是指在整体风格应用中的ESB。

此外，我们发现面向服务的风格是这么的拙劣：从试图使用ESB隐藏复杂性，到使用多年才认识到发费数百美元却没产生任务价值这样的失败，到集中治理模式抑制变更。而且这些问题往往很难发现。
可以肯定的时，微服务社区中使用的许多的技术都开发者是从大型机构的整合服务经验中发展来的。

Tolerant Reader模式就是这样的一个例子。由于互联网的发展，利用简单的协议这种方法，让它从这些经验传达的出来。这是从已经很复杂的集中式标准中的一种反模式，坦白的说，真让人惊叹。（无论何时，当你需要用一个服务来管理你的所有的服务，你就知道这很麻烦。）

SOA的这种常见行为让微服务的提倡者拒绝打上SOA的标签，尽管有人认为微服务是从SOA中发展而来的，或许面向服务是对的。无论如何，事实上SOA表达这么多的含义，它给一个团队清醒的认识到这种构架风格就已经值的了。

多语言，多选择
JVM做为一个平台，它的增长就是一个平台中运行多语言的最大的例子。过去二十年中，它通常做为更高层次语言的壳，以达到更高层次的抽象。比如，研究它的内部结构，、使用低级的语言写更高效的代码。尽管如此，许多整体风格并不需要这种层次的性能优化或者在语法及高层次上的抽象，这很常见（让我们很失望）。此外整体构架通常意味着使用单一的语言，这也限制着使用技术的数量。

实践标准和强制标准
它有点尴尬，微服务团队倾向于避免这种通常由企业架构队伍定制的僵硬的强制标准，但是它们却非常乐于甚至推广这些开放的标准，如HTTP、ATOM、其它微规范。
关键的不同在这些标准是怎么开发出来的，以及它们是怎么被推广的。标准被一些组件管理，如IETF认证标准，仅当它们在互联网上有几个在用的实现，通常源自于开源工程的成功应用。
这些标准单独分离出来，与那种在企业中通常有没有什么编码经验的或者没有什么影响力的厂商标准进行区别。

让做对事更容易
一方面，我们发现在持续发布、部署越来越多的使用自动化，是很多有用的工具开发出来帮助开发者和运营商的努力结果。为打包、代码管理、支撑服务的工具，或者增加标准监控的记录的工具，现在都非常常见了。网络中最好的，可能就是Netflix’s的开源工具，但是包含Dropwizard在内的其它工具也被广泛的使用着。

断路器(circuit breaker)和产品中现有的代码
断路器(circuit breaker)出现在《Realease It!》一书中，与Bulkhead和Timeout这样的模式放在一起。实施起来，这些模式用于构建通信应用时相当的重要。Netflix的博客在解释它们的应用时，做了大量的工作。

同步是有害的
任务时候，你在服务间的调用使用同步的方法，都会遇到宕机时间的乘积效应。简单的说，你的系统宕机时间是你系统的单独组件的宕机时间的乘积。你面临的选择使用异步或者管理宕机时间。在www.guardian.co.uk中，它们在新平台中使用一种简单的规则来实现它：在Netflix中每次用户请求的同步调用，他们重新设计的平台API都会把它构建成异步的API来执行。

总结

MVC：三层架构（控制层，业务层，持久层）

MVVM：

微服务架构：

微服务架构，把服务拆成了一个个的微服务，就相当于 ssm 开发时的业务。
服务（业务）service：userService：==》模块！比如这是用户的业务
但是服务变成了分布式了，要分布在不同的电脑去放，一台电脑单机放不下了。
怎么办/li>
是不是这个服务（模块）就得单独放一个电脑了。
所以把服务变成一个模块。
这个服务里面就做这么一件事情
SpringMVC 已配置，controller ，微服务负责提供接口：
微服务提供接口，其他电脑就可以用了
有很多很多接口的时候分布在不同电脑上，是不是一个网状的概念，这就是微服务了。
所以微服务不是新东西，只是把我们原来的业务再拆分，拆分成一个个模块。

官方说法：
微服务是一种架构风格，它要求我们在开发一个应用的时候，这个应用必须构建成一系列小服务的组合；可以通过http的方式进行互通。RPC

3.2开发演变

随着互联网的发展，网站应用的规模不断扩大，常规的垂直应用架构已无法应对，分布式服务架构以及流动计算架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

用户下单：controller 1s
仓库冻结：资金冻结：验证：购买成功，仓库数量减少，仓库解冻，服务解冻，资金解冻 10s

程序：高内聚，低耦合

文章推荐
原文：https://martinfowler.com/articles/microservices.html
论文：https://www.cnblogs.com/liuning8023/p/4493156.html

3.3如何构建微服务

一个大型的微服务架构，就像一个复杂交织的神经网络，每一个神经元就是一个功能元素，他们各自完成注解的功能，然后通过http相互请求调用。

比如一个电商系统，查缓存、连数据库、浏览页面、结账、支付等服务都是一个个独立的功能服务，都被微化了，它们作为一个个微服务共同构建了一个庞大的系统。修改其中的一个功能，只需升级其中一个功能服务单元即可。

但是这种庞大的系统架构给部署和运维带来很大的难度。于是，Spring为我们带来了构建大型分布式微服务的全套、全程产品

4.第一个SpringBoot程序

版本

构建Spring boot 项目添加web 依赖

Spring boot 默认结构

直接使用idea 创建一个Spring Boot项目（一般开发直接在idea创建）

spring-boot-starter 所有的Springboot 依赖都是使用这个开头的

4.1修改启动时的Logo

只需一步：到项目下的 resources 目录下新建一个banner.txt 即可。
图案可以到：https://www.bootschool.net/ascii 这个网站生成，然后拷贝到文件中即可！

来源：闲言博客

声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！

【狂神说Java】SpringBoot最新教程IDEA版通俗易懂

目录