微服务太多怎么办？简单聊聊微服务治理( 二 ) _微服务

文章插图

服务治理服务调用客户端的服务发现与治理的类UML图如下：

文章插图

服务治理平台管理各服务的资源组，并把核心业务独立出单独的资源组进行管理。监控各服务调用的压力、平均耗时、错误数、调用趋势等信息，并可以对单个服务的超时、限流、降级、资源池、负载均衡策略进行都动态调整。
资源隔离对服务调用实行线程池隔离，避免不同的服务失败导致线程被耗尽产生故障传播，对于部分核心流程如登录、注册、商品信息、下单支付等可在原线程隔离基础上再隔离出单独的线程池，保障核心业务不受影响。
熔断可对不同的接口请求应用不同的超时策略，超时后直接熔断走服务降级逻辑，避免服务被拖垮。依赖服务异常次数超限后直接熔断，通过hystrix定时检查服务是否恢复。
降级在服务调用失败、超时、熔断器开路、线程池或信号量容量超额，服务执行后备逻辑，支持服务的failfast和failsafe等容错。
限流基于网关的服务限流措施，可结合Nginx限流使用，避免流量高峰期的系统过载过高，影响核心业务的运行。
负载均衡策略可对不同的服务应用不同的负载均衡策略，可选择轮询、加权轮询、随机、本地优先和最小活跃数等策略。

文章插图

Service MeshService Mesh（服务网格）是一个基础设施层，用于处理服务间通信。Service Mesh 实际上就是处于 TCP/IP 之上的一个抽象层。在实际应用当中，Service Mesh 通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但应用程序不需要知道它们的存在。Service Mesh 是一种新的服务治理思想，它是把对服务的治理由应用层下沉到基础服务层。

文章插图

Service Mesh作为一个独立的代理进程部署在每一台主机上，主机上的多个服务消费者（Consumer）应用可以共用这个代理来实现服务发现和负载均衡。
Service Mesh将负责服务发现、负载均衡、熔断限流等相关逻辑从原有的消费客户端进程拆分到单独的代理进程中，由这个独立部署的代理来负责服务发现、路由分流（负载均衡）、熔断限流、安全控制、监控等功能。

文章插图

Service mesh 有如下几个特点：

应用程序间通讯的中间层
轻量级网络代理
应用程序无感知
解耦应用程序的重试、超时、监控、追踪和服务发现

目前Service Mesh的开源解决方案有：Buoyant 公司推出的 Linkerd 和 google、IBM 等厂商牵头的 Istio 。Linkerd 更加成熟稳定些，Istio 功能更加丰富、设计上更为强大，社区相对也更加强大一些。
本文转载于博客园，原文：https://www.cnblogs.com/qingfengEthan/p/12633149.html