微服务架构
微服务的核心思想便是应用功能拆分与解耦，降低业务系统实现复杂性。微服务强调将应用功能拆解为一组松耦合服务，每个服务遵守单一责任原则。微服务架构解决了传统单体式架构存在的几个固有问题：每个服务可以独立部署和交付，大大提升了业务敏捷性；每个服务可以独立横向扩展、收缩，应对互联网规模的挑战。
微服务架构回归了去中心化的点对点调用方式，在提升敏捷性和可伸缩性的同时，也牺牲了业务逻辑和服务治理逻辑解耦所带来的灵活性。
现有微服务框架痛点
- 侵入性强：想要集成 SDK 的能力，除了需要添加相关依赖，往往还需要在业务代码中增加一部分的代码、或注解、或配置；业务代码与治理层代码界限不清晰。
- 升级成本高：每次升级都需要业务应用修改 SDK 版本，重新进行功能回归测试
- 版本碎片化严重：由于升级成本高，而中间件却不会停止向前发展的步伐，久而久之，就会导致线上不同服务引用的 SDK 版本不统一、能力参差不齐，造成很难统一治理。
- 中间件演变困难：由于版本碎片化严重，导致中间件向前演进的过程中就需要在代码中兼容各种各样的老版本逻辑，带着 “枷锁” 前行，无法实现快速迭代。
- 内容多、门槛高：Spring Cloud 被称为微服务治理的全家桶，包含大大小小几十个组件，内容相当之多，往往需要几年时间去熟悉其中的关键组件。而要想使用 Spring Cloud 作为完整的治理框架，则需要深入了解其中原理与实现，否则遇到问题还是很难定位。
- 治理功能不全：不同于 RPC 框架，Spring Cloud 作为治理全家桶的典型，也不是万能的，诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。
服务网格（service mesh）
服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，Service Mesh 通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。
Service Mesh的特点
- 应用程序间通信的中间层
- 轻量级网络代理
- 应用程序无感知
- 解耦应用程序的重试/超时、监控、追踪和服务发现
理解 Service Mesh
-
应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控。
-
什么是Sidecar
将应用程序的功能划分为单独的进程，就是Sidecar模式,在服务网格中，一般在业务容器生成的时候，会生成一个对应的伴生容器，用于接管业务容器的所有流量，并可以对这些流量进行管控。
Service Mesh如何工作
- Sidecar将服务请求路由到目的地址，根据请求中的参数判断是到生产环境、测试环境还是 staging 环境中的服务（服务可能同时部署在这三个环境中），是路由到本地环境还是公有云环境？所有的这些路由信息可以动态配置，可以是全局配置也可以为某些服务单独配置。
- 当 sidecar 确认了目的地址后，将流量发送到相应服务发现端点，在 Kubernetes 中是 service，然后 service 会将服务转发给后端的实例。
- Sidecar 根据它观测到最近请求的延迟时间，选择出所有应用程序的实例中响应最快的实例。
- Sidecar 将请求发送给该实例，同时记录响应类型和延迟数据。
- 如果该实例挂了、不响应了或者进程不工作了，sidecar 会将把请求发送到其他实例上重试。
- 如果该实例持续返回 error，sidecar 会将该实例从负载均衡池中移除，稍后再周期性得重试。
- 如果请求的截止时间已过，sidecar 主动标记该请求为失败，而不是再次尝试添加负载。
- SIdecar 以 metric 和分布式追踪的形式捕获上述行为的各个方面，这些追踪信息将发送到集中 metric 系统。
Service Mesh的优势
- 微服务架构的一些公共组件已经是现成的
- 使用最好的工具和编程语言，而无需担心不同平台对软件库和模式的支持存在差异。
服务网格带来的变革
- 微服务治理与业务逻辑的解耦。
服务网格把 SDK 中的大部分能力从应用中剥离出来，拆解为独立进程，以 sidecar 的模式进行部署。服务网格通过将服务通信及相关管控功能从业务程序中分离并下沉到基础设施层，使其和业务系统完全解耦，使开发人员更加专注于业务本身。
- 异构系统的统一治理。
随着新技术的发展和人员更替，在同一家公司中往往会出现不同语言、不同框架的应用和服务，为了能够统一管控这些服务，以往的做法是为每种语言、每种框架都开发一套完整的 SDK，维护成本非常之高，而且给公司的中间件团队带来了很大的挑战。有了服务网格之后，通过将主体的服务治理能力下沉到基础设施，多语言的支持就轻松很多了。只需要提供一个非常轻量级的 SDK，甚至很多情况下都不需要一个单独的 SDK，就可以方便地实现多语言、多协议的统一流量管控、监控等需求。
服务网格相对于传统微服务框架的三大优势
- 可观察性。
服务网格是一个专用的基础设施层，所有的服务间通信都要通过它，所以它在技术堆栈中处于独特的位置，以便在服务调用级别上提供统一的遥测指标。
- 流量控制。
通过 Service Mesh，可以为服务提供智能路由（蓝绿部署、金丝雀发布、A/B test）、超时重试、熔断、故障注入、流量镜像等各种控制能力。
- 安全。
在某种程度上，单体架构应用受其单地址空间的保护。然而，一旦单体架构应用被分解为多个微服务，网络就会成为一个重要的攻击面。更多的服务意味着更多的网络流量，这对黑客来说意味着更多的机会来攻击信息流。而服务网格恰恰提供了保护网络调用的能力和基础设施。服务网格的安全相关的好处主要体现在以下三个核心领域：服务的认证、服务间通讯的加密、安全相关策略的强制执行。
Istio
Istio简介
Istio是一个开源平台，提供了对整个服务网格的行为洞察和控制能力，是一个服务网格的完整解决方案。通过Sidecar的模式为每一个业务容器注入一个伴生容器，伴生容器接管了所有的流量处理，以做到无侵入的服务治理实现。
Istio架构图
Istio核心功能
数据平面
在数据平面由多个服务代理（通过 Envoy）组成，而微服务之间Sidecar的通信是通过 策略控制和遥测收集 （通过 Mixer ）实现。
控制平面
在控制平面通过Pilot ， Citadel 和 Galley 管理和配置Sidecar代理之间的通信。Citadel 用于密钥和证书管理。Pilot 将授权策略和安全命名信息分发给代理 — 主要用于服务发现和服务配置(服务访问规则维护)，Pilot中的adapter机制可以适配各种服务发现组件（Eureka、Consul、Kubenetes）,最好的是Kubernetes。Galley 验证规则（Pilot、Mixer、Citadel配置的规则）。
Istio核心能力
- 通过身份验证和授权来保护服务间通信。
- 支持访问控制，资源配额和资源分配的策略层。
- 支持HTTP，gRPC，WebSocket和TCP通信的负载均衡。
- 集群内所有流量的度量，日志和跟踪，包括集群的入口和出口。
- 通过故障转移，故障注入和路由规则，来配置和控制服务间通信。
