Spring Cloud:微服务基础知识

Posted 2022-12-11 不断前进的皮卡丘

✨ Spring Cloud:微服务基础知识

• 一、系统架构演变
• • 1. 单体应用架构
  • 2. 垂直应用架构
  • 3. 分布式架构
  • 4. SOA架构
  • • 4.1 SOA概念
    • 4.2 SOA
  • 5.微服务架构
  • 6.SOA和微服务架构的关系
• 2.分布式核心知识
• • 1.分布式中的远程调用
  • • 1.1RESTFUL接口
    • 1.2RPC协议
    • 1.3二者的区别与联系
  • 2.分布式中的CAP原理

📃个人主页:不断前进的皮卡丘
🌞博客描述:梦想也许遥不可及，但重要的是追梦的过程，用博客记录自己的成长，记录自己一步一步向上攀登的印记
🔥个人专栏:微服务专栏

一、系统架构演变

随着互联网的发展，网站应用的规模不断扩大，常规的应用架构已无法应对，分布式服务架构以及微服务架构势在必行，亟需一个治理系统确保架构有条不紊的演进。

1. 单体应用架构

在企业发展的初期，一般公司的网站流量都比较小，只需要一个应用，将所有的功能代码打包成一个服务，部署到服务器上就能支撑公司的业务。这样也能够减少开发、部署和维护的成本。
比如搭建一个电商系统：客户下订单，商品展示，用户管理。这种将所有功能都部署在一个web容器中运行的系统就叫做单体架构。

Web应用程序发展的早期，大部分web工程(包含前端页面,web层代码,service层代码,dao层代码)是将所有的功能模块,打包到一起并放在一个web容器中运行。

单体架构优点
1.所有的功能集成在一个项目工程中
2.项目架构简单，前期开发成本低，周期低，是小型项目的首选

单体架构缺点
1.所有功能集成在一个工程中，对于大型项目不容易开发、扩展和维护，如果需要修改、新增某一个功能的话，需要对整个系统进行测试，重新部署。
2.系统性能扩展只能通过扩展集群节点，成本高，有瓶颈
3.一个模块出现问题，可能导致整个系统崩溃。
4.各个模块使⽤同⼀种技术框架，局限性太大，很难根据业务选择最适合的技术架构。
5.多团队同时对数据进行管理，容易产生安全漏洞。
6.模块内容太复杂，如果员工离职，可能需要很长时间才能完成任务交接。

2. 垂直应用架构

随着企业业务的不断发展，发现单节点的单体应用不足以支撑业务的发展，于是企业会将单体应用部署多份，分别放在不同的服务器上。但是，此时会发现不是所有的模块都会有比较大的访问量。如果想针对项目中的某些模块进行优化和性能提升，此时对于单体应用来说，是做不到的。因此，垂直应用架构诞生了。
垂直应用架构，就是将原来一个项目应用进行拆分，将其拆分为互不想干的几个应用，以此来提升系统的整体性能。

我们将单体应用架构拆分为垂直应用架构之后，一旦访问量变大，我们只需要针对访问量大的业务增加服务器节点即可，无需针对整个项目增加服务器节点了。

优点：
项目架构简单，前期开发成本低，周期短，小型项目的首选。
通过垂直拆分，原来的单体项目不至于无限扩大
不同的项目可采用不同的技术。
各系统能够分担整体访问的流量，解决了并发问题。
一个系统发生了故障，不应用其他系统的运行情况，提高了整体的容错率。
缺点：
拆分后的各系统之间相对比较独立，无法进行互相调用。
各系统难免存在重叠的业务，会存在重复开发的业务，后期维护比较困难。

3. 分布式架构

我们将系统演变为垂直应用架构之后，当垂直应用越来越多，重复编写的业务代码就会越来越多。此时，我们需要将重复的代码抽象出来，形成统一的服务供其他系统或者业务模块来进行调用。此时，系统就会演变为分布式架构。
在分布式架构中，我们会将系统整体拆分为服务层和表现层。服务层封装了具体的业务逻辑供表现层调用，表现层则负责处理与页面的交互操作。

优点:提高代码的复用性
缺点:耦合度变高，调用关系变得复杂

4. SOA架构

4.1 SOA概念

如何通俗易懂地解释什么是SOA？
SOA 全称为 Service-Oriented Architecture，即面向服务的架构。它可以根据需求通过网络对松散耦合的粗粒度应用组件(服务)进行分布式部署、组合和使用。一个服务通常以独立的形式存在于操作系统进 程中。
站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用。
通过上面的描述可以发现 SOA 有如下几个特点：分布式、可重用、扩展灵活、松耦合

4.2 SOA

在分布式架构下，当部署的服务越来越多，重复的代码就会越来越多，对于容量的评估，小服务资源的浪费等问题比较严重。此时，我们就需要增加一个统一的调度中心来对集群进行实时管理。此时，系统就会演变为SOA（面向服务）的架构。

优点：
抽取公共的功能为服务,提高开发效率
对不同的服务进行集群化部署解决系统压力
基于ESB/DUBBO减少系统耦合
缺点：
抽取服务的粒度较大
服务提供方与调用方接口耦合度较高

5.微服务架构

微服务是什么
微服务是一种架构模式，它提倡把单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务之间采用轻量级的通信机来互相协作(通常是基于HTTP协议的RESTful API)，每一个服务都围绕在具体业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。而且，我们应尽量避免统一的、集中式的服务管理机制，对具体的一个来说，应该要根据业务上下文，选择合适的语言、工具来进行构建。

1. 所谓“服务”，其实指的是项目中的功能模块，它可以帮助用户解决某一个或一组问题，在开发过程中表现为 IDE（集成开发环境，例如 Eclipse 或 IntelliJ IDEA）中的一个工程或 Moudle。

2. “微小”则强调的是单个服务的大小，主要体现为以下两个方面：

• 微服务体积小，复杂度低：一个微服务通常只提供单个业务功能的服务，即一个微服务只专注于做好一件事，因此微服务通常代码较少，体积较小，复杂度也较低。
• 微服务团队所需成员少：一般情况下，一个微服务团队只需要 8 到 10 名人员（开发人员 2 到 5 名）即可完成从设计、开发、测试到运维的全部工作。

3. 每个服务都能够独立地部署到各种环境中，例如开发环境、测试环境和生产环境等，每个服务都能独立启动或销毁而不会对其他服务造成影响。

优点：

• 通过服务的原子化拆分，以及微服务的独立打包、部署和升级，小团队的交付周期将缩短，运维成

本也将大幅度下降

• 微服务遵循单一原则。微服务之间采用Restful等轻量协议传输。

缺点：

• 微服务过多，服务治理成本高，不利于系统维护。
• 分布式系统开发的技术成本高（容错、分布式事务等）。
• 如果某个系统的远程调⽤出现问题，导致微服务不可⽤，就有可能产⽣级联反应，造成整个系统的

崩溃。

6.SOA和微服务架构的关系

2.分布式核心知识

1.分布式中的远程调用

在微服务架构中，通常存在多个服务之间的远程调用的需求。远程调用通常包含两个部分：序列化和通
信协议。常见的序列化协议包括json、xml、hession、protobuf、thrift、text、bytes等，目前主流的
远程调用技术有基于HTTP的RESTful接口以及基于TCP的RPC协议。

1.1RESTFUL接口

REST，即Representational State Transfer的缩写，如果一个架构符合REST原则，就称它为RESTful架构。
资源（Resources）
所谓"资源"，就是网络上的一个实体，或者说是网络上的一个具体信息。它可以是一段文本、一张图 片、一首歌曲、一种服务，总之就是一个具体的实在。你可以用一个URI（统一资源定位符）指向它， 每种资源对应一个特定的URI。要获取这个资源，访问它的URI就可以，因此URI就成了每一个资源的地
址或独一无二的识别符。REST的名称"表现层状态转化"中，省略了主语。“表现层"其实指的是"资 源”（Resources）的"表现层"。
表现层（Representation）
“资源"是一种信息实体，它可以有多种外在表现形式。我们把"资源"具体呈现出来的形式，叫做它的"表现层”（Representation）。比如，文本可以用txt格式表现，也可以用html格式、XML格式、JSON格式表现，甚至可以采用二进制格式；图片可以用JPG格式表现，也可以用PNG格式表现。URI只代表资源 的实体，不代表它的形式。严格地说，有些网址最后的".html"后缀名是不必要的，因为这个后缀名表示 格式，属于"表现层"范畴，而URI应该只代表"资源"的位置。
状态转化（State Transfer）
访问一个网站，就代表了客户端和服务器的一个互动过程。在这个过程中，势必涉及到数据和状态的变
化。互联网通信协议HTTP协议，是一个无状态协议。这意味着，所有的状态都保存在服务器端。因 此，如果客户端想要操作服务器，必须通过某种手段，让服务器端发生"状态转化"（State Transfer）。 客户端用到的手段，只能是HTTP协议。具体来说，就是HTTP协议里面，四个表示操作方式的动词： GET、POST、PUT、DELETE。它们分别对应四种基本操作：**GET用来获取资源，POST用来新建资源 **（也可以用于更新资源），PUT用来更新资源，DELETE用来删除资源。

综合上面的解释，我们总结一下什么是RESTful架构：

• 每一个URI代表一种资源；
• 客户端和服务器之间，传递这种资源的某种表现层；
• 客户端通过四个HTTP动词，对服务器端资源进行操作，实现"表现层状态转化"。

1.2RPC协议

RPC（Remote Procedure Call ）
一种进程间通信方式。允许像调用本地服务一样调用远程服务。RPC
框架的主要目标就是让远程服务调用更简单、透明。RPC框架负责屏蔽底层的传输方式（TCP或者
UDP）、序列化方式（XML/JSON/二进制）和通信细节。开发人员在使用的时候只需要了解谁在什么
位置提供了什么样的远程服务接口即可，并不需要关心底层通信细节和调用过程。

1.3二者的区别与联系

1、HTTP相对更规范，更标准，更通用，无论哪种语言都支持http协议。如果你是对外开放API，例如 开放平台，外部的编程语言多种多样，你无法拒绝对每种语言的支持，现在开源中间件，基本最先支持 的几个协议都包含RESTful。
2、 RPC 框架作为架构微服务化的基础组件，它能大大降低架构微服务化的成本，提高调用方与服务提 供方的研发效率，屏蔽跨进程调用函数（服务）的各类复杂细节。让调用方感觉就像调用本地函数一样 调用远端函数、让服务提供方感觉就像实现一个本地函数一样来实现服务。

2.分布式中的CAP原理

分布式中的CAP原理

1.分布式系统一定是由多个节点组成的系统。其中，节点指的是计算机服务器，而且这些节点一般不是孤立的，而是互通的。
2.这些连通的节点上部署了我们的节点，并且相互的操作会有协同。

分布式系 统的最大难点，就是各个节点的状态如何同步。CAP 定理是这方面的基本定理，也是理解分布式系统的 起点。
CAP理论由 Eric Brewer 在ACM研讨会上提出，而后CAP被奉为分布式领域的重要理论。分布式系统的
CAP理论，首先把分布式系统中的三个特性进行了如下归纳：

通过学习CAP理论，我们得知任何分布式系统只可同时满足二点，没法三者兼顾，既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点，所以我们就需要抛弃一样：