容器化
市场上容器产品非常多，可以简单理解为Docker，是安装在Linux上的一个软件，可以用镜像堆起来一个个应用，这就是容器技术。
容器应用部署安装与传统应用有很大不同，传统应用安装需要需要配置很多东西，例如在Windows上安装Office软件，之后不小心删掉了，想重新安装Office，有时会报错，这就是上次安装系统造成的，全新系统安装就不会有这样的问题。
相比容器化是将一个应用拆分成很多细小服务，对外提供服务，服务之间呈现松耦合的方式。修改应用，只需无限复制新版本并销毁原来容器，即可完成迭代更新。
容器可以提供很多不一样的服务，也可以提供很多一样服务，也就是横向扩展，提供控制系统的弹性伸缩。容器化解决了效率问题，如应用开发、测试、部署、迭代等都发生了天翻地覆的变化。
以互联网应用为代表，开发人员普遍采用了容器化手段和开发方法，传统行业企业数字化转型，创新业务发展也应该采用容器化的方式，传统业务应用也需要进行容器化改造。
容器化与虚拟化
容器化需要首先部署虚拟化吗？这个问题始终存在争论。有舆论认为，容器化替代虚拟化，容器化是虚拟化的大敌。
虚拟化早于容器化，以VMware vSphere、微软HyperV、开源KVM等软件为代表，传统行业企业普遍采用虚拟化技术。虚拟化技术重点解决了CPU计算资源利用率不高的问题，通过构建虚拟机，提高计算资源的利用效率。虚拟化技术是云计算技术的基础，这也是为什么云计算初期被称为虚拟化的原因。
在Intel的支持下，CPU芯片直接部署虚拟化，虚拟化虚拟物理设备，所谓虚拟机，其上安装操作系统，部署应用。
容器化和虚拟化在功能上存在一定程度重合，本意都是屏蔽CPU资源调度技术的复杂性和差异性。从目前的情况看，容器可以直接部署在物理主机上，也可以部署在虚拟机上，特别对于传统行业企业用户而言，虚拟化技术普遍采用，因此需要同时管理容器和虚拟化，相互之间存在交际。
新的元原生应用，可以直接部署物理硬件的操作系统中，由于没有虚拟化的开销，更加具有成本效率，它们凭借K8S平台对集群中的容器进行管理，这也是有舆论认为容器化将取代虚拟化的动议来源。
但是这种开销也并非绝对。以虚拟化为例，虚拟化内核与跟K8S紧密结合在一起，也就是说，在虚拟化就有对容器调度的mini资源嵌入。如此部署容器应用的时候，根本不用考虑，是部署在虚拟机上，还是部署在物理服务器上，根本不用关心底层的基础设施。有厂商数据显示：超过80%的容器部署是运行在虚拟机上，其余部署在物理服务器上，很多用户希望物理服务器资源的调配管理能够通过容器编排软件实现。也有第三方的测试显示：借助新的平台对虚拟机和Kubernetes进行管理，相比物理机裸机设备部署，有8%的性能提升，看上去匪夷所思，原因也很简单，主要得益于虚拟化对于物理资源的高效调配。
微服务：单体化应用和微服务架构的变化
微服务是相对于大型单体应用而言的。
传统的应用开发模式下，随着用户对应用陆陆续续提交新的需求，开发人员需要在原来的应用上不断添加新的功能，这个过程就相当于在一个船上不断修修补补的过程，它的功能越多，也就意味着下次改动需要注意的地方越多，一次改动可能会带来很大的影响。简单说，这是一种紧密耦合的架构。
从单体架构向微服务架构转变，与此前的垂直架构、SOA架构的开发思想一脉相承。通俗地说，微服务是将单体应用拆分为多个组件，如用户界面、消息队列、数据库访问等，以电商交易为例，拆分为在线支付、订单生成、订单跟踪等多个微服务，其中，每个微服务也可以进一步拆分，微服务之间通过接口进行调用，如此，就构建成了松耦合的架构，微服务彼此独立，修改、更新、迭代不会牵涉到其他微服务的模块。
从开发效率来讲，传统单体应用开发模式下，许多人共同面向一个大的应用，就像一群工人围在一起组装一台汽车一样，工序之间相互影响，相互干扰，效率不高；微服务化则把汽车的生产变成了工业流水线，一个工人只负责其中一部分，每个工人只需要熟悉自己负责的那部分就好，每一部分可被独立完成，可独立部署和更新。
微服务之间通过RESTful API进行连接。由于微服务之间以及微服务与客户端之间的连接要很快速，而且消耗要尽可能的低，REST API就非常合适。
微服务体系建设内容（驱动设计、平台支撑、治理框架）
使用微服务需要治理平台支撑，经过微服务化拆分之后，服务从本地调用变为远程方法调用，各种不确定因素变多了，必须有微服务治理平台来应对，常见的有Spring Cloud 、Apache Dubbo、Spring Cloud Alibaba、Apache Service Comb等等，其中包括服务发现、服务订阅、服务监控、服务追踪、服务日志等。
当一切就绪，平台上发布了成百上千个服务，每个服务或微服务相互连接成网状，如何让这个网络有序、有逻辑便非常重要，一来便于修改和维护，二来保证稳定和性能。
如何让网络变得有序有逻辑呢？
治理平台首先梳理系统对外开放的服务化接口、服务分组以及动态路由等等，然后对拆散的服务进行归类、界定，确定服务领域和服务边界，最后通过服务迁移、切换，对同一领域的服务接口进行服务整合，提供统一的服务出口，实现服务编排。
领域驱动设计（Domain-Driven Design，DDD）是软件行业最新的方法，当拿到一个需求的时候，DDD强调应该首先考虑要解决什么问题，它的问题域是什么，而不是先考虑用哪种技术去实现。这里出现了域的概念，域可以简单的理解为微服务化拆分后的又一个整合，域是同类功能或者问题的一个集合。
从领域驱动设计的角度来看，探讨需求首先应该从问题域出发，探讨关于业务边界的事情，梳理要实现哪些功能和需求。下一阶段拓展到工作边界，探讨如何分工协作，确定团队合作的方式。最后，到达应用边界，即技术实现的解决问题领域。
微服务架构不适合纵向业务流架构。
微服务并不是什么灵丹妙言，在判断基于微服务的方案是否适合时，理解业务域是至关重要的。业务类型大体上可以分为稳态和敏态，稳态业务对于系统的稳定性要求较高，一般都是纵向Scale-up架构为主，对于性能的要求比较稳定，短时间内不会有较大变动，这类应用一般作为企业运行的核心根本，企业现有的架构一般就可以满足，从投入成本以及实际收效来看，将这类业务改造为微服务架构是得不偿失的，而且会影响原有业务的正常运行，这类业务并不适合微服务架构。
敏态业务多为横向扩展Scale-out架构为主，作为企业创新的业务支撑平台，可以很短的时间内建立起新型应用，可以通过打通各个部门间的数据打造出创新的方案，创新应用的方案规模可以随需而变，创新应用的类型可以多种多样，可以随时变动，微服务架构明显非常适合此类业务。
微服务也是对大数据、AI、物联网的有效支撑
开发运营平台收集处理数据，用包括数据库、数据仓库、数据湖的方式存储海量数据，采用各种先进的大数据和人工智能AI技术对数据进行挖掘，从数据中心获取洞察力，为产品优化，降本增效提供支撑。
大数据、AI、物联网等都需要各种不同的运算、存储以及网络传输能力，而基于K8s提供容器微服务可以动态提供资源和平台支撑，微服务在可管理性上，在成本上，在提升效率和质量上都有明显优势。
DevOps
DevOps是Development（开发）和Operations（运维）的组合词，DevOps是一组过程、方法与系统的统称，通过一系列自动化流程能使构建、测试、发布变得更加快捷、频繁和可靠，可用于促进软件开发、技术运营和质量保障（QA）部门之间的沟通和协作，最终为软件产品和服务的及时交付提供保障。
DevOps领域最明显可见的还是在工具层面，常用的工具包括比较多包括监控工具Zabbix,Nagios，性能分析/APM工具Newrelic、Oneapm、Pinpoint、Zipkin，批量+自动化运维工具Puppet、Ansible、Chef、Saltstack，日志分析工具Graylog、Nagios、Elastic Stack、LOGalyze、Fluentd，持续集成/发布工具Jenkins。
AWS对DevOps的定义是：DevOps集文化理念、实践和工具于一身。可以提高组织交付应用程序和服务的能力。与使用传统软件和基础设施管理流程相比，能够帮助组织更快的发展和改进产品。这种速度使组织更好的服务其客户，并在市场上高效的参与竞争。
可见，工具整合只是技术实现，不是DevOps，除了工具还有文化理念和实践。
DevOps追求的是一种理想化的协作状态，涉及开发、测试、产品、项目管理、运维人员等等，在DevOps中，开发人员专注于业务应用的生命周期管理，运维人员专注于自动化环境资源的维护，QA人员专注于自动化业务运行环境的供给和质量跟踪保证。许多人认为，所有能在保持质量的前提下提高交付效率的方法和方法论都属于DevOps的范畴。
无论国内还是国外，DevOps的企业实践中很少有特别成功的案例，或者说，行业内还没有一个能广为接受的DevOps实践模型来作为参考，DevOps本身有很高的实践性和灵活性的特点，在实践中，很多企业也确实从DevOps中获益良多，但对于更多企业来说，没有成熟的参考模式做起来就会比较困难，这要求企业能提供试错的空间，也就意味着会出现意料之外的成本。
一个比较容易接受的路径是，由实际的业务来驱动，当企业开发一些新兴业务的时候，就以DevOps来进行，一昧的对原有系统进行改造是得不偿失的，所以，在实际落地钟，DevOps还要看契机。
那么如何构建业务流程梳理与度量体系完善DevOps呢？
通过职责梳理，确定流程与职责的对应关系，在实践中，通过对照制度发现各各个部门在职责方面的问题，做出弥补和修正。
通过流程诊断实现流程优化，依据制度对流程进行审核，发现流程与制度之间的不一致后要识别改进或优化的机会。
流程的跨部门审核、各种管理制度审查完善，结合控制要求和得到广泛应用的流程诊断技术进行流程诊断，根据诊断结果完成流程优化工作。
流程优化工作，要在整个架构的框架下审视流程，既要保证流程完整顺畅又要关注流程之间工作步骤的衔接关系。
DevOps度量体系可以帮助负责人了解团队的生产力，可以帮助了解目前应用的状况怎么样，可以回答三天后能否上线的问题，而不是“大概”“可能”这类回答，可以帮助团队认清并提升团队的生产力。
度量体系中的引领性指标定义了一些达成目标关系最为重要的行动，在可以驱动的指标事情上倾斜资源，为实现滞后性指标提供支撑。引领性指标关注目标如何完成，而滞后性指标关注目标是否完成，滞后性指标的数据比较容易获得。
持续交付 频繁交付、快速交付、降低发布风险CI/CD
CI的英文名称是Continuous Integration（持续集成）。CI中，开发人员将会频繁地向主干提交代码，提交的代码在经过编译和自动化测试后，最终合并到主干。持续集成的目标是快速确保提交的修改是不是好的，确定新代码能不能和原有代码集成起来。
CD可以是指持续交付Continuous Delivery，也可以是在说持续部署Continuous Deployment。
持续交付：持续交付负责将CI之后的代码发布到存储库,持续交付维护了一个可随时部署到生产环境的代码库，可供终端用户使用。持续部署：是将持续交付的代码自动发布到生产环境。
持续交付表示的是一种能力，而持续部署表示的则一种方式。持续部署是持续交付的最高阶段，上文提到，所有能在保持质量的前提下提高交付效率的方法和方法论都属于DevOps的范畴，所以，CI/CD是DevOps的必不可少的部分。
在实践中，Jenkins是最为常见的CI/CD工具。
容器对系统的扰动很小，每次改动也很小，如果做一个比喻的话，单体应用就好比射箭，需要远距离瞄准发射，开弓没有回头箭，社区去的箭很难再调整方位，而容器则像近身肉搏，拳脚都可以快速出击，而且可以随时调整出拳的方位和力道。
同样的，应用代码通过持续频繁快速的交付，可以降低发布的风险。
后记：
为了帮助传统行业企业加速完成云原生化改造，百易传媒（DOIT）联合Intel、VMware、阿里云、腾讯云、百度云、华为云、浪潮、金山云、红帽、灵雀云、青云、焱融云、xSky、杉岩、青藤云、蚂蚁金服、Portworx、UCloud、DaoCloud、数人云、京东云、网易云、亚信科技、云徙科技、时速云、七牛云、Caicloud才云、CSphere希云（排名不分先后）等国内外领先的云原生应用厂商的专家，共同组织编纂了《行业云原生应用报告指南》白皮书，希望能够为传统行业企业提供帮助。
《行业云原生应用指南》白皮书也将于近期发布，欢迎关注！
