1. 什么是微服务

所谓微服务,其实就是分布式架构中的一种思想

在分布式架构中,需要对项目进行拆分,将每一个模块都拆分为一个单独的项目,我们称之为服务

1.1 单体架构与分布式架构

单体架构：将业务的所有功能集中在一个项目中开发，打成一个包部署

单体架构的优缺点如下：

优点：

架构简单
部署成本低

缺点：

耦合度高（维护困难、升级困难）

因为传统的单体架构业务功能都写在了一起, 随着业务复杂, 代码耦合度非常高, 不利于升级维护,同时也不利于多人协作,因此才产生了分布式架构:

分布式架构：根据业务功能对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务

分布式架构的优缺点：

优点：

降低服务耦合
有利于服务升级和拓展

缺点：

服务调用关系错综复杂

分布式架构虽然降低了服务耦合，但是服务拆分时也有很多问题需要思考：

服务拆分的粒度如何界定？
服务之间如何调用？
服务的调用关系如何管理？

1.2 微服务

微服务的架构特征：

单一职责：微服务拆分粒度更小，每一个服务都对应唯一的业务能力，做到单一职责
自治：团队独立、技术独立、数据独立，独立部署和交付
面向服务：服务提供统一标准的接口，与语言和技术无关
隔离性强：服务调用做好隔离、容错、降级，避免出现级联问题

微服务架构示例图:

在这里插入图片描述

微服务的上述特性其实是在给分布式架构制定一个标准，进一步降低服务之间的耦合度，提供服务的独立性和灵活性。做到高内聚，低耦合

因此，可以认为微服务是一种经过良好架构设计的分布式架构方案

而提到微服务,就不得不提到SpringCloud,很多人都会将微服务误以为就是SpringCloud,但其实微服务远不止SpringCloud,在我们将一个项目拆分为一个一个的微服务时,就必然会产生一些问题,而SpringCloud仅仅只是解决了服务拆分时的服务治理问题,至于其他的拆分时产生的更复杂的问题并没有给出解决方案,因此我们说微服务远不止SpringCloud, 因此SpringCloud只是提供了一个整合微服务技术栈的容器而已

1.3 微服务所需技术栈

先上图:

在这里插入图片描述

在微服务拆分的时候, 第一步就是拆分, 每个项目(服务)只完成一部分的业务功能,独立开发与部署, 这些服务称之为服务集群

接着一个业务往往不仅需要一个服务,他可能继续服务A完成,也需要服务B来完成,当业务越来越复杂时这些服务之间的调用关系也会越来越复杂, 因此这些服务之间需要通信

因此出现了一个组件:注册中心(完成服务发现与注册, Eureka, Nacos等),他会记录微服务中每个服务的IP,端口以及它能干什么事等信息, 因此当一个服务需要调用另一个服务时只需要去注册中心拉去或注册服务信息

同时随着服务越来越多, 如果每个服务都有自己的配置文件, 那将来维护与修改都将很麻烦,因此又出现了配置中心(SpringCloudConfig,Nacos等技术), 这个配置中心会统一管理整个服务集群里成千上百的这些配置,如果需要修改配置时,只需要找到配置中心修改即可, 配置中心会去通知相关微服务来实现配置的热更新, 最后这些服务会从配置中心拉取配置信息

接着项目组建起来了, 用户可以来访问了, 但是这么多的微服务,用户怎么知道该访问哪个呢, 而且也不是随便什么人都能来访问服务吧, 因此就需要服务网关(Gateway,Zuul等). 服务网关一方面需要对用户身份进行校验, 另一方面可以将用户的请求路由发到到我们的服务中, 还可以做一些负载均衡

好啦,用户也能访问了,此时收到用户请求服务也该访问数据库数据了, 但是我们的数据库集群不管多庞大都不可能比用户多吧, 此时数据库就会扛不住这种高并发访问, 因此我们还需要加入分布式的缓存(redis)(都这种时候了, 肯定不可能是单体的啦), 缓存就是将数据库中的数据放到内存中, 此时效率就比数据库访问高得多了

接下来就是搜索功能了, 像一些简单查询还可以走缓存,然后没有数据再走数据库, 但是一些海量数据的复杂的搜索, 统计和分析缓存也做不了, 这个时候就又需要用到==分布式搜索功能(elasticsearch)==了

接着在微服务里还需要一些做异步通信的消息队列组件(rabbitMQ, rocketMQ和kafka等), 异步通信的消息队列作用就是:在微服务中服务调用时, 不会说服务A调用了服务B就暂停等了,而是会异步的执行或者服务A直接结束了, 这样子可以让执行速度,效率都提高,而不是等于服务调用链中服务的运行总和, 也可以提高并发,在像秒杀之类的高并发场景就可以使用了

我们构建了一个如此庞大的项目微服务,那如果将来出现了问题岂不是很难排查. 因此我们还需要引入俩个组件来解决服务的异常定位:第一个是分布式日志服务, 他可以去统计整个集群当中成千上百的服务的运行日志, 统一的去做一个存储, 统计分析等, 这样子将来出现问题就好定位了;还有一个是系统监控和链路追踪(Sleuth, zipkin, skywalking等), 他可以去实时监控整个集群中每个服务节点的运行状态,CPU的负载, 内存的占用等,一旦出现问题可以直接定位到具体的方法,你就可以很快就定位到异常所在

如此庞大复杂的微服务集群部署显然是不可能人工部署的, 因此还需要自动化的部署, 例如使用Jenkins这样的工具进行自动化的编译与部署, 接着再使用Docker这样的容器来进行打包形成镜像, 接着再基于Kubernetes或者RANCHER这样的工具来完成自动化部署, 这一套下来称之为持续集成DevOps

上面就是完整的微服务技术栈了, 以上概况起来就是下图:

在这里插入图片描述

常用技术栈:

微服务技术条目	落地技术
服务开发	SpringBoot、Spring、SpringMVC等
服务配置与管理	Netfix公司的Archaius、阿里的Diamond等
服务注册与发现	Eureka、Nacos、Zookeeper、etcd、Consul等
服务调用	Rest、PRC、gRPC
服务熔断器	Hystrix、Envoy等
负载均衡	Ribbon、Nginx等
服务接口调用(客户端调用服务的简化工具)	Fegin等
消息队列	RabbitMQ、rocketMQ、Kafka等
服务配置中心管理	SpringCloudConfig、Nacos、Chef等
服务路由(API网关)	Gateway、Zuul等
服务监控	Zabbix、Nagios、Metrics、Specatator等
全链路追踪	Sleuth、Zipkin、skywalking、Brave、Dapper等
数据流操作开发包	SpringCloud Stream(封装与Redis，Rabbit，Kafka等发送接收消息)
时间消息总栈	SpringCloud Bus
服务部署	Docker、OpenStack、Jenkins、RANCHER、Kubernetes等