什么是微服务

当我们提到微服务，很多人第一反应就是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的，并且有版本的兼容关系，如下：