什么是云原生？带你了解云原生的四步走

Posted 2021-04-02 万间科技

点击上方 “万间科技”  可以订阅哦！

1. 云原生的由来

云原生是过去一年里云计算最火的用词之一。几乎每一个云计算的产品厂商都会把自己的产品与云原生联系在一起。但是到底这个词是什么意思，它的具体含义是什么，其实却是非常含糊的。

云原生这个词最早在2014年左右起源于Pivotal。Pivotal是一家做PaaS服务的公司。之后在2015年夏天，Linux基金会创建了云原生基金会CNCF。CNCF在宣布成立时也没有一个关于云原生的具体定义。只是提到了一些相关的技术，包括开源，容器，微服务，编排工具。但是并没有明确地描述怎样使用这些工具开发出来的应用才可以被称作云原生的应用。时至今日CNCF也还没有提出过这个明确的定义。

于是很多公司按照自己的理解去使用这个概念。这导致在很多时候，大家是在说不同的事情。很多公司的理解是只要是涉及云的应用就是云原生。或者是可以给云服务用的工具或者产品就是云原生的。

在知乎中，2019年腾讯和阿里表达出“云大厂”对“云原生”的看法：

What？鹅厂回复的就这么“不走心”？都不给自己家产品打个广告？

我们来看下面几条新闻，才发现原来都是在蓄势待发憋大招。

9 月，阿里巴巴成立云原生技术委员会，推动阿里经济体全面云原生化；

12 月初，华为发布云原生 2.0 全景图，并预测，到 2025 年，所有企业信息技术解决方案都会被云化，85% 以上企业应用会被部署到云上；

12 月 20 日，腾讯发布了云原生路线图，从开发、计算、架构、数据、安全的维度重新定位了云原生。值得关注的是，这份落地路线图，首次梳理了腾讯与企业共同落地的典型案例，从实践角度诠释了云原生改造的全过程。

2. 腾讯云原生改造路线

大量企业云原生化改造的过程并非一蹴而就，往往会选择一种稳妥的方式逐步迭代进行，尤其是传统企业，系统规模大、关联关系复杂、网络架构复杂、技术架构传统。业务部门要求系统可伸缩、支撑数据的快速增长，又不额外增加成本。技术部门考虑破除商业产品的锁定的方案、拥抱开源，还希望上云后的服务质量不比商业产品差。

一般的做法是，先拿一些简单的模块试水，摸清路数后再逐步进入深水区，完成企业整体云原生技术改造。那么问题来了，企业在云原生改造过程中，一般会经历哪些阶段？每个阶段的侧重点是什么？会用到哪些技术或产品？改造后的衡量标准怎么定？

腾讯把云原生改造分为 4 个阶段，分别是： 开发云原生、计算云原生、架构云原生、数据云原生，在这个过程中，安全云原生为整个改造过程以及之后的系统运营提供数据安全及稳定性保障。

3. 云原生第一步-开发

这一阶段的重点是解决“企业研发运维流程效率”问题。在传统的开发模式中，研发人员需要了解和学习不同 API 的具体使用方式和含义，开发完成还需要负责编译、打包并申请资源，过程复杂且耗时良久。运维技术支持不足、流程不完善、缺少监管手段等，也让运维过程缓慢低效。

以腾讯自身的云原生实践为例，最先切入的点就是软件研发运维流程。之前来自技术团队各方面经常会听到一些抱怨，开发人员说环境太少，构建发布流程太慢；测试人员抱怨太多非标准版本或者发布，版本质量不可控；运维人员埋怨发布不可控，疲于救火。正是因为大家在这里都很痛，并且涉及到大部分团队成员，就很容易快速推进。

这个阶段完成的好与坏，有两个关键的衡量标准：

第一，企业的组织架构、研发运维流程是否符合 DevOps 理念，是否能够支持企业对应用进行快速的迭代、测试、发布、试错和优化；

第二，是否能建设和使用软件流程中的工具平台，提升团队协作效率，同时根据流程规范搭建一个自动化的“构建 - 测试 - 灰度发布”平台，减少因为“人”的因素导致的低效或者失误。

4. 云原生第二步-计算

这个阶段有两个关键词：“容器化”、 “Serverless 化”。改造目标是降低对 IaaS 层的异构和差异、资源的部署和调度 (包括计算资源、网络资源、存储资源) 的关注。

这个阶段涉及的业务模块大多与“数据”相关度低，比如无状态类服务 (Web 网站、接入 层服务、逻辑层服务等)，消息触发类服务 (转码、定时任务等)。所以往往改造成本较低，灰度验证也容易，一旦出现问题也能够快速恢复。改造成本和风险较低，也最适合在云原生改造初始阶段切入的地方。

这个阶段同样有 3 个关键的衡量标准，在改造完成后，我们的业务模块能否具备：

第一，极致的调度能力包括：自动伸缩、跨界点、跨集群、跨机房的调度等；

第二，全面的故障容灾能力包括：业务、节点、机房的容灾；

第三，极简的运维模式，需要屏蔽 IaaS 差异和具备 Serverless 计算能力。

5. 云原生第三步-架构

这个阶段会深入到复杂的软件架构层面，伴随着微服务化和架构改造，因此难度较大，但收益也会更大。

在改造过程中，一些成熟的框架服务的使用，能让改造事半功倍。例如微服务平台、服务网格、云开发 TCB 等，它们集成了很多运维能力，包括日志、监控、服务注册和发现、故障容灾等。除了提高研发效率外，也能提升改造后系统的整体运维能力。

在这个阶段其实也有两个关键的衡量标准：

第一，整个架构的微服务化改造是否拆分到位，流量是否可以调度、可以治理、可以观测；

第二，企业的研发和运维模式是否极简，企业能否聚焦在业务逻辑本身的开发和运维上。

6. 云原生第四步-数据

在这个阶段，企业的云原生改造已经进入到深水区，目标是将 Kubernetes、Serverless 的技术和理念应用到“数据服务”中，让“数据服务”也具备极致的弹性伸缩能力，在资源成本上能够做到最优。

这个阶段有三个关键的衡量标准：

第一，数据服务的计算与存储是否分离，存储是否可以支持不同存储介质；

第二，数据服务的算力资源是否能够真正做到按需分配，按量计费，并且在需要的时候自动且快速自动扩充；

第三，数据算力与在线业务能否做到混部技术，最大限度的提升资源利用率，降低我们企业的成本。

7. 云原生第五步-安全

企业在进行云原生化建设的同时，安全能力应贯穿云原生的整个生命周期，这称之为“安全云原生”。

在开发阶段，提供集成的代码级安全及合规检测能力，提前发现风险隐患，或通过向开发者提供安全 SDK，使产品具备内生安全能力。处于发布阶段的制品 (例如容器镜像) 需要持续地进行自动扫描和更新， 从而避免遭受漏洞、恶意软件、危险代码以及其它不当行为的侵害。完成这些检查之后，应该对制品进行签名来保障其完整性和不可否认性。

在部署阶段，集成的安全性能够对工作负载的属性进行实时的持续验证 (例如完 整性签名、容器镜像和运行时的安全策略等)。在上线运行阶段，能够提供对应用、服务和工作负载的运行时 防护、并通过态势感知能力和云平台的灵活、弹性机制，对网络安全事件进行实时自动化响应并进行协同处置，帮助客户实现高效的安全防护及合规。

安全云原生部署达标参考标准:

第一，代码安全漏洞和开源合规检测；

第二，自动化镜像加固及扫描 ; 镜像签名及安全 策略的实时校验；

第三，应用、服务、工作负载的动态可弹性扩展运行时防护；

第四，安全事件的自动化响应。

8. 最后

现代企业的 IT 规划要面对两个紧迫事实，一是当前的客户需求、行业竞争状态已和 20 年前、10 年前全然不同，企业业务的更新速度很多已经从以周为单位提升到按小时计；二是云原生是新生事物，企业技术人员从零学习、到消化吸收、再到创新都需要人力成本和技术试错成本。

当面临着行业竞争紧迫、技术试错成本和人才培养成本的三大压力，找到一个合适的参照，以此为基础迭代自己的业务解决方案和产品技术架构，是当前很多企业所需要的操作。

欢迎转发，建议收藏学习！

扫码关注，万间持续放送！

阅读原文，深入了解应用！