1、现在公司的基本情况

现在所有的企业都开始拥抱微服务的框架模式

saas化：Software As A Service 软件即服务

pass化：Platform As A Service 平台即服务

微服务的好处可以降低成本费用

1.1构架的分类

单体架构

SOA面向服务的架构

分布式架构

微服务架构

在微服务的架构模式下，使用的也是轻量级的通信模式（REST API），在微服务的架构模式中，需要清楚的是它的通信可以分为同步通信模式和异步通信模式，或者更加具体本质的说就是请求/响应和异步请求/响应（发布/订阅模式）

2、协议相关知识

2.1HTTP协议：超文本传输协议

目前HTTP最新的版本是：HTTP/2.0（gRPC的协议就是基于HTTP/2.0的版本来进行设计的）

但是业界使用的版本是HTTP/1.1

2.2查询HTTP版本的网站：

http://ws.webxml.com.cn/WebServices/MobileCodeWS.asmx?op=getMobileCodeInfo

2.3HTTP请求流程图

 从上图我们可以捕获的信息有

1、由客户端向服务端发起建立连接请求

2、由客户端向服务端发出请求信息

3、由服务端回送响应信息到客户端

4、由客户端进行向服务端进行关闭请求

2.4关于HTTP版本不同（HTTP1.0与HTTP1.1及以上版本进行比较）

在HTTP1.0版本中，浏览器每次请求，都是简历一次单独的连接，在处理完每一次的请求后，就会自动释放连接，这让我想起来了在学习自动化测试当中，类似于我们在编写代码时，每次测试一个用例的时候，都要进行初始化和清空的过程

在HTTP1.1及以上的版本中，则可以进行一次链接中处理多个请求，并且多可请求可以重叠进行，不需要等待一个请求结束后再发送下一个请求，也就是持久连接（keep-alive），拥有了持续连接，减轻了服务端的负载，也提升了整体相求相应时间的性能。

2.5URI和URL

URL：同意资源定位符（指的是资源的具体地址）

URI：统一资源标识符（指的是标识某一个互联网的资源）

3、微服务的架构通信模式：

微服务的通信模式使用的方式有两种：

1、一种是才用基于REST API的轻量级的基于HTTP的协议

2、使用的是gRPC的协议

3.1通信的两种模式

同步模式：

客户端发送请求给服务端，服务端必须得回应客户端的请求。 容易超时，客户端发送请求后，服务端迟迟没有回应客户端的请求 如果请求是存在大的计算量和逻辑存在问题，就会导致请求堵塞，后面的都积压 同步通信又可以说是请求/响应的模式

 异步模式：

在异步的交互中，客户端和服务端互相不需要 关注对方的存在，只需要关注对应的MQ的消息，客户端与服务端的交互主要是会通过MQ的消息中间作为消息的 传递来进行交互的 。

 MQ：

RabbitMQ,Kafka(linkyin),ActivityMQ(alibaba)

所有的M Q都可以说是队列机制，也可以说是生产者消费者的模式。所谓队列机制，遵守先进先出的规则

生产者消费者模式：生产后，基于进行快速的消费

如图所示  生产者消费者的模式

4、TCP/IP分层管理

TCP/IP协议按层次主要分为：应用层，传输层，网络层，数据链路层

4.1应用层

应用层决定了向用户提供应用服务时通信的活动。而HTTP的协议和gRPC的协议就是属于应用层的协议。

HTTP是应用层的协议

4.2传输层

应用层的下层是网络传输层，提供处于网络连接中的两台计算机之间的数据传输。

TCP/IP协议是传输层的核心

TCP/IP通信传输流

4.3链路层

主要是处理连接网络的硬件部分，如操作系统，硬件设备的驱动等

 websoket协议（auth2.0）

客户端：拿微信来说，手机微信，电脑微信，都是客户端

服务端：腾讯的微信服务器

websoket协议：客户端与服务端始终保持持久连接 不会断开

个人举例说明：

在和女朋友视频的时候 如上图所示 假设我为客户端  女朋友为服务端 （可能比较扯）

应用层为我们通过腾讯QQ进行视频

传输层为我在视频时说的话其中包括（手势，面部特征，语音等）将这些所谓的操作通过网络建立连接传给链路层进行传输到女朋友那里

从女朋友那里进行解析通过传过来的数据通过（二进制解析）到传输层

最终传输到女朋友的腾讯QQ上

备注：由于网络等一系列不确定的元素，会导致中间可能存在数据丢失（说话音卡没了等等）

4.4物联网

物联网：互联网技术的深度发展，互联网使用的协议是websockert的协议

4.5协议的分类

http

websocket

gRPC

5、三次握手概念

 SYN=发送一个同步请求
ACK=确认报文
1、客户端向服务端发送同步请求
2、服务端收到了同步请求，然后向客户端发送确认报文，和同步请求
3、客户端收到了同步请求后，向服务端发送确认报文
 
问题：为什么是三次握手而不是两次
答案：因为，三次握手才能让双方均确认自己和对方的发送和接收能力都正常

5.1为什么会有三次握手的设计？

应用层的协议是为了上层应用之间的交互，但是不需要关注底层网络传输层之间的事情，那么问题来了？应用层既然不关注网络传输层的事情，网络传输层怎么保障应用层之间数据的传输？所以为了数据传输的安全和保障，就设计了三次握手。 1、服务端的确认：客户端发送数据出去，服务端需要确认我收到了 2、服务端反馈：服务端告诉客户端，你发送的数据我这边确认收到了 3、客户端确认：客户端需要向服务端再次反馈，客户端收到服务端的反馈了

5.1.1问题：为什么是三次握手而不是两次握手？

    答案：因为，三次握手才能让双方均确认自己和对方的发送和接收能力都正常

6、四次挥手

 如图所示  主动关闭端向被动关闭端发送关闭请求，由被动关闭端确认关闭请求，确认报文，被动关闭端继续向主动关闭端发送数据，主动关闭端等待被动关闭端发送关闭向向主动关闭端发送请求，主动关闭端接受被动关闭端发送请求，主动关闭端发出报文，关闭连接，被动关闭端接收到报文后关闭连接

7、发送Requests

1、请求地址

2、请求方法

3、请求头

4、请求参数（可能有，也可能没有）

7.1Response回复：

1、协议状态码 2、响应数据 3、响应头