# 一、什么是微服务？
首先，[马丁福勒](https://martinfowler.com/articles/microservices.html)说了微服务概念没有统一的定义。所以下面的说法只是其中之一，**微服务**是一种架构风格，将一个单一的具有多个不同功能模块的应用程序划分成一组小的小的应用程序，每个小的应用程序只负责一个功能模块，并且运行在单独的进程中，它们之间使用轻量级机制通信。
## 总结
- 一个服务只负责一个功能
- 每个服务单独部署
- 每个服务以不同的进程来运行
- 用有数据库==>可以单独自己拥有，也可以共同拥有
# 二、微服务架构
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务,服务之间互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务与服务间采用轻量级的通信机制互相写作(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应当尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
# 三、微服务优缺点
## 微服务架构的优势
使用微服务架构能够为我们带来如下好处：
1. **服务的独立部署**
每个服务都是一个独立的项目，可以独立部署，不依赖于其他服务，耦合性低。
2. **服务的快速启动**
拆分之后服务启动的速度必然要比拆分之前快很多，因为依赖的库少了，代码量也少了。
3. **更加适合敏捷开发**
敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行。服务拆分可以快速发布新版本，修改哪个服务只需要发布对应的服务即可，不用整体重新发布。
4. **职责专一，由专门的团队负责专门的服务**
业务发展迅速时，研发人员也会越来越多，每个团队可以负责对应的业务线，服务的拆分有利于团队之间的分工。
5. **服务可以动态按需扩容**
当某个服务的访问量较大时，我们只需要将这个服务扩容即可。
6. **代码的复用**
每个服务都提供 REST API，所有的基础服务都必须抽出来，很多的底层实现都可以以接口方式提供。
## 微服务架构的劣势
微服务其实是一把双刃剑，既然有利必然也会有弊。下面我们来谈谈微服务有哪些弊端，以及能采取什么办法避免。
1. **分布式部署，调用的复杂性高**
单体应用的时候，所有模块之前的调用都是在本地进行的，在微服务中，每个模块都是独立部署的，通过 HTTP 来进行通信，这当中会产生很多问题，比如网络问题、容错问题、调用关系等。
2. **独立的数据库，分布式事务的挑战**
每个微服务都有自己的数据库，这就是所谓的去中心化的数据管理。这种模式的优点在于不同的服务，可以选择适合自身业务的数据，比如订单服务可以用 MySQL、评论服务可以用 Mongodb、商品搜索服务可以用 Elasticsearch。
缺点就是事务的问题了，目前最理想的解决方案就是柔性事务中的最终一致性，后面的章节会给大家做具体介绍。
3. **测试的难度提升**
服务和服务之间通过接口来交互，当接口有改变的时候，对所有的调用方都是有影响的，这时自动化测试就显得非常重要了，如果要靠人工一个个接口去测试，那工作量就太大了。这里要强调一点，就是 API 文档的管理尤为重要。
4. **运维难度的提升**
在采用传统的单体应用时，我们可能只需要关注一个 Tomcat 的集群、一个 MySQL 的集群就可以了，但这在微服务架构下是行不通的。当业务增加时，服务也将越来越多，服务的部署、监控将变得非常复杂，这个时候对于运维的要求就高了。
# 四、微服务技术栈
加粗部分是SpringCloud提供的
|微服务条目(相关概念)|落地技术|
|-------|-------|
|服务开发|**SpringBoot、Spring**....|
|服务配置与管理|**Archaius**、Diamond...|
|服务注册与发现|**Eureka**、Consul、Zookeeper...|
|服务调用|**REST**、RPC、gRPC...|
|服务熔断器|**Hystrix**、Envory...|
|负载均衡|**Ribbon**、Nginx...|
|服务接口调用(简化 HTTP 接口的调用)|**Feign**|
|消息队列|Kafka、RabbitMQ、ActiveMQ等|
|服务配置中心管理|**SpringCloudConfig**、Chef等|
|服务路由(API网关)|**Zuul**等|
|服务监控|Zabbix、Nagios、Metrics、Spectator等|
|全链路追踪|Zipkin、Brave、Dapper等|
|服务部署|Docker、OpenStack、Kubernetes等|
|数据流操作开发包|**SpringCloud Stream**(封装与**Redis、Rabbit、Kafka**等发送接受消息)|
|时间消息总线|**SpringCloud Bus**|
# 五、SpringCloud是什么？
## 概述
Spring Cloud 是一系列框架的有序集合。它利用 Spring Boot 的开发便利性，巧妙地简化了分布式系统基础设施的开发，如服务注册、服务发现、配置中心、消息总线、负载均衡、断路器、数据监控等，这些都可以用 Spring Boot 的开发风格做到一键启动和部署。
通俗地讲，Spring Cloud 就是用于构建微服务开发和治理的框架集合（并不是具体的一个框架），主要贡献来自 Netflix OSS。
## SpringBoot和SpringCloud之间的区别
- SpringBoot可以开发具体的单个微服务,可以独立运行
- SpringCloud是将SpringBoot开发的单个微服务整合起来协调治理的,SpringCloud是需要依赖SpringCloud的
# 六、SpringCloud 与 Dubbo
## 目前成熟的互联网框架
## Spring Cloud 与 Dubbo区别
表 1 Spring Cloud与Dubbo功能对比
|功能名称 |Dubbo |Spring Cloud
|-------|-------|-------|
|服务注册中心 |ZooKeeper |Spring Cloud Netflix Eureka
|服务调用方式 |RPC |REST API
|服务网关 |无 |Spring Cloud Netflix Zuul
|断路器 不完善 |Spring |Cloud Netflix Hystrix
|分布式配置 |无 |Spring Cloud Config
|服务跟踪 |无 |Spring Cloud Sleuth
|消息总线 |无 |Spring Cloud Bus
|数据流 |无 |Spring Cloud Stream
|批量任务 |无 |Spring Cloud Task
**最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式。**
严格来说，这两种方式各有优劣。虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。
**品牌机与组装机的区别**
很明显，Spring Cloud的功能比DUBBO更加强大，涵盖面更广，而且作为Spring的拳头项目，它也能够与Spring Framework、Spring Boot、Spring Data、Spring Batch等其他Spring项目完美融合，这些对于微服务而言是至关重要的。使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题；而Spring Cloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。
**社区支持与更新力度**
最为重要的是，DUBBO停止了5年左右的更新，虽然2017.7重启了。对于技术发展的新需求，需要由开发者自行拓展升级（比如当当网弄出了DubboX），这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的，中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案，并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。
## 总结
# 七、构建微服务案列
## 概要
本案列使用MyBatis-Plus+SpringBoot+MySql搭建,使用Maven来构建项目，维护依赖，主要分为一个父模块，三个子模块。
## 第一步，创建父模块
使用idea 创建一个空的Maven项目,可以在此模块中加入一些通用的包，项目ID就是**micro-service-cloud**，注意**package**属性需要时**pom**，**modules**就是子模块,会自动生成
**pom.xml**
```xml
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
```
## 第二步、创建提供对象服务模块
就是里面只有简单对象，其实可以提取到父模块中去的，这里尚硅谷的列子可能是为了体现一个服务只负责一个功能，而案列的功能又太少了，好了闲话不多说了，服务名叫做 **micro-service-cloud-api**，需要引入父模块，然后 **package** 是生产构建成 **jar** 包，同时可以加入一些只有本模块使用的依赖。
**pom.xml**
```xml
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
```
## 第三步、创建部门提供者微服务模块
就是说一个提供接口服务调用的单个服务模块，服务名叫做 **micro-service-cloud-api**，需要引入父模块，然后 **package** 是生产构建成 **jar** 包，同时可以加入一些本模块使用的依赖。
**pom.xml**
```xml
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> ${basedir}/src/main/resources/generator/generatorConfig.xml
```
## 第四步、创建部门消费者微服务模块
其实就是去使用RestTemplate调用服务提供者里面的接口，就只是为了顺带提一下SpringCloud的Restful接口调用通信的，服务名称叫做**micro-service-cloud-provider-dept-8001**，然后**package** 是生产构建jar包的，同时可以加上一些本模块单独使用的依赖。
**pom.xml**
```xml
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> ${basedir}/src/main/resources/generator/generatorConfig.xml
```