c2c网站怎么做,网站开发 京东,德州最新通知,搭建服务器多少钱文章目录网络传输可靠性将微服务控制下沉到网络栈#xff1f;Sidecar从 Sidecar 到 Service MeshService Mesh 部署平台参考网络传输可靠性
从计网的学习过程中我们可以知道数据在网络传输中可能会出现一些异常状况#xff1a;
数据丢失#xff1a;数据包可能会到达一个缓…
文章目录网络传输可靠性将微服务控制下沉到网络栈Sidecar从 Sidecar 到 Service MeshService Mesh 部署平台参考网络传输可靠性
从计网的学习过程中我们可以知道数据在网络传输中可能会出现一些异常状况
数据丢失数据包可能会到达一个缓冲区已经被塞满的路由器接着被丢掉顺序出错一组数据包可能会途径闲忙程度不同的多个路由器出现不同程度的延迟最后到达顺序会与发出时的顺序不一致
这些丢包重发、顺序重组等控制机制已经由网络协议栈帮我们实现好了使开发人员更加关注业务层次 在微服务架构中则需要引入更多的机制来保障整体的可靠性
Service Discovery 机制通过服务注册查询机制让一个微服务能够找到另一个从而允许动态伸缩、以及故障转移熔断机制Circuit Breaker pattern提供断路保护就像电表跳闸防止某个服务不可用引发级联故障比如操作不成功导致疯狂重试请求堆积甚至耗尽相关资源系统中不相关的部分也因此出现故障
同样这部分工作早期也是由微服务来完成的与业务逻辑并存于微服务中 紧接着出现了Finagle、Proxygen等开源类库由专门的类库来完成这些工作而不必在每个服务中重复相同的控制逻辑 然而随着系统中服务数量的增多这种方式也暴露出了一些问题
胶水部分的资源投入需要投入资源将第三方库与系统其余部分连接起来类库限制了微服务的技术选型这些类库通常是特定于平台的仅支持特定运行时或编程语言会给微服务的技术选择造成限制。毕竟微服务的一大特点就是允许使用不同的编程语言来编写不同服务类库的维护成本类库本身也需要持续维护升级每次更新都需要重新部署所有服务即便服务没有任何改动
这样看来类库似乎不是个理想的解决方案. 既然在应用层解决不太合适那么能否如法炮制下沉到网络栈呢
将微服务控制下沉到网络栈
与通用的基础通信机制不同这些应用服务相关的控制机制很难交由下层网络栈来实现照搬下沉行不通。
Sidecar
不能在服务里面也不能在下面所以最后放到了旁边 即通过代理来实现这些网络控制所有出入流量都经过代理称之为 Sidecar。 Sidecar 作为辅助进程随应用程序运行在一旁并为其提供额外的功能。 问题似乎已经通过网络代理完美解决了业界也出现了一些开源方案Nerve 和 Synapse 基于ZookeeperPrana 基于Eureka
从 Sidecar 到 Service Mesh
Sidecar 方案都建立在特定的基础组件之上而我们需要的是一种基础组件无关的解决方案这种模型叫做 Service Mesh 如果给每个服务配套一个代理 Sidecar服务间仅通过代理互相通信最终得到了类似这样的部署模型 即代理之间相互连接形成了一个网状网格称之为 Service Mesh服务网格
服务网格是处理服务到服务通信的专用基础结构层。
它负责通过复杂的服务拓扑结构可靠地传递请求这些服务构成了一个现代的云本地应用程序。具体的Service Mesh 能够提供Service Discovery、负载均衡、加密、观察/跟踪、身份验证和授权以及熔断机制等支持。 从 Sidecar 到 Service Mesh关键在于以更高的视角看待这一个个代理发现它们形成的网络所具有的价值
Service Mesh 部署平台
Service Mesh 很自然地与掌控着 Service 的部署平台擦出了火花如Istio Kubernetes进而衍生出了控制层Control Plane让这层基础设施变得配置化 并最终形成了控制层 数据层的上下结构 其中管理实例间网络流量的部分称为数据层Data Plane数据层的行为由控制层Control Plane生成的配置项来控制而控制层一般会提供 API、CLI 以及 GUI 等多种方式管理应用
参考
http://www.ayqy.net/blog/service-mesh/
