1。服务网格简介1.1.当前微服务架构面临的一些挑战目前，微服务架构在企业中得到了很大的发展，主要是因为它解决了传统单体架构存在的问题。单体架构拆分成微服务架构，你能高枕无忧吗？很明显不是。微服务架构体系也存在诸多挑战。比如把原来单体应用拆分成很多分散的微服务，它们互相调用完成一个任务。概率越大），排查难度非常大。如果对用户请求的响应太慢，我们需要知道慢在哪里？调用整个链路的每个阶段需要多少时间？哪些调用是并发执行的，哪些是串行的？这些问题需要我们非常清楚整个集群的调用情况和流量情况。微服务被拆分成这么多的组件，如果单个组件的错误概率保持不变，那么整体的错误概率就会增加。如果在调用服务时没有错误处理机制，就会出现很多问题。应用数量的增加也是日常应用发布的一个问题。应用程序的发布需要非常谨慎。如果一次性升级应用，一个错误会导致整个在线应用不可用，影响范围太大。很多时候，我们需要同时拥有不同的版本，通过AB测试来验证哪个版本更好。如果版本升级改变了API，相互依赖，那我们也希望在release时自动控制不同的版本访问不同的地址。这些问题需要智能流量控制机制。为了保证整个系统的安全，每个应用都需要实现一套类似的功能，如认证、授权、HTTPS、限流等。没错，ServiceMesh的出现就是为了解决上述问题。这就是我们学习这套课程的目的。1.2.技术架构的演变1.2.1．发展历程大事记1.2.2．单机小型机时代第一个计算机网络诞生于1969年，这就是美军的Arpanet。Arpanet可以实现与其他计算机的联机操作，但早期只是用于军事目的。2000年初，中国约有890万网民。许多人不知道互联网是什么。因此，服务业务大多单一、简单，采用典型的单机+数据库模式，功能一应俱全。编写在应用程序中并集中部署。说明：论坛业务、聊天室业务、邮箱业务都耦合在一台小型机上，所有的业务数据也存储在一个数据库中。1.2.3.垂直拆分随着应用的日益复杂和多样化，开发者对系统的容灾、扩展和业务响应能力提出了更高的要求。如果任何一个小型机和数据库出现故障，整个系统如果某个部分的功能需要更新，整个系统就需要重新发布。显然，这在商业飞速发展的万物互联时代是不允许的。如何在保证可用性的情况下快速响应业务变化，需要对系统进行拆分，将上述应用拆分成多个子应用。优点：应用间解耦，提高系统容错能力，解决应用独立发布问题。应用垂直拆分解决了应用发布的问题，但是随着用户数量的增加，单台电脑的计算能力仍然是九牛一毛。1.2.4.集群负载均衡架构的用户越来越多，意味着需要更多的小型机，但小型机价格昂贵，运维成本高。这时候更好的选择是在多台PC上部署同一个应用，但是这时候需要对这些应用进行负载均衡，因为客户端不知道请求会落到哪个后端PC应用上。负载均衡可以分为硬件级和软件级。硬件级别：F5软件负载级别：LVS、Nginx、Haproxy负载均衡思路：对外暴露统一接口，根据用户请求转发相应规则，负载均衡还可以做限流等。负载均衡后，后端应用可以根据流量的大小进行动态扩展，我们称之为“横向扩展”。2008年，阿里巴巴提出去除“IOE”，即IBM小型机、Oracle数据库、EMC存储，全部改为集群负载均衡架构。2013年，支付宝最后一台IBM小型机下线。优点：通过横向扩展，增强了系统的并发能力。1.2.5.服务改造架构虽然系统进行了垂直拆分，但拆分后发现论坛、聊天室功能重复，如用户注册、发送邮件等，一旦项目大了，集群部署会是的，这些重复的功能无疑会造成资源的浪费，所以将重复的功能提取出来，取名为“XX服务（Service）”。为了解决服务与服务之间如何相互调用，需要一个程序之间的通信协议，于是就有了远程过程调用（RPC），用来让服务之间的程序调用像本地调用一样简单。优点：在之前架构的基础上解决了业务复用的问题。1.2.6.服务治理随着业务的增加，基础服务越来越多，调用网络之间的关系从最初的几个增加到几十个、几百个，导致调用环节错综复杂，需要进行服务治理。服务治理需求：当我们有几十个或者上百个服务节点的时候，我们需要对服务有一个动态的感知，引入注册中心。当服务链接调用很长时，如何实现链接监控。对于单个服务的异常，如何避免整个链路的异常（雪崩）需要考虑熔断、降级、限流等。服务的高可用性：负载均衡。典型的框架有：Dubbo，默认使用Zookeeper作为注册中心。1.2.7.微服务时代微服务是2012年提出的概念，微服务的希望是一个服务只负责一个独立的功能。根据拆分的原则，任何需求都不会因为发布或维护而影响不相关的服务，一切都可以独立部署和维护。比如传统的“用户中心”服务，对于微服务来说，需要根据业务再拆分，可能需要拆分成“买家服务”、“卖家服务”、“商家服务”等等。典型代表：SpringCloud。与传统的分布式架构相比，SpringCloud使用HTTP作为RPC远程调用。配合注册中心Eureka和API网关Zuul，可以细分内部服务，对外暴露统一接口。让外界对系统的内部结构无感。另外SpringCloud的config组件也可以统一管理配置。SpringCloud微服务架构的不足：SpringCloud是一个侵入式框架。需要在项目中添加springcloudmaven依赖，添加springcloud组件注解，编写配置，打包成jar时也必须包含非业务代码。融合在一起。微服务中的服务支持不同语言的开发，也需要维护不同语言和非业务代码的成本；业务代码开发者应该把更多的精力放在业务熟悉上，而不是非业务上，虽然SpringCloud可以解决微服务领域的很多问题，但是学习成本还是比较大的。互联网公司产品的版本升级非常频繁。为了保持各个版本的兼容性、权限、流量等，因为SpringCloud是一个“代码侵入式框架”，此时的版本升级注定要让非业务代码在一起，一旦出现问题，耦合多语言之间的调用，工程师会很痛苦。我们已经感受到，服务拆分得越细，感觉就像是轻量级解耦，但是维护成本越高。1.2.8、新时代的服务网格（ServiceMesh）ServiceMesh要解决的主要问题是让开发者专注于业务，服务发现、服务注册、负载均衡等对开发者透明，他们可以更专注于业务逻辑的实现。如果把为微服务提供通信服务的逻辑从应用进程中抽取出来，部署为一个单独的进程，作为服务之间的通信代理，可以得到下图所示的架构：Sidecar，翻译成中文是sidecar，很有形象。当部署了大量的服务时，服务部署的sidecaragent之间的连接形成了如下图所示的网格，成为微服务的通信基础层，承载着微服务之间的所有流量，即称为ServiceMesh（服务网格）。服务网格中有大量的sidecar代理。如果每个代理都单独设置，工作量会很大。为了更方便地对服务网格中的代理进行统一集中控制，在服务网格中增加了控制平面组件。1.3.什么是ServiceMeshServiceMesh就是用来描述组成这些应用的微服务网络以及它们之间的交互。随着服务网格的规模和复杂性的增长，它变得越来越难以理解和管理。它的需求包括服务发现、负载均衡、故障恢复、指标和监控等。服务网格通常还有更复杂的操作需求，比如A/B测试、金丝雀发布、速率限制、访问控制和端到端验证。1.4.服务网格产品1.4.1。CNCFCCF是一个开源软件基金会，致力于使云原生计算具有普遍性和可持续性。云原生计算使用开源软件技术堆栈将应用程序部署为微服务，将每个部分打包到自己的容器中，并动态编排这些容器以优化资源利用率。云原生技术使软件开发人员能够更快地构建出色的产品。官网：https://www.cncf.io/常用毕业云原生项目：KubernetesKubernetes是全球最流行的容器编排平台，也是第一个CNCF项目。Kubernetes帮助用户构建、扩展和管理应用程序及其动态生命周期。PrometheusPrometheus为云原生应用提供实时监控和告警，包括强大的查询和可视化能力，并集成了很多流行的开源数据导入和导出工具。JaegerJaeger是Uber开发的分布式跟踪系统，用于监控其大型微服务环境。Jaeger具有高度可扩展性和可用性，具有现代UI，旨在与OpenTracing、Kubernetes和Prometheus等云原生系统集成。EnvoyEnvoy是最初在Lyft创建的服务网格（ServiceMesh），现在在谷歌、苹果和Netflix等公司内部使用。Envoy是用C++编写的，旨在最大限度地减少内存和CPU占用空间，同时提供微服务环境中的负载平衡、深度网络可观察性、跟踪和数据库活动等功能。ContainerdContainerd是Docker开发的基于DockerEngine运行时的行业标准容器运行时组件。作为首选的容器生态系统，Containerd提供了一个运行时，允许将Docker和OCI容器映像作为新平台或产品的一部分进行管理。1.4.2.LinkerdLinkerd是Buoyant2016年第一个开源的高性能网络代理程序，是业界第一个ServiceMesh产品。甚至可以说，Linkerd的诞生标志着ServiceMesh时代的开始，带动了ServiceMesh的飞速发展。发展。主要用于解决分布式环境下服务间通信面临的一些问题，如网络不可靠、不安全、延迟和丢包等。Linkerd采用Scala语言编写，运行在JVM上，其底层基于Twitter的Finagle库，相应地进行了扩展。最重要的是Linkerd具有快速、轻量、高性能的特点。它可以以最小的延迟和负载每秒处理数万个请求。便于横向扩展。经过产线测试验证，可在任意平台运行产线级服务。网格工具。1.4.3.EnvoyEnvoy也是一个高性能的网络代理程序，由Lyft于2016年10月开源，专为云原生应用而设计，可以作为处理外部流量的边界入口。当然也可以作为内部服务之间的通信代理，实现服务之间的可靠通信。Envoy的实现借鉴了现有的生产线级代理和负载均衡器的实践经验，如Nginx、HAProxy、硬件负载均衡器、云负载均衡器等。同时，基于C++编写和Lyft的产线实践，Envoy的表现非常出色。稳定。Envoy可以作为一个独立的代理层，也可以作为ServiceMesh架构中的数据平面层。因此，Envoy通常与服务一起运行，以抽象应用程序的网络功能。Envoy提供了通用的网络功能，实现了平台和语言的独立性。1.4.4、Istio2017年5月24日，Google、IBM和Lyft联合发布了Istio的第一个公开版本（0.1）。Istio是一个开源的平台软件，为微服务提供服务间的连接、管理和安全保障。支持Kubernetes、Mesos等容器管理工具，但不限于Kubernetes、Mesos。它的底层依赖于Envoy。Istio提供了一种简单的方法来实现服务之间的负载均衡、服务之间的认证和监控等功能，而无需调整应用层代码。它的控制面由Pilot、Citadel和Galley组成，数据面由Envoy实现。通常，数据面代理Envoy采用sidecar模式部署，使得所有服务间的网络通信都由Envoy实现，而Istio的控制面则负责服务间的流量管理、安全通信策略等功能。1.4.5.ConduitConduit于2017年12月发布，是继Linkerd之后由Buoyant赞助的又一个开源项目。Conduit旨在彻底简化用户在Kubernetes中使用服务网格的复杂性，提升用户体验，而不是像Linkerd那样针对各种平台进行优化。1.4.6.国内产品国内很多团队已经在做研究了。这些团队主要分为四类系统：以蚂蚁金服为首的开源系统：SOFA（ScalableOpenFinancialArchitecture）蚂蚁金服自研的Mesh在一开始走开源路线的时候参考了设计Istio和Envoy的思想，重新实现了自己的ServiceMesh体系。旁路网关（Sidecar）基于Go语言。该系统的前身是开源的SOFARPC框架。蚂蚁金服于2018年7月正式将其开源，可能还需要一段时间才能形成正式的可用于生产的框架。以华为为代表的自研部门：在ServiceMesh这个概念出来之前，华为可能有过类似的想法，但没有提炼出一个共同的概念。无论是华为早期的HSA，还是后来的CSEMesher，都是对ServiceMesh的探索。CSEMesher的整个架构是基于华为自身在微服务架构方面的经验开发的，它的sidecar也是用Go语言编写的。正如其官方文档所述，其资源占用非常小，正常状态下仅30MB。以腾讯为代表：腾讯的TencentServiceMesh定制开源产品（如Istio），加强吸收再加入自己的特殊业务逻辑。腾讯选择的Sidecar是Envoy，用C++写的，比较符合腾讯的技术栈。它的公开技术并不多，内部还是主要在小范围内使用。以UCloud为代表的适配体系：主要依赖开源方案，但并未完整介绍其产品，??只是在几个关键部分增加适配适配企业现有产品，并引入改动最小的ServiceMesh体系成本。本文由传智教育博学谷-狂野建筑师教研团队发布，转载请注明出处！如果本文对您有帮助，请关注并点赞；有什么建议也可以留言或私信。您的支持是我坚持创作的动力
