文章目录

什么是微服务
微服务技术栈
单体架构
分布式架构
认识微服务
微服务技术框架
SpringCloud

什么是微服务

当我们提到微服务，很多人第一反应就是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没什么差别。