微服务架构Istio学习笔记1——发展历史

转自《从分布式到微服务，深挖Service Mesh》以下是重点记录

发展历史

• 原始阶段，服务直连
• 随着技术发展，计算和网络异步的问题显现，网络协议栈从服务中单独分离出来

流量控制

• 服务之间可能无法实时同步，存在阻塞等问题
• 随着TCP/IP的出现，流量控制被加入到网络协议栈中，并与服务分离开
• 流量控制用于防止在端口阻塞的情况下丢帧，这种方法是当发送或接收缓冲区开始溢出时通过将阻塞信号发送回源地址实现的。流量控制可以有效的防止由于网络中瞬间的大量数据对网络带来的冲击，保证用户网络高效而稳定的运行。

TCP/IP协议面临的问题

• 计算资源的快速提供
• 基本的监控
• 快速部署
• 易于扩展的存储
• 可轻松访问边缘
• 认证与授权
• 标准化的RPC

服务发现

• 服务发现是在满足给定查询条件的情况下自动查找服务实例的过程
• 通过调用一些服务发现进程，返回一个满足条件的服务列表
• 通常使用DNS、负载均衡器和一些端口号的约定（例如，所有服务将HTTP服务器绑定到8080端口）来实现
• 但在分布式系统中，服务发现变得复杂

断路器

• 断路器将一个受保护的函数调用包含在用于监视故障的断路器对象中
• 一旦故障达到一定阈值，则断路器跳闸，并且对断路器的所有后续调用都将返回错误，并完全不接受对受保护函数的调用
• 通常，如果断路器发生跳闸，你还需要某种监控警报
• 但在分布式系统中，情况变得复杂，一个组件中的一个故障可能会在许多客户端和客户端的客户端上产生连锁反应，从而触发数千个电路同时跳闸

新的逻辑

• 使用高级协议（如HTTP）编写非常复杂的应用程序和服务，无需考虑TCP是如何控制网络上的数据包的
• 解决方案是通过一组代理来实现。这个的想法是，服务不会直接连接到它的下游，而是让所有的流量都将通过一个小小的软件来透明地添加所需功能
• 在这个领域第一个有记载的进步使用了边三轮（sidecars）这个概念。“边三轮”是一个辅助进程，它与主应用程序一起运行，并为其提供额外的功能
  

Service mesh

• Service mesh架构中为每个服务都配备了一个Sider car，其部署架构图如下
  

• service mesh是用于处理服务到服务通信的专用基础设施层

• 它负责通过复杂的服务拓扑来可靠地传递请求

• service mesh常被实现为与应用程序代码一起部署的轻量级网络代理矩阵，并且它不会被应用程序所感知

• service mesh的整体架构如下
  

• 实际的服务流量仍然直接从代理流向代理，但是控制面知道每个代理实例

• 控制面使得代理能够实现诸如访问控制和度量收集这样的功能