云原生有什么用？一文带你了解云原生四要素！ Posted 2021-05-20 联奕云原生
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了云原生有什么用？一文带你了解云原生四要素！相关的知识，希望对你有一定的参考价值。
从云原生的概念中，我们总是能看到持续交付、DevOps、微服务、容器等技术的出现，那么它们到底是什么，这里引用Pivotal台湾云计算资深架构师的部分观点，为大家逐一揭开他们的神秘面纱！
首先是持续交付，什么样的时候客户要求持续交付？敏捷开发要求持续交付，因为敏捷开发要求随时有一个版本可以上到大群环境，所以要持续交付。
换句话说，持续交付就是不误时开发。
举一个例子，有些公司非常喜欢谈需求，谈很久，可是开发只剩1/3时间就开发完成，然后交付，再上线运营。
这就会碰到一个问题，就是你开始谈需求到最后交付产品的时间，短则三月，长则半年，这中间市场已经变化了，需求也随之变化了。
因此市场上出现了新的想法：是不是能够小步快跑，把交付的周期缩短一点，我可以实现快速交付，每次交付都可以重新确认方向，这样尽量避免与未来期待的落差。
那么问题来了，持续交付对于开发的人谈的需求、开发的方式有改变，那它对于开发有影响吗？
如果说公司的开发团队一天可以交付五次，那研发团队要帮忙部署一次吗？现在公司大部分部署都是研发团队帮忙部署应用的，研发团队部署五次，要改版五次就需要部署一次，这是无法实现的。
而且每次部署的时候都要面对停机，而实际公司的应用经不起一天停机五次部署，在互联网的思维之下，零宕机时间已经是现在企业的基本要求。于是“蓝绿部署”的概念营运而生。
即在一个环境里面，第一版还在线上服务，第二版先做封测，封测完成后，让外面的流量进来一些，看log是不是开发人员要的，确认后再把全部的流量导到新的版本上。
但“蓝绿部署”在系统过多过复杂的情况下，在传统架构上实现非常困难，所以企业要做到zero down time的持续交付就需要有良好的平台與工具协助。因此，持续交付的优势在于，它可以缩小开发者认知，重新确认开发方向。
微服务是什么？有客户表示，提供商出产品，客户把应用全部放上去，结果就是一个微服务。这种认知是错误的，因为微服务是一个架构的改变。那么微服务是怎么做的呢？它所面临的最大挑战是什么？
是切割。那么如何切割呢？其实这件事情早在1968年康威就提出了——康威定律，系统的服务划分应该是根据组织架构的功能来划分。1968年康威就提出了这个想法，我认为拿来做微服务的切割非常适用。
Going Agile - Breaking the monolith
Conway's Law and Microservices
1.内聚更强，所有遵循同一种业务准则的人内聚在一起，就容易解决问题。
2.服务解耦，变更容易，更加敏捷。当做到解耦合的时候，要变更就容易。所以微服务应该是切分成这个样子，由上而下来切，根据Function来切。
另外一个划分微服务的技巧，可以运用领域驱动设计(Domain Driven Design)的理论，而领域驱动设计亦可算是面向物件的一种设计思维；聚合可以让微服务划分更有依据，也让未來的系统变更具有弹性。
值得一提的是领域驱动设计，也提供微服务中的事物问题。因为过去巨石应用进行两个报数的阶段，相当容易也常见，但在微服务架构中，如何在分散的服务中进行事物就显得相当困难。利用领域驱动设计的Event Souring进行设计，是目前最好的解決办法。
1.有HA（High Available）的需求需要微服务。
2.有性能调校的需求（例如：图片的呈现或者搜寻）需要微服务。
实际上，微服务需要关注的源代码范围比较小，使得各个服务解耦、变更容易，内聚更强，因为都会集中在服务里。另外，它更容易单独改版，因为微服务之间是用RESTful间接起来的，用RESTful只要API的界面不改，原则上则不会错，也更敏捷。
在机器上运行的容器只是主机操作系统上的一个进程，与任何其他进程无异。那么，为什么容器如此受欢迎呢？原因在于这个进程被隔离和限制的方式，这种方式很特殊，可简化开发和运维。
其实1979年就有容器技术，很多人会以为说Docker是不是等于容器，其实Docker不等于容器。容器的历史可追溯到Linux操作系统，容器利用了Linux的内核功能，Linux中容器的核心概念（cgroup、namespaces和filesystems）在独立的区域运行。容器的神奇之处在于将这些技术融为一体，以实现最大的便利性。
VMware之前的技术专家在2011年发展出一个技术，把这个技术贡献出来成立了一个Cloud Foundry基金会。Docker在2013年才开始有，而且它第一版是用SLC的技术去做的。后来陆续一路成长，使得为服务的实现更容易了。
从上面这个表中可以看出，从左边开始，IaaS，虚拟化技术有了之后，刚刚提到的所谓第三代平台，这四个区块开发人员交付的内容不一样。所有的IaaS、CaaS、PaaS、FaaS一路的变化演进，对于客户的负担越到后面越小，而对于开发人员的想象力则愈发抽象。
大家一定会遇到下列这些计算，单体应用，或者翻译成巨石应用。也一定会遇到一些批次的管理，另外就是所谓的数据库的部分，开始可能会有容器技术，像K8S、Dock。
Docker是软件行业最受欢迎的软件容器项目之一。思科、谷歌和IBM等公司在其基础设施和产品中使用Docker容器。
Kubernetes是软件容器领域的另一个值得关注的项目。Kubernetes是一个允许自动化部署、管理和伸缩容器的工具。为了便于管理其容器，谷歌建立了Kubernetes。它提供了一些强大的功能，例如容器之间的负载均衡，重启失败的容器以及编排容器使用的存储。
容器为云原生应用程序增加了更多优势。使用容器，你可以将微服务及其所需的所有配置、依赖关系和环境变量移动到全新的服务器节点上，而无需重新配置环境，这样就实现了强大的可移植性。
DevOps不是一种工具，DevOps其实要谈的是运维合一。
DevOps如果从字面上来理解只是Dev（开发人员）+Ops（运维人员），实际上，它是一组过程、方法与系统的统称。其概念从2009年首次提出发展到现在，内容也非常丰富，有理论也有实践，包括组织文化、自动化、精益、反馈和分享等不同方面。
首先， 组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计。
其次， 自动化是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代。再次，DevOps的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合作。
总之， DevOps强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理，从而更快、更频繁地交付更稳定的软件。 在内部沟通上，你可以想象DevOps是一个敏捷思維，是一个沟通的文化。
当运营和研发有良好的沟通效率，才可以有更大的生产力。如果你的自动化程度够高，可以自主可控，工作负担降低，DevOps能够带来更好的工作文化、更高的工作效率。
综上所述，云原生的DevOps、平台、持续交付、微服务都是云原生不可或缺的一部分，需要以全局地眼光看待问题，脱离任何一个元素，对于企业来说都是“管中窥豹”、“一叶障目”，只有加以整合才能见到云原生的全局风貌。
面对业态各异的业务上云以及碎片化的智慧校园解决方案部署，利用云原生思维和模式，构建基于云原生的奕云体系以及解决方案，势必将加速教育行业
智慧化转型。
1.《Golang Cloud Native编程》，作者：Mina Andrawos
2.《云原生应用的下一站》，作者：Jimmy Song
3.《什么是云原生应用 有哪些关键点？》，51CTO
4.《云原生架构实践》，作者：网易云基础服务架构团队
5.《见微知著：驱动云原生架构，全新应用分享》，作者：王钧平
