解密云原生---看企业云的未来
对于大部分的企业来说，IT是有历史包袱的。因为原来的IT应用部署模式，都是竖井式的，不同的应用都由不同的软件开发商提供的，系统之间还有网络安全隔离，各系统间还有协同关系，网络、应用拓扑很复杂。企业IT上云是一个系统性的工程，原来的应用可能还需要结合云上提供的虚拟机、网络和存储的特点进行必要的改造，不能简单的“原来物理机什么配置，虚拟机什么配置，原来应用什么架构，上云后什么架构”的迁移方法，这其实完全失去了“上云”的优势，要防止为了上云而云的做法。
云原生是一种构建和运行应用程序的方法，它充分利用了云计算交付模型的优势，更天然的贴合云的特点。云原生（Cloud Native），是Matt Stine提出的一个概念，它是一个思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。Cloud Native也可以说是一系列Cloud技术、企业管理方法的集合。
云原生是一个不断丰富的理念和技术体系，它在基础架构、应用程序和管理上都将深刻的影响和改变企业云的未来！
1、基础架构的变革与云原生
基础架构即服务（IaaS）是云供应商的众多产品之一。它提供了原始的计算、网络和存储，客户可以根据需要消费。它还包括支持服务，如身份和访问管理（IAM）、供应和库存系统。
企业传统的数据中心基础架构具有这样几个特点：1、评估难。采购规模无依据，服务器和存储过量采购，硬件折旧快，很容易在降低IT成本和满足业务需求之间产生矛盾关系。2、部署慢。部署需要数周时间，设计复杂、范围大、人员协调难，迟滞于业务的快速变化，敏捷性差。3、管理成本高。不具备自恢复能力，管理成本高，难以应对业务规模增大带来的复杂管理需求，系统弹性差。4、可维护性差。缺乏端对端的可见性，出问题往往定位不清楚，互相扯皮，导致运营管理成本随业务规模呈几何级增长，可维护性差。
云的特点就是弹性、敏捷、分布式、可扩展、自管理自恢复，符合云的特点的基础架构就可以称为云原生基础架构。云原生基础架构需要在提供自主应用程序管理的IaaS之上创建一个平台。该平台建立在动态创建的基础架构之上，以抽象出各个服务并促进动态资源分配调度和扩展。云原生的基础架构需要在以下几个方面做出变革：1、科学评估，按需采购。改变采购模式，无需一次性大规模采购，抓取平台监控数据科学评估，按需采购及时补充；不依赖于特定的底层虚拟化（esxi/kvm/xen/hyper-v）,解耦虚拟化平台，按需使用。2、部署快速。从上机架开始30分钟内即可交付使用，部署快速，这更多的需要软硬一体化的能力，软硬件的融合不仅可以降低用户使用云计算的复杂度，也大大降低的企业的应用风险。超融合通过对软硬件一体化的改造，不断提升产品的性能、密度、性价比和易用性等，切实让用户体验到什么叫“开箱即用”，快速部署。3、统一管理。通过软件统一管理计算、存储、虚拟化等资源，使运维管理简单化集约化。4、自管理高可用。全链路所有节点可见，分布式架构，线性扩展，无节点数限制，无单点故障，内置同城和异地容灾能力。
总结：当软件功能越来越强大之后，原来必须在硬件层面的支持就可以转移到软件上来实施。在基础架构这一层，技术驱动的结果就是企业用户越来越没必要花那么多钱去搞那么多昂贵复杂的专业设备了，软件定义的基础架构会越来越流行和重要。
2、云原生应用程序的构建和部署
一般说来，企业传统应用向云环境的迁移往往是一个应用重新部署的过程，而向PaaS或SaaS环境迁移，则要对应用系统进行重新拆分、重新设计架构和重新构建。很多应用系统PaaS化是为了更好的利用容器、微服务等技术和理念，实现弹性和敏捷，满足软件服务化的需求。
我们看到过去几年云平台在不断地发展，但应用程序在云平台运行，仍然需要为不同的开发语言安装相应的运行时环境。虽然自动化运维工具可以降低环境搭建的复杂度，但仍然不能从根本上解决环境的问题。
容器的出现成为软件开发行业新的分水岭；容器技术的成熟，也标志技术新纪元的开启。Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中，并且摆脱了环境依赖的问题。通过集装箱式的封装，开发和运维都以标准化的方式发布的应用，异构语言不再是桎梏团队的枷锁。
而Kubernetes则统一了容器编排系统，为云原生应用提供了一站式的服务。Kunernetes的出色表现，为运维工程师的工作模式带来了颠覆性的改变。他们再也无需像照顾宠物那样精心的照顾每一台服务器，而当出问题时，直接将出问题的服务器换掉即可。业务开发工程师不必再过分关注非功能需求，只需专注自己的业务领域即可。而中间件开发工程师，则需要开发出健壮的云原生中间件，用来连接业务应用与云平台。
随着云化的深入，越来越多的应用被部署在云端，以往单体应用的劣势就体现的愈加明显。因为应用变更的范围和周期被捆绑在一起，即使只变更应用的一部分，也需要重新构建并部署整个单体应用，而且无法对需要更多资源的部分模块单独扩展，而是必须将整个应用整体扩展。这样粗粒度的划分，不利于系统的管理和资源的利用。因此，人们越来越倾向于将应用进行合理的拆分。于是，微服务应运而生。它将一个复杂的单体应用分解成为多个独立部署的微型服务，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制，如：RESTFul API。服务可以使用不同的开发语言和数据存储技术。通过微服务的拆分，系统可以更加自由的将所需资源分配到所需的应用中，而不是直接扩展整个应用，同时这种扩展在垂直或水平方向都非常灵活简便。
总结：云原生应用系统需要与操作系统等基础设施分离，不应该依赖Linux或Windows等底层平台，或依赖某个云平台。也就是说，应用从开始就设计为运行在云中，无论私有云或公有云；其次，该应用必须能满足扩展性需求，垂直扩展（向上和向下）或水平扩展（跨节点服务器）。
3、云原生与管理自动化、智能化
当在应用软件交付生命周期当中引入云原生机制之后，我们可以快速为软件添加新功能，同时又不影响其在生产环境下的稳定性与安全性水平的能力。众所周知，我们的应用程序在运行过程中需要基础设施、中间件以及支持服务的多方配合，而云原生方案则通过对这些因素的自动化改造实现上述目标。
一套全面的云原生架构当中包含自动化与编排管理两类机制，能够帮助用户直接获得相关能力，而无需再将自动化流程作为可定制设计进行编写。比如K8S其内置的自动化管理、自我修复和自动扩展。换句话来说，这类自动化管理的内置特性使我们得以更轻松地构建出可以自动化方式管理的应用程序。
当然，这些新特性同时也会对软件的开发方式提出新的要求。开发人员必须利用一整套新的架构实践组合——例如微服务与容器技术，从而确保应用程序能够在云平台之上得到很好的管理，这也是我们在软件开发提速之外需要认真考量的保障前提。在运营层面也带来多项助益，具体包括应用程序实例可迁移、统一化登录以及通过监控手段保障应用程序及数据流正常运作等等。另外就是DevOps的引入能对产品交付、测试、功能开发和维护（包括──曾经罕见但如今已屡见不鲜的──“热补丁”）起到意义深远的影响。在缺乏DevOps能力的组织中，开发与运营之间存在着信息“鸿沟”──例如运营人员要求更好的可靠性和安全性，开发人员则希望基础设施响应更快，而业务用户的需求则是更快地将更多的特性发布给最终用户使用。这种信息鸿沟就是最常出问题的地方，DevOps的出现正是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。
要发挥云原生管理的固有优势，较为理想的途径之一就是引入智能化实现自治管理。目前企业在上云后，大多依靠“以人为本”的方式，凭借大量工作人员的个人能力和经验、自觉来进行运维工作，这种将劳动密集型服务简单粗暴的从传统IT基础设施转移到云平台的方式，只能是市场体量较小、技术发展程度不高的现实条件下，采取的过渡方案。引入智能化，实现服务自动发现、告警自动检测、故障自治处理，改变这种传统的服务方式下的效率低下、人力成本过高、手工运维过程中的误操作，也会大大提高企业云的可用性，日益扩大企业级的云服务市场。
总的来说，Cloud Native云原生是更好的工具、自我修复系统和自动化系统的集合，可以让应用和基础设施的部署和故障修复更加快速和敏捷，极大的降低企业在云计算方面的部署成本，加快企业云的变革。
展望：企业云的未来