共计 2484 个字符，预计需要花费 7 分钟才能阅读完成。
作者：Sudip Sengupta
翻译：Bach（才云）
校对：bot（才云）、星空下的文仔（才云）
微服务 会将应用程序合成为多个较小的服务组件。与传统的一体化（Monolithic）架构相比，微服务架构将每个微服务视为独立的实体与模块，从根本上有助于简化代码和相干基础架构的保护。应用程序的每个微服务都能够编写在不同的技术堆栈中，并且能够进一步独立地部署、优化和治理。
从实践上讲，微服务体系结构特地有利于简单的大型应用程序的构建，但实际上，它也被宽泛用于小型应用程序的构建。
微服务架构的益处
- 能够通过不同的技术堆栈开发和部署应用程序中的各个微服务。
- 每个微服务都能够独立优化、部署或扩大。
- 更好的故障解决和谬误检测。
K8sMeetup
微服务架构的组件
在微服务架构上运行的古代云原生应用程序依赖于以下要害组件：
- 容器化（通过相似 Docker 的平台）：通过将服务分为多个过程进行治理和部署。
- 编排（通过相似 Kubernetes 的平台）：配置、调配、治理服务的系统资源。
- 服务网格（通过相似 Istio 的平台）：通过服务代理网格进行服务间通信，以连贯、治理、爱护微服务。
以上三个是微服务架构中最重要的组件，这些组件容许云原生堆栈中的应用程序在负载下扩大，甚至在云环境局部故障期间也能执行。
K8sMeetup
微服务架构的复杂性
大型应用程序被合成为多个微服务时，每个微服务都应用不同的技术堆栈（开发语言、数据库等），因而咱们须要把这些环境组成一个简单的体系结构进行治理。只管曾经将每个微服务划分为独自 Docker 容器中运行的多个过程，以此来帮忙治理和部署单个微服务，但 因为咱们必须解决整体零碎运行状况、容错和故障点，服务间通信依然非常复杂。
咱们能够通过购物车在微服务架构上工作的例子来进一步理解。这里微服务将与库存数据库、领取网关服务、基于客户拜访历史的产品倡议算法等无关。只管从实践上讲，这些服务依然是独立的微型模块，但它们的确须要彼此交互。
K8sMeetup
为什么咱们须要服务网格？
微服务体系结构中服务到服务通信十分重要，那么很显著，通信通道须要确保无故障、平安、高可用性和健壮性。这些是 服务网格作为根底结构组件呈现的中央，它通过实现多个服务代理来确保服务到服务的通信。服务网格不负责增加新性能，但能够微调不同服务之间的通信。
在服务网格中，与单个服务一起部署的代理能够实现服务之间的通信，这被宽泛称为 边车（Sidecar）模式。边车模式有着解决服务间通信的重要性能，例如负载平衡、断路、服务发现等。
通过服务网格，咱们能够：
- 保护、配置、爱护应用程序中所有或选定微服务之间的通信。
- 在微服务中配置和执行网络性能，例如网络弹性、负载平衡、网络中断、服务发现等。
- 网络性能与业务逻辑拆散，为独自实体，因而开发人员能够专一于应用程序的业务逻辑，而与网络通信相干的大部分工作都由服务网格来解决。
- 因为微服务到服务的代理通信始终应用诸如 HTTP1.x/2.x、gRPC 等标准协议，因而开发人员能够应用任何技术来开发单个服务。
K8sMeetup
服务网格架构的组件
业务逻辑
业务逻辑蕴含了微服务的外围利用程序逻辑、根底代码、应用程序的计算以及服务到服务的集成逻辑。微服务架构的劣势就是能够在任何平台上编写业务逻辑，并且业务逻辑齐全独立于其余服务。
根本网络性能
根本网络性能包含发动网络申请和连贯服务网格代理。只管微服务中的次要网络性能是通过服务网格来解决的，然而给定的服务必须蕴含根本网络性能能力与 Sidecar 代理连贯。
利用网络性能
与根本网络性能不同，该组件通过服务代理保护和治理要害的网络性能，包含网络中断、负载平衡、服务发现等。
服务网格管制立体
所有服务网格代理都由管制立体集中管理和管制。通过管制立体，咱们能够指定身份验证策略、度量规范生成，并在整个网格中配置服务代理。
K8sMeetup
应用 Istio 施行服务网格
只管有其余服务网格，但 Istio 是最受欢迎的，上面咱们看看如何将 Istio 用于云原生应用程序的服务网格架构。
如上文所述，在微服务体系结构中，Istio 会通过造成根底结构层以连贯、爱护和管制分布式服务之间的通信。Istio 会在每个服务旁边部署一个 Istio 代理（称为 Istio sidecar），但该服务自身的代码很少有更改。所有服务间的流量都定向到 Istio 代理，该代理应用策略管制服务间通信，同时施行部署、故障注入和断路器的根本策略。
Istio 的外围能力
- 通过身份验证和受权来爱护服务间通信。
- 反对访问控制、配额和资源分配的策略层。
- 反对 HTTP、gRPC、WebSocket 和 TCP 通信的主动负载平衡。
- 集群内所有流量的主动指标、日志和跟踪，包含集群的入口和进口。
- 通过故障转移、故障注入和路由规定配置和管制服务间通信。
Istio 不依赖任何平台，这意味着它能够在多种环境中运行，包含云、本地、Kubernetes 等。Istio 以后反对：
- Kubernetes 上的服务部署
- 在 Consul 注册的服务
- 在单个虚拟机上运行的服务
外围 Istio 组件
图像源：istio.io
Istio 服务网格由 数据立体（data plane）和 管制立体（control plane）组成。
- 在 数据立体 由多个服务代理（通过 Envoy）组成，而微服务之间 Sidecar 通信是通过策略和遥测收集（通过 Mixer）实现。
- 在 管制立体 通过 Pilot、Citadel 和 Galley 治理和配置 Sidecar 代理之间的通信。Citadel 用于密钥和证书治理。Pilot 将受权策略和平安命名信息分发给代理，次要用于服务发现和服务配置(服务拜访规定保护)，Pilot 中的 adapter 机制能够适配各种服务发现组件（Eureka、Consul、Kubenetes），最好的是 Kubernetes。Galley 验证规定（Pilot、Mixer、Citadel 配置的规定）。
管制立体对数据立体组件进行治理和保护，这造成了 Istio Service Mesh 最重要的层。
原文地址：https://mp.weixin.qq.com/s/xPyXBvp_-e-1ODAapDgWHw
