SpringBoot_1
- 微服务（Microservice）是什么？
SOA（面向服务的架构）
微服务，是与之前的服务化思路和实践相比较而来的。
早些年的服务实现和实施思路是将很多功能从开发到交付都打包成一个很大的服务单元（一般称为 Monolith），而微服务实现和实施思路则更强调功能趋向单一，服务单元小型化和微型化。
如果用“茶壶煮饺子”来打比方的话，原来我们是在一个茶壶里煮很多个饺子，现在（微服务化之后）则基本上是在一个茶壶煮一个饺子，而这些饺子就是服务的功能，茶壶则是将这些服务功能打包交付的服务单元，如图 1 所示。
所以，从思路和理念上来讲，微服务就是要倡导大家尽量将功能进行拆分，将服务粒度做小，使之可以独立承担对外服务的职责，沿着这个思路开发和交付的软件服务实体就叫作“微服务”，而围绕着这个思路和理念构建的一系列基础设施和指导思想，笔者将它称为“微服务体系”。
微服务是怎么来的？
微服务的概念我们应该大体了解了，那么微服务又是怎么来的？原来将很多功能打包为一个很大的服务单元进行交付的做法不能满足需求吗？
实际上，并非原来“大一统”（Monolith）的服务化实践不能满足要求，也不是不好，只是，它有自己存在的合理场景。
对于 Monolith 服务来说，如果团队不大，软件复杂度不高，那么，使用 Monolith 的形式进行服务化治理是比较合适的，而且，这种方式对运维和各种基础设施的要求也不高。
但是，随着软件系统的复杂度持续飙升，软件交付的效率要求更高，投入的人力以及各项资源越来越多，基于 Monolith 的服务化思路就开始“捉襟见肘”。
在开发阶段，如果我们遵循 Monolith 的服务化理念，通常会将所有功能的实现都统一归到一个开发项目下，但随着功能的膨胀，这些功能一定会分发给不同的研发人员进行开发，造成的后果就是，大家在提交代码的时候频繁冲突并需要解决这些冲突，单一的开发项目成为了开发期间所有人的工作瓶颈。
为了减轻这种苦恼，我们自然会将项目按照要开发的功能拆分为不同的项目，从而负责不同功能的研发人员就可以在自己的代码项目上进行开发，从而解决了大家无法在开发阶段并行开发的苦恼。
到了软件交付阶段，如果我们遵循 Monolith 的服务化理念，那么，我们一定是将所有这些开发阶段并行开发的项目集合到一起进行交付。
这就涉及服务化早期实践中比较有名的“火车模型”，即交付的服务就像一辆火车，而这个服务相关的所有功能对应的项目成果，就是要装上火车车厢的一件件货物，交付的列车只有等到所有项目都开发测试完成后才可以装车出发，完成整个服务的交付。
很显然，只要有一个车厢没有准备好货物（即功能项目未开发测试完成），火车就不能发车，服务就不能交付，这大大降低了服务的交付效率。如果每个功能项目可以各自独立交付，那么就不需要都等同一辆火车，各自出发就可以了。
顺着这个思路，自然而然地，大家逐渐各自独立，每一个功能或者少数相近的功能作为单一项目开发完成后将作为一个独立的服务单元进行交付，从而在服务交付阶段，大家也能够并行不悖，各自演化而不受影响。
所以，随着服务和系统的复杂度逐渐飙升，为了能够在整个软件的交付链路上高效扩展，将独立的功能和服务单元进行拆分，从而形成一个一个的微服务是自然而然发生的事情。
这就像打不同的战役一样，在双方兵力不多、战场复杂度不高的情况下，Monolith 的统一指挥调度方式是合适的。而一旦要打大的战役（类似于系统复杂度提升），双方一定会投入大量的兵力（软件研发团队的规模增长），如果还是在狭小甚至固定的战场上进行厮杀，显然施展不开！
所以，小战役有小战役的打法，大战役有大战役的战法，而微服务实际上就是一种帮助扩展组织能力、提升团队效率的应对“大战役”的方法，它帮助我们从软件开发到交付，进而到团队和组织层面多方位进行扩展。
总的来说，一方面微服务可以帮助我们应对飙升的系统复杂度；另一个方面，微服务可以帮助我们进行更大范围的扩展，从开发阶段项目并行开发的扩展，到交付阶段并行交付的扩展，再到相应的组织结构和组织能力的扩展，皆因微服务而受惠。
早期我们从开发到交付，都是单一应用结构，所有功能都集中在一个项目中，统一管理和开发。【雕版印刷】
微服务就是一个项目中的功能，独立的分成多个子项目，并行开发。【活字印刷】
微服务其实是一种架构风格，提倡一个应用应该是一组小型服务组成；可以通过HTTP的方式进行互通。
在没有微服务之前我们软件架构方式称为单体应用：ALL IN ONE。就是所有的内容统一集中在一个应用程序中。
这种单体应用的优点：开发测试简单，不会涉及多个应用之间的互联互调，应用部署也简单，只需要一个war包就OK,不会对运维造成太大负担，还有就是应用程序的水平扩展也简单，就是新增模块简单。当并发量高的时候，我们可以将这个单体应用多复制几份部署在多个服务器上，通过负载均衡机制控制运行，可以提高并发访问。
他的缺点也很明显，那就是到我们需要对程序进行修改的时候就需要重新打包，重新部署，重新运行，这就是一个牵一发动全身的情况，当然更大的挑战是来自于日益增长的软件需求。
目前我们随便做一个软件都需要提供很多更能，不管这些功能有用没有都得实现，这个一个小应用就都成一个大型应用。而大型应用我们不可能将所有功能全部都写在一个应用中，因为分工合作麻烦，维护量大，而且这个应用到时候可能谁都不知道这个应用会有多大。所以我们才要学习使用微服务开发，来避免这样的问题。
可以这样理解：单体应用就是雕版印刷
微服务就是活字印刷
微服务：每一个功能元素最终都是一个可独立替换和独立升级的软件单元；
那么利用微服务搭建起来的项目长什么样？
这种类似于神经网络一样的结构就是最终微服务构建起来的项目，每一个圆圈就是服务，服务于服务之间通过http协议访问连接。
那么这种庞大微服务应用程序如何构建和部署整合呢，这时我们的SPringBoot就有用武之地。
通过SpringBoot快速构建微服务应用，通过SpringCloud进行分布式互联互调，形成分布式结构，通过SpringCloudDataFlow进行流式数据运算和批处理操作。
- Spring Boot简介
SpringBoot是Spring团队在2014年，伴随Spring4.0版本推出的一个新的框架。
主要作用：
SpringBoot使创建独立的、生产级的、基于Spring的应用程序变得容易，您可以“只运行”。
就是帮助我们快速的创建出基于Spring的应用程序。
想一想在你没有SpringBoot的时候我们使用Spring创建应用程序，或者是整合SpringMVC、MyBatyis,往往都需要先导入很多的依赖包，然后编写大量的配置文件，然后开发业务逻辑，最后测试，接下来就是打war包，部署到服务器，部署之前还得配置好服务器环境，这样才完成工作。所以在以前没有SpringBoot的时候，我们对java EE程序的开发都是比较笨重的开发,需要繁多的配置，带来低下的开发效率和复杂的部署流程,还有第三方技术集成难度大。因此上SpringBoot的出现实际上就是用来简化我们对java EE程序的开发，帮助我们快速的创建出基于Spring的应用程序。
SpringBoot的底层实际上还是使用的Spring技术，他其实就是通过整合Spring提供的针对不同领域的开发框架来达到简化Java EE 程序的开发步骤的
Spring提供的针对不同领域的开发框架：
Spring Framework：提供IOC容器
Spring Cloud：分布式框架
Spring Data：数据库访问框架
Spring Security：安全校验框架
等等......
SpringBoot--帮助我们快速的创建出基于Spring框架的应用程序的一个框架。利用SpringBoot创建的Spring应用程序，可以很轻松的实现Spring各种子框架的应用和整合。
SpringBoot的优点
2.1快速创建独立运行的Spring项目以及与主流框架集成
2.2使用嵌入式的Servlet容器，应用无需打成WAR包
2.3 starters自动依赖与版本控制
2.4大量的自动配置，简化开发，也可修改默认值
2.5无需配置XML，无代码生成，开箱即用
2.6准生产环境的运行时应用监控
2.7 与云计算的天然集成
在学习使用的SpringBoot之前我们需要我一下的一些基本内容：
- 熟练使用Spring框架
- 熟练使用Maven进行项目的构建和依赖包的管理
- 熟练使用Eclipse或者IDEA
约束环境
1.jdk1.8
2.maven3.x
3.IntelliJ IDEA 2017
4.Spring Boot 1.5.9.RELEASE
3.Spring Boot HelloWorld
需求:浏览器发送hello请求，服务器接受请求并处理，响应Hello World字符串。
- 创建一个maven工程；（jar）
一路next直至项目创建成功！
3.pom文件配置
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
</dependency>可以帮助我们将开发基于Spring的web应用程序的所有依赖包全部自动导入
4.在src/main/java下创建控制器类
package com.wangxing.springboot.controller;
import org.springframework.context.annotation.ComponentScan;
i
最低0.47元/天 解锁文章
6214
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
