微服务架构--什么是微服务

微服务

1、什么是微服务

​ 相对于传统单体服务项目而言，微服务顾名思义体现在“小”上，它仅仅是整个应用程序的一个个较小且独立的功能单元，我们可以把他们成为一个个“服务”，是用户能够感知的最小功能集。这些服务运行在自己独立的进程中，通过轻量级的通信机制互相通信（例如HTTP REST、RPC）并共用一个管理工具进行管理。

​ 另外，微服务之间是完全独立的， 可通过全自动部署机制独立部署 （独立部署）；每一个服务可以使用不同的开发语言围绕业务需求进行构建（独立开发）；每一个服务可以使用不同的存储技术（独立存储）。

2、为什么要使用微服务架构

​ 传统的互联网架构一般都是单体架构，所有的业务功能都运行在一个进程当中，各个业务之间相互依赖，虽然我们可以使用包、类等语言固有的特性完成一定程度的解耦，但是随着应用规模的不断扩大，这种方式并不能完全满足我们的需求，主要暴露出来的问题有：

​ 系统的维护和扩展成本高、不灵活、不便捷，部署项目困难等。

​ （1）系统可维护性变差

​ 比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。 当项目的人员发生流动，会给后续接收的人带来非常大的困扰。

​ （2）系统扩展成本变大

​ 当程序规模越来越大，每当我们需要增加或者修改一个功能，我们需要面对不仅仅是某几行代码，而是整个应用，因为系统各模块之间的联系是非常紧密的，所以一旦操作不当，就可能导致整个项目崩溃，为了不产生这种情况，扩展的成本也就会变大。

​ （3）部署速度降低

​ 单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。

​ （4）无法按需伸缩

​ 比如有时我们仅仅需要修改或者升级项目中的某一个模块，那么我们就不得不将整个应用重新打包部署，这样做是事倍功半的。

​ 为了解决上述的问题，微服务架构的思想应运而生。

​ 相比于单体服务，微服务具有以下优点：

​ （1） 易于开发和维护

​ 将应用中的每一个功能模块都独立出来， 代码量明显减少， 遇到问题也相对来说比较好解决。 降低了维护可扩展成本。

​ （2）部署灵活并且速度较快

​ 从整体来看，项目需要部署的次数变多了，因为每一个服务模块都需要单独部署，但是对于后续维护来讲，当我们需要修改或者升级某一个功能时，重新部署的时间花费是变少了的。

​ （3）技术栈不受限

​ 各个服务模块的开发变得更加灵活，每个模块可以使用不同的编程语言，不同的数据存储技术等，我们可以根据各个服务的特性灵活的选择使用的技术。

​ （4）按需伸缩

​ 当我们需要更新某一个功能模块时，不需要考虑其他模块的影响。

​ （4）开发效率更高

​ 微小的服务模块只需要较少的开发人员，团队之间的合作更加紧密，沟通成本更低，开发效率更高。

​ 相反的，它也具有一下的缺点：

​ （1）运维要求高

​ 对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。

​ （2）接口调整成本高

​ 比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高。

​ （3）分布式的复杂性

​ 对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。

​ （4）重复劳动

​ 对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

3、微服务的本质

​ 让应用在结构上松耦合，在功能上表现为一个整体。

​ 这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。

​ 实现微服务的关键在于：合理有效地拆分应用！！！

​ 微服务的拆分与设计原则：

​ 从单体式结构转向微服务架构中会持续碰到服务边界划分的问题：比如，我们有user 服务来提供用户的基础信息，那么用户的头像和图片等是应该单独划分为一个新的service更好还是应该合并到user服务里呢？如果服务的粒度划分的过粗，那就回到了单体式的老路；如果过细，那服务间调用的开销就变得不可忽视了，管理难度也会指数级增加。目前为止还没有一个可以称之为服务边界划分的标准，只能根据不同的业务系统加以调节 。

​ 但是拆分的一大原则是：

​ 当一块业务不依赖或极少依赖其它服务，有独立的业务语义，为超过2个的其他服务或客户端提供数据，那么它就应该被拆分成一个独立的服务模块。

​ 微服务的几个设计原则：

​ 单一职责原则：

​ 每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。

​ 服务自治原则：

​ 每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。

​ 轻量级通信原则：

​ 通信的技术必须非常的轻量，并且该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。

​ 接口明确原则：

​ 由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。

4、微服务架构的实现方案

​ 对于微服务架构来讲，想要在在功能上表现为一个整体，必须要解决下面的四个问题：

​ 1、客户端如何访问这些服务？（服务访问）

​ 2、各个服务之间如何互相通信？（服务调用）

​ 3、众多服务怎么查找？（服务发现）

​ 4、个别服务挂了怎么办？（服务容灾）

​ 无论哪一种微服务的解决方案，都是围绕着这四个问题进行的，下面介绍目前常见的几种实现方式：

​ 1、SpringCloud NetFlix

​ 2、Dubbo+Zookeeper

​ 3、SpringCloud Alibaba

​ 4、…

​ 以上的解决方案是一种技术生态，是若干技术的集合体，主要的技术栈如下：

不同解决方案之间的比较：

​ 为什么要选择SpringCloud？

​ 因为它是专门为了解决微服务架构而生的，是一个完整的微服务框架，不需要外接其他的技术栈即可完成微服务架构；框架的整体成熟度高，有活跃的社区，学习路线平缓。

二、SpringCloud简介

1、什么是SpringCloud

SpringCloud是基于SpringBoot提供的一套微服务一站式解决方案，是各个微服务架构技术的集合体，俗称微服务全家桶。包括服务注册与发现，配置中心，全链路监控，服务网关，负载均衡，熔断器等组件。这些技术不是Spring官方重复造轮子的结果，而是整合了各家公司开发比较成熟、经得起考验的框架，通过SpringBoot风格进行了二次封装，屏蔽掉了复杂的配置和实现原理，最终给开发者留下了一套简单易懂，易于部署和维护的分布式系统开发工具包。

2、SpringBoot和SpringCloud

​ 区别：SpringBoot专注于快速、方便的开发单个服务；SpringCloud关注全局的服务治理，它为SpringBoot开发的各个服务提供：配置管理、服务发现、断路器、路由、微代理、事件总线、分布式会话等集成服务。

​ 联系：SpringCloud依赖了SpringBoot，SpringCloud利用了SpringBoot自动装配的特性，快速便捷的配置各个分布式组件，使得自身成为了一套简单易懂，易于部署和维护的分布式系统开发工具包。

3、SpringCloud和Dubbo

​ Dubbo本质上只是一个RPC通信框架，而服务通信仅仅是分布式系统要解决的众多问题之一，它不能解决所有的问题。而SpringCloud是分布式系统的一站式解决方案，二者从本质上就有区别。SpringCloud兼容Dubbo，但是默认是采用的REST API完成服务间的通信问题，这样做虽然牺牲了服务调用的性能，但是REST相比RPC更加灵活，服务提供方和调用方只依靠一纸契约，没有代码间的强依赖，这一点在快速迭代的微服务系统中是很重要的。

4、SpringCloud的版本选择

​ 上面说到，SpringCloud是依赖与SpringBoot的，所以在选择SpringCloud的版本时，必须要考虑到它与SpringBoot版本的匹配问题。针对这个问题，SpringCloud在，每一个版本的参考文档中都指明了SpringBoot的官方推荐版本。

​ 除了可以查看SpringCloud的官方文档外，我们还可以访问下面的网址：

	https://start.spring.io/actuator/info

​ 得到一个关于版本匹配的json字符串，然后可以使用在线的json格式化工具查看其中的内容，如下：

{
	"git": {
		"branch": "63e711a835eb5c3f35e8710cefa01a1fa7126822",
		"commit": {
			"id": "63e711a",
			"time": "2020-07-23T11:37:07Z"
		}
	},
	"build": {
		"version": "0.0.1-SNAPSHOT",
		"artifact": "start-site",
		"versions": {
			"spring-boot": "2.3.1.RELEASE",
			"initializr": "0.10.0-SNAPSHOT"
		},
		"name": "start.spring.io website",
		"time": "2020-07-23T11:37:58.888Z",
		"group": "io.spring.start"
	},
	"bom-ranges": {
		"azure": {
			"2.0.10": "Spring Boot >=2.0.0.RELEASE and <2.1.0.RELEASE",
			"2.1.10": "Spring Boot >=2.1.0.RELEASE and <2.2.0.M1",
			"2.2.4": "Spring Boot >=2.2.0.M1 and <2.3.0.M1",
			"2.3.1": "Spring Boot >=2.3.0.M1"
		},
		"codecentric-spring-boot-admin": {
			"2.0.6": "Spring Boot >=2.0.0.M1 and <2.1.0.M1",
			"2.1.6": "Spring Boot >=2.1.0.M1 and <2.2.0.M1",
			"2.2.4": "Spring Boot >=2.2.0.M1"
		},
		"solace-spring-boot": {
			"1.0.0": "Spring Boot >=2.2.0.RELEASE and <2.3.0.M1",
			"1.1.0": "Spring Boot >=2.3.0.M1"
		},
		"solace-spring-cloud": {
			"1.0.0": "Spring Boot >=2.2.0.RELEASE and <2.3.0.M1",
			"1.1.0": "Spring Boot >=2.3.0.M1"
		},
		"spring-cloud": {
			"Finchley.M2": "Spring Boot >=2.0.0.M3 and <2.0.0.M5",
			"Finchley.M3": "Spring Boot >=2.0.0.M5 and <=2.0.0.M5",
			"Finchley.M4": "Spring Boot >=2.0.0.M6 and <=2.0.0.M6",
			"Finchley.M5": "Spring Boot >=2.0.0.M7 and <=2.0.0.M7",
			"Finchley.M6": "Spring Boot >=2.0.0.RC1 and <=2.0.0.RC1",
			"Finchley.M7": "Spring Boot >=2.0.0.RC2 and <=2.0.0.RC2",
			"Finchley.M9": "Spring Boot >=2.0.0.RELEASE and <=2.0.0.RELEASE",
			"Finchley.RC1": "Spring Boot >=2.0.1.RELEASE and <2.0.2.RELEASE",
			"Finchley.RC2": "Spring Boot >=2.0.2.RELEASE and <2.0.3.RELEASE",
			"Finchley.SR4": "Spring Boot >=2.0.3.RELEASE and <2.0.999.BUILD-SNAPSHOT",
			"Finchley.BUILD-SNAPSHOT": "Spring Boot >=2.0.999.BUILD-SNAPSHOT and <2.1.0.M3",
			"Greenwich.M1": "Spring Boot >=2.1.0.M3 and <2.1.0.RELEASE",
			"Greenwich.SR6": "Spring Boot >=2.1.0.RELEASE and <2.1.17.BUILD-SNAPSHOT",
			"Greenwich.BUILD-SNAPSHOT": "Spring Boot >=2.1.17.BUILD-SNAPSHOT and <2.2.0.M4",
			"Hoxton.SR6": "Spring Boot >=2.2.0.M4 and <2.3.3.BUILD-SNAPSHOT",
			"Hoxton.BUILD-SNAPSHOT": "Spring Boot >=2.3.3.BUILD-SNAPSHOT and <2.4.0.M1",
			"2020.0.0-SNAPSHOT": "Spring Boot >=2.4.0.M1"
		},
		"spring-cloud-alibaba": {
			"2.2.1.RELEASE": "Spring Boot >=2.2.0.RELEASE and <2.3.0.M1"
		},
		"spring-cloud-services": {
			"2.0.3.RELEASE": "Spring Boot >=2.0.0.RELEASE and <2.1.0.RELEASE",
			"2.1.7.RELEASE": "Spring Boot >=2.1.0.RELEASE and <2.2.0.RELEASE",
			"2.2.3.RELEASE": "Spring Boot >=2.2.0.RELEASE and <2.3.0.M1"
		},
		"spring-statemachine": {
			"2.0.0.M4": "Spring Boot >=2.0.0.RC1 and <=2.0.0.RC1",
			"2.0.0.M5": "Spring Boot >=2.0.0.RC2 and <=2.0.0.RC2",
			"2.0.1.RELEASE": "Spring Boot >=2.0.0.RELEASE"
		},
		"vaadin": {
			"10.0.17": "Spring Boot >=2.0.0.M1 and <2.1.0.M1",
			"14.3.1": "Spring Boot >=2.1.0.M1 and <2.4.0-M1"
		},
		"wavefront": {
			"2.0.0-SNAPSHOT": "Spring Boot >=2.1.0.RELEASE"
		}
	},
	"dependency-ranges": {
		"okta": {
			"1.2.1": "Spring Boot >=2.1.2.RELEASE and <2.2.0.M1",
			"1.4.0": "Spring Boot >=2.2.0.M1 and <2.4.0-M1"
		},
		"mybatis": {
			"2.0.1": "Spring Boot >=2.0.0.RELEASE and <2.1.0.RELEASE",
			"2.1.3": "Spring Boot >=2.1.0.RELEASE and <2.4.0-M1"
		},
		"geode": {
			"1.2.8.RELEASE": "Spring Boot >=2.2.0.M5 and <2.3.0.M1",
			"1.3.0.RELEASE": "Spring Boot >=2.3.0.M1 and <2.4.0-M1"
		},
		"camel": {
			"2.22.4": "Spring Boot >=2.0.0.M1 and <2.1.0.M1",
			"2.25.1": "Spring Boot >=2.1.0.M1 and <2.2.0.M1",
			"3.3.0": "Spring Boot >=2.2.0.M1 and <2.3.0.M1",
			"3.4.1": "Spring Boot >=2.3.0.M1 and <2.4.0-M1"
		},
		"open-service-broker": {
			"2.1.3.RELEASE": "Spring Boot >=2.0.0.RELEASE and <2.1.0.M1",
			"3.0.4.RELEASE": "Spring Boot >=2.1.0.M1 and <2.2.0.M1",
			"3.1.1.RELEASE": "Spring Boot >=2.2.0.M1 and <2.4.0-M1"
		}
	}
}

​ 上面的字符串中不仅指明了SpringCloud的版本问题，还指明了其他的工具与SpringBoot的匹配关系，可以参考上面的内容进行选型