云原生
云原生
何谓云原生？
技术的变革，一定是思想先行，云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。
2015年云原生计算基金会（CNCF）成立，CNCF掺和进来后，最初把云原生定义为包括：容器化封装+自动化管理+面向微服务；到了2018年，CNCF又更新了云原生的定义，把服务网格(Service Mesh)和声明式API给加了进来。
可见，不同的人和组织对云原生有不同的定义，相同的人和组织在不同时间点对云原生也有不同的定义，真是乱的一匹，搞得鄙人非常晕菜，我的应对很简单，选一个我最容易记住和理解的定义：DevOps+持续交付+微服务+容器。
总而言之，符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。
云原生构建应用简便快捷，部署应用轻松自如、运行应用按需伸缩。优点不一而足，缺点微乎其微；秒杀传统Web框架，吊打祖传IT模式，实在是保命**、评优晋级不可多得的终极绝密武器。
云元素的四要素
微服务：几乎每个云原生的定义都包含微服务，跟微服务相对的是单体应用，微服务有理论基础，那就是康威定律，指导服务怎么切分，很玄乎，凡是能称为理论定律的都简单明白不了，不然就忒没b格，大概意思是组织架构决定产品形态，不知道跟马克思的生产关系影响生产力有无关系。
微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。
容器化：Docker是应用最为广泛的容器引擎，在思科谷歌等公司的基础设施中大量使用，是基于LXC技术搞的，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡，谷歌搞的，Docker和K8S都采用Go编写，都是好东西。
DevOps：这是个组合词，Dev+Ops，就是开发和运维合体，不像开发和产品，经常刀刃相见，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。
持续交付：持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。
如何云原生？
首先，云原生借了云计算的东风，没有云计算，自然没有云原生，云计算是云原生的基础。
随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。
云计算的3层划分，即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引，真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。
1.本地部署的传统应用往往采用c/c++、企业级java编写，而云原生应用则需要用以网络为中心的go、node.js等新兴语言编写。
2.本地部署的传统应用可能需要停机更新，而云原生应用应该始终是最新的，需要支持频繁变更，持续交付，蓝绿部署。
3.本地部署的传统应用无法动态扩展，往往需要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，通过共享降本增效。
4.本地部署的传统应用对网络资源，比如ip、端口等有依赖，甚至是硬编码，而云原生应用对网络和存储都没有这种限制。
5.本地部署的传统应用通常人肉部署手工运维，而云原生应用这一切都是自动化的。
6.本地部署的传统应用通常依赖系统环境，而云原生应用不会硬连接到任何系统环境，而是依赖抽象的基础架构，从而获得良好移植性。
7.本地部署的传统应用有些是单体(巨石)应用，或者强依赖，而基于微服务架构的云原生应用，纵向划分服务，模块化更合理。
可见，要转向云原生应用需要以新的云原生方法开展工作，云原生包括很多方面：基础架构服务、虚拟化、容器化、容器编排、微服务。幸运的是，开源社区在云原生应用方面做出了大量卓有成效的工作，很多开源的框架和设施可以通过拿来主义直接用，2013年Docker推出并很快成为容器事实标准，随后围绕容器编排的混战中，2017年诞生的k8s很快脱颖而出，而这些技术极大的降低了开发云原生应用的技术门槛。
虽说云原生的推介文档有引导之嫌，但面对它列举的优点，作为杠精的我亦是无可辩驳。这么说的话，云原生也忒好了吧，应用是不是要立刻马上切换到云原生架构？我的观点是：理想很丰满，现实经常很骨感，需从应用的实际需要出发，目前的问题是否真的影响到业务发展，而推倒重来的代价能否承受得来。
软件部署模式
这里我先不直接说什么云原生技术，我们先来看看软件部署模式在云原生下的方式，先直观感受一下云上技术带来的变化。如果没有直观的感觉，大家都不好理解云上技术带来的便利。
案例
以我内部一个平台系统的简化架构为例：特点：
- 系统稍微复杂一点，相关模块较多。
- 开发人员也较多，根据不同的技术栈分了多个人开发。
原文出处：云原生技术解读系列1-什么是云原生？：https://cloud.tencent.com/developer/article/1900493
传统的部署方式
下面是我们传统的部署方式，可以看到就是直接申请机器，并且做高可用互备的部署，大概需要3台到7台机器不等。遇到机器坏了也是要申请机器进行替换，再从新部署和更新路由等信息。
原文出处：云原生技术解读系列1-什么是云原生？：https://cloud.tencent.com/developer/article/1900493
云上的部署方式
下面是云上的部署方式，因为是一个内部系统，访问人数一天也就是几百人，qps并没有多大，也并不怎么消耗资源，测试环境每个模块部署只分配 0.1 核的资源，线上环境 0.1～0.5 核左右。内存就不用说了，需要的更少。CPU 的需要总共下来这么多模块也就不到 1 核资源搞定，而且不用我做备份。云平台帮我搞定，我只需要申请使用我真是需要的资源就好了。
原文出处：云原生技术解读系列1-什么是云原生？：https://cloud.tencent.com/developer/article/1900493
案例总结
从这里大家可以看出云上方式和传统方式的一点区别了吧。
总结一下：案例中我们真实需要的是什么？我们只是需要 CPU，内存和网络这些必要的资源，让我们的服务能运行起来，并且可以通过网络进行访问。
我们真实需要机器吗？扪心自问，我认为我们可以不要机器，或者说我们不关心机器，我们需要的是计算和网络资源。如果有地方可以提供高可用的计算和网络资源，我就不需要关心什么机器了。人总是这样，要解决一个问题，就需要找另外的工具和资源，又会想到能提供这种工具和资源的东西是什么，再去找，这样不断的寻找解决办法，最终可能就会形成思维定势，而忘记了最直接的解决方式。
所以在计算这块，云提供了最纯粹的解决方式，要 CPU 就给 CPU，要内存就给内存，要网络就给网络，给你你真正想要的。
总结
看了上面的介绍，大家也看出了，对于云原生的明确定义到目前还只是一个大概，定义中都说具有某些特征。但是从另一方面来看，具有的这些特征都还是比较典型的。
我从网上看到下面这个图的时候，感觉更能表达云原生的全貌和层次关系。所以我认为大家学习云原生技术可以参考这个图。
原文出处：云原生技术解读系列1-什么是云原生？：https://cloud.tencent.com/developer/article/1900493
原文链接
什么是云原生？这回终于有人讲明白了：https://zhuanlan.zhihu.com/p/150190166
云原生技术解读系列1-什么是云原生？：https://cloud.tencent.com/developer/article/1900493
