什么是微服务
当我们提到微服务，很多人第一反应就是SpringCloud，但是微服务技术并不能与SpringCloud完全划等号：
在这里插入图片描述微服务是分布式架构的一种，所谓分布式架构就是要把服务做一定的拆分。而拆分的过程中会产生各种各样的问题需要去解决，而SpringCloud仅仅只是解决了服务拆分中的服务治理问题。至于其他的一些分布式中设计的更复杂的问题，SpringCloud中并没有给出解决方案。所以一个完整的微服务技术包含的不仅仅是SpringCloud。
所以接下来我们看一看微服务中所涉及的技术栈。
微服务技术栈
微服务需要做的第一件事就是拆分，因为传统的单体架构所有的业务功能全部写在一起，随着业务越来愈复杂，代码的耦合度也会越来越高，将来我们想升级维护就会非常的困难。
在这里插入图片描述所以一些大型的互联网项目都会去做拆分，而微服务在做拆分的时候会根据业务功能模块，把一个单体的项目拆分成一个个独立的项目，每个项目完成一部分独立的业务功能，将来独立开发和部署。
在这里插入图片描述==我们把这一个个的项目称作服务==。一个大型的互联网项目，常常会包含数百或上千的服务，最终形成一个服务集群。
在这里插入图片描述一个业务往往就需要由多个服务共同来完成。比如一个请求来了，他可能先去调了服务A，而服务A可能又调了服务B，而后又去调了服务C，当业务越来越多、越来越复杂的时候，这些服务之间的调用关系就会越来越复杂：
在这里插入图片描述而这么复杂的调用关系让人去记录和维护是很难实现的。为了解决这一个问题，在微服务中我们有一个组件叫注册中心，它可以去记录微服务中每一个服务的IP、端口以及它能干什么事这些信息。当有一个服务需要去调用另外一个服务时，我们不需要自己去记录对方的IP，只需要去找注册中心就行了，然后去它那里拉取对应的服务信息：
在这里插入图片描述同时随着服务越来越多，每一个服务都有自己的配置文件，将来如果我们要修改配置，一个个的去修改未免也太过麻烦。于是在微服务中还有一个配置中心，它可以管理整个服务集群中成百上千的配置:
在这里插入图片描述当我们需要变更一些配置的时候，我们只需要去找到配置中心就可以了，他会去通知相关的微服务，实现配置的热更新。
当我们的微服务运行起来以后，用户就可以来访问我们了，但是这个时候我们还需要一个网关组件：
在这里插入图片描述因为我们这里有这么多的微服务，那用户怎么知道该访问哪一个呢？而且不一定每一个人都可以被允许来访问我们的服务。也就是说服务网关主要为我们做两件事：
- 对用户身份做校验
- 把用户的请求路由到我们具体的服务
在我们路由的过程中我们也可以做一些负载均衡：
在这里插入图片描述我们在处理业务的时候有时还会用到数据库。在一些大型项目中我们使用的可能是数据库集群。但是在用户多的场景下，我们难免会遇到高并发带来的问题。因此我们会加入缓存 ，缓存就是把数据放入到内存当中，内存的查询效率肯定是比数据库快很多的。而且这种缓存还不能是单体缓存，为了应对高并发，我们要把它我们要把它做成分布式的缓存(也是一个集群)。用户的请求先到缓存，如果缓存没有命中，再去查询数据库。
简单的查询可以做缓存，一些海量数据复杂的搜索、统计和分析，缓存也做不了，这个时候我们还要用到分布式搜索：
在这里插入图片描述最后在我们的微服务中还要一种异步通讯的消息队列组件。因为对于一般的分布式服务或者说微服务里面，他的业务往往会跨越多个服务，整个服务的链路可能会很长(服务A-->服务B-->服务C-->·····-->服务X)。那么我们的调用的时长就等于每个服务的执行时长之和，这样的话性能会有所下降。而异步通讯就可以有效地缩短我们的服务链路，优化我们的调用时长。
在这里插入图片描述我们如此庞大复杂的服务如果出现了什么问题是很难排查的，这可怎么办呢？
我们在微服务运行过程中引入两个组件来解决服务的异常定位：
分布式日志服务：他可以去统计整个集群当中成百上千的服务的运行日志，统一的去做一个存储、统计、分析，将来出现问题就比较好定位系统监控链路追踪：他可以去监视我们整个服务集群中每个服务节点的运行状态、CPU的负载、内存的占用等等情况，一旦出现任何的问题，可以直接定位到某一个方法，帮助我们快速定位问题所在。
在这里插入图片描述我们这么庞大的微服务集群使用人工部署是很困难的，==所以我们的微服务集群一般采用自动化的部署==，这时候我们就会使用到Jenkins工具，它可以帮助我们对微服务项目做一个自动化的编译，然后再基于Docker做一些打包形成镜像。然后我们再基于k8s或者rancher这样的技术，实现自动化的部署。这一套我们称为持续集成，结合我们前面所说的微服务技术，这就是完整的微服务技术栈。
在这里插入图片描述这其中涉及很多知识点：
在这里插入图片描述但我们可以对他们大致进行一个分类，概括成为五个部分：
- 微服务治理(也就是SpringCloud所包含的技术)
- 异步通信技术
- 缓存技术
- 分布式搜索的技术
- 持续集成DevOps技术
在这里插入图片描述单体架构
单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署。
在这里插入图片描述单体架构的优缺点如下：
优点：
- 架构简单
- 部署成本低
缺点：
- 耦合度高（维护困难、升级困难）
分布式架构
分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务。
在这里插入图片描述分布式架构的优缺点：
优点：
- 降低服务耦合
- 有利于服务升级和拓展
缺点：
- 服务调用关系错综复杂
我们可以举一个例子：
有一个Online Shopping的项目，我们做好服务拆分，同时为了保证高可用我们还要做集群：
在这里插入图片描述当我们拆分完之后就会发现一个新的问题，原来是单体项目的时候各个服务都在一起，我在下单的时候如果需要商品信息直接调用就可以。但是现在不一样了，做了拆分之后，这是两个服务，部署在不一样的机器上，直接调肯定是行不通的。这个时候我们就要用到远程调用，从一个服务向另外一个服务发送请求来进行调用，这是一种跨越服务、跨越机器的调用。
在这里插入图片描述分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：
- 服务拆分的粒度如何界定？
- 服务之间如何调用？
- 服务的调用关系如何管理？
人们需要制定一套行之有效的标准来约束分布式架构。
认识微服务
微服务是一种经过良好架构设计的分布式架构方案 。
微服务的架构特征：
- 单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
- 自治：团队独立、技术独立、数据独立，独立部署和交付
- 面向服务：服务提供统一标准的接口，与语言和技术无关
- 隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题
在这里插入图片描述这些特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合。
微服务技术框架
微服务这种方案需要技术框架来落地，全球的互联网公司都在积极尝试自己的微服务落地技术。在国内最知名的就是SpringCloud和阿里巴巴的Dubbo。
接下来我们看一看一些微服务技术的对比：
在这里插入图片描述- Dubbo是被阿里巴巴开源的，因诞生时期较早，当时还没有完整的微服务体系与相关概念，所以它的核心就是远程调用以及注册发现。我们可以发现在Dubbo里面技术体系实际上并不完整，并且我们发现注册中心相关功能是依赖于
zookeeper和Redis实现的，这些并不是专业的注册中心，我们知道Redis是用来做缓存的，zookeeper是用来做集群管理的。而服务的远程调用才是Dubbo的核心。Dubbo专门基于http协议定义了一套标准也就是Dubbo协议。服务监控和保护功能也相对较弱 - SpringCloud将全球各公司的开源的微服务技术进行了整合，形成了一套完整的微服务技术体系。SpringCloud具有完善的注册中心，包含
Eureka、Consul，在服务远程调用方面，为了减少学习成本，使用的直接就是基于http协议的标准。只不过SpringCloud帮我们封装了一种客户端Feign，来帮助我们发送http的请求。同时它还具有专业的配置中心叫做SpringCloudConfig，如果再结合SpringCloudBus就能够实现配置变化时的自动通知、热更新功能。在服务网关方面，SpringCloud提供了Gateway和Zuul两种技术，其中Gateway网关更常用，里面基于了最新的响应式编程，吞吐能力更强。服务保护方面使用了Hystrix技术，实现了服务的隔离，以及熔断等等相关技术 - SpringCloudAlibaba可以说是SpringCloud的一部分，他是实现了SpringCloud的标准接口的，所以我们会发现SpringCloudAlibaba里面的一些组件用起来跟SpringCloud没什么差别。
在我们的企业中可能会使用以下四种途径去实现微服务架构：
在这里插入图片描述SpringCloud
SpringCloud是目前国内使用最广泛的微服务框架。
官网地址：https://spring.io/projects/spring-cloud。
SpringCloud集成了各种微服务功能组件，并基于SpringBoot实现了这些组件的自动装配，从而提供了良好的开箱即用体验。
其中常见的组件包括：
在这里插入图片描述另外，SpringCloud底层是依赖于SpringBoot的，并且有版本的兼容关系，如下：
在这里插入图片描述
