阿里云云原生学习及思考笔记-云原生理解

本文涉及的产品
云原生 API 网关,700元额度,多规格可选
简介: 1.什么是云原生2.API,容器,微服务之间的关系又是如何?3.DevOps与CI/CD呢?

1.什么是云原生
真正的云化不仅仅是基础设施和平台的变化,应用也需要做出改变,摈弃传统的土方法,在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点,重新设计,从而建设全新的云化的应用,即云原生应用。
云原生是指从云的原生应用角度出发,一整套设计、开发、部署、运行、维护的流程、技术栈以及背后文化理念的统称。[1]

从这个角度来看,与云原生对应的是传统的部署方式。用来对比的是云原生应用和传统应用。

image.png
云原生的发展脉络[1]

2.API,容器,微服务之间的关系又是如何?
API 是应用程序编程接口(Application Programming Interface)的缩写。维基百科指出,“总的来说,它是各种组件之间的一组明确定义的通信方法”。
现如今,当人们谈论 API 时,他们通常指的是通过 HTTP 端点公开的远程接口。为了区分这些远程 API 和上面提到的本地系统 API,我将用术语“Web API”指代远程 API。
我们通过底层设计范式(如查询、RPC 或 RESTful)或协议(如 SOAP、gRPC 或 GraphQL)进一步对远程 API(或 Web API)进行分类。除此之外,我们还通过目标受众来区分 API,将它们分为公共、合作伙伴或私有 / 内部 API。
微服务,又叫微服务架构,是一种软件架构方式。它将应用构建成一系列按业务领域划分模块的、小的自治服务。
在微服务架构中,每个服务都是自我包含的,并且实现了单一的业务功能。简单来说,就是将一个系统按业务划分成多个子系统,每个子系统都是完整的,可独立运行的,子系统间的交互可通过HTTP协议进行通信(也可以采用消息队列来通信,如RoocketMQ,Kafaka等)。[3]
与微服务相对比的是单体架构,一个比较形象的例子区别单体架构和微服务是装配式建筑。传统建筑(单体应用)的施工周期(开发时间)很长,往往依赖于建筑公司(开发团队)的能力和水平,修建完成后难以搬迁和复用,而装配式建筑(微服务)的梁、板、柱、墙等构件(单个服务)可以事先批量化的在工厂(容器)生产,而在建造过程中,我们可以把构件想象成一块块乐高积木,在施工现场只需把它们拼合在一起,大大提升了施工进度和建筑质量。[5]
一组服务可以运行在tomcat容器内,服务间采用轻量级通信机制,如HTTP RESTful API,独立自动部署,可以采用不同的语言及存储方式。[5]
如果没有容器,要么把服务器配置成可以运行多个微服务,让这些微服务不可避免地相互产生负面干扰,要么每个微服务都需要一个单独的服务器或自己的虚拟机,导致不必要的开销。因此,微服务通常被部署在一组由容器集群软件(如 Kubernetes)管理的一组容器中。可以肯定地说,容器和微服务的崛起其实是相互影响、相互促进的结果。【此处强调的是容器的隔离性,以前为了保证隔离性,需要分别部署在不同的VM上,但是这样也导致了启动时间长(相较于容器的秒级启动);其次,对服务代码进行容器化,它的运行环境、依赖关系、系统库等,都被打包在一起,保证了环境的隔离。】

image.png
不同的隔离级别[8]

基于微服务架构构建的应用程序或 API 不仅要把自己完全暴露出来,还需要在内部组件(微服务)之间建立连接。由于每个微服务都可以使用不同的编程语言实现,我们需要依赖标准协议(如 HTTP)来建立微服务之间的连接。这个时候我们就回到了 API 上。[2]

提到了API,我们不得不提及API管理与API集成。
1、全生命周期API管理
API 全生命周期管理(Full Life Cycle API Management)是指对 API 从规划、设计到实施、测试、发布、运行、调用直至版本变更与退出的整个周期的管理。7
2、API网关:微服务基础设施
全生命周期API管理里一个细分的领域是API网关(API Gateway),API网关顾名思义,是出现在系统边界上的一个面向API的、串行集中式的强管控服务,这里的边界是企业IT系统的边界,主要起到隔离外部访问与内部系统的作用,并处理常见的南北向流量。[5]
API网关作为企业能力开放的一个门户,除了具备基本的请求转发、协议转换、路由等功能,以及高性能和高稳定性外,还需具备良好的扩展性[5]

image.png
API网关:微服务基础设施

[5]
例如Uber,在传统的单体架构遇到越来越大挑战的时候,决定改变自己的架构,效仿亚马逊、Netflix、Twitter等其他超级增长公司,将其整体架构拆分为多个代码库,以形成一个微服务架构。其主要变化是引入了API网关,所有的司机和乘客都是通过这个网关连接的。从API网关,所有的内部点都连接在一起,如乘客管理、司机管理、行程管理等。每个单元是单独的可部署单元,执行单独的功能。例如:如果你想在账单微服务中更改任何内容,那么只需部署账单微服务,而不必部署其他服务。所有的功能都是单独扩展的,即每个特征之间的相互依赖被移除。[5]

image.png
Uber的微服务架构[5]

微服务通用框架[6]
因为微服务是功能粒度上的拆分,必然导致拆分之后的模块变多。针对模块与模块之间的通信与维护,又演变出如下问题:
模块与模块之间如何通信;
每个被拆分的微服务如何做负载均衡;
服务如何做注册,如何做发现;
服务之间调用如何做限流,服务调用失败如何做降级,流量异常如何做熔断;
服务调用是否可以做统一的访问控制;

ESB与API网关
https://blog.csdn.net/aeaiesb/article/details/107661866

目前国内用的最多的无外乎是两套框架:Dubbo,Spring Cloud。Dubbo大家都很熟悉,从开源到无人维护再到重新冲击Apache顶级项目。但是Dubbo更加准确来说是一个分布式服务框架,致力于提供高效的RPC远程服务调用方案以及SOA服务治理方案。说白了就是个分布式远程服务调用框架。
Spring Cloud 基于 Spring Boot,为微服务体系开发中的架构问题,提供了一整套的解决方案——服务注册与发现,服务消费,服务保护与熔断,网关,分布式调用追踪,分布式配置管理等。[6]
微服务架构最常见、最广泛使用的框架是基于Java的Spring Cloud(集成了上图里的Netflix OSS技术栈),提供了服务发现、负载均衡、故障转移、动态扩展和数据分区等功能,已经成为微服务的最佳实践。
但是Spring Cloud构建在Java虚拟机之上,不能满足高并发下的性能要求,所以许多开源产品层出不穷,其中也包括中国互联网企业所贡献的微服务框架,例如华为的ServiceComb、阿里的Dubbo等等。[5]

另外,提及了API网关,就不得不提及服务网格
服务网格和API网关是两个联系非常紧密的概念,它们的用途既不同,但是在某些方面又相互重叠。在某种程度上,我们可以认为服务网格是一个分布式的、微观层面的API网关,解决微服务服务发现、负债均衡、流量控制等需求。在具体用途上,API网关处理的是所谓南北向流量即内外部请求;而服务网格处理的是东西向流量即内部服务相互间的访问。想深入了解两者区别的读者可以仔细阅读《Service Mesh和API Gateway关系深度探讨》这篇文章。[5]

image.png

3.DevOps与CI/CD呢?
DevOps才得到了快速的发展。DevOps不单是一个实现自动化的工具链,而是组织、流程与技术的结合。组织上强调全栈团队、团队特性专一、团队自治;技术上打通开发与运维;流程上强调端到端、可视化、灰度升级、A/B测试等。
对于DevOps,微服务不是必须的,但微服务为DevOps提供了最好的架构支撑,对于组织和流程的要求也是一致的。所以,也有人称微服务是DevOps架构。

另一个角度来说,DevOps是配合微服务的理念组织构建团队协作的方式,各团队可以独立开发,测试、发布和迭代各自的微服务,互不干扰,沟通协调成本小。[5]

如果你将微服务打包为容器的一部分,容器镜像就成为一个部署单元,DevOps团队只需要知道如何部署容器就可以了,不需要去考虑里面运行的是什么应用。通过这种方式,你也能够避免由于缺少依赖库,或者环境版本(比如你的服务所需要的框架、依赖)不匹配所造成的服务失败,服务所需要的所有的东西都被打包在一起,成为一个不可变的环境,这就是典型的持续集成的一部分。[8]
持续集成(CONTINUOUS INTEGRATION,CI)指的是开发人员频繁的(一天多次的)将所有开发者的工作合并到主干上。这些新提交在最终合并到主线之前,都需要通过编译和自动化测试流进行验证,以保障所有的提交在合并主干之后的质量问题,对可能出现的一些问题进行预警。持续集成的核心在于确保新增的代码能够与原先代码正确的集成。

与持续集成相比,持续交付(CONTINUOUS DELIVERY,CD)的侧重点在于交付,其核心对象不在于代码,而在于可交付的产物。由于持续集成仅仅针对于新旧代码的集成过程执行了一定的测试,其变动到持续交付后还需要一些额外的流程。与持续集成相比较,持续交付添加了测试Test->模拟Staging->生产Production的流程,也就是为新增的代码添加了一个保证:确保新增的代码在生产环境中是可用的。
持续部署(CONTINUOUS DEPLOYMENT)指的是通过自动化部署的手段将软件功能频繁的进行交付。与持续交付以及持续集成相比,持续部署强调了通过自动部署的手段,对新的软件功能进行集成。同持续交付相比持续集成的区别体现在对生产的自动化。从开发人员提交代码到编译、测试、部署的全流程不需要人工的干预,完全通过自动化的方式执行。这一策略加快了代码提交到功能上线的速度,保证新的功能能够第一时间部署到生产环境并被使用。
DevOps、持续集成、持续交付、持续部署并不是某种技术栈或者框架,而是开发文化、流程、理念和操作方式。[4]

[1]云原生时代(一)云原生及CNCF基金会https://zhuanlan.zhihu.com/p/143417185
[2]别再管你的 API 叫微服务了:容器、微服务和API之间是什么关系?cloud.tencent.com/developer/news/378771
[3]微服务是什么https://zhuanlan.zhihu.com/p/66190538
[4]云原生时代(二):DevOps与CI/CDhttps://zhuanlan.zhihu.com/p/143424111
[5]云原生时代(三):微服务、API管理与集成https://zhuanlan.zhihu.com/p/143472291
[6]微服务全流程分析https://zhuanlan.zhihu.com/p/101417273
(文章基于Dubbo,Spring Cloud架构内,各组件做了详细拆解分析,针对两种微服务架构初期学习非常有帮助)
[7]为什么我们说云原生时代,企业数字化转型更需要做好 API 全生命周期管理?https://developer.aliyun.com/article/793174
[8]从微服务开始(二):容器与微服务https://blog.csdn.net/steelren/article/details/77162713

相关文章
|
19天前
|
Cloud Native Serverless 数据中心
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
ACK One注册集群已正式支持ACS(容器计算服务)算力,为企业的容器化工作负载提供更多选择和更强大的计算能力。
|
1天前
|
Cloud Native Serverless 数据中心
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
17 10
|
22天前
|
运维 Cloud Native 应用服务中间件
阿里云微服务引擎 MSE 及 云原生 API 网关 2025 年 1 月产品动态
阿里云微服务引擎 MSE 面向业界主流开源微服务项目, 提供注册配置中心和分布式协调(原生支持 Nacos/ZooKeeper/Eureka )、云原生网关(原生支持Higress/Nginx/Envoy,遵循Ingress标准)、微服务治理(原生支持 Spring Cloud/Dubbo/Sentinel,遵循 OpenSergo 服务治理规范)能力。API 网关 (API Gateway),提供 APl 托管服务,覆盖设计、开发、测试、发布、售卖、运维监测、安全管控、下线等 API 生命周期阶段。帮助您快速构建以 API 为核心的系统架构.满足新技术引入、系统集成、业务中台等诸多场景需要
阿里云微服务引擎 MSE 及 云原生 API 网关 2025 年 1 月产品动态
|
2天前
|
Cloud Native 安全 Serverless
云原生应用实战:基于阿里云Serverless的API服务开发与部署
随着云计算的发展,Serverless架构日益流行。阿里云函数计算(Function Compute)作为Serverless服务,让开发者无需管理服务器即可运行代码,按需付费,简化开发运维流程。本文从零开始,介绍如何使用阿里云函数计算开发简单的API服务,并探讨其核心优势与最佳实践。通过Python示例,演示创建、部署及优化API的过程,涵盖环境准备、代码实现、性能优化和安全管理等内容,帮助读者快速上手Serverless开发。
|
21小时前
|
边缘计算 Cloud Native 调度
感谢认可!阿里云云原生大规模云边协同技术荣获浙江省科学技术进步奖一等奖
感谢认可!阿里云云原生大规模云边协同技术荣获浙江省科学技术进步奖一等奖
|
2天前
|
人工智能 关系型数据库 分布式数据库
阿里云PolarDB重磅发布云原生与Data+AI新特性,打造智能时代数据引擎
阿里云PolarDB重磅发布云原生与Data+AI新特性,打造智能时代数据引擎
|
2月前
|
运维 关系型数据库 分布式数据库
阿里云PolarDB:引领云原生数据库创新发展
阿里云PolarDB引领云原生数据库创新,2024云栖大会将分享其最新发展及在游戏行业的应用。PolarDB凭借弹性、高可用性、多写技术等优势,支持全球80多个站点,服务1万多家企业。特别是针对游戏行业,PolarDB助力Funplus等公司实现高效运维、成本优化和业务扩展。通过云原生能力,PolarDB推动游戏业务的全球化部署与快速响应,提升用户体验并保障数据安全。未来,PolarDB将继续探索AI、多云管理等前沿技术,为用户提供更智能的数据基础设施。
|
3月前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
3月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
4月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
86 3