《SpringCloud》笔记一：认识微服务技术

所有课程的学习及相关资料都是源自b站黑马程序员
感谢黑马程序员给予我们新手的无私帮助，感谢！！！
黑马程序员-----yyds

一、什么是微服务

我们先看看百度百科对微服务的解释

一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，将应用程序构造为一组松散耦合的服务。在微服务体系结构中，服务是细粒度的，协议是轻量级的。
微服务（或微服务架构）是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务通常

那么了解过一点微服务技术的人可能会说：微服务嘛，不就是Dubbo，或者是SpringCloud吗。

如果你真这样子以为，那你就真是太天真了。

微服务，从技术上来讲就是对以前独占式的应用进行拆分、拆分成多个。
它所包含的内容可不仅仅是springCloud，而是一系列技术栈，内容及其复杂。

那微服务又包含哪些技术、或者说它的生态圈是怎么样的呢。
下面都会一一讲解。

二、微服务生态圈

首先我们得知道微服务的第一重任就是将传统的单机应用架构进行拆分。拆分成多个小的微服务应用，就像这样

那为什么需要微服务架构呢，以前的单体应用架构不是很好，还非常省成本。

那其实呢单体架构好不好，顺不顺利主要还是看这单体所承受的业务量，一般中小型项目的话单体架构是可以应付的，但是如果到了偏访问量高的大项目的时候，单体项目的缺点就开始慢慢体现出来了（如淘宝等应用）。

那么单体架构有哪些缺点呢

• 当项目越来越大，业务越来越多的时候，代码耦合度也会越来越高，这很不利于后期项目的维护（代码引用关系复杂）
• 很难承受高量的并发访问
• 开发周期较长、很难维护一套新的技术栈
• …

那么现在有了微服务，我们就可以解决这里面绝大部分的问题了
如：

①、可以将单体项目拆分成不同的独立项目，项目之间基本上没有直接的耦合关系，而且可以做到每个项目各自完成一部分不重复的功能，到时候可以独立部署，这大大降低了项目业务的耦合性，增强了聚合能力。
由此而知，那么每个独立的项目就是一个服务。

②随着服务的不断增加，那么如此多的服务最终会形成一个服务集群。
而一个业务就可能要多个服务来相互协同来完成。

③、业务间接带动了服务直接产生一定的关系，如业务A可能需要的服务流程是服务1先调用服务2，然后服务2再调用服务3，最终再返回结果给业务层。
那么随着服务集群的不断扩大，集群内的服务调用将变得十分复杂，基本上通过人力已经很难去维护和记录了。

④、那我们怎么解决服务之间这种复杂的调用关系呢？诶，这个时候微服务生态圈就提出了一个组件，叫注册中心

注册中心的功能是什么呢？

• 帮忙记录服务集群里面所有的服务实例
• 服务消费者可以通过注册中心拉取相关的服务信息，然后完成指定的服务调度任务
• 注册中心可以监控服务实例的健康状态（服务实例会在一定周期内向注册中心发送心跳包，以确保自身状态是否正常）

⑤、可单单仅有注册中心是不够的，如果我们要对每个服务实例做不同要求的配置修改，每个都去改，还好考虑兼容性等一系列问题，这将是一个巨大的工作量，所以，微服务生态圈再次推出一个组件配置中心
可以实现配置的热更新。

⑥、是不是以为就完了，呵呵还是太天真了，一个公寓集群怎么能少的了保安呢，所以我们还需要一个组件——服务网关
因为服务是一个集群，内部服务实例比较庞大，我们用户并不知道应该访问哪个服务实例，而且也不是什么请求都可以对服务进行访问，我们可能需要一些拦截恶意功能、身份校验，将请求路由到具体的服务实例、负载均衡等操作，所以服务网关的重要性就不言而喻了。

⑦、现在用户访问的问题暂时解决了，那我们该考虑数据库了，如此大的访问群体、访问量，数据库可没有服务实例那么大的庞大数量、很难承担如此之大的并发量，而且访问速度也是一大障碍，那该怎么解决这些问题呢？
这个时候，我们就需要引入一套服务集群——分布式缓存
那缓存是什么，缓存就是将一部分数据库的数据放到内存当中，我们都知道访问内存的速度是远远大于远程访问数据库的速度，我们可以把用户经常访问的数据缓存到内存当中，此时当用户的请求过来时，我们先进入缓存看看是否命中，如果未命中，再访问数据库。

⑧、你以为这就完了吗，咳咳，不，还没有结束，我还可以继续说：
用户的访问可以说是千变万化、那么对数据库的搜索要求就必然很高，简单的搜索功能已经无法满足庞大的并发访问需求了，那么我们需要再次引入一个服务集群——分布式搜索
而有了分布式搜索集群，我们可以都搜索内容进行切片、分词等操作，多机器搜索结果聚合的操作，那么这个时候数据库其实只需要做一些读写操作、安全事务等操作就可以了。

⑨、我们再考虑一个问题，如果一个请求所需的访问链路很长（服务1调服务2、服务2调服务3、服务3调服务4 …）,那么很明显这样子性能就会下降，而且如果服务2阻塞了，还要等待其完成，可以说是服务效率大打折扣。
那么为了应对这种问题，我们引入了一个集群——异步消息队列集群
那么什么是异步消息呢，简单说就是如果我此时调用服务1，我就给服务2发送一条消息，说我要调用服务2，这个时候服务2开始干活，服务1和服务2异步进行，减少中间的阻塞传递的时间，一定程度上提高了性能。

写到这里相信你也看到了微服务团体是如此的庞大，怎么复杂的服务要是出了问题我们却很不容易定位，那怎么办？
很简单，我们这个时候就需要引入两个组件来协同我们完成故障排查。
分布式日志系统 和 系统监控链路追踪

如此庞大的服务集群，那部署又成了一个大难题了，总不可能一个一个去人工部署吧，那么我们就需要再次引入一个框架——JenKins

我们可以对这些打包完成的项目制作成镜像，方便多台不同集群使用，那Docker这个成熟的框架就可以帮我们解决这些问题

那么好了，包也打好了，镜像也做好了，我们还需要一个工具帮我们进行自动化处理，那K8S 或者 RANCHER就可以

到此为止这是一套完整的微服务技术栈，那你们还会认为微服务就是Dubbo或者SpringCloud吗 O(∩_∩)O哈哈~

三、微服务带来的问题

在讲问题之前我们先来看看微服务的完整技术栈

如此复杂的微服务技术栈，那带来的问题也是非常多的。

• 如何做到一个服务调用另一个服务？
• 随着部署量的增大，运维的难度也变得越来越大，怎么办？
• 依赖的服务不稳定怎么办？分布式的事务要怎么处理？
• 跨语言、跨系统所带的稳定性、兼容性、性能等问题该如何处理？
• …

那么程序员就会根据问题发布相关的解决方案

四、SpringCloud

为什么选择springCloud就不用说了吧，Dubbo可以说比较旧了，现在的SpringCloud可以说是一统后端江湖，技术发展也是相当成熟，组件也十分丰富。

后期的SpringCloudAlibaba也算是SpringCloud里面的一部分，SpringCloudAlibaba加强了原有SpringCloud里面某些组件的不足的功能、然后扩展一些自己的功能，让SpringCloud的生态圈变得更加成熟稳定。

点我进入SpringCloud的官网

那么下个笔记就正式开始记录我学习SpringCloud的点点滴滴了。
共勉！