什么是微服务？
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制（通常用HTTP资源API）。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
微服务架构应该具备以下特性：
-
每个微服务可独立运行在自己的进程里。
-
一系列独立运行的微服务共同构建起整个系统。
-
每个服务为独立的业务开发，一个微服务只关注某个特定的功能，例如订单管理，用户管理等。
-
微服务之间通过一些轻量的通信机制进行通信，例如通过RESTful API进行调用。
-
可以使用不同的语言与数据存储技术
- 全自动部署机制
聚合器微服务设计模式 这是一种最常用也最简单的设计模式（见下图）
6种微服务设计模式参考： https://blog.csdn.net/stubborn_cow/article/details/50287597
微服务框架有哪些？
Dubbo 是阿里开源的一款高性能 RPC 框架，特性包括基于透明接口的 RPC（Remote Procedure Call,即远程过程调用）、智能负载均衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理。
Spring Cloud 基于 Spring Boot，使用 HTTP协议 为微服务体系开发中的架构问题，提供了一整套的解决方案——服务注册与发现，服务消费，服务保护与熔断，网关，分布式调用追踪，分布式配置管理等。
- 请求统一通过 API 网关（Zuul）来访问内部服务。
- 网关接收到请求后，从注册中心（Eureka）获取可用服务。
- 由 Ribbon 进行均衡负载后，分发到后端具体实例。
- 微服务之间通过 Feign 进行通信处理业务。
- Hystrix 负责处理服务超时熔断。
- Turbine 监控服务间的调用和熔断相关指标。
官网： https://spring.io/projects/spring-cloud
版本名：是伦敦的地铁名
版本号：SR（Service Releases）是固定的 稳定版本。后面会有一个递增的数字。
所以 Finchley.SR4就是Finchley的第4个Release版本
从上面这个图也可以看出，Spring Cloud 的子组件版本 也不是很统一.
使用Spring脚手架快速搭建应用
先编写服务提供方代码
在我们的工程当中，New --> Module... --> Spring Initializr（SDK 1.8)-->填写坐标(如下图)-->选择要引入的依赖
(Web---Spring Web; SQL---JDBC API,MyBatis Framework,MySQL Driver ； 别忘记了选择SpringBoot版本)-->下一步 Finish
修改pom.xml，手动增加通用Mapper的坐标(通用Mapper是中国人自己写的，故需要自己手动引入)
<dependency>
<groupId>tk.mybatis</groupId>
<artifactId>mapper-spring-boot-starter</artifactId>
<version>2.1.5</version>
</dependency>
另外我在pom.xml文件中又增加了几个编码和编译版本的属性值，默认只生成了java.version
首次引入这些包需要网络下载，故需要一些时间，请耐心等待.
对配置文件修改
我们不再用properties文件，把生成的配置文件重命名成yml文件，我们看看yml的写法。
代码编写（实体类，拷贝的之前的Spring boot里面的）
通用Mapper使用
引导类增加注解
BaseUserService
BaseUserController
启动测试
再编写服务调用方代码
在我们的工程当中，New --> Module... --> Spring Initializr（SDK 1.8)-->填写坐标(如下图)-->选择要引入的依赖
(Web---Spring Web； 别忘记了选择SpringBoot版本)-->下一步 Finish
***若右侧显示出来了 Run Dashboard面板，一定要显示起来，如果万一关闭了，请参考 IDEA关于 Run Dashboard的手动打开方法。，它可以快速启动Spring Boot应用，不要自己去找引导类。
pom.xml文件基本不用改动
配置文件我们暂时就改个端口
引导类，加上 RestTemplate
实体类
Controller 调用服务提供者程序的接口
测试
以上方式是在没有使用 Spring Cloud 的前提下，以前的分布式服务调用的方式
存在什么问题？
-
在consumer中，我们把url地址硬编码到了代码中，不方便后期维护
-
consumer需要记忆provider的地址，如果出现变更，可能得不到通知，地址将失效
-
consumer不清楚provider的状态，服务宕机也不知道
-
provider只有1台服务，不具备高可用性
-
即便provider形成集群，consumer还需自己实现负载均衡
其实上面说的问题，概括一下就是分布式服务必然要面临的问题：
-
服务管理
-
如何自动注册和发现
-
如何实现状态监管
-
如何实现动态路由
-
-
服务如何实现负载均衡
-
服务如何解决容灾问题
-
服务如何实现统一配置
以上的问题，我们都将在SpringCloud中得到答案。
黑马用“滴滴平台”这样的例子
同时，服务提供方与Eureka之间通过“心跳”机制进行监控，当某个服务提供方出现问题，Eureka自然会把它从服务列表中剔除。
这就实现了服务的自动注册、发现、状态监控
-
-
提供者：启动后向Eureka注册自己信息（地址，提供什么服务）
-
消费者：向Eureka订阅服务，Eureka会将对应服务的所有提供者地址列表发送给消费者，并且定期更新
-
心跳(续约)：提供者定期通过http方式向Eureka刷新自己的状态
编写注册中心工程代码
在我们的工程当中，New --> Module... --> Spring Initializr（SDK 1.8)-->填写坐标(如下图)-->选择要引入的依赖
(Spring Cloud Discovery---Eureka Server； 别忘记了选择SpringBoot版本)-->下一步 Finish
pom.xml ,Spring Cloud的版本统一管理引入，它使用了dependencyManagement
Netflix（耐飞）是一家在线影片租赁提供商，对比国内的优酷 。 美国上市公司
覆盖默认配置:
引导类增加注解
