架构演进
发展历程
我们再来回顾一下架构发展历程，从前往后的顺序依次为单机小型机->垂直拆分->集群化负载均衡->服务化改造架构->服务治理->微服务时代
- 单机小型机：采用典型的单机+数据库模式，将所有功能写在一个应用程序进行集中部署。
- 垂直拆分：随着应用的日益复杂和多样性，对系统容灾、伸缩和业务响应能力有了更高的要求。单机小型机架构中如果小型机和数据库任何一个出现故障或宕机，整个系统都会奔溃；若某个板块的功能需要更新，那么整个系统也需重新发布，显然这在业务快速发展的万物互联网时代是不被允许的。需要将系统进行拆分，拆分为多个子应用。
- 优点：应用和应用解耦，系统容错提高了，也解决了独立应用发布的问题。
-
集群化负载均衡：随着用户数量的增加，单个小型机的计算能力依旧是杯水车薪，无法应对业务的增加的需要。且小型机的价格比较昂贵，维护成本较高。在此时更优的选择是采用多台PC机部署同一个应用的方案，考虑到客户端不知道那个请求需要落在哪一个后端PC应用上，因此引入负载均衡的机制。负载均衡思想是对外暴露一个统一的接口，根据用户请求进行相应规则的转发，而这样后端的应用可以根据流量的大小进行动态扩容或者成为水平扩展。国内阿里巴巴在2008年提出去IOE（也即为IBM小型机、Oracle数据库、EMC存储），全部改为集群负载均衡架构，到2013年最后一批IBM小型机下线。
- 负载均衡主要分为硬件层面和软件层面均衡：
- 硬件层面负载均衡常用的如F5。
- 软件负载均衡如LVS、Nginx、Haproxy。
- 优点：在垂直拆分优点基础上增加水平扩展来支持大流量业务。
- 负载均衡主要分为硬件层面和软件层面均衡：
-
服务化改造架构：虽然有垂直拆分，但是拆分之后发现论坛和聊天室中有重复功能，比如登录、用户注册、发邮件等等，重复功能会造成资源的浪费，因此服务化改造会把重复的功能抽取出来做成Service服务的形式来调用，为了解决服务之间的相互调用就有了RPC（远程调用）的通信协议，作用就是让服务之间的调用就像本地调用一样的简单。
- 优点：在前面基础解决业务重用的问题。
-
服务治理：随着业务增加，基础服务也越来越多，服务之间调用关系越来越错综复杂，对此有了服务治理的需求。服务治理基本要求如下，基于Java技术栈在这一阶段典型的框架有Dubbo，默认采用Zookeeper作为注册中心。
- 当服务数量几十上百个的时候，需要对服务有动态的感知，因此引入注册中心。
- 当服务的调用链路很长的时候如何实现链路的监控。
- 单个服务的异常如何能避免整条链路的异常或雪崩，需要考虑熔断、限流、降级等机制。
- 服务的高可用，服务负载均衡。
-
微服务时代:微服务希望一个只负责一个独立的功能并可以做到独立部署和运维。比如用户中心，对于为服务来说还可以分为卖家服务、卖家服务、商家服务等。基于Java技术栈这一阶段典型的代表就是SpringCloud，默认使用HTTP协议作为RPC，增加分布式配置中心、分布式事务、分布式消息队列等融合。
- Spring Cloud Alibaba组件：
- Nacos:服务注册和发现、配置中心:可以向阿里巴巴Nacos注册实例，客户端可以使用spring管理的bean发现实例。支持Ribbon，通过Spring Cloud Netflix的客户端负载均衡器，分布式配置使用阿里巴巴Nacos作为数据存储。
- Sentinel:流量控制和服务降级:阿里巴巴Sentinel流量控制、断路和系统自适应保护。
- Seata:一种高性能、易于使用的分布式事务解决方案，适用于微服务架构。解决微服务中的分布式事务问题。
- Dubbo与Spring Cloud Alibaba的整合:Dubbo为Apache Dubbo 是一款高性能、轻量级的开源服务框架，提供了六大核心能力：面向接口代理的高性能RPC调用，智能容错和负载均衡，服务自动注册和发现，高度可扩展能力，运行期流量调度，可视化的服务治理与运维。
- Spring Cloud Netflix Ribbon：客户端负载均衡器，Nacos客户端中已默认集成Ribbon。
- Spring-Cloud-OpenFeign：是一个声明式的伪RPC（Feign英文意思为“假装，伪装，变形”）的REST客户端，它用了基于接口的注解方式，可以以Java接口注解的方式调用Http请求，从而将请求模块化。
- Spring Cloud Gateway：提供了一个在Spring WebFlux上构建API网关的库，旨在提供一种简单而有效的方式来路由到api，并为它们提供横切关注点，如安全性、监控/指标和弹性。
- Apache SkyWalking：国产优秀开源的分布式系统的应用程序性能监控工具，特别为微服务，云本地和基于容器(Docker, Kubernetes, Mesos)架构设计。
- Spring Cloud Alibaba组件：
Service Mesh时代
上一张接着微服务时代继续说，之前文章也介绍SpringCloud Alibaba一站式微服务解决方案入门示例（后续文章我们会详细介绍相关的微服务组件），有了一定理解，但这些微服务存在以下问题，因此可以说Service Mesh概念提出的初衷就是来解决这些问题的。
- 侵入性太强：比如基于Java技术栈主流的SpringCloud Alibaba也需要引用各类微服务组件如配置中心、注册中心、网关、限流、分布式事务等starter依赖，有些还需在启动类开启使用、配置文件配置、注解等，与我们微服务业务模块耦合绑定在一起，有可能因为微服务组件的版本兼容问题影响整个微服务模块。
- 多语言支持：不能同时支持多种开发语言，对于团队要求统一语言太苛刻。
- 学习框架成本太高：虽然目前如SpringCloud Alibaba对于使用者来说还算比较简单的，但是还是需要理解微服务架构、组件原理和应用、开发等，一整套下来学习成本也很高。
- 框架版本升级：主流微服务框架目前更新迭代速度较快，适应版本升级带来额外的工作量。
Service Mesh解决思路
- 本质上就是要解决服务之间的通信问题，不应该将非业务的代码融入业务代码当中。服务之间通信如服务发现、负载均衡、版本控制等等。
- 客户端发起请求要能顺利到达对应的服务，在这中间的网络通信要尽量和业务代码无关。
简单介绍Sidecar
Sidecar降低了与微服务架构相关的复杂性，并且提供负载均衡、服务发现、流量管理、电路中断、故障注入等特点。该种模式允许向应用无侵入的添加多种功能，避免为满足第三方组件需求而对应用添加额外的配置代码。其借鉴了Proxy代理模式，代表产品有 Lyft 构建的Envoy、Netflix的Prana。
Sidecar为了通用基础设置而设计，服务的业务代码与Sidecar绑定在一起，每个服务配置一个Sidecar代理，每个服务所有流量都要经过Sidecar,控制服务流量的进出，Sidecar帮我们屏蔽通信的细节，开发人员只需关注业务代码实现，通信的工作就交由Sidecar处理，做到与技术框架无侵入性。
Envoy
Envoy是一个开源的边缘和服务代理，专为云本地应用设计用于云原生应用，云原生基金会 CNCF 项目。 最初是在 Lyft 构建的，它是为单一服务和应用程序设计的高性能 C++ 分布式代理，以及为大型微服务 Service Mesh 体系结构设计的通信总线和通用数据平面。目前最新版本为1.21.1.特点：
-
Envoy是为大型现代面向服务架构设计的L7代理和通信总线，Envoy是一个自包含的进程，旨在与每个应用程序服务器一起运行。所有的envoy都形成了一个透明的通信网络，每个应用程序在其中向本地主机发送和接收消息，并且不知道网络拓扑。
- 适用于任何应用语言。一个Envoy部署可以在Java、c++、Go、PHP、Python等之间形成一个网格。面向服务的体系结构使用多个应用程序框架和语言越来越普遍。
- 可以在大型面向服务体系结构的整个基础设施上透明地快速部署和升级，解决部署库升级的痛苦问题。
-
L3/L4 filter architecture
-
HTTP L7 filter architecture
-
First class HTTP/2 support
-
HTTP/3 support (currently in alpha):
-
HTTP L7 routing
-
gRPC支持
-
服务发现和动态配置
-
运行状况检查
-
负载平衡
-
前/边缘代理支持
-
最好的观察性
什么是Service Mesh？
Service Mesh（服务⽹格）是一种控制应用程序不同部分彼此共享数据的方式，旨在以减少管理和编程开销的形式来连接微服务。主要目的是让开发⼈员更专注的聚焦到业务上，以代码无侵入形式实现微服务中的服务发现、服务注册、负载均衡等常用功能。Service Mesh的核心思想是将为微服务提供通信服务的这部分逻辑从应⽤程序进程中抽取出来，作为⼀个单独的进程进⾏部署，并将其作为服务间的通信代理当服务⼤量部署时，随着服务部署的Sidecar（边⻋，很形象的翻译）代理之间的连接形成⽹格结构并成为了微服务的通讯基础设施层，承载了微服务之间的所有流量。
特点：基础设施、云原生、网络代理、对应用透明
Linked项目
Buoyant公司的Linked为第一个意义上的Service Mesh项目，由Twitter开发，很好结合了K8S的云原生概念，无侵入业务代码就能管理服务的流量，兼容K8S提供全部功能。设计思想如下图：
但Linked部署较为繁琐，且只是实现数据层面的问题，缺乏对于数据层的管理。国外Service Mesh产品发展还是非常迅猛的，NginxMesh，F5的AspenMesh、HashiCorp的Consul Connect、Kong、AWS的AppMesh和微软发起的一项标准化各种服务网格接口的倡议SMI。后面我们再来说说Istio-毫无疑问当前最主流的ServiceMesh产品。
国内ServiceMesh发展
这里我们也提一下国内在ServiceMesh方向上实践的一些公司，有时间也可以去了解下
- 蚂蚁金服的SofaMesh
- 腾讯的Tencent Service Mesh Framework,简称 TSF Mesh，选择的Sidecar是Envoy
- 华为 Mesher 与 ASM
- 阿里Dubbo Mesh
- 网易云轻舟微服务推出的Service Mesh平台
- 小红书ServiceMesh落地与Aeraki 组件优化扩展
Istio
概述
Istio官网地址 https://istio.io/
Istio GitHub地址 https://github.com/istio
ServiceMesh：现代应用程序通常被架构为分布式的微服务集合，每个微服务集合执行一些的业务功能。服务网格是一个专用的基础设施层，可以添加到应用程序中。它允许您透明地添加如可观察性、流量管理和安全性等功能，代码无侵入。“服务网格”描述了用于实现该模式的软件类型，以及在使用该软件时创建的安全或网络域。
随着分布式服务(比如基于kubernetes的系统)的部署规模和复杂性的增长，它可能会变得更难理解和管理，如服务发现、负载平衡、故障恢复、指标和监控。服务网格还可处理更复杂的操作需求如A/B测试、金丝雀部署、速率限制、访问控制、加密和端到端身份验证。
服务到服务通信使得分布式应用程序成为可能，随着服务数量的增长，在应用程序集群内部和跨应用程序集群路之间的通信变得越来越复杂，Istio有助于降低这些部署的复杂性，并减轻开发团队的压力。
Istio是由Google、IBM和Lyft共同发起的开源服务网格项目，由go语言编写，但又不仅仅是服务网格那么简单。Istio的目的是解决当单体应用程序向分布式微服务架构过渡时开发人员和运营商所面临的挑战。Istio透明地分层到现有的分布式应用程序上，通过在部署的每个应用程序中添加代理“sidecar”，Istio允许您在网络中编程应用程序感知的流量管理、不可思议的可观察性和健壮的安全功能；能够成功且高效地运行分布式微服务架构，并提供保护、连接和监控微服务的统一方法。Istio提供了对整个服务网格的行为洞察和操作控制的能力，以及一个完整的满足微服务应用各种需求的解决方案。
为何使用？
Istio 可以轻松地创建一个已经部署了服务的网络，比如实现负载平衡、服务到服务身份验证和监视的服务的代码只需很少更改甚至无需更改。Istio极大的减少了应用程序代码，底层平台和策略之间的耦合，使微服务更容易实现了！通过在整个环境中部署一个特殊的 sidecar 代理为服务添加 Istio 的支持，而代理会拦截微服务之间的所有网络通信，然后使用其控制平面的功能来配置和管理 Istio控制平面的特点：
- 为 HTTP、gRPC、WebSocket 和 TCP 流量自动负载均衡。
- 通过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。
- 可插拔的策略层和配置 API，支持访问控制、速率限制和配额。
- 集群内（包括集群的入口和出口）所有流量的自动化度量、日志记录和追踪。
- 在具有强大的基于身份验证和授权的集群中实现安全的服务间通信。
Istio 为可扩展性而设计，可以满足不同的部署需求。
组成部分
Istio由数据平面和控制平面两部分组成：
- 数据平面：各业务之间的通信平面。如果没有服务网格，网络就无法理解发送过来的流量，也无法根据流量的类型来决定如何分发。Service mesh使用一个代理来拦截所有的网络流量。目前代理使用的Lyft的Envoy项目，它和集群中启动的每个服务一起部署，或者运行在每一个虚拟机服务。
- 控制平面：获取所需的配置及其服务视图，并动态地根据规则或环境对代理进行管理。
核心特性
- 流量管理：在单个集群内和跨集群路由流量都会影响性能，支持更好的部署策略。Istio 简单的规则配置和流量路由允许您控制服务之间的流量和 API 调用过程。Istio 简化了服务级属性（如熔断器、超时和重试）的配置，并且让它轻而易举的执行重要的任务（如 A/B 测试、金丝雀发布和按流量百分比划分的分阶段发布）。
- 可观察性：如何在服务复杂性环境监控服务调用和性能？Istio为服务网格内的所有通信生成详细的遥测技术。这种遥测技术提供了服务行为的可观察性，使操作员能够排除故障、维护和优化他们的应用程序，无侵入也即是不更改应用程序基础上使用所有这些工具。通过Istio，操作人员可以全面了解被监视的服务如何交互，包括详细的指标、分布式跟踪和完整的访问日志。Istio 健壮的追踪、监控和日志特性让您能够深入的了解服务网格部署。通过 Istio 的监控能力，可以真正的了解到服务的性能是如何影响上游和下游的；而它的定制 Dashboard 提供了对所有服务性能的可视化能力，可以看到与其他进程的影响关系。
- 安全功能：的安全特性解放了开发人员，使其只需要专注于应用程序级别的安全。Istio 提供了底层的安全通信通道，并为大规模的服务通信管理认证、授权和加密。有了 Istio，服务通信在默认情况下就是受保护的，可以让您在跨不同协议和运行时的情况下实施一致的策略——而所有这些都只需要很少甚至不需要修改应用程序。Istio提供了一个全面的安全解决方案，使运营商能够解决如防止中间人攻击、灵活的访问控制、审计工具和相互TLS的需求。它提供强大的身份和策略，透明的TLS加密，以及认证，授权和审计(AAA)工具来保护服务和数据。Istio的安全模型是基于默认安全的，旨在提供深入的防御，部署具有安全意识的应用程序，甚至跨越不可信的网络。
组件
Istio是一个开放平台，提供统一的方式来集成微服务、管理跨微服务的流量、执行策略和聚合遥测数据。Istio的控制平面在底层集群管理平台(如Kubernetes)上提供了一个抽象层，Istio由以下组件组成
- Envoy：每个微服务的Sidecar代理，用于处理集群中服务之间以及服务与外部服务之间的入口/出口流量。代理构成了一个安全的微服务网格，提供了一组丰富的功能，如发现、丰富的7层路由、断路器、策略实施和遥测记录/报告功能。
- Istiod - Istio控制平面。它提供服务发现、配置和证书管理。它由下列子组成部分组成
- Pilot ：负责在运行时配置代理。
- Citadel ：负责证书的签发和轮换。
- Galley：负责验证、吸收、聚合、转换和分发Istio内部的配置。
- Operator：该组件提供了用户友好的选项来操作Istio服务网格。
下一篇我们再来部署和简单实战Istio
**本人博客网站 **IT小神 www.itxiaoshen.com