初识微服务技术栈

认识微服务

• 随着互联网行业的发展，对服务的要求也越来越高，服务架构也从单体架构逐渐演变为现在流行的微服务架构，这些架构之间有怎样的差别呢？ 

导学：

• 了解微服务的优缺点；
• 了解微服务架构的演变过程；
• 认识微服务的一种实现：Spring Cloud 

 CMS系统指的就是内容管理系统。

微服务架构的演变 

• 导学：微服务架构它是如何演变过来的？ 

传统的单体架构 => 分布式架构 => SOA面向服务架构 => 微服务架构模式 => 服务网格

传统的单体架构

单体架构：传统的单体架构，也就是为单点应用，将业务的所有功能都集中在一个项目中开发，整个项目中所有功能模块都在一个工程中开发，打成一个包去部署（部署在同一个Tomcat中），整个项目/系统的所有服务都部署在一台服务器上面，由一台服务器组成的系统。 

单体架构的优缺点如下：

优点：

• 开发简单，架构简单
• 部署成本低

缺点：

• 该架构模式没有对我们的业务逻辑去实现拆分，耦合度高，扩展性差，因为所有代码写在一个项目里（维护困难 - 如果是个人开发倒还好、升级困难） ，适合小型项目，比如：学生管理系统，适合于小团队或个人形式开发，不适合团队模式协同工作开发
• 单机资源有限，单机处理能力有限，当业务增长到一定程序的时候，单机的硬件资源将无法满足业务需求
• 存在单点故障的问题：如果这台服务器出现问题，整个系统就会出现问题，解决方案：搞服务集群：将相同的服务，分别部署到多台服务器中，由多台服务器来共同承担系统压力，其中一台服务器挂掉，也不会影响整个系统。

分布式架构- 垂直应用架构

分布式架构：分布式的架构模式是基于传统的单体架构模式演变而来，根据业务功能或业务逻辑对系统做拆分，每个业务功能模块作为独立项目开发，称为一个服务，说白了就是按照业务垂直划分，每个业务都是单体架构，通过API互相调用  =>  分散部署在多台服务器上面，多台机器组成的一个运行环境/系统，一个系统中的多个服务部署在不同的服务器上，由多台服务器组成的系统。

分布式架构的优缺点：

优点：

• 降低服务耦合，服务之间的耦合度降低了
• 扩展性好，有利于服务升级和拓展
• 系统拆分实现了流量分担，解决了并发问题，而且可以针对不同模块进行优化和水平扩展
• 从这种架构模式开始慢慢适合于互联网公司的团队开发

缺点：

• 架构复杂，难度大，服务调用关系错综复杂（只能远程调用：跨越机器、跨越服务的调用） ，适合大型互联网项目，比如：淘宝、京东
• 分布式也并不能解决单点故障的问题，分布式跟单点问题没有关系，真正解决单点故障的方式是在分布式下面再继续搞集群，采用集群的方案
• 分布式架构下所带来的分布式Session问题

集群（服务集群）    

• 单机处理到达瓶颈的时候，你就把单机复制几份，这样就构成了一个“集群”。
• 将相同的服务，分别部署到多台服务器中，由多台服务器来共同承担系统压力，同时，其中一个服务器挂掉，也不会影响到整个系统。
• 集群中每台服务器就叫做这个集群的一个“节点”，所有节点构成了一个集群。
• 每个节点都提供相同的服务，那么这样系统的处理能力就相当于提升了好几倍（有几个节点就相当于提升了这么多倍）。  

优点：

•  资源可以横向扩展，可以解决单点故障问题

缺点：

•  维护成本较高，且会有本地缓存数据无法共享的问题

但问题是用户的请求究竟由哪个节点来处理呢？  

• 最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均；
• 要实现这个功能，就需要在所有节点之间增加一个"调度者"的角色，用户的请求都先交给它，然后它再来根据当前所有节点的负载情况，决定将这个请求交给哪个节点来进行处理，这个"调度者"就是负载均衡服务器。

在上面的图中仅展示了Tomcat的集群，如果MySQL压力比较大的情况下，我们也是可以对MySQL进行集群的。 

分层架构

• 当垂直应用越来越多，重复的业务代码就会越来越多，这时候，我们就思考可不可以将重复的代码抽取出来，做成统一的业务层作为独立的服务，然后由前端控制器调用不同的业务层服务呢？
• 这样就产生了新的分布式系统架构，它把工程拆分成表现层和服务层两个部分：服务层种包含业务逻辑，表现层只需要处理页面的交互，业务逻辑都是调用服务层的服务来实现。

优点：

• 抽取公共的功能作为服务层，提高代码复用性

缺点：

• 系统间耦合度变高，调用关系错综复杂，难以维护 

SOA面向服务架构模式

• SSO：单点登录的认证系统

Service-Oriented Architecture，简称SOA，SOA面向服务架构就是基于我们的分布式架构模式演变过来，俗称服务化，也就是面向与接口开发（面向服务开发），服务就是只有接口，将共同存在的业务逻辑抽取成一个公共的服务，提供给其它接口实现调用，服务与服务之间的通讯采用RPC远程调用技术。

SOA架构模式解决了代码的冗余性问题。

SOA架构模式的特点：

1. SOA架构模式的传输协议采用SOAP协议（HTTP / HTTPS + XML）实现传输，SOA架构模式的通讯种，采用XML方式实现传输，在高并发的情况下，通讯过程中该协议存在大量的冗余性传输（XML格式肯定非常的冗余），而且非常占用带宽，所以在后来的微服务架构模式种使用JSON格式替代了XML。
2. SOA架构模式的实现方案为WebService或者ESB企业服务总线，底层采用SOAP协议传输

传统政府、银行项目还是在使用WebService，互联网公司肯定采用HTTP + JSON格式实现传输。

WebService架构模式

• WebService架构模式中最核心的组件：wsdl，wsdl就是描述WebService的接口信息、方法、调用地址、参数等         

 

以下是一个简单的面向服务架构（SOA）的架构图： 

在SOA中，系统被分解为多个服务，每个服务都有独立的功能，并按照一定标准进行设计和实现。服务之间通过ESB企业服务总线来传递消息，并且可以动态发现和调用其他服务。 

企业服务总线（ESB）是什么？[注意：它并不是注册中心] 

• 作用：解决多系统之间跨语言无法实现通讯的问题，对我们的数据协议实现转换，可以提高可靠的消息传输，第三方框架实现。 

在面向服务的架构中，企业服务总线（ESB）是一个关键的组件，它将不同的服务连接在一起，并协调和控制服务之间的交互。通过使用ESB，可以提高系统的可靠性、可维护性和可扩展性。 

SOA架构模式存在哪些缺点：

1. 底层采用SOAP协议实现通讯，整个过程是XML传输非常重，效率比较低
2. 服务化的管理和治理设施不够完善 
3. 依赖于服务发现机制
4. 不适合前后端分离开发，因为前端解析XML非常的麻烦

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

• 服务拆分的粒度如何界定？
• 服务集群的地址如何维护？    服务治理问题
• 服务之间如何实现远程调用？会出现跨进程跨主机的服务调用，跨服务的远程调用问题
• 服务的调用关系如何管理？    服务的请求路由问题
• 服务健康状态如何感知？万一你这个服务都挂了我还来调你，导致我这里也调用失败 - 级联失败

人们需要指定一套行之有效的标准来约束分布式架构，因此就出现了微服务~！ 

知识补充：热更新（Hot Reload）

• 热更新指的是应用程序运行时，修改程序代码后无需重启整个应用程序，而是只需要重新加载修改后的部分代码，使得修改的代码可以立即生效，通过这种方式，可以避免每一次修改后都需要重新启动应用程序，等待整个应用程序重新加载的情况出现，使得开发人员可以更加方便地进行代码调试和修改。

微服务架构模式的基本概念 

• 微服务架构模式就是从我们的SOA面向服务架构演变过来的，它比SOA架构对服务的粒度会更加精细，采用前后端分离的架构模式，让专业的人去做专业的事情，目的是可以去实现高效率开发，微服务架构中，每个服务之间都是互不影响的，每个服务必须要独立进行部署、运维，互不影响，微服务架构模式非常轻巧，轻量化，适合于互联网公司开发模式。
• 技术栈：SOA服务通常使用统一的技术栈和平台，这可能限制了技术的多样性和灵活性，而微服务架构允许每个服务使用不同的技术栈和平台，这有助于提高技术的多样性和灵活性。

什么是微服务？

• 微服务它其实是分布式架构的一种，所谓分布式架构就是要把服务做拆分。
• 微服务是一种经过良好架构设计的分布式架构方案（微服务架构）。
• 微服务的架构它是属于一种分布式系统的架构。
• 微服务是一种软件架构的风格，它是以专注于单一职责的很多小型项目为基础，组合出复杂的大型应用。
• 微服务架构，简单的说就是将单体应用进一步拆分，拆分成更小的服务，每一个服务都是一个可以独立运行的项目。

微服务的优缺点：

优点：

• 拆分粒度更小、服务更独立、耦合度更低

缺点：

• 架构非常复杂，运维、监控、部署难度提高 

微服务的架构特征：独立部署、可配置、动态化

• 服务拆分粒度 - 单一职责：SOA架构它强调的服务的拆分是公共服务的拆分，因此SOA面向服务架构中的服务通常具有较大的粒度；而微服务架构中服务的拆分粒度更小，每一个服务都对应唯一的业务能力，每个服务都围绕着具体业务进行构建，做到单一职责（微服务关注单一职责原则），避免重复业务开发

• 面向服务：微服务要对外暴露业务接口（这样服务之间就可以做一些相互的调用了），服务提供统一标准的接口，与语言和技术无关

• 自治：指的就是独立：微服务架构强调服务的独立性，团队独立、技术独立、数据独立（是指每个服务可以有自己独立的数据库，都有自己独立的数据存储，实现了数据解耦）、部署独立（能够被独立的部署到生产环境）和交付独立，整个服务架构更加轻巧，轻量级；而在SOA架构中，有可能存在多个服务共享同一个数据库，但是微服务架构强调每个服务必须是独立的数据库部署，互不影响。

• 隔离性强：服务调用要做好隔离、容错、降级，避免出现级联问题

• 通信协议：SOA采用如SOAP复杂的通信协议，而微服务架构倾向于使用轻量级的通信协议，在微服务架构中去除了SOA架构中的SOAP协议和ESP企业服务总线，服务与服务之间通讯的协议采用如RESTful API和gRPC，数据交换格式采用HTTP + JSON格式实现传输，整个传输过程中，采用二进制（0101），所以HTTP协议可以实现跨语言的平台，并且和其它语言实现通讯。

• 一般情况下都是采用HTTP + JSON格式传输，所以没有必要使用ESB企业服务总线。

• 迭代：微服务的架构模式比SOA架构模式，更加适合于互联网公司敏捷、高效、快速的迭代版本开发，因为粒度非常精细。

微服务的上述特征其实是在给分布式架构制定一个标准，这些特征其实最终的目的就是为了实现高内聚、低耦合，降低服务之间的耦合度，（降低服务它所能产生影响的范围），提高服务的独立性和灵活性，避免整个集群的故障！ 

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

• 在单体架构下，一个应用系统的多个功能模块由于组织在一起在同一个应用进程内部署与运行，因此，模块之间直接通过方法调用即可完成对一次请求的响应；
• 但在微服务系统中，需要对一个应用系统根据其功能特点，按照一定粒度进行拆分后单独部署，以便实现模块内的高内聚，模块间的低耦合，实现整个微服务系统的高可扩展性。 

微服务与传统单体式应用架构最大区别就是强调软件模块的拆分！ 

• 微服务它一种其实是分布式架构的一种，所谓分布式架构就是要把服务做拆分，而拆分的过程中其实会产生各种各样的问题需要去解决，而Spring Cloud其实仅仅是解决了服务拆分时的服务治理问题，至于其它的一些分布式的更复杂的一些问题，并没有给出解决方案，所以一个完整的微服务技术，要包含的不仅仅是Spring Cloud。

• 微服务要做的第一件事情就是拆分，因为传统的单体结构，所有的业务功能全部写在一起，随着业务越来越复杂，代码也变得耦合的越来越多，将来你想升级、维护就会很困难，所以像一些大型的互联网项目，就必须去做拆分；
• 微服务在做拆分的时候，会根据业务功能模块把一个单体的项目拆分成许多个独立的项目，每个项目完成一部分业务功能，将来独立开发和部署，我们把这样一个独立的项目称为一个服务；
• 一个大型的互联网项目往往会包含数百甚至上千的服务，最终形成一个服务集群，而集群中的每个服务都要遵循单一职责的原则，并且要面向服务，对外暴露业务接口，这样服务之间就可以做一些相互的调用，只不过不同技术在实现这些接口的时候，可能会有差异；
• 在Spring Cloud生态中，采用服务注册与发现模型，来实现微服务之间的互相发现与调用：而一个业务往往需要有多个服务共同来完成，比如说一个请求来了，它可能先去调了服务A，而服务A可能又调了服务B，然后又去调了服务C，当业务越来越多，越来越复杂的时候，这些服务之间的调用关系就会越来越复杂，这么复杂的一个调用关系一定需要我们去维护，想靠人去记录和维护，这是不可能的，所以在微服务里，一定会有一个组件，叫做注册中心：它可以去维护微服务里面每个节点的信息，并且去监控这些节点的状态：所有的微服务应用在启动过程中会将自身包含服务名称、主机IP地址和端口号等信息发送到注册中心去中，它可以去记录微服务中每一个服务的IP、端口以及它能干什么事这些信息，当有一个服务需要调用另外的服务时，它不需要自己去记录对方的IP，只需要去找注册中心就行了，由注册中心去拉取对应的服务信息，根据服务名称到注册中心中查找对应服务的所有实例IP地址和端口号来进行服务调用，从而让分散的微服务系统之间能像一个整体一样对外提供请求处理能力。

• 配置管理 - 分布式配置中心：并且将来随着服务越来越多，每一个服务都有自己的配置文件，如果将来有一些配置需要去做修改，将来如果要更改配置，难道我们手动的去微服务里面逐一去修改吗？这就太麻烦了，所以在微服务里还会有一个分布式配置中心：它可以去统一的管理整个服务群体成千上百的这个配置信息，如果以后有配置需要变更，只需要去找到分布式配置中心就可以了，它会去通知相关的微服务，利用通知的方式去让对应的服务服务监控到配置的变化，从而实现配置的热更新 - 使用分布式配置中心，可以在运行时动态更新配置信息，而无需重新启动应用程序；而在传统的开发方式中，这些配置信息通常硬编码到应用程序的代码中，与程序代码一起打包和部署，然而，这种方式有很多缺点，比如配置信息不易维护，只要修改配置就得重新构建和部署等。
• 将来当我们的微服务一旦部署上线，用户就可以来访问我们了，但这个时候，还需要有一个网关组件，因为你这里有这么多的微服务，用户怎么知道该访问哪一个呢？而且也不是说你随便什么人都能来访问我们的服务吧，所以这些服务集群还需要有一个统一的服务网关作为入口，我们的服务网关一方面就是对用户身份对校验，另一方面就是由网关把用户的请求路由到我们的具体的服务，当然在路由过程中，也可以去做一些负载均衡，并且路由的时候或者服务之间的调用过程中，我们还要做好服务的容错处理，避免因为服务故障带来级联失败，还要做好服务保护、隔离、降级等等这些措施；
• 而这时候呢，服务进入到你的请求去处理业务，该访问数据库的时候就去访问数据库，最后再把查询到的数据返回给用户，将来数据库肯定要做集群，但是你集群再庞大，也不可能有用户多把，所以数据库将来肯定无法抗住高并发的场景，因此还会加入缓存，缓存就是把数据库数据放入到内存当中，内存查询效率肯定要比数据库快很多，而且这种缓存还不能是单体缓存，为了应对高并发，还要做成分布式缓存，也是一个集群：用户请求先到缓存，缓存未命中，再去查询数据库。
• 以后我们的业务中还会有一些复杂的搜索功能，简单查询可以走缓存，一些海量数据的复杂的搜索、统计和分析，缓存也做不了，这个时候就需要用到分布式搜索功能，数据库将来主要的职责其实就是做一种数据的写操作，还有一些事务类型、对数据安全要求较高的一些数据存储；
• 最后在微服务里边，还需要一种异步通信的消息队列组件，因为对于这种分布式的服务或者微服务里面，它的业务往往会跨越多个服务，一个请求来了，先调的服务A，A再调B，B再去调C，整个业务的链路就很长，调用时长就会等于每个服务的执行时长之和，所以其实性能是有一定的下降的，而异步通信的意思就是，请求来了，我调了服务A，服务A我不是去调你服务B和C，而是通知你们，发一条消息，你们两个赶紧干活去，于是，那两个哥们去干了，而服务A直接结束了，所以它的业务链路就会变短了，响应时间也缩短了，自然吞吐能力也就变强了，所以异步通信可以大大的提高我们服务的并发，在一些类似于秒杀这样的高并发场景下就可以去利用了。

当然，我们如此庞大和复杂的一个服务，在运行的过程当中，如果出现了什么问题，就不太好排查，所以在微服务运行过程中，我们还会引入两个新的组件来去解决服务的异常定位：

1. 第一个是分布式日志服务，它可以去统计整个集群当中成千上百的这些服务，它们的运行日志，统一的去做一个存储、统计和分析，将来如果出现问题，就比较好定位了；
2. 而且还有第二个东西，叫做系统监控和链路追踪，它可以去实时监控我们整个群体中每一个服务节点的一个运行状态、CPU的负载、内存的占用等等的情况，一旦出现任何的问题，直接可以定位到具体的某一个方法（栈信息），那么你就能够很快速的定位到异常所在了。

那么如此庞大、复杂的一个微服务集群，将来很有可能会达到成百上千甚至上万的服务，这个时候，我们部署该怎么办呢？

• 如果还是靠以前，人工去部署，显然不太现实，所以将来这些微服务集群还需要去做一种自动化的部署，我们就会利用Jenkins这样的工具，它可以对这些微服务项目进行自动化的编译，基于docker再去一些打包，形成镜像，再基于kubernetes（K8s）或RANCHER这样的技术去实现自动化的部署，这一套我们称之为持续集成。

结合微服务的这些技术再加上持续集成，这才是完整的微服务技术栈！

• 持续集成DevOps：开发运维 

微服务技术对比

目前最流行的两种微服务解决方案是Spring Cloud和Dubbo。 

• 微服务这种方案也需要技术框架来落地，全球的互联网公司都在积极尝试开发自己的微服务落地技术，在国内最知名的就是Spring Cloud和阿里巴巴的Dubbo  =>  不管是Spring Cloud还是Alibaba的Dubbo，都是微服务方案的实现，所以它们所包含的组件实现的功能基本是一致的，首先它们都需要去做微服务的拆分，形成微服务集群，而集群中的每个服务都要遵循单一职责的原则，并且要面向服务，对外暴露业务接口，这样服务之间就可以做一些相互的调用了...
• 微服务这种分布式架构方案的落地，其实在Java领域最引人注目的就是SpringCloud提供的方案了。

Spring Cloud VS Spring Cloud Alibaba VS Dubbo的区别与联系？ 

Spring Cloud和Dubbo其实它们在实现的过程中，其实是有一些差异的：

Dubbo技术它早在2012年左右就已经开源出来了，是Alibaba公司开源的，但是那个时候微服务技术在国内可能连听都没听过，所以说Dubbo并不是严格意义上的一个微服务技术，Dubbo最开始只是一个简单的RPC调用框架，它对标的是我们的Spring Cloud中的OpenFeign来实现RPC的，在那个时候，它的核心就是服务的远程调用以及注册发现，所以在Dubbo里面技术体系并不完整，而且注册中心也不是Dubbo里面自己实现的，而是依赖于zookeeper或Redis去做的，这些并不是专业的注册中心（半吊子），像Redis是做缓存的，zookeeper是做集群管理的，所以Dubbo并不具备完善的注册中心功能，而服务的这种远程调用才是Dubbo的核心，Dubbo它最开始的优势是在于自定义的Dubbo通信协议，Dubbo使用的是RPC通信，二进制传输，占用带宽小，效率要比HTTP协议高不少，在当时，Dubbo专门基于这种TCP的协议定义了一套标准，也就是Dubbo协议，Dubbo协议是一种基于TCP协议的RPC协议，所以遵循Dubbo这种远程调用，必须得定义Dubbo这种标准的接口。而且配置中心和服务网关Dubbo都没有实现，至于服务监控Dubbo里面只提供了一个非常基本的dubbo-admin功能，只是来统计一下服务调用时的一个响应时间、QPS等等，功能非常单一，所以Dubbo所实现的这个服务的治理，其实是非常不完善的。

而到了2015年~2017年这段时间，可以说是微服务技术井喷的时候，各种各样的微服务技术层出不穷，但是一直没有一个一统江湖的，直到Spring Cloud的出现，Spring Cloud它并不是发明了什么东西，而是整合，它把全球各个公司的开源的这种微服务技术都给整合起来了，而后形成了一套完整的微服务技术体系，是一个集大成者，它里面的功能是非常完善的，它首先有完善的注册中心，里面包含了Eureka、Consul这种专业的注册中心，并且Spring Cloud的服务调用它并没有去整一种全新的协议和标准，它用的是直接基于HTTP协议的标准的Feign客户端，由它来去发送HTTP的请求（不用它也行，只要遵循Restful风格 => 基于HTTP协议的RESTful API），Spring Cloud还提供了专业的配置中心，叫做SpringCloudConfig，另外Spring Cloud还提供了SpringCloudGetway以及Zuul两个不同的网关，在目前比较流行的是SpringCloudGetway网关，因为它里面基于了最新的响应式编程，吞吐能力非常强，还有服务监控和保护 - Hystrix，Hystrix它是一个非常强大的服务保护技术，但是它里面也带有一些监控的功能，但核心是保护，主要就是实现了服务的隔离和熔断等等一些相关技术，功能也是十分强大。

由于Dubbo和Spring Cloud相比还是存在比较大的差距，Dubbo它不是一个完善的微服务的技术栈，所以阿里巴巴也认识到了这一点，因此阿里巴巴为了追赶Spring Cloud的脚步，形成了一套能够与Spring Cloud无缝衔接的开源组件和工具，也就是Spring Cloud Alibaba，Spring Cloud Alibaba本质上是实现了Spring Cloud标准接口的，Spring Cloud Alibaba是对Spring Cloud的标准实现，Spring Cloud Alibaba基于Spring Cloud，符合Spring Cloud标准，所以可以认为Spring Cloud Alibaba是Spring Cloud的一部分，Spring Cloud Alibaba是Spring Cloud的一个子项目，Spring Cloud Alibaba是Spring Cloud的拓展，是阿里的微服务解决方案，用于构建云原生微服务应用。SpringCloud Alibaba最终的目的还是想要把Dubbo也整合进来，所以SpringCloud Alibaba也实现了自己的注册中心、配置中心 - Nacos以及服务监控 - Sentinel，Nacos注册中心它的强大之处在于它既支持Dubbo这种调用，又支持Feign的这种调用，也就是说既支持Dubbo标准的接口，又支持Feign标准的接口，因此Spring Cloud Alibaba同时兼容Dubbo和Spring Cloud这两种架构。

采用的协议方式不同，将来提供的接口标准也就不同，接口标准不同，将来项目的架构也就不一样了。

Spring Cloud和Spring Cloud Alibaba在概念和功能上有很大的相似性，都致力于构建和管理微服务架构，但Spring Cloud Alibaba更加专注于阿里巴巴云生态，并提供了一些额外的功能和针对云原生应用的支持。

Spring Cloud第一代和第二代的区别？ 

Spring Cloud 本身并不是一个开箱即用的框架，它是一套微服务规范，共有两代实现：

• Spring Cloud Netflix 是 Spring Cloud 的第一代实现，主要由 Eureka服务治理、Ribbon客户端负载均衡器、Feign[基于Ribbon和Hystrix的声明式服务调用组件]、Hystrix服务保护框架、Zuul网关组件等组件组成，Spring Cloud第一代实际上都是用的Netfix公司开源的组件整合的微服务解决方案。
• Spring Cloud Alibaba 是 Spring Cloud 的第二代实现，主要由 Nacos、Sentinel、Seata 等组件组成，Spring Cloud第二代实际上就是自己研发和国内优秀的微服务解决框架实现整合。

Spring Cloud Alibaba 是阿里巴巴结合自身丰富的微服务实践而推出的微服务开发的一站式解决方案，是 Spring Cloud 第二代实现的主要组成部分。吸收了 Spring Cloud Netflix 微服务框架的核心架构思想，并进行了高性能改进。自 Spring Cloud Netflix 进入停更维护后，Spring Cloud Alibaba 逐渐代替它成为主流的微服务框架。 

同时 Spring Cloud Alibaba 也是国内首个进入 Spring 社区的开源项目。2018 年 7 月，Spring Cloud Alibaba 正式开源，并进入 Spring Cloud 孵化器中孵化。 

Nacos分布式注册中心 + Nacos分布式配置中心 = Eureka注册中心 + Spring Cloud Config配置中心

为什么Alibaba要推出Spring Cloud组件？

• 目的就是为了对阿里云的产品实现扩展，Spring Cloud Alibaba就是为了推广阿里云的产品以及对我们目前的Spring Cloud 2.x版本实现扩展功能。

Spring Cloud Alibaba 和 Spring Cloud、Spring Cloud Netflix 的区别在哪？​

Spring Cloud：Spring 官方提供的分布式应用开发的一套共用模式，也可以理解成一套微服务开发的统一的抽象编程模型。

Spring Cloud Netflix：基于 Spring Cloud 编程模型实现的微服务框架，是最早期的微服务框架。近年来，Netflix 宣布大多数组件停止维护。

Spring Cloud Alibaba：Alibaba 提供的基于 Spring Cloud 编程模型实现的微服务框架，其所有组件都来自于阿里巴巴微服务技术，无论是解决方案完整性、技术成熟度、社区还是文档资料等都对国内开发者非常友好。

为什么选择SpringCloud Alibaba？

• 这里我们为什么选择SpringCloud Alibaba呢，主要因为SpringCloud Netflix的组件：服务注册与发现的 Eureka、服务限流降级的 Hystrix、网关 Zuul都已经停止更新了，当然继续使用是没问题的，只是出现问题，官方不维护，需要自行解决。

Spring Cloud & Spring Boot的关系？

• Spring Cloud是目前国内使用最广泛的微服务框架，Spring Cloud是一系列框架的有序集合
• Spring Cloud是分布式微服务架构的一站式解决方案，集成了各种优秀的微服务功能组件，它利用Spring Boot的开发便利性巧妙的简化了分布式系统基础设施的开发，使我们能在Spring Boot的基础上轻松的实现微服务系统的构建，如服务注册与发现、配置中心、消息总线（Spring Cloud Bus）、负载均衡、断路器、数据监控等，都可以利用Spring Boot的开发风格做到一键启动和部署。
• Spring Cloud提供以微服务为核心的分布式系统构建标准。

官网地址：Spring Cloud

中文网站：Spring Cloud中文网-官方文档中文版 

Spring Cloud集成了各种微服务功能组件，并基于Spring Boot实现了这些组件的自动装配（重点），从而提供了良好的开箱即用体验。

其中常见的组件包括：

Spring Cloud是在Spring Boot之上构建的一套微服务生态体系，包括服务发现、配置中心、限流降级、分布式事务、异步消息等，因此通过增加依赖、注解等即可完成Spring Boot应用到Spring Cloud升级。 

另外，Spring Cloud底层是依赖于Spring Boot的，一个Spring Cloud项目是由多个Spring Boot项目组成的，Spring Cloud是一个基于Spring Boot实现的服务治理工具包，Spring Boot专注于快速、方便的开发单个微服务（单体架构应用的开发），而Spring Cloud关注于全局的微服务整合和管理，Spring Cloud关注全局的服务治理组件的集合，Spring Cloud是构建在Spring Boot之上的一个服务治理框架，并且有版本的兼容关系，Spring Cloud它是拥有很多子项目的大项目，Spring Cloud与Spring Boot的版本兼容关系如下：

Hoxton版本是 Hoxton.SR10，因此对应的SpringBoot版本是2.3.x版本。  

Hoxton版本是SR5，对应的SpringBoot版本是2.2.x版本，SR5以上，则对应的Spring Boot版本就是2.3.x。

微服务四大件：注册中心、服务提供者、服务消费者、服务治理 

微服务架构的项目结构

最左边为客户端：

• IoT：物联网设备
• Mobile：移动端
• Browser：浏览器

API Getway：API网关

Service registry：服务注册中心     registry：注册，注册表

Config server：配置服务，配置中心

Microservices：微服务

Distributed：分布式   trace：追踪    分布式追踪：追踪每个请求的流向/走向

一些专业术语

• 配置中心：可以说是一个"大货仓"，内部放置着各种配置文件，可以通过自己所需进行获取配置加载到对应的客户端。
• 注册中心：可以说是微服务架构中的"通讯录"，它记录了服务和服务地址的映射关系，在分布式架构中，服务会注册到这里，当服务需要调用其它服务时，就到这里找到服务的地址，进行调用，进行彼此通信。
• 服务器：用于运行服务的计算机，这些计算机可以是虚拟机/物理机/云服务器等，服务器分为软件服务器与硬件服务器，软件服务器：类似于Tomcat这种跑项目的程序；硬件服务器：物理设备，用来部署项目的电脑(一般性能要比个人电脑好)
• 配置：软件系统中的配置是指在软件运行过程中所需要的各种设定和参数，包括系统配置（操作系统、硬件和网络等基本环境参数的设定）、应用配置（应用程序的各种参数和选项的设定，如数据库连接字符串、日志级别等）和用户配置（用户自定义的各种选项和参数，如快捷键、界面布局、语言等）等。配置在软件系统中是对系统源代码的一种重要补充！
• 服务：操作系统上的术语，成品软件，可以独立运行起来，可以向外提供服务能力，一个能够对外提供功能的程序，比如MySQL、Redis以及我们写好的程序
• 框架：半成品的软件，用于帮助开发人员快速开发系统功能，需要借助其他服务来运行应用
• 微服务：小的服务（更细粒度的服务），一个完整项目可以拆分为N个子项目，这些子项目能够独立运行，独立对外提供功能
• 节点：一台服务器；一个虚拟机；一个容器（Docker容器 => 轻量级的虚拟机？）
• 实例：描述的是具体某一个服务，运行了几个进程
• 垂直扩展：纵向的扩展能力，垂直扩展是指增强单机（单台机器）的硬件性能，说白了就是增加单台机器的硬件能力，垂直扩展它的扩展资源是有限的，因为你一台机器肯定不可能无限去堆硬件
• 水平扩展 - 加多台机器（推荐）：横向拓展，增加系统的规模，通过增加更多的服务器或者程序实例来分散负载，从而提升存储能力和计算能力
• 容错率：允许出错的比例，允许服务器集群（一堆服务器）错误（异常/故障）出现的范围和概率。
• 高内聚，低耦合：内聚 - 模块或组件内部的元素之间的联系紧密程序，程序功能独立    耦合 - 模块或组件之间的相互依赖程序，程序间交互  以Java为例，高内聚，低耦合：设计类时尽量边界清晰，功能简单，类与类之间的交互尽可能少，减少类与类之间的相互调用 
• 流量：访问量，用户量，请求次数
• 服务间的依赖：项目与项目间的调用，程序与程序间的调用
• 资源调度：调度 - 负责分配资源    开发中的资源：服务器，内存，CPU，IO，网络等
• 单点（Signle Point）：指的就是一个（这个服务只运行了一个实例：一个MySQL只运行了一份；这个服务器只有一个节点），系统或架构中的单个组件、服务或资源
• 单点故障（Signle Point of Failure，简称SPoF）：如果项目或程序部署在唯一的一个服务器上，如果这个服务器挂了，那么整个系统也就挂了，单点故障会导致整个系统或应用无法正常工作
• 宕机（Downtime）：服务器挂掉了
• 负载（Load）：是指系统正在处理或等待处理的工作量或任务数，它通常用于衡量系统资源的使用情况或性能状况。比如CPU负载：指系统中正在使用CPU资源的工作量。

Spring Boot开发三板斧

加依赖（整合什么，就加什么的依赖）

• 官方提供的starter格式：spring-boot-starter-xxx
• 非官方提供的starter格式：xxx-spring-boot-starter

写注解：

• 某些需要用到注解的，需要在启动类或者在指定的地方上加上注解

写配置：

• 可以是Bean类型的配置类
• 也可以是resources下的yml&yaml&properties等加配置 

分布式系统常见问题 

• 哪些问题是原先在单体架构中不存在的而在分布式系统中却存在的一些问题?

集群（Cluster）

• 我们通常讲的集群指的是分布式下的集群，集群是属于分布式下的一个子的概念
• 集群就是把一个服务实例变成多个服务实例，集群中的每台服务器就叫做这个集群的一个"节点"（Nodes），所有节点就构成了一个集群，每个节点都提供相同的服务。

现在的问题是用户的请求究竟由哪个节点来处理呢？

• 最好能够让此时此刻负载较小的节点来处理，这样使得每个节点的压力都比较平均；

• 要实现这个功能，就需要在所有节点之前增加一个 "调度者" 的角色，用户的所有请求都先交给它，然后它根据当前所有节点的负载情况，决定将这个请求交给哪个节点处理，这个"调度者"叫做负载均衡服务器。

注意：

• 集群不一定是分布式，反例：我在一台机器上运行多个相同的服务，比如我在一台机器上面运行三个Redis实例，它是集群，但是它不是分布式（伪集群或伪分布式） 

集群的优点：

• 资源可以横向扩展，可以解决单点故障问题

集群的缺点：

• 维护成本较高，且会有本地缓存（Session属于本地缓存的一种）数据无法共享问题（分布式Session问题 - Session无法共享：通常我们在开发后台管理系统时，会使用Session来保存用户的会话(登录)状态，由于Session是存储在服务器内存中的，每个Tomcat当中都有一份属于自己的Session，当对服务器进行横向扩展时，无法将服务器内存中的Session一起共享，多台Tomcat并不共享Session存储空间，当请求切换到不同Tomncat服务时导致数据丢失的问题，因此用户访问另一台服务器时没有数据，导致用户可能又要重新进行登录，问题在于分布式系统每次会把请求随机分配到不同的服务器，此时产生分布式Session问题） 

分布式Session/缓存共享问题的解决方案：

• 解决方案一：负载均衡算法，保障用户只会访问到某一个服务器；
• 解决方案二：远端缓存（Redis）- 分布式缓存：将缓存信息不存储到服务器，而是存储到另外的服务中，所有的服务都去访问远端缓存获取数据，从而实现数据共享  =>  借助Redis对这些Session信息进行统一的存储和管理，这样无论请求发送到哪台服务器，服务器都会去同一个Redis获取相关的Session信息，这样就解决了分布式系统下Session存储的问题。

分布式唯一ID问题

• 当系统有多个数据库（即分库分表）时，一条数据往多个不同库（或表）中存储时，由于原先默认的主键自增策略，可能会导致主键ID出现相同的情况，这种情况会导致我们无法确实数据到底是哪一条。

应用服务既可以访问DB1，也可以访问DB2。。。 

解决方案 - 分布式ID生成算法：

• 雪花算法

• UUID  

分布式资源争抢问题

• 线程安全问题：多线程并发访问并修改同一共享资源而造成的数据错乱问题。

在单体式系统中，我们可以借助系统内部的锁（单机锁），来避免系统内多个线程争抢资源，但是在分布式系统中，每个系统内部都会有一把锁，这些锁各自之间是没有关联的，也就意味着每个系统都能够有至少一个线程去访问共享资源，因此还是会出现多线程争抢共享资源的问题 => 线程安全问题 => 一个节点更新的数据，其他节点无法及时感知到这个更新！

目标 

• 了解微服务常用的概念

• 了解项目架构演变

• 掌握微服务环境搭建

• 掌握微服务治理组件-Nacos Discovery

• 掌握微服务负载均衡调度组件-Ribbon

• 掌握微服务远程调度组件-Feign

• 掌握微服务流控容错组件-Sentinel

• 掌握微服务网关组件-Gateway

• 掌握微服务链路追踪组件-Sleuth&Zipkin

• 掌握微服务配置中心-Nacos Config

• 开口表述上面所有组件概念、定位、原理与运用(每个10分钟)

微服务架构中会存在哪些问题？

• 分布式事务的解决方案：RabbitMQ、RocketMQ的事务消息、lcn（已经被淘汰了）、Setata，思想是最终一致性的问题。
• 分布式任务调度平台：XXL-JOB、elastic-job、AlibabaCloud Scheduler
• 分布式的服务注册与发现：Eureka、Consul、Zookeeper、Nacos
• 分布式日志采集系统：ELK + Kafka
• 分布式服务追踪与调用链系统：Zipkin
• 分布式服务配置中心：SpringCloud Config、携程的Apollo、disconfig

为什么要使用到Spring Cloud？

• Spring Cloud它并不是一个RPC的远程调用框架，而是一个微服务全家桶的解决方案的框架，理念就是一条龙服务去解决我们在微服务架构中遇到的问题。

注意：如果去一些比较大型的互联网公司中，整个公司内部实现的RPC通讯的框架，包括像服务的治理都是内部自己研发，第一点，它有钱，除了有钱之外，第二点它研发框架的目的是能够结合到我公司内部的业务场景，其次是安全。

公司有一定规模但是不是特别有钱的就会使用到Spring Cloud。

RPC远程调用框架有哪些？

• HttpClient、Dubbo、Feign、gRPC、基于Netty手写RPC