开发者社区> busighszgro74> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

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

简介: 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

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
共建共享数字世界的根:阿里云打造全面的云原生开源生态
目前,阿里云开源主要涵盖云原生、操作系统、大数据&AI、数据库四大领域,在 GitHub 上收获 Star 总数超百万,阿里已经连续十年蝉联中国厂商开源活跃度、影响力第一。
31 0
共建共享数字世界的根:阿里云打造全面的云原生开源生态
目前,阿里云开源主要涵盖云原生、操作系统、大数据&AI、数据库四大领域,在GitHub上收获Star总数超百万,阿里已经连续十年蝉联中国厂商开源活跃度、影响力第一。
89 0
阿里云数据库ApsaraDB| 学习笔记
快速学习阿里云数据库ApsaraDB
66 0
阿里云云开发实践笔记【1】
阿里云云开发实践笔记
48 0
阿里云云服务器 ECS 介绍|学习笔记
快速学习 阿里云云服务器 ECS 介绍
52 0
阿里云云存储和CDN| 学习笔记
快速学习阿里云云存储和CDN
101 0
阿里云数据库ApsaraDB| 学习笔记
快速学习阿里云数据库ApsaraDB
98 0
第一堂“云原生”课 | 学习笔记
快速学习第一堂“云原生”课。云原生具备重要意义,它是云时代技术人自我提升的必备路径
133 0
阿里云ECS七天训练营-搭建个人Leanote云笔记
Leanote是一款在线的云笔记应用,有如下特点: • 支持网页、PC、手机APP客户端和微信版,随时记录,方便分享,支持语音,图片输入。 • 代码高亮,涵盖所有主流语言的代码高亮,随心所欲在Leanote里写代码,记知识。 • Markdown 编辑器,实时同步预览。 • 专业数学公式编辑,像Word和Latex能编辑数学公式。 • 支持创建思维脑图,将散乱的想法以树状信息分层展示。 • 详细历史纪录,每次保存都在后端备份,轻松查找,一键恢复。 • 实时同步云端
234 0
成为阿里云大使的笔记
20170706,成为云大使
2201 0
+关注
busighszgro74
以云架构师为目标而努力奋斗的小年轻
2
文章
0
问答
文章排行榜
最热
最新
相关电子书
更多
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载
冬季实战营第三期:MySQL数据库进阶实战
立即下载