【总结】校招版-云原生

面试被问到的公司：字节跳动-基础机构-后端开发、腾讯-IEG-后端开发、百度-ACG-Java研发等；

面试被问到的问题：

了解云原生吗？简单讲一下自己的理解？现在为什么都在提云原生？
主要的技术有哪些？哪些是自己用过的？
什么是微服务？微服务的好处？
K8s和Docker的好处？为什么要用Docker？Docker

一、什么是云原生

云原生从字面意思上来看可以分成云和原生两个部分。
云是和本地相对的，传统的应用必须跑在本地服务器上，现在流行的应用都跑在云端，云包含了IaaS、PaaS和SaaS。
原生就是土生土长的意思，我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的，要充分利用云资源的优点，比如️云服务的弹性和分布式优势。

总结：云原生是基于分布部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。云原生应用也就是面向“云”而设计的应用，在使用云原生技术后，开发者无需考虑底层的技术实现，可以充分发挥云平台的弹性和分布式优势，实现快速部署、按需伸缩、不停机交付等。

1. 微服务

微服务解决的是我们软件开发中一直追求的低耦合+高内聚，记得有一次我们系统的接口出了问题，结果影响了用户的前台操作，于是黎叔拍案而起，灵魂发问：“为啥这两个会互相影响？！”

微服务可以解决这个问题，微服务的本质是把一块大饼分成若干块低耦合的小饼，比如一块小饼专门负责接收外部的数据，一块小饼专门负责响应前台的操作，小饼可以进一步拆分，比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼，这样每个小饼出问题了，其它小饼还能正常对外提供服务。

2. DevOps

DevOps的意思就是开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。我们现在开发和运维已经是一个团队了，但是运维方面的知识和经验还需要持续提高。

3. 持续交付

持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用，要做到这点非常非常难。我们现在两周一个版本，每次上线之后都会给不同的用户造成不同程度的影响。

4. 容器化

容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护，现在比较流行的工具是docker和k8s。

Docker是一个开源的应用容器引擎，开发者可以打包他们的应用及依赖到一个可移植的容器中，发布到流行的Linux机器上，也可实现虚拟化。
k8s是一个开源的容器集群管理系统，可以实现容器集群的自动化部署、自动扩缩容、维护等功能。

所以你也可以简单地把云原生理解为：云原生 = 微服务 + DevOps + 持续交付 + 容器化

二、云原生能带来什么

1.相比于传统应用，云原生应用意味着统一：

统一的技术标准：通常以微服务架构进行服务开发，服务之间使用标准的API契约进行通信。松耦合的架构方式会减轻因需求变更导致的系统迭代成本，并加快交付速度。

微服务倡导基于API接口通信，避免在服务间共享数据库，文件等有状态的实体。单个服务能独立的更新，扩展，重启而不影响其他服务。
微服务使得单个服务的开发团队更小，也更加独立。亚马逊内部采取2个披萨原则——即团队规模维持在刚好两个披萨能够吃饱，来限定团队规模。团队沟通成本可以维持在较低水平，同时每个人都承担富有挑战性的工作。
松耦合+独立小型的团队使得持续更新和敏捷管理协作成为可能，因此微服务成为了云原生应用的最佳开发实践之一。

统一的交付方式：标准容器化的打包方式实现了真正的应用可移植性，不依赖于特定的基础架构（虚拟机，混合云等）。

容器技术起源于linux的进程隔离虚拟化技术，将一组进程单独限定在同一个资源目录下，并可以限定其资源使用的配额。
Docker的出现将应用的整个运行时环境都打包成一个镜像文件，并基于容器本身的隔离特性，实现了应用在特定容器中可以轻松的在不同环境间移植，同时确保宿主机的安全。
在资源有限的场景，容器基于进程粒度的资源使用方式，也会降低系统的资源开销。
基于容器的应用将有助于构建统一的开发，交付和集成环境，是云原生应用的最佳交付载体。

统一的运维部署：基于容器的编排平台，可以充分利用不可变基础设施的特性。这使得在传统运维模式中的复杂部署策略（如灰度，蓝绿）变得轻而易举。

容器编排平台提供的自动化运维特性和声明式资源管理方式简化了持续构建中工具链之间的协作和调度。
容器编排带来的弹性伸缩能力和容错调度能力也让智能化运维成为可能。
技术驱动下的敏捷协作，和编排平台带来的运维能力共同构建了云原生应用的最佳运维实践——DevOps

云原生应用VS传统应用：

云原生应用	传统的企业应用
可预测；云原生应用符合旨在通过可预测行为最大限度提高弹性的框架或“合同”。云平台中使用的高度自动化的容器驱动的基础架构推动着软件编写方式的发展。第一次作为 12 因素应用记录的 12 个原则就是阐释此类“合同”的良好示例。	不可预测；传统应用的架构或开发方式使其无法实现在云原生平台上运行的所有优势。此类应用通常构建时间更长，大批量发布，只能逐渐扩展，并且会发生更多的单点故障。
操作系统抽象化。云原生应用架构要求开发人员使用平台作为一种方法，从底层基础架构依赖关系中抽象出来，从而实现应用的简单迁移和扩展。实现云原生应用架构最有效的抽象方法是提供一个形式化的平台。Pivotal Platform 非常适用于在谷歌云端平台、微软 Azure 或亚马逊云服务等基于云的基础架构上运行。	依赖操作系统。传统的应用架构允许开发人员在应用和底层操作系统、硬件、存储和支持服务之间建立紧密的依赖关系。这些依赖关系使应用在新基础架构间的迁移和扩展变得复杂且充满风险，与云模型相背而驰。
合适的容量。云原生应用平台可自动进行基础架构调配和配置，根据应用的日常需求在部署时动态分配和重新分配资源。基于云原生运行时的构建方式可优化应用生命周期管理，包括扩展以满足需求、资源利用率、可用资源编排，以及从故障中恢复，最大程度减少停机时间。	过多容量。传统 IT 会为应用设计专用的自定义基础架构解决方案，这延迟了应用的部署。由于基于最坏情况估算容量，解决方案通常容量过大，同时几乎没有能力继续扩展以满足需求。
协作。云原生可协助 DevOps，从而在开发和运营职能部门之间建立密切协作，将完成的应用代码快速顺畅地转入生产。	孤立。传统 IT 将完成的应用代码从开发人员“隔墙”交接到运营，然后由运营人员在生产中运行此代码。企业的内部问题之严重以至于无暇顾及客户，导致内部冲突产生，交付缓慢折中，员工士气低落。
持续交付。 IT 团队可以在单个软件更新准备就绪后立即将其发布出去。快速发布软件的企业可获得更紧密的反馈循环，并能更有效地响应客户需求。持续交付最适用于其他相关方法，包括测试驱动型开发和持续集成。	瀑布式开发。 IT 团队定期发布软件，通常间隔几周或几个月，事实上，当代码构建至发布版本时，该版本的许多组件已提前准备就绪，并且除了人工发布工具之外没有依赖关系。如果客户需要的功能被延迟发布，那企业将会错失赢得客户和增加收入的机会。
独立。微服务架构将应用分解成小型松散耦合的独立运行的服务。这些服务映射到更小的独立开发团队，可以频繁进行独立的更新、扩展和故障转移/重新启动操作，而不影响其他服务。	依赖。一体化架构将许多分散的服务捆绑在一个部署包中，使服务之间出现不必要的依赖关系，导致开发和部署过程丧失敏捷性。
自动化可扩展性。大规模基础架构自动化可消除因人为错误造成的停机。计算机自动化无需面对此类挑战，可以在任何规模的部署中始终如一地应用同一组规则。云原生还超越了基于以虚拟化为导向的传统编排而构建的专用自动化。全面的云原生架构包括适用于团队的自动化和编排，而不要求他们将自动化作为自定义方法来编写。换句话说，自动化可轻松构建和运行易于管理的应用。	自动化可扩展性。大规模基础架构自动化可消除因人为错误造成的停机。计算机自动化无需面对此类挑战，可以在任何规模的部署中始终如一地应用同一组规则。云原生还超越了基于以虚拟化为导向的传统编排而构建的专用自动化。全面的云原生架构包括适用于团队的自动化和编排，而不要求他们将自动化作为自定义方法来编写。换句话说，自动化可轻松构建和运行易于管理的应用。
快速恢复。容器运行时和编排程序可在虚拟机上提供动态的高密度虚拟化覆盖，与托管微服务非常匹配。编排可动态管理容器在虚拟机群集间的放置，以便在发生故障时提供弹性扩展和恢复/重新启动功能。	恢复缓慢。基于虚拟机的基础架构对于基于微服务的应用来说是一个缓慢而低效的基础，因为单个虚拟机启动或关闭的速度很慢，甚至在向其部署应用代码之前就存在很大的开销。

即：

2.云原生化的云服务平台，不仅能够显着的降低基础建设与管理成本、提高布署灵活性与可扩充性，而且还有较高的安全性。

在微服务化方面：云原生将应用程序代码解耦成独立模块化单元，降低微服务的部属时间与互依性，提高应用的扩展性等。
在容器化包装方面：过去程序开发者可能需要创建多个虚拟机好让不同的应用程序运作，但程序容器化让多个应用程序得以存在同一操作环境中，开发人员将代码、微服务放置在可复制、搬移的容器中，轻松地复制、发布到任意云平台，多个容器间不会互相干扰（沙盒机制），不仅减少管理工作还能更有效地利用硬件资源，实现更快的持续集成、交付与发布。
在动态管理方面：通过集中的编排调度系统进行动态管理和调度，达到高速、低风险、迅速扩展和部署的方式，进行应用或服务的构建、测试、部署。

借助以上优势以及相对一致的实践方式，云原生能快速的打通各家云环境的壁垒，企业可以对市场变化做出最快的反应，使得新创云原生企业拥有能不断颠覆传统企业的威力。

三、云原生作用

对于应用开发团队而言，原来云原生技术可以提升应用开发的效率，提升应用交付的质量。比如通过容器，技术开发团队可以更容易地获取开发所需要的环境与资源，开发出来的应用可以被运维团队更容易地部署和管理。通过DevOps的最佳实践，应用交付的速度和质量可以被有效的提升。
对于业务方来说，云原生的好处是所提交的需求,可以更快地被响应和实现。因为云原生技术可以有效地缩短应用交付的周期，让需求更快地变成代码,代码更快地变成线上的应用，最终为用户服务，实现价值。

云原生应用可以更好地弹性扩展，满足不同业务的需求。例如容器应用提供的应用自愈能力，可以帮助减少应用的停机时间提升用户的体验。
云原生技术可以提升应用开发的交付效率，缩短应用。上线所需要的时间，开发和业务团队人员可以有更多的时间和精力进行业务创新，有效地提升团队的创新能力，从而提升企业在市场的静能力。

四、云原生涉及的技术领域

容器( Containers )：容器是一种轻量级的虚拟化技术，通过容器可以简化应用的部署、管理和交付。目前各大IT厂商已经投入了大量的资源进行容器产品和服务的研发，可以预见，未来容器将会是一种主流的应用交互手段，非常有前景。
微服务( Microservices )：微服务倡导运用化整为零，实现各个功能的独立开发与部署、提升应用架构的灵活性，从而提升对业务的响应速度。在提倡敏捷的今天，微服务已经成为应用架构的一种默认的选择。
无服务( Serverless )：无服务器架构并不是说,未来不再需要服务器，而是不再着重关注底层的基础架构，更多的注意力可以放在和业务更相关的一些逻辑实现上，例如一些函数的代码片段,平台自动根据负载按需部署和启动，以及自动伸缩代码逻辑来满足业务处理的需求。
DevOps：DevOps这个框什么都可以往里装，提供了指导思想、流程和工具，为应用的迭代更新保驾护航，运维行业的未来之路。
Service Mesh(服务网格)：Service Mesh是近年兴起的一个话题,在容器微服务的基础上，通过Service Mesh可以让用户更精细、更智能的去管理服务之间的通讯。ServiceMesh社区的旗舰项目Istio，当前的热度正在迅速的飙升。
云(Cloud)：云是云原生的基础，没有云也就没有云原生。没有对云正确地理解，也不可能对云原生有正确的打开方式。对于非技术人员来说，至少要理解云的多种不同的服务模型，比方laaS、PaaS、SaaS以及各种服务模型的应用场景和价值。

容器( Containers )、微服务( Microservices )、无服务 ( Serverless )、DevOps、ServiceMesh(服务网格)、云( Cloud )这6个方面，并不是孤立的，而是相互联系的。

云是一切的基础，为上层应用的运行提供了计算、网络、存储等基础架构资源；
容器在云的基础架构和应用之间，集有了应用和基础架构资源；
应用层面，用户可以根据场景来选择微服务架构或者是无服务器架构；
在复杂的交互场景当中，通过服务网格，可以对服务组建的通讯进行管控；
通过DevOps构建一个应用架构不断迭代更新的正向循环；

云原生毕竟是一个很大的概念，理论上所有从设计和开发之始就以部署在云上的设计理念都能够称为云原生，而微服务则是云原生在服务维度典型的表现形式，而容器服务即是能够将微服务成功落地的核心技术。Serverless是一个技术也可以从字面意思理解为未来的发展方向，核心理念仍然是将非业务部分的功能下沉至基础设施，从这点上来说，理想中的Serverless甚至不必包含目前K8S中的集群容量规划、安全维护和故障诊断等功能，将这些集中考虑为云基础设施所应该具有的功能，而功能模块只需考虑自身的业务，充分体现出的是轻量，通过事件驱动将轻量的服务和服务间以及轻量服务和云平台之间连接起来，整个体系相比集群化部署来说，与其说是一个系统，不如说是云基础设施基础上各类微服务形成的生态。