背景
微服务是什么
微服务的优势
微服务带来的挑战
微服务架构和单体架构的对比
什么是微服务治理
微服务之间一旦建立起路由，就意味着会有数据在服务之间流通。由于不同服务可以提供的资源和对数据流量的承载能力不尽相同，为了防止单个 Consumer(消费者) 占用 Provide(生产者） 过多的资源，或者突发的大流量冲击导致 Provider 故障，需要服务限流来保证服务的高可用。
在服务治理中，虽然可以通过限流规则尽量避免服务承受过高的流量，但是在实际生产中服务故障依然难以完全避免。当整个系统中某些服务产生故障时，如果不及时采取措施，这种故障就有可能因为服务之间的互相访问而被传播开来，最终导致故障规模的扩大，甚至导致整个系统奔溃，这种现象我们称之为“雪崩”。熔断降级其实不只是服务治理中，在金融行业也有很广泛的应用。比如当股指的波动幅度超过规定的熔断点时，交易所为了控制风险采取的暂停交易措施。
针对以微服务带来的方便以及挑战，从裸金属到虚拟化再到公有云，再到容器，到serverless，技术不断革新，应对微服务带来的挑战，如何对服务进行注册发现，请求链路追踪，负载均衡，服务熔断/降级，服务限流，访问控制，监控日志，配置管理，金丝雀发布呢
微服务治理istio
Service Mesh
Service Mesh 的中文译为“服务网格”，是一个用于处理服务和服务之间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求，并为服务通信实现了微服务所需的基本组件功能，例如服务发现、负载均衡、监控、流量管理、访问控制等。在实践中，服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。
服务网格（Service Mesh）这个术语通常用于描述构成这些应用程序的微服务网络以及应用之间的交互。随着规模和复杂性的增长，服务网格越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标收集和监控以及通常更加复杂的运维需求，例如 A/B 测试、金丝雀发布、限流、访问控制和端到端认证等。
服务网格技术对企业现有分布式系统架构的影响主要体现在系统分层和能力下沉。传统微服务框架以 RPC 框架为基础，提供服务目录、注册发现、服务治理、流量管理、配置中心、全链路追踪等核心能力，并且向外延伸到安全审计、监控告警、统计分析、知识库等平台化能力，服务网格技术要做的事情就是把这些微服务架构支撑能力下沉到 Sidecar 里，并且在这个改造过程中不中断业务。要做到这个过程平滑，除了在服务网格数据面和控制面组件中对服务注册发现、RPC 协议、配置下发进行扩展之外，还要对现有的上层的研发工作台、运维效能平台等支撑平台进行兼容。
Istio 提供了一个完整的解决方案，通过为整个服务网格提供行为洞察和操作控制来满足微服务应用程序的多样化需求。
Service Mesh 部署网络结构图:
Service Mesh有四大特点：
如此一来，Service Mesh将业务模块和服务治理分开。
从上图中看到，控制面和数据面分离，应用在部署的时候，每个应用附带一个SideCar，这个SideCar是拦截每一个应用对外请求的。同时控制面的服务治理策略下到SideCar中具体的执行，这样的话，即使业务模块升级和服务治理的升级也能互不影响的，还能动态调整服务治理的规则和策略。
从Service Mesh的结构和特点，可以总结出其对于服务治理的理念：
以Service Mesh的杰出代表Istio为例来聊聊最新的服务治理的架构，它对Service Mesh完全支持，架构清晰，拆分数据面、控制面；拥有通信、安全、控制、观察等功能，实现开放，且插件化，多种可选实现。
Istio可结合K8S使用，K8S提供服务生命周期的管理，Istio在K8S之上实现服务治理的整体的功能。
Istio 概述
Isito是Service Mesh的产品化落地，是目前最受欢迎的服务网格，功能丰富、成熟度高。 Linkerd是世界上第一个服务网格类的产品
中文文档地址：https://istio.io/latest/zh/docs/
Istio 近几个版本持续演进的方向：把控制面组件合并为 istiod 和完善 istioctl 的集群生命周期管理能力来降低运维复杂性；将 Mixer 组件能力下沉到 Sidecar 降低服务东西向网络延时；增加对虚拟机的原生支持，便于非容器化业务平滑迁移……等等，这其中的每一项都是业务生产落地 Istio 时面临的痛点问题。
主要有以下特点
- 流量管理
- 负载均衡
- 灰度发布
- 动态路由
- 故障注入
- 认证
- 鉴权
- 限流
- ACL
- 监控
- 调用链
主要应用于服务治理：
Isito 架构与组件
◆ 性能总结
Istio 负载测试网格包含了 1000 个服务和 2000 个 sidecar，全网 格范围内，QPS 为 70,000。 在使用 Istio 1.6.2 运行测试后，我们 得到了如下结果：
• 通过代理的 QPS 有 1000 时，Envoy 使用了 0.5 vCPU 和 50 MB 内存。
• 网格总的 QPS 为 1000 时，istio-telemetry 服务使用了 0.6 vCPU。
• Pilot 使用了 1 vCPU 和 1.5 GB 内存。
• 90% 的情况 Envoy 代理只增加了 6.3 ms 的延迟
注：此页中图片和数据引用自Istio官网
东西南北流量
先看一张图
在Service Mesh微服务架构中，我们常常会听到东西流量和南北流量两个术语。
南北流量（NORTH-SOUTH traffic）和东西流量（EAST-WEST traffic）是数据中心环境中的网络流量模式。下面通过一个例子来理解这两个术语。
假设我们尝试通过浏览器访问某些Web应用。Web应用部署在位于某个数据中心的应用服务器中。在多层体系结构中，典型的数据中心不仅包含应用服务器，还包含其他服务器，如负载均衡器、数据库等，以及路由器和交换机等网络组件。假设应用服务器是负载均衡器的前端。
当我们访问web应用时，会发生以下类型的网络流量：
南北流量
在这个例子中，前者即客户端和服务器之间的流量被称为南北流量。简而言之，南北流量是server-client流量。
东西流量
第二种流量即不同服务器之间的流量与数据中心或不同数据中心之间的网络流被称为东西流量。简而言之，东西流量是server-server流量。
当下，东西流量远超南北流量，尤其是在当今的大数据生态系统中，比如Hadoop生态系统（大量server驻留在数据中心中，用map reduce处理），server-server流量远大于server-client流量。
该命名来自于绘制典型network diagrams的习惯。在图表中，通常核心网络组件绘制在顶部（NORTH），客户端绘制在底部（SOUTH），而数据中心内的不同服务器水平（EAST-WEST）绘制。