云原生架构的发展历史2

简介: 云原生架构的发展历史2

7.3 Linkerd

2016年1月,离开Twitter的基础设施工程师打造的一个服务网格项目,第一个Service Mesh项目由此诞生,解决通用性。

Linkerd很好地结合了Kubernetes所提供的功能,以此为基础,在每个Kubernetes Node上都部署运行一个Linkerd实例,用代理的方式将加入Mesh的Pod通信转接给Linkerd,这样Linkerd就能在通信链路中完成对通信的控制和监控。

Linkerd设计思想


Linderd的思想跟sidecar很类似,目标也是屏蔽网络通信细节

Linkerd除了完成对Service Mesh的命名,以及Service Mesh各主要功能的落地,还有以下重要创举:

  • 无须侵入工作负载的代码,直接进行通信监视和管理;
  • 提供了统一的配置方式,用于管理服务之间的通信和边缘通信;
  • 除了支持Kubernetes,还支持多种底层平台。
  • 总结:
  • 跟我们前面sidecar很类似,以前的调用方式都是服务来调用服务,在Linkerd思想要求所有的流量都走sidecar,Linkerd帮业务人员屏蔽了通信细节,通信不需要侵入到业务代码内部了,这样业务开发者就专注于业务开发的本身
  • Linkerd在面世之后,迅速获得用户的关注,并在多个用户的生产环境上成功部署、运行。2017年,Linkerd加入CNCF,随后宣布完成对千亿次生产环境请求的处理,紧接着发布了1.0版本,并且具备一定数量的商业用户,一时间风光无限,一直持续到Istio横空出世。

问题: 在早期的时候又要部署服务,又要部署sidecar,对于运维人员来说比较困难的,所以没有得到很好的发展,其实主要的 问题是Linkerd只是实现了数据层面的问题,但没有对其进行很好的管理。

数据层面:通过sidecar解决了数据处理的问题

打开github:搜索linkerd,是由scala语言编写的

7.4 istio

由Google、IBM和Lyft共同发起的开源项目

打开github:搜索istio,是由go语言编写的

什么是istio?

地址https://istio.io/docs/concepts/what-is-istio/#why-use-istio

Istio makes it easy to create a network of deployed services with load balancing, service-to-service authentication, monitoring, and more, with few or no code changes in service code. You add Istio support to services by deploying a special sidecar proxy throughout your environment that intercepts all network communication between microservices, then configure and manage Istio using its control plane functionality
翻译:
通过Istio,可以轻松创建带有负载平衡,服务到服务的身份验证,监视等功能的已部署服务网络,使得服务中的代码更改很少或没有更改。 通过在整个环境中部署一个特殊的sidecar代理来拦截微服务之间的所有网络通信,然后使用其控制平面功能配置和管理,可以为服务添加Istio支持。

注意这句话:

使得服务中的代码更改很少或没有更改

这句描述非常重要,如果我们用的是spring cloud通信功能,是不是要加依赖、加注解、改配置

什么是控制平面?

控制平面就是来管理数据平面,也就是管理sideCar

所以istio既有数据平面也有控制平面

istio能干什么?

Automatic load balancing for HTTP, gRPC, WebSocket, and TCP traffic.
Fine-grained control of traffic behavior with rich routing rules, retries, failovers, and fault injection.
A pluggable policy layer and configuration API supporting access controls, rate limits and quotas.
Automatic metrics, logs, and traces for all traffic within a cluster, including cluster ingress and egress.
Secure service-to-service communication in a cluster with strong identity-based authentication and authorization.
翻译:
1.HTTP、gRPC、WebSocket和TCP流量的自动负载平衡。
2.路由、重试、故障转移和故障注入对流量行为进行细粒度控制。
3.支持访问控制、速率限制、配置API。
4.集群内所有流量的自动衡量、日志和跟踪,包括集群入口和出口。
5.使用基于身份验证和授权来保护集群中服务跟服务之间的通信。

**总结:**很明显Istio不仅拥有“数据平面(Data Plane)”,而且还拥有“控制平面(Control Plane),也就是拥有了数据 接管与集中控制能力。

7.5 什么是服务网格

服务网格:指的是微服务网络应用之间的交互,随着规模和复杂性增加,服务跟服务调用错综复杂

如下图所示

如果每一个格子都是一个sidecar数据平面,然后sidecar进行彼此通信,那么servicemech就是来管理每个格子的控制平面,这就是服务网格,从架构层面看起来跟网格很像
特点:
基础设施:服务网格是一种处理服务之间通信的基础设施层。
支撑云原生:服务网格尤其适用于在云原生场景下帮助应用程序在复杂的服务间可靠地传递请求。
网络代理:在实际使用中,服务网格一般是通过一组轻量级网络代理来执行治理逻辑的。
对应用透明:轻量网络代理与应用程序部署在一起,但应用感知不到代理的存在,还是使用原来的方式工作。

7.6 什么是Service Mesh

istio官网 也对什么是service mesh给出了定义

地址https://istio.io/docs/concepts/what-is-istio/#what-is-a-service-mesh

Istio addresses the challenges developers and operators face as monolithic applications transition towards a distributed microservice architecture. To see how, it helps to take a more detailed look at Istio’s service mesh.
翻译:
解决开发与运维部署分布式微服务面临的问题
The term service mesh is used to describe the network of microservices that make up such applications and the interactions between them. As a service mesh grows in size and complexity, it can become harder to understand and manage. Its requirements can include discovery, load balancing, failure recovery, metrics, and monitoring. A service mesh also often has more complex operational requirements, like A/B testing, canary rollouts, rate limiting, access control, and end-to-end authentication.
翻译:
也是解决微服务之间服务跟服务之间通信的问题,可以包括服务发现、负载平衡、故障恢复、度量和监视,服务网格通常还具有更复杂的操作需求,如A/B测试、速率限制、访问控制和端到端身份验证

7.7 CNCF云原生组织发展和介绍

云原生发展历史时间轴

  • 微服务
马丁大师在2014年定义了微服务
  • Kubernetes
从2014年6月由Google宣布开源,到2015年7月发布1.0这个正式版本并进入CNCF基金会,再到2018年3月从CNCF基金会正式毕业,迅速成为容器编
  • Linkerd
Scala语言编写,运行在JVM中,Service Mesh名词的创造者 
2016年01月15号,0.0.7发布 
2017年01月23号,加入CNCF组织 
2017年04月25号,1.0版本发布
  • Envoy
envoy是一个开源的服务代理,为云原生设计的程序,由C++语言编程[Lyft] 
2016年09月13号,1.0发布 
2017年09月14号,加入CNCF组织
  • Istio
Google、IBM、Lyft发布0.1版本
Istio是开源的微服务管理、保护和监控框架。Istio为希腊语,意思是”起航“。

CNCF介绍

CNCF 是一个开源软件基金会,致力于使云原生计算具有普遍性和可持续性。 云原生计算使用开源软件技术栈将应用程序部署为微服务,将每个部分

CNCF解决了什么问题

  • 统一基础平台:kubernetes
  • 如果我们需要日志监控:Prometheus
  • 需要代理:Envoy
  • 需要分布式链路跟踪:Jaeger

地址https://www.cncf.io/

介绍几个常用的已经毕业的云原生项目

  • Kubernetes
Kubernetes 是世界上最受欢迎的容器编排平台也是第一个 CNCF 项目。 Kubernetes 帮助用户构建、扩展和管理应用程序及其动态
  • Prometheus
Prometheus 为云原生应用程序提供实时监控、警报包括强大的查询和可视化能力,并与许多流行的开源数据导入、导出工具集成。
  • Jaeger
Jaeger 是由 Uber 开发的分布式追踪系统,用于监控其大型微服务环境。 Jaeger 被设计为具有高度可扩展性和可用性,它具有现
  • Containerd
Containerd 是由 Docker 开发并基于 Docker Engine 运行时的行业标准容器运行时组件。 作为容器生态系统的选择,Containerd
  • Envoy
Envoy 是最初在 Lyft 创建的 Service Mesh(服务网格),现在用于Google、Apple、Netflix等公司内部。 Envoy 是用 C++ 编写
  • Fluentd
Fluentd 是一个统一的日志记录工具,可收集来自任何数据源(包括数据库、应用程序服务器、最终用户设备)的数据,并与众多警报、分析

孵化中的项目

  • Open Tracing
OpenTracing:为不同的平台,供应中立的API,使开发人员可以轻松地应用分布式跟踪。
  • GRPC
gRPC 是一个高性能、开源和通用的 RPC 框架,语言中立,支持多种语言。
  • CNI
CNI 就是这样一个标准,它旨在为容器平台提供网络的标准化。不同的容器平台能够通过相同的接口调用不同的网络组件。
  • Helm
Helm 是 Kubernetes 的包管理器。包管理器类似于我们在Centos中使用的yum一样,能快速查找、下载和安装软件包。
  • Etcd
一个高可用的分布式键值(key-value)数据库。etcd内部采用raft协议作为一致性算法,etcd基于Go语言实现。一般用的最多的就是作为一个注册中心来使用

7.8 国内兴起的服务网格


前面提到,在Service Mesh这个概念得到具体定义之前,实际上已经有很多厂商开始了微服务新的尝试,这一动作势必引发对微服务治理的强劲
  • 蚂蚁金服 sofa Mesh

代理架构

前身是SOFA RPC ,2018年07月正式开源

  • 腾讯 Tencent Service Mesh

代理架构

  • 华为 CSE Mesher

代理架构

总结: 基本上都借鉴了Sidecar、Envoy和Istio等设计思想

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
1月前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
1月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
1月前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####
|
1月前
|
弹性计算 运维 Cloud Native
云原生架构的崛起与未来展望
在数字化转型的浪潮中,云原生架构凭借其高效、灵活和可扩展的特性,正逐渐成为企业IT战略的核心。本文旨在探讨云原生架构的定义、关键特性、实施优势以及面临的挑战,同时展望未来的发展趋势。通过深入分析,我们期望为读者提供一个关于云原生架构全面而深入的视角,助力企业在云计算时代做出更明智的决策。
38 3
|
1月前
|
Cloud Native API 持续交付
云原生时代的微服务架构设计
随着云计算的蓬勃发展,云原生概念逐渐成为IT行业的热点。本文将通过深入浅出的方式,介绍在云原生环境下,如何设计一个高效、可扩展的微服务架构。文章不仅涉及理论概念,还将结合实际代码示例,帮助读者理解微服务架构的核心要素和设计原则,以及如何在云平台上实现这些设计。
|
2月前
|
Cloud Native 持续交付 云计算
云原生技术在现代IT架构中的转型力量####
本文深入剖析了云原生技术的精髓,探讨其在现代IT架构转型中的关键作用与实践路径。通过具体案例分析,展示了云原生如何赋能企业实现更高效的资源利用、更快的迭代速度以及更强的系统稳定性,为读者提供了一套可借鉴的实施框架与策略。 ####
28 0
|
2月前
|
消息中间件 运维 Cloud Native
云原生架构下的微服务优化策略####
本文深入探讨了云原生环境下微服务架构的优化路径,针对服务拆分、通信效率、资源管理及自动化运维等核心环节提出了具体的优化策略。通过案例分析与最佳实践分享,旨在为开发者提供一套系统性的解决方案,以应对日益复杂的业务需求和快速变化的技术挑战,助力企业在云端实现更高效、更稳定的服务部署与运营。 ####
|
1月前
|
Cloud Native API 持续交付
云原生架构下的微服务治理策略与实践####
本文旨在探讨云原生环境下微服务架构的治理策略,通过分析当前面临的挑战,提出一系列实用的解决方案。我们将深入讨论如何利用容器化、服务网格(Service Mesh)等先进技术手段,提升微服务系统的可管理性、可扩展性和容错能力。此外,还将分享一些来自一线项目的经验教训,帮助读者更好地理解和应用这些理论到实际工作中去。 ####
42 0
|
1月前
|
Cloud Native 持续交付 云计算
云原生架构的崛起:企业数字化转型的加速器
在当今快速发展的技术环境中,企业正面临着前所未有的变革压力。本文深入探讨了云原生架构如何成为推动企业数字化转型的关键力量。通过分析其核心概念、优势以及实施策略,本文旨在为读者提供对云原生技术的全面理解,展示其在现代企业中不可或缺的作用。
27 0
|
2月前
|
Cloud Native 持续交付 云计算
云计算的转型之路:探索云原生架构的崛起与实践####
随着企业数字化转型加速,云原生架构以其高效性、灵活性和可扩展性成为现代IT基础设施的核心。本文深入探讨了云原生技术的关键要素,包括容器化、微服务、持续集成/持续部署(CI/CD)及无服务器架构等,并通过案例分析展示了这些技术如何助力企业实现敏捷开发、快速迭代和资源优化。通过剖析典型企业的转型经历,揭示云原生架构在应对市场变化、提升业务竞争力方面的巨大潜力。 ####
41 0