13. 什么是云原生(Cloud Native Computing)->为云而生
只有为云而生的应用才
是云原生应用
2 0 1 9 年
云 原 生 爆 发 成 为 主 攻 方 向
2 0 1 5 年
P i v o t a l 提 出 云 原 生 概 念
P i v o t a l 、 C N C F 同 时 提 出 云 原 生 是 一 种 充 分 利 用 云 计 算 优 势 构 建 和 运 行
应 用 的 方 式 。
D o c k e r 被 认 为 是 能 够 适 应 于 云 原 生 理 念 的 技 术 , 而 微 服 务 被 认 为 是 适 合
D o c k e r 这 种 环 境 , 它 们 一 起 直 接 进 入 云 原 生 领 域 。
M e s o s 、 D o c k e r C o m p o s e 、 K 8 s 等 容 器 编 排 软 件 相 继 出 现
2 0 0 9 年
阿 里 云 飞 天 系 统 诞 生
聚焦于CapEx到OpEx的转变,但是应用依然需要自己解决稳定性问题
企业开始摸索大规模上云的可能性,而同时微服务架构开始出现。
2 0 0 0 年
F r e e B S D 提 出 容 器 , 而 资 源 隔 离 能 力 早 在 1 9 7 5 年 就 已 经 存 在
2003年Docker兴起,但云原生架构依然没
有出现,Docker公司还差点死了
1 9 9 6 年
戴 尔 提 出 云 计 算 理 念
2006年亚马逊率先推出
了弹性计算云(EC2)
分水岭
云原生
Docker:
抽象云资源,使
得更容易使用
微服务:
加快业务迭代更新
从支持应用不同维度发展,最终走在了一起
29. 标准化能力-按需调度-Serverless SSR前端一体化渲染
SSR 顾名思义就是 Server-Side Render, 即服务端渲染。原理很简单,就是服务端直接渲染出 HTML 字符串模板,浏
览器可以直接解析该字符串模版显示页面,因此首屏的内容不再依赖 Javascript 的渲染(CSR - 客户端渲染)。
1. 首屏加载时间:因为是 HTML 直出,浏览器可以直接解析该字符串模版显示页面。
2. SEO 友好:正是因为服务端渲染输出到浏览器的是完备的 html 字符串,使得搜索引擎能抓取到真实的内容,利
于 SEO。但是SSR会占用更多服务器资源,需要更多的渲染时间,高并发场景下可能导致业务堵塞。
结合 Serverless 和 SSR 的特点,我们可以发现他们简直是天作之合。借助 Serverless,前端团队无需关注 SSR 服
务器的部署、运维和扩容,可以极大地减少部署运维成本,更好的聚焦业务开发,提高开发效率。
同时也无需关心 SSR 服务器的性能问题,理论上 Serverless 是可以无限扩容的。
32. 标准化能力-微服务PAAS-应用架构治理-运行态稳定性管理-1
• 资源的治理,比如扩缩容、自愈等等
• 流量的治理,比如熔断、限流、可观察性、运维等等
• 代码的质量,比如DevOps、CICD等等
以上是完成运行态稳定性管理的三要素,其中代码的质量是交给DevOps的,从以上可以看到Paas要真得能够实现运行态稳定性管理,
就必须集成容器服务底座、服务治理和DevOps才能实现。容器服务底座和DevOps前面也都讲过,这里不在重述。
Token
Zuul
网关
Hystrix
熔断限流
Service A Service B
Service C
Nacos Config
熔断监控
Turbine
Zipkin
EFK
prometheus
• 适合大部分客户希望原封不动的低成本迁移上云。
• 大部分周边依赖无法做到平台化,导致管理碎片化严重,并与
微服务框架直接关联,成本较高。
Ingress
Service A Service B
Service C
k8s-ETCD ConfigMap Zipkin
EFK
prometheus
• 适合新项目上云,如果是已经存在的项目就需要修改代码
• 注册中心、配置中心、跟踪链、日志分析、性能分析、流量网
关等都是平台提供的,也需要碎片化适配,并与微服务框架直
接关联,治理能力也必须委托给微服务框架。
有没有可能集成两种部署方式的优势呢,即可以实现透明化迁移同时可以保证标准化能力呢?
本质而言,我们是需要一个可以托管各类微服务的通用云原生应用架构治理平台
69. 高级能力-云原生数据库-应用的基石-2-技术架构
Application Application Application
Read Read
Write
DB Server
User Space File
system
Data
Router&Cache
DB Server
User Space File
system
Data
Router&Cache
DB Server
User Space File
system
Data
Router&Cache
RDMA
Read Only Read Only
R/W
Parallel-Raft Protocol&Storage Serverless
Data Chunk Data Chunk Data Chunk
• 云原生的本质在于为云这种弹性资源下能够为应用提供
稳定的基础架构,所以云原生数据库相对于传统数据库
最大的不同也在这个方面:弹性
• 对于数据存储的高性能、高稳定性、高拓展、资源成本
等等都需要同时满足(和传统CAP相悖)
• 接入层需要能够根据规则的路由,以及兼容各类协议接
口以及数据模型,并能根据应用的规模来自动拓展。
• 实现HTAP(OLTP+OLAP),将在线事务|分析混合计算模型
基础上,实现多模数据模型,使得集成成本经一步降低。
• 计算层,与存储彻底剥离开来,实际是微服务化架构,
可以自由伸缩,并自动故障转移,采用读写分离,适应
高负荷的场景。另外也需要进一步将计算和内存分离出
来,使得计算层彻底变为无状态,可以做到灵活的拓展
能力和故障恢复能力。这样在计算层也实现了Serverless
模式。
• 通过RDMA,绕过CPU,直接和远端内存通信,在计算
与存储分离、计算与内存分离架构上,提升网络利用率
和性能,也能得到传统数据库网络和性能上一样的体验。
• 底层Data Chunk,采用去中心存储,单体失败不影响数
据的完整性,并且自动自愈(Serverless)。
• 通过跨域数据同步能力,实现多地域数据多活。
这个例子,也给数据库云原生化上的技术架构演进提
供了一个范本,并不是原封不动的迁移就变成云原生