基础设施架构的演进与云原生

IT基础设施建设和升级的必要性

作为一个未来布局科技型公司的目标来看，拥有自研产品、技术平台甚至拥有对其他公司做技术顾问的能力是有必要的。“合抱之木，生于毫末；九层之台，起于累土”除了说明了所有伟大的工程都起于基础的平台上，也说明伟大的应用需要一个稳固的基础设施，地基打好了，计划图做好了才能起来万丈高楼。各自为政打一枪换一个地方的打法能不能达到我们的伟大目标呢？就如同100只兔子拉车，恐怕是做不到的，我们在做这些伟大的复杂的事情之前都需要做系统的规划和基础的建设。而这一切的基础的建设又要考虑到历史的进程和技术的发展，软件架构的进化从大单体->前后端分离->微服务->云原生，这一切的进化有因技术的发展而主动推进的也有因业务的复杂度和管理的复杂度而被动推进的。中小型公司的劣势是技术团队新组建，团队协作不成熟，相对应的优点是：没有因历史发展而带来的技术债务，我们可以从头开始打造团队和基础设施，可以在这些的基础上打造产品和业务。
那将现有传统IT架构向云原生过渡是必然趋势么？首先肯定一个结论：传统IT架构向云原生过渡是必然的趋势。
主要原因有三点：
首先IT架构的历次演进，技术因素并非是其中的主因，而更像是其中的一个结果。简单来说IT架构的变化，每次都有深刻的市场趋势、业务需求、竞合关系变化这样的一些背景，云原生架构与其说是一次技术变革，不如说是一次社会分工的再次调整，来作为机构市场幅度的极大延伸（全球化市场）、管理和运营能力的快速部署需求（全球化企业）、信息产业竞合关系的调整（最大程度发挥规模优势和降低边际成本，专业的事专业的人来做）这些趋势所做出的应对。
其次，云的应用在“移动为先、云为先”这样的共识到来之前，实际已有了大量的实践和积累。现阶段更像是“水到渠成”的阶段，邮件、即时通讯、协同办公、共享中心等等在过往的几十年中，或在一些点或在一些面都有了大量的“云”应用，这个架构的迭代，并不是偶发的、突然的，而近年来电商等平台型企业的出现无疑大大加速了这个模式的到来。
最后，所谓传统IT架构更多是和“传统”企业相生相伴，这些企业的技术迭代并非像类似云原生架构的互联 企业那样更新，而是或受限于巨大的存量“遗留系统”的改造代价不菲（脱离业务收益的获得而进行单纯的技术升级，风险成本与收益根本不匹配，内部的支持不足）、或局限于传统的“思维方式”的人而非企业是不是“传统”的，或许用不了太多的时间，大家会发现这其实是一个不需要讨论、不能够阻挡、需要融入其中的洪流。

基础设施建设的特点

基于技术的公司针对技术深入挖掘技术本身是必须的，不管是出于投机考虑还是出于长远的规划都要做相应的技术规划，而且对于技术布局之于公司的发展又有以下特点：
短期被高估，长期被低估
一般情况下初期公司在刚开始对于技术总不可避免的抱有或多或少的幻想，认为技术会解决这些问题那些问题，而初期表现也确实如此，技术红利带来的好处很明显，所以经常会造成短期被高估的情况。但技术在初期能带来一些现实的好处，比如很快是使用一些技术攒出产品，支持业务，但也因此会造成很多人特别是中层人员对技术的误解，认为技术有很多急功近利的好处，这就是短期内技术被高估。
随着业务发展，慢慢地技术会面对比如业务复杂度提高、服务稳定性要求提高和业务负载提高的时候就会遇到技术的瓶颈，这时候那些看不见的技术：基础设施建设、业务分层、数据资源的重新整合甚至运维本身都变得更重要了，但这些反而不容易被看到而忽略，直到发展到业务无法支撑而像流沙上的高楼一样而崩溃。在业务发展的过程中一部分人会认为技术没那么重要的时候反而是更应该对技术发力的时候，这就是技术长期来看被低估。
没有速成的武林绝学和神话
软件是工程学的一部分，既然是工程学那它也符合工程学的一般特点，那就是在技术领域同样没有银弹和神话的存在。软件工程作为一个复杂性和可变性很高的工程，在它的建设过程中也一样要尊重自然规律，不能迷信神话传说，也不能幻想通过某个俗称的武林绝学一夜达到绝世高手的程度。除了科学的设计规划以外也需要脚踏实地的付出才能达到我们的目标。而打造坚实的IT基础设施架构恰恰是科学的规划中最早也是最基础的一部分。

基础设施的发展

传统云计算的三层架构

基础设施即服务（Infrastructure as a Service，IaaS）、平台即服务（Platform as a Service，PaaS）、软件即服务（Software as a Service，SaaS）是传统对云计算的三层分类，最基础的是IaaS，中间为PaaS，最后直观呈现出来的是SaaS。
IaaS层包含服务器、存储、 络等硬件设备。用户可以在任何时候利用这些硬件来运行应用，节省维护成本和办公场地。目前比较知名的IaaS公司有亚马逊、阿里云、腾讯云等。
PaaS为应用开发提供软件平台环境，例如中间件、数据库、商业智能和开发工具等。PaaS公司与IaaS公司有许多重叠。
SaaS是目前普通用户接触最多的层面， 络上任意一个远程服务器上的应用都属于SaaS。比如阿里的钉钉、用友以及金蝶云都属于这一类。

基于虚拟机的基础设施的局限性

之前的IT基础设施建设主要是基于IaaS的自建云、或者结合自建云和公有云的混合云，一定程度上确实改善了一部分IT基础设施的问题，但基于虚拟机的基础设施远离业务，对研发和业务的支持能力很有限，还是只能提供操作系统级的服务。但随着软件架构的发展和产品开发模式的发展，这种粗糙的资源管理和特别基层的服务，显然已经遇到挑战。IT企业对于基础设施的理解也慢慢上移，从对提供整个操作系统的虚拟机到提供一个到几个进程的容器；从单纯需要操作系统到需要灵活的软件运行集群环境+开发运维辅助工具（DevOps）+高度可视化、自动化的运维综合平台，基础设施不可避免地上升到了PaaS层甚至SaaS层。

基于容器编排的新基础设施-云原生平台

云原生简介

云原生（Cloud Native）概念是随着Docker、Kubernetes等容器技术的发展而产生2015年云原生基金会（Cloud Native Computing Foundation，CNCF）的成立，云原生被认为让应用更有弹性、容错性、观测性的基础技术，让应用更容易部署、管理的基础软件、让应用更容易编写、编排的运行框架等。
云原生的概念由Pivotal公司的Matt Stine于2013年首次提出，后一直延续至今。这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合，并得到了社区的不断完善，包括DevOps、持续支付、微服务、敏捷
基础设施等12个要素，不但包含根据业务能力对公司进行文化、组织架构的重组，也包括方法论与原则、具体的操作工具。通过使用云原生技术和一系列管理方法，能够更好地把业务迁移至云平台，进而可以享受云带来的高效和持续服务能力。
借助云服务能实现更优雅的设计，比如弹性资源的需求、跨机房的高可用、11个9（99.999 999 999%）的数据可靠性等特性，这些基本是云计算服务本身就能提供的能力，开发者直接选择对应的服务即可，一般不需要过多考
虑本身机房的问题。如果架构设计本身又能支持多云的设计，可用性会进一步提高，比如Netfix能处理在AWS的某个机房无法正常工作的情况，还能为用户提供服务，这就是云带来的魔力。当然，云服务架构设计对技术人员的要求也很高。除了对场景的考虑外，对隔离故障、容错、自动恢复等非功能需求会考虑更多。

云原生带来的收益

IT资源一体化管理

针对数据中心承载信息系统的基础资源分散、部署运维自动化程度低等问题，将基础设施、数据、服务、应用等IT资源进行一体化管理，构建企业私有云生态，实现数据资产集中管理、数据资源充分共享、信息服务按需获取、信息系统安全可靠的新型数据中心。同时，随着近年AR、VR、无人机、无人驾驶、智慧终端等应用场景的出现。各行业通过将数字技术与实体经济深度融合，不断提高实体产业数字化、智能化水平，加速云计算、大数据、人工智能高速发展。其中企业私有云平台不仅仅作为基础设施提供计算、存储和 络等服务，更重要的是对应用提供整个全生命周期的闭环管理，灵活定义服务需求，在此基础上协同数据或者AI组件，提供大数据分析和AI所需的核心分析能力。

敏捷基础设施

正如通过业务代码能够实现产品需求，通过版本化的管理能够保证业务的快速变更，在基于云计算的新开发模式下，运维人员可以更频繁地构建更强、可控和更稳定的基础设施，开发人员可以随时拉取一套基础设施来服务于开发、测试、联调和灰度上线等需求。技术人员部署服务器、管理服务器模板、更新服务器和定义基础设施的模式都是通过代码来完成的，并且是自动化的，不能通过手动安装或克隆的方式来管理服务器资源。运维人员和开发人员一起以资源配置的应用代码为中心。基础设施通过代码来进行更改、测试，在每次变更后，执行测试的自动化流程，确保能维护稳定的基础设施服务。

持续交付

为了满足业务需求频繁变动和快速迭代，软件产品要拥有能随时能发布的能力，这也是持续支付的开发实践方法。它可分为持续集成、持续部署、持续发布等阶段，用来保证从需求提出到设计开发和测试，再到代码快速、安全部署到产品环境中。持续集成是指每当开发人员提交一次变动，就立刻进行构建、自动化测试，确保业务应用和服务能符合预期，从而可以确定新代码和原有代码能否正确地集成在一起。持续交付是软件发布能力，是在持续集成完成之后，达到能够将系统发布到生产环境的条件。持续部署是指使用完全的自动化过程来把每个变更自动提交到测试环境，然后将应用安全部署到产品环境，打通开发、测试、生产的各个环节，自动持续、增量地交付产品，也是大量产品追求的最终目的。当然，在实际运行过程中，有些产品会增加灰度发布等环境。总之，它更多是代表一种软件交付的能力。

DevOps和规范的开发流程

DevOps如果从字面上来理解只是Dev（开发人员）+Ops（运维人员），实际上它是一组过程、方法与系统的统称，其概念从2009年首次提出发展到现在，内容非常丰富，有理论也有实践，包括组织文化、自动化、精益、反馈和分享等不同方面：①组织架构、企业文化与理念等，需要自上而下设计，用于促进开发部门、运维部门和质量保障部门之间的沟通、协作与整合，简单而言组织形式类似于系统分层设计；②自动是指所有的操作都不需要人工参与，全部依赖系统自动完成，比如上述的持续交付过程必须自动化才有可能完成快速迭代；③DevOps的起因是IT行业渐渐意识到，如果要准时交付软件产品或者服务，开发部、运维部必须紧密合作。总之，DevOps提倡的是高效组织团队之间的合作，通过自动化软件协作，完成软件的生命周期管理，目的是迅速频繁地交付应用软件。

微服务和灵活快速的架构

随着企业的发展，传统业务架构面临着很多问题：①单体架构在需求越来越多时无法满足其变更要求，因此开发人员对大量代码进行变更会越来越困难，同时也无法很好地评估风险，造成迭代速度慢；②系统经常会因为某处业务的瓶颈导致整个业务瘫痪，架构无法扩展，木桶效应严重，无法满足业务的可用性要求；③整体效率低下，无法很好地利用资源，存在大量的浪费。因此，架构迫切需要进行改变。随着大量开源技术的成熟和云计算的发展，服务化的改造应运而生，微服务架构设计风格随之涌现，最有代表性的是Netfix公司。它是国外最早基于云进行服务化架构改造的公司，2008年因为全站瘫痪被迫停业3天后，通过改造实现了从单体架构到微服务全球化的变迁，满足了业务的千倍增长，并产生了一系列的最佳实践。
由微服务的定义分析可知，一个微服务基本是一个能独立发布的应用服务，因此可以作为独立组件升级、灰度或复用等，对整个大应用的影响较小。每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出即可完成开发，甚至整个团队的组织架构也会更精简，因此沟通成本低、效率高。根据业务需求，不同的服务可以根据业务特性进行不同的技术选型，不管是计算密集型还是I/O密集型应用都可以依赖不同的语言编程模型或者运行软件，各团队可以根据本身的特色独自运作。

后记

以上大概从基础设施的层面简单介绍了基础设施与云原生的关系，以及使用云原生带来的一些益处。下一篇文章着重从软件架构的发展和产品开发的发展聊聊这两个领域和云原生的相辅相成的发展。