云原生架构到底是个啥？
Posted 琳时闲话
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云原生架构到底是个啥？相关的知识，希望对你有一定的参考价值。
在说云原生架构之前，让我先来尝试解释一下，什么是“云原生”（cloud-native）。
时下业界对云原生比较流行的解释大都来自CNCF、Pivotal这些来自开源社区的主力推手，他们口中的云原生涵盖的内容包括，容器和容器编排、微服务、devops等关键元素。但是这些厂商口中的云原生，就有着很深刻的行业印记。做容器起家的自然会说容器编排是云原生，做微服务技术框架的就会告诉你不搞微服务就不是云计算，搞企业OA、研发协同的会跟你讲不能支持devops的云计算不是个正经云。
当你无法明确定义一件事物的时候，就会用描述取代定义
总之，各说各话，概念为王。云原生是个筐，什么都能往里装。也很好理解，不体现领域特长，自家方案怎么卖钱呢？
所以，以上的解读都对，又都不全面，需要注意区别语境和适用场景。
相比之下，云计算3A大厂（AWS, Azure, Aliyun）语境中下的云原生定义，就会涵盖更广的范畴。
比如，阿里云对云原生的定义就包括了
资源服务化：云上一切皆资源，皆可通过api管理
极致弹性伸缩：背靠高效的运维管控系统负责资源调度
容灾高可用：完备的灾备方案，可依赖的SLA能力（如99.9999%）
云上应用全生命周期管理：DevOps活动，如需求管理、开发测试、部署运维等，都发生在云端
可分层的云原生能力：客户根据实际需求自由选择IaaS、PaaS、SaaS、DaaS产品
安全可信的云端数据链路：企业用户在云上产生的数据归属，云计算出海合规，皆有赖于此。
那么云原生架构，就是基于云原生能力的，一种新型的IT系统架构。云原生架构构筑的系统，具有“永远在线，随时可得；资源无限，弹性伸缩”的特点。
当然，云计算这个产业也在快速发展，不断进化，相信随着这个行业更多玩家和客户上云应用的深化，云原生架构在未来也一定会继续丰富其内涵。
随时随地，无处不在的云，已经渗入到你我的日常生活
上述描述未免太不直观，还是以阿里云为例，一个完全在云原生架构下工作的场景可能会是这样的。
程序员小马一天的工作从登录阿里云开始：
9:00~9:30 - 打开云邮箱，查看前一天晚上海外团队发来的邮件，回复客户问题，收到老板发来的技术评审会议邀请。
9:30~10:30 - 在钉钉上加入多人视频会议，讨论新的技术方案，打开钉钉会议助手，将实时语音讨论转成文字纪要。
会议结束，会议纪要自动保存为钉钉共享文档，同步发给所有参会人。
10:30~11:30 - 进入“云效”平台，选择测试服务，查看昨晚的回归测试结果。
啊~有报错，登录云上集成测试环境，发现是新架构系统需要更多的虚拟机资源。
小意思，再购买5台高规格ECS实例吧，添加到云效平台的测试资源里，重启集成测试，搞定~
11:30~11:45 - 收到邮件通知，产品经理给我提了两个新的功能需求。
打开云效的项目协作查看需求内容，是上午技术评审会决定的功能详细规约。Hmm，先把需求拖进本期迭代，确认排期，容我吃个饭先，想想怎么实现。
12:00~13:30 - 吃饭，打王者荣耀，午休……困，再发呆五分钟。
13:35~15:30 - 钉钉设置勿扰，进入专注编码的贤者时间。
打开云上的线上IDE开始在线编程（这里有部分尚未实现），从应用模板创建项目工程，云上的代码托管服务可以让我随时拉取/提交代码到自己的开发分支，云效CI/CD流水线支持随时执行编译、构建测试，在云端运行UT回归，构建得到新的镜像，会保存在云端的镜像制品库里，可以一键发布到云上的测试环境。
按需求，新的系统架构需要加入一个大数据集群来做数据清洗，以前手动组建集群麻烦的要死，现在就简单了，登录EMR控制台购买个集群实例，20分钟后集群就绪，开始联调自测。
功能自测完毕，自信满满地在云效平台上提交一个代码评审活动，邀请组长和下游的小伙伴来做个code review。
去公司门口买杯咖啡，顺便眺望下街边路过的小妹子，让眼睛休息，休息一下。
15:50 - 手机忽然响了，是钉钉语音机器人，“系统报警，您线上的RDS实例xxxxx不可用已超过5分钟……”，谢特，什么情况?
“在哪儿呢？快回来~郑爽的第三段录音刚又tm上热搜了，咱们数据库怎么又卡了？！~”
“哦，组长，已经收到告警在看了……这就来。”
15:53~16:25 - 回到工位，赶紧登录云数据库RDS的控制台，启动RDS备用实例，走紧急变更把生产环境的业务流切换到备用实例，恢复线上服务先。
结合SLS日志服务，定位问题发生的确切时间和调用现场，用RDS提供的数据洞察功能找到可能引发业务卡死的慢SQL，但是未能重现之前的问题……hmm，没头绪，提个工单给阿里云的专家服务来分析一下吧。
16:30~17:00 - 继续钉钉会议，共享桌面完成代码评审。今天运气不错，一轮顺利通过。晚上22:00排期上线。
17:00~18:00 - 新上的容器镜像已经发布到云容器服务ACK的应用列表，下班前就在一个沙箱环境里拉起一个灰度系统，调整负载均衡服务SLB的配置，把线上5%的流量引入到这个灰度系统测试一下具体表现，一旦有服务异常，ACK的实时监控助手会通过钉钉通知到责任人的。
下班咯~
22:00~22:30 - 在家里登录阿里云。
看起来新架构在灰度系统里的表现还不错，那就可以向生产环境做蓝绿发布了，暂时维持SLB的分流比例不变。
后续线上生产系统的蓝绿版本流量切换，就交给海外的运营团队继续跟进吧。顺便提醒他们公司的OSS容量要再扩容100T，谁知道明天哪个明星又要宣布离婚呢~
晚安咯~阿里云。
小马登出阿里云，结束一天的工作。这真是充实而有意义的一天呀~
（以上剧情描述仅供场景展示）
那么云原生架构的目标就不难理解了，就是为了让客户价值可以快速得到体现。
如果以开源社区的视角来看云原生的社区生态，也会是一幅非常壮观的画卷，上图。
cloud-native landscape, 摘自CNCF官网
当然，在目前这个历史条件下，前述那个完全云原生架构下的工作场景，要想达到每个环节背后的服务都丝滑稳定，同时还能有一批把云原生能力用得游刃有余，跟现有工作做到无缝衔接的用户，还是有很长的一段路要走。暂时的，你可以把上述场景当成是一个很美好的愿(da)景(bing)来保持期待，未来的某一天，彻底的“云原生舒适”体验，一定会实现的！
而在实现云原生舒适的那一天之前，从非云到云化过程中都有哪些坑，存在着哪些技术、文化、和使用习惯上的障碍，我会择日单独开一篇展开。
敬请期待
以上是关于云原生架构到底是个啥？的主要内容，如果未能解决你的问题，请参考以下文章