云计算普及的同时，”云原生”这个新的应用分类也随之出现。这个词越来越频繁地出现在开发者对话和技术文章中，却因为过度使用成了一个时髦词汇，反而让真正有价值的技术判断标准被淹没。从一开始就按云原生思路设计方案，企业才能真正释放云的潜力，而不是费力地把现有架构硬塞进云环境。
云原生的定义
Linux基金会给出的定义是：”云原生计算使用开源软件栈，以微服务形式部署应用，将每个模块打包成独立容器，并对这些容器进行动态编排以优化资源利用率。”
分析师Janakiram MSV则描述道：”云原生指的是基于容器的环境。云原生技术用于开发以服务为核心、以容器为载体、以微服务方式部署，并通过敏捷DevOps流程和持续交付工作流，运行在弹性基础设施上的应用。”
这些技术定义虽然准确，却容易让人只见树木不见森林。我们认为有必要跳出技术细节，从更宏观的视角来看待云原生：所谓云原生，是指一个解决方案本身具备云的核心特征。仅仅让系统”运行在云上”已经不够，云必须成为设计过程的核心考量，让方案从底层架构开始就充分利用云环境的优势。
“迁移上云”（lift and shift）是个典型的反例——把原本为传统数据中心设计的系统搬到云上，并不会带来任何云原生特性，只是把同样的架构跑在了不同的基础设施上，往往反而增加了复杂度。
如何判断一个方案是否云原生
云原生方案的核心特征在于：可以随时、按需、快速地部署、迭代和重新部署。这种灵活性是在云中快速实验和落地的基础。云原生方案还能在不中断业务的前提下动态扩缩容，在性价比和应对需求变化之间灵活调整，只为当下实际需要的资源付费。
在成本和运维层面，云原生方案同样有明显优势。大量部署和运维工作可以自动化完成，运维团队可以在任何地方统一管理软件的部署与运行，并且能方便地集成各类云工具，实现全面监控和快速故障响应。
此外，高可用是云原生方案的内在要求，但高可用意味着成本。对于确实需要极高可靠性的场景，这个代价是值得的；对于要求没那么严苛的场景，一个真正的云原生架构应该允许灵活调节可靠性级别，以匹配实际需求的成本预算。
云原生如何衡量？
在评估新技术时，应认真衡量它在多大程度上符合上述标准。重点关注数据的存储方式，以及更关键的——数据如何进出生产环境。以下几个问题可以帮助判断一个方案的云原生程度：
- 可靠性、弹性伸缩和安全性是如何实现的？
- 是否能在不影响用户和应用的情况下随时扩缩容？
- 这个方案除了易于部署，能否快速完成配置调整？
这类问题有助于揭示方案的底层架构。云原生这件事本质上是非此即彼的——不存在”追加云原生特性”这种做法。对于企业和软件厂商来说，在云上构建系统是重新审视应用与架构的机会，能让系统更灵活、更具弹性、更易扩展，也会根本性地改变容量规划、安全策略等方面的思维方式。
还需要避免两个极端：设计得过于狭窄，会导致很难适应云环境中快速涌现的新场景；一开始就为所有可能的需求过度设计，则会带来不必要的工程复杂度，拖慢项目进展，并埋下系统脆弱的隐患。
最后，不要想当然地认为来自云厂商的方案就一定是最云原生的。对每一个应用场景都应该独立评估，确认它既符合你的实际需求，也达到你对云原生的期望。
原创文章，作者：余初云，如若转载，请注明出处：https://blog.jidcy.com/jsjc/2379.html