注：今天阅读整理了infoQ发布的《云原生的技术探索和落地实践》。这本指南只是对其中一些重要内容的重新思考，我就不重复书中的细节了。电子书可以在infoQ网站上免费下载阅读。
InfoQ在2020年底发布了《云原生的技术探索与落地实践》研究报告。基于InfoQ对云原生技术生态的深度观察，本报告从技术演进、业务战略创新、业务价值释放等方面为大家提供了“云原生”的全景图。梳理技术发展脉络，分析商业创新模式，了解行业实践的红利释放，看“云原生”浪潮如何吞噬旧秩序，重塑新世界。
电子书的整体目录结构如下：
一、云原生概述
1.云诞生：云计算的下一站
2.云原生前世
3.云原生价值链生态
二、主要云原生技术
1.云原生底层技术
2.安排和管理
第三，云原生走向基于开源战略的新竞争。
1.开源社区是实践平台化战略的最佳场所。
2.开源战略是构建技术生态系统的有效途径。
四是云原生技术的落地和应用
1.云原生创新技术解决方案和产品
2.各行各业的云原生应用
动词（verb的缩写）未来前景
该书可从infoQ网站下载，网址如下：
https://www.infoq.cn/minibook/GaaadEVc7hFNLpRAiBU7
00-1010云原生的基本概念在此不再赘述，包括在之前的文章中，我也提到过，对云原生的简单理解是一系列技术最佳实践(微服务、容器、CI/CD、DevOps)和管理最佳实践(敏捷研发、康威定律)的集成。
云的原始本质
这本书里说云原生是一种指导软件架构设计的思想。这个提法没有错，但一定有属性。也就是说，云原生是一种架构设计思想，指导软件在云中诞生，在云中成长，在云中运行和管理。Zjdkfd按照这个思路设计软件，那么软件就可以充分利用云平台的弹性可扩展性、高可用性等能力。
当你想清楚这一点时，你可以清楚地看到以下要点。
例如，软件是如何诞生在云上的？
简单来说，软件要充分利用云平台提供的能力。前期这个能力只是IaaS资源池提供的资源，但在云原生阶段，一定是PaaS层提供的技术服务能力。简单来说，只要云平台能提供技术服务，就不要申请资源来实现这种技术服务。
其次，软件要充分利用云平台的弹性扩展能力、传统单一应用开发、传统应用虚拟机自行安装数据库和中间件。其实这种自动弹性膨胀能力是不具备的。其次，传统的单一应用本身规模大，载体是部分权重的虚拟机，资源调度本身很难敏捷高效。正是因为这个原因，云平台希望传统的单一软件可以拆分，也就是在之前采访中讨论的扩展立方体架构中，除了资源的基本弹性扩展之外，云平台希望软件本身可以拆分业务模块和数据库的微服务，提高自动扩展能力。
第三，在传统的软件开发和部署中，软件开发通过测试后，需要申请资源，然后手工完成部署和配置。也就是说，开发、运营、运维三个关键阶段是脱节的，需要大量的人工操作和沟通协调。云原生的一个重要思想是，只要按照云原生技术的要求和标准来开发软件，那么软件自然就会在云平台上生长和运行，也就是软件开发、测试和最终交付的过程是自动化的，你不需要在意。
由此可见，微服务、DevOps、容器技术、敏捷研发等最佳实践。都是关于架构设计和技术管理的调整和优化，以便软件在cl上更好的发展
由于云原生是一系列技术和管理最佳实践的结合，我们可以看到云原生本身不会产生任何新的东西。类似微服务、持续集成和持续部署、容器技术、敏捷研发、自动化测试等。都是多年来提出并成熟的最佳实践。
云原生的一个核心能力是基于Docker的容器云的PaaS平台，所以书中也给出了PaaS平台本身的一个发展演变过程。
从最早的基于虚拟机的资源调度平台，实现了像Cloudfoundry或Cloudify这样的开源PaaS平台。随着Docker轻量级容器技术的广泛应用，与Docker合作出现了容器编排、资源调度、微服务治理等关键内容。
然而，这一个忽略了PaaS平台发展的一个重要变化，即从传统的应用托管PaaS平台向提供多样化技术服务能力的厚PaaS平台转变。
我在讲企业私有云的PaaS平台的时候说过，企业私有云PaaS就是厚PaaS，它不仅提供消息、缓存、流程引擎、4A等常见的技术服务能力，还提供常见的业务服务能力。对于公共云PaaS平台，除了业务服务能力之外，
也完全可以提供类似消息，缓存，文件，通知等各种技术服务能力。从传统虚拟机到轻量容器时代，是PaaS一个重要发展趋势。
在底层虚拟资源轻量化后，上层的应用托管和基于资源的动态调度也同样轻量化和高效，也就是持续了基于容器的托管部署，容器编排技术，如当前的Kurbernetes来实现分布式资源调度和自动化运维。
云原生的价值链生态
从技术发展的价值链演进来看，云原生是云计算应用价值的延伸，解决更贴近企业业务、架构、组织层面的关键问题。
在云计算逐渐由资源中心演变为创新技术熔炉的过程中，云原生更进一步，帮助企业将应用和业务“云化”，解耦业务和基础设施，只关注业务逻辑和价值，将非业务逻辑的复杂性下沉到基础设施，使基础设施更高效、更高性能、更稳定可靠，从而更充分释放云的价值。
简单来说，传统公有云平台大量应用场景是在SaaS应用和互联网，而以后公有云平台将大量应用到传统行业数字化和信息化建设，智慧城市中的交通，政务，医疗等各个垂直行业应用中。
即云平台要帮助企业业务和IT能力的云化，协助企业全面上云，充分地使用到云平台提供的各种能力优势。在这个过程中云原生会做好各种迁移，架构调整，云端持续交付等各项工作，其目的都是协助企业上云。云平台希望达到的一个目标就是业务和技术要充分解耦，只要和业务无关的技术层面内容都能够下沉到云平台以服务方式提供。
那么应用开发只关注业务，不关注技术能力实现，是否应用或微服务的开发过程就比原来简单了呢？对于这个问题我们简单总结如下：
搞清楚云平台提供哪些技术能力，并搞明白使用和消费场景，如何集成，这个过程仍然相当复杂，但是在完成第一轮的集成后，后续的持续集成和交付一定简单。
主要云原生技术
从技术需求的角度来看，微服务架构是解决单体复杂度问题的首选方式，却带来整个系统的整体复杂度大幅增加，容器技术和 Kubernetes 分别解决了微服务架构下大量应用的部署、以及容器的管理和调度问题，同时，Kubernetes 也为 ServiceMesh 提供了更好的底层支撑，也带来了底层基础设施的 Serverless 云原生化和中间件能力的进一步下沉。
再回到扩展立方体的架构思路。
对于传统的单体应用只能够通过集群等水平复制方式进行扩展，这种扩展方式最大的问题点仍然在于数据库往往存在扩展瓶颈，其次就是单体太大后对变更不友好。而引入微服务架构后接近了另外两个维度的扩展，其一是单体拆分为多个微服务的功能扩展，其二是数据库也拆分进行数据层面的扩展。
引入微服务后虽然接近了扩展性问题，但是同样由于微服务拆分，整体的集成，部署，交付难度指数级增加，如果再使用传统的人工方式来完成集成和部署，完全无法适应。这也是后续出现DevOps，容器和资源编排等各种技术支撑的一个关键。
当我们采用一个新技术来解决一个业务问题的时候，往往需要引入更多的能力来支撑新技术，否则新技术也无法很好的落地。
这也是在前面强调过了，虽然微服务架构实施没有强制约束一定要DevOps和容器化，但是为了微服务更好的落地，往往这些云原生技术反而是必须具备的技术支撑能力。
容器技术
容器是将进程有效地划分成一个独立空间，以便在独立的空间之间平衡资源使用冲突的技术。本质上，容器是一种特殊的进程，其核心功能是通过约束和修改进程的动态表现创造出一个“边界”，此外，其资源限制能力、以及基于镜像功能表现出的“强一致性”，都使得容器技术成为云原生最关键的底层技术之一。
容器技术简单来讲就是在共享 OS操作系统层的情况下还能够实现资源和进程间的隔离。具体容器技术方面的内容在这里不再展开。
容器编排
Kubernetes 项目的主要设计思想在于，从更宏观的角度，以统一的方式来定义任务之间的各种关系，并且为将来支持更多种类的关系留有余地。从功能的角度来看，Kubernetes更擅长按照用户的意愿和整个系统的规则，自动化地处理好容器之间的各种关系，即容器的编排，包括部署、调度和节点集群间扩展等主要功能。
简单来说，Kubernetes本身是构建了一个高可用的分布式集群，对于容器都是集群管理的各个节点对象。其次才是实现了基于容器的动态部署，基于容器的资源动态调度能力。
对于Kubernetes可以理解为容器云时代的核心PaaS平台能力，起到很好地承上启下作用，在整个微服务的持续集成和交付过程中，可以看到微服务模块和应用与底层的IaaS资源之间，核心即是通过Kubernetes来完成集成和协同。比如在进行微服务部署的时候，实际是通过调研Kubernetes提供的API接口服务来完成。
微服务
目前为止，微服务并没有统一的标准定义，结合 Martin Fowler 描述：微服务架构是一种架构模式 / 架构风格，将单独的应用程序开发为一套小服务并独立运行在自己的进程中，相互之间使用 HTTP API 等轻量级机制通信。这些服务围绕着具体业务进行构建，通过完全自动化部署机制来独立部署，并可使用不同的编程语言书写，以及不同数据存储技术，并保持最低限度的集中式管理。
微服务架构本质上是通过承受更高的运维复杂度来换取更好的敏捷性，其优势在于小而治之、去中心化，但也导致基础架构的需求、成本和复杂性激增。
ServiceMesh服务网格
Service Mesh 通常被译为服务网格，在云原生应用复杂的服务拓扑结构中，Service Mesh 作为基础设施层，负责在这些拓扑结构中实现请求的可靠传递。Service Mesh 通过在请求调用的路径中增加Sidecar，将原本由客户端完成的复杂功能下沉到Sidecar 中，实现对客户端的简化和服务间通信控制权的转移，当系统中存在大量服务时，服务间的调用关系表现为网状，这也是服务网格名称的由来。
在微服务和容器化后，为了彻底的去中心化，同时又需要实现微服务治理和管控，那么ServiceMesh一定是一个最终的发展趋势和路径。虽然现在ServiceMesh本身应用还不足够的普遍和成熟，但是技术趋势一定如此。Sidecar边车代理的下沉通过Kubernetes的自动部署可以完全做到对微服务应用开发和交付的黑盒，这个才是服务网关最大的价值。
云原生中间件
这个地方电子书里面重点介绍了消息中间件，实际这里改为叫云原生技术服务平台更好合适，即类似消息中间件，缓存，对象存储，调度，通知，文件，数据库等都属于PaaS层可以提供的核心技术服务能力。
云原生中间件是将传统公有云PaaS转变为厚PaaS技术平台的一个关键组成。
DevOps研发运维一体化
DevOps作为Development 和 Operations 的组合，被定义为实现软件开发和组合 IT 团队之间流程自动化的一组实践，这些实践建立在团队之间协作文化的基础上，填补了开发端和运维端之间的信息鸿沟，以便更快、更可靠地构建、测试和发布软件，目前已经成为主流的软件开发交付模式。
对于DevOps我前面很多文章都谈到，在这里不再展开。
云原生技术的落地和应用
建议这块参考阿里云发布的云原生技术白皮书，里面也有详细的云原生落地实践和应用案例分析。而infoQ电子书这部分的内容整体感觉完全是打广告，在这里不再展开。
实际上企业进行微服务架构转型，或者说实施云原生和全面上云是一个相对困难的事情，特别是企业本身的信息化技术基础薄弱，治理能力跟不上的时候更是如此。很多企业连传统的单体应用架构和集成都做不好，却要马上去实施微服务架构和容器云集成，这些都是相对不现实的事情。
对于企业如何上云，我在前面专门写过两篇文章供参考：
云原生-企业IT和软件架构发展演进和全面上云
数字化转型中企业真正困惑-传统IT架构如何改造和全面上云
你要真正实施云原生，简单来说还是要将类似敏捷研发管理，持续集成和持续部署，微服务开发和接口集成，容器云等各个核心要素先做好，再来考虑这些技术和管理要素之间如何更好的集成和协同。