Spring Cloud:微服务基础知识_spring cloud 微服务协议

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

一、系统架构演变

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

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理论我们得知任何分布式系统只可同时满足二点没法三者兼顾既然一个分布式系统无法同时满足一致性、可用性、分区容错性三个特点所以我们就需要抛弃一样：