基础设施之云原生架构

导读

本文记录了楼主对云原生架构、理念、技术、产品的一些思考和沉淀。

云原生的概念

CNCF对云原生的最新定义，为，

  • 计算模型：云原生技术有利于各组织在公有云、私有云、混合云等新型动态环境中构建和运行可弹性伸缩的应用。
  • 代表技术：云原生的代表技术包括容器、服务网格、微服务、不可变基础设施、声明式API。
  • 架构原则：这些技术能够构建容错性好、易于管理、便于观察的松耦合系统。结合可靠的自动化手段，云原生技术是工程师能够轻松地对系统做出频繁和可预测的重大变更。”

从上述定义看，云原生应该包括云原生技术、云原生产品、云原生架构、云原生开发理念、云原生应用等部分。具体的，

  • 云原生产品和技术，需要基于公有云、私有云、混合云的云基础设施（IaaS）
  • 云原生架构和开发理念，基于云原生产品和技术来构建、实现
  • 云原生应用，基于云原生架构和开发理念构建、实现

云原生这几个部分的关系，大体如下图， zone

云原生提供的这一组架构原则和设计模式集合，能够带来多方面的优势。具体的，

  • 降低了研发成本和项目维护的复杂度。RD只需要关心业务逻辑，非功能性代码、三方调用可以被大大简化，如IaaS容灾
  • 加速了软件迭代速度，降低了管理和运行成本。开发者/运维开始面向云API的研发，软件被做成容器集装箱、交付效率大大提高

云原生架构的原则

云原生遵循的架构原则，包括服务化、弹性、可观测、韧性、自动化、持续演进、零信任等。具体的，

  • 服务化原则：模块拆分、实现微服务或小服务化，接口通信、定义业务间的契约和复用，服务治理、抽象业务&实现基于服务流量的控制和治理
    • 模块拆分，按模块功能拆分业务代码、采用微服务/小服务架构，提升迭代效率(不同生命周期彼此独立迭代)
    • 接口通信，以接口方式、定义模块间的契约和复用，包括接口定义、标准协议(如HTTP)，做到模块功能的高内聚、高复用
    • 服务治理，抽象业务逻辑(如DDD)，做到基于服务流量的服务治理体系，如切限降熔、灰度、反压、零信任等
    • 备注，小服务是介于单体和微服务之间的形态，共享少量数据，一般是为了提升性能、降低调用复杂度
  • 弹性原则：容量可以随业务量大小自动调整，无需事前囤积固定的软硬件资源
    • 水平扩展，业务架构支持水平扩展，支持多实例、多单元，能做到流量分区调度
    • 自动部署，根据预设的规则、检测条件，实现自动伸缩
    • 主要收益，从容应对突增流量、降低IT成本
  • 可观测原则：通过日志、指标、追踪、事件，提供统一的监控视图、关联分析，有效降低故障的MTTR
    • 主要难点，分布式环境、标准化采集、关联分析
  • 韧性原则：抵御异常，持续提供服务、提高MTBF
    • 完整定义，当软件所依赖的软硬件环境出现异常时，软件需要具备抵御异常、持续提供服务的能力，这就是韧性
    • 核心理念，面向失败的设计
    • 表现形式，切限降熔、反压、重试、重启、回滚、异步化等，其中切依赖单元化、多AZ部署、多Region容灾、异地多活等多活基础
  • 自动化原则：通过配置数据自描述、面向终态的交付，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化
    • 产生原因，微服务、第三方组件大量应用，使软件的组件规模变大，Devops、容器理念技术推广，使技术栈更多样。两个因素，使得软件交付变的更复杂，不自动化只能死路一条
    • 设计原则，标准化、面向终态、关注点分离(不同工种关注不同的事项)、面向失败等
    • 注意事项，自动化系统的执行过程，同样需要遵循人工变更的最佳实践，做到灰度执行、变更可回滚、结果可观测、影响可追溯
  • 可持续原则：软件世界是不断变化的，架构演进本身也是一个不断尝试的过程，需要继承优秀的既有理念、做叠加式创新
    • 组织保障，需要类似一个架构治理委员会的组织，来把控节奏、评估风险、防止出现重大偏差
  • 零信任原则：以身份为中心进行访问控制，对每个访问请求都要做认证、授权，这是云原生场景下的安全架构设计
    • 之前大多以网络为中心进行访问控制

云原生架构的成熟度模型

根据ACNA的SESORA定义，云原生架构成熟度模型有如下5个关键指标维度，

zone

ACNA中将无服务（ServerLess）定义为关键指标，从当前的形势看，ServerLess产品尚处于探索期、不足以作为关键指标。

云原生架构的模式

  • 声明式设计模式
    • 声明式，面向目标，用户做目标定义，服务端(执行引擎)负责实现定义约定的内容、将复杂的中间过程黑盒化。如，IaC、K8S Yaml
    • 命令式，面向过程，用户做过程定义，根据服务端的执行情况、编排和调度各个过程。如，经典CD、工单
    • 声明式代表了一种思维方式，即抽象和封装系统的核心功能，让用户在一个更高的层面进行操作
    • 声明式的核心是执行引擎，该引擎既要做到幂等性，又要实现复杂性抽象(本质是知识沉淀)

命令式和声明式的边界对比，如下：

zone

云原生架构的理念

  • 开放应用标准OAM
    • 以应用为中心，而不是以工作负载为中心
    • 关注点分离。对外呈现「业务组件定义」和「运维特征定义」两个视图，OAM负责将两个视图整合为「应用配置」，并最终转化为「K8S可理解的编排调度声明」
  • DevOps理念和技术
    • DevOps目标是缩短从开发到部署的周期，通过打破开发、测试、运维之间的壁垒，实现持续交付(Continuous Delivery)
    • DevOps落地依赖组织文化(Culture)、自动化(Automation)，同时也要关注结果度量(Measurement)、知识分享(Sharing)，所谓的CAMS四原则。CICD等自动化技术只是其中一个环节，并非全部
    • 云原生吸纳和演进了DevOps理念，云原生技术促进了DevOps的结果达成
    • zone
    • zone

备注：DevOps相关图片引用自鲜枣课堂的《DevOps到底是什么意思》一文。

云原生对不同岗位的影响

云原生创造或翻新了产品、技术、架构、理念，对不同段位的从业者都带来了新的挑战。具体的，

  • CXO/IT主管：对外，需要关注开源、关注国产化；对内，需要拥抱云原生，升级组织结构、文化，落地云原生、重构现状
  • 架构师：云原生对架构师角色的影响是深远的，跟不上潮流、就可能被淘汰。具体的，
    • 架构演进，评估公司现有能力、在架构升级和稳定性之间做好权衡。毕竟，云原生本质上是要改变软件运行的基础环境，需要打破原稳态并构建新稳态
    • 技术选型，确定云原生落地的领域，做好技术和产品选型
    • 应用升级，重写而非重构（这是阿里的观点，本人不认同）
    • 重塑IT流程，云原生带来了新的工具、方法和标准，对现有的IT流程会有不同方面的提升
    • 安全规划，DevSecOps
  • 开发：云原生对开发提出了新的要求，开发环境云化、技术栈云化、被IaC简化的业务开发、不得不学的分布式设计模式、生产环境盲测逐渐时兴、彻底拥抱敏捷开发等等。也许有很多不情愿
  • 运维：基础设施工程师的角色进一步从运维剥离出来，运维变的更像运维。技术栈需要更新到云原生，使用新的运维工具，基于链路感知的监控、定位、SLA能力，AIOps可能更近了一点点，等等
  • 交付工程师：云原生工具隔离了IaaS环境、交付更加标准化，典型的配置可以实现共享、自动化程度更高，开始基于公有云做交付，面临更广泛的开源产品、知识体系，等等
  • DBA：XX

技术工作者的职业生涯如逆水行舟，年龄在变大、技术持续革新，不努力一定死、努力了才有可能活。

云原生架构的发展趋势

站在2021年看，云原生架构的几个关键点、有如下发展趋势

  • 容器技术
    • 运行时: 虚拟化、容器技术进一步融合，催生出隔离性更好、损耗更低的容器运行时。如Kata、Firecracker、gVisor、MicroVM技术等
    • 调度器: K8S作为容器领域的事实标准，进一步发展成为云原生操作系统。K8S定义了开放的、标准的访问接口，向下封装资源、向上支持应用，这和Linux的概念模型很相似
    • 资源层: IaaS更加多样，包括公有云、私有云、混合云、边缘云等，提供了动态、混合、分布式等多维的选择空间
  • 应用编程界面
    • 应用全生命周期托管，声明式、配置化的资产编排(IaC)，代码框架边车化(做到框架和语言无关)，这些方面构成了应用编程的新界面
    • 举例: 生命周期托管依赖ServerLess技术的发展、周边配套的完善，IaC依赖类似Terraform工具的完善，流量管理的框架逻辑已经被ServiceMesh实现、接下来会有更多通用框架能力被边车化
  • ServerLess
    • 从离线业务扩展到在线业务，依赖ServerLess稳定性提升
    • 公有云基础设施、业务应用充分适配ServerLess模式
    • ServerLess依赖更好地容器运行时技术；同时也将引入更多的硬件架构，除x86外，GPU、FPGA、TPG都可以被纳入硬件基础设施
    • 更小的镜像、更快的分发
  • 软件交付
    • 基于K8S和公有云API，制定一套「云端应用管理规范」，做到软件代码、软件资源配置、硬件环境这三者的高效适配(即应用自包含、自说明)
    • OAM项目是云原生时代的应用标准定义和架构模型，在OAM规范下，应用定义是由应用组件、应用特征两部分组成，应用组件对应代码描述、是开发视角，应用特征主要是定义和描述应用的运维特征、对应运维视角
  • 大数据
    • 实时化，这是大数据领域的发展趋势；技术流派包括，流计算应对海量数据、OLAP提供近实时能力
    • 湖仓一体，依赖更规范的元数据管理，会有多种计算场景的融合
    • 与人工智能进一步融合
  • 数据库
    • 更加PaaS化，公有云厂商对齐标准、具备高效打通能力，企业用户解除单云锁定（类似情况还会发生在所有充分竞争的公有云领域）
    • 数据库和大数据技术相互融合，数据库向着海量数据场景进化
    • 安全基本盘

特别的，K8S极有可能成为云原生时代的操作系统，如下：

page.png

page.png

云原生脑暴

从能力覆盖来看，云原生更多是计算能力的原生，存储和网络更加服务化、但底层并未波及。对应的，云原生对应用的交付、管理、成本都带来了革命性；对于大数据、数据库等重存储重网络的领域，云原生贡献了新的产品理念、技术、和基础设施能力，但原体系只改良、不革命。

从云服务模型来看，云原生的影响主要集中在IaaS层。具体的，

  • 云原生对IaaS形成了降维打击。云原生的产品、技术、架构、理念成为了公有云的新界面。公有云的底座依然是原有IaaS能力，但需要更多的考虑云原生的产品延伸，在运维管理成本、交付效率、资源使用率等方面提供新的界面和支持
  • 公有云PaaS层依然相对封闭。不同云PaaS尚未完全打通，部分产品接口标准尚不一致，客观上阻碍了多云架构的推进。这其中，先发厂商”单云绑定、大肥猪不许动”的商业模式，是非常顽固的力量；如大数据体系。同时我们也看到，后发厂商都在积极的拥抱开源、拥抱统一标准，推进PaaS层面的南北向接口统一；如，消息队列、数据库、缓存等。最终，PaaS会迎来交互视角的统一
  • SaaS处于最高层，服务交付因IaaS云原生而大大简化，PaaS依然会存在单云绑定的问题。从老美的经历看，中国互联网会出现PaaS变薄、SaaS变厚的趋势

其实，我们并不在乎公有云在底层、内部适配云原生的方式。我们只关注接口、界面等交互视角的统一性，以达成应用的多云能力。

从技术趋势看，

  • ServerLess是很好的产品形态，将交付、管理、成本的问题全家桶式解决。目前ServerLess处在产品能力落地期、诸多不完善，预计2-3年后会产生实际效果
  • ServiceMesh证明了其在服务治理中的核心地位，但Iatio在大规模场景的统治力在变弱。期待出现一种去中心化的、更加K8S原生的解决方案

分隔线、分割线，线上概述、线下详情。以下的章节，是对上文某些章节的详细论述。

云原生的架构原则-论述

云原生遵循的架构原则，包括服务化、弹性、可观测、韧性、自动化、持续演进、零信任等。

服务化原则

在经典的三维模型中，应用服务扩展遵循水平容量扩展(单实例到多实例)、纵向功能划分(单体到微服务)、Z向数据分区的设计(单分区到多分区)。简言之，拆分业务单元，使能独立迭代；面向接口编程，提升功能内聚；合理抽象业务(如DDD)，做到基于服务流量的策略控制和治理。具体的，

当代码规模超出小团队的合作范围时，就有必要进行服务化拆分了，包括拆分为微服务架构、小服务 (Mini Service)架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免迭代频繁模块被慢速模块拖慢，从而加快整体的进度和稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。分布式环境下的限流降级、熔断隔仓、灰度、反压、零信任安全等，本质上都是基于服务流量(而非网络流量)的控制策略，所以云原生架构强调使用服务化的目的还在于从架构层面抽象化业务模块之间的关系，标准化服务流量的传输，从而帮助业务模块进行基于服务流量的策略控制和治理，不管这些服务是基于什么语言开发的。

服务化架构是云时代构建云原生应用的标准架构模式，要求以应用模块为颗粒度划分一个软件，以接口契约（例如 IDL）定义彼此业务关系，以标准协议（HTTP、gRPC 等）确保彼此的互联互通，结合DDD（领域模型驱动）、TDD（测试驱动开发）、容器化部署提升每个接口的代码质量和迭代速度。服务化架构的典型模式是微服务和小服务（Mini Service）模式，其中小服务可以看做是一组关系非常密切的服务的组合，这组服务会共享数据，小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太细而导致过多的调用损耗和治理复杂度。通过服务化架构，把代码模块关系和部署关系进行分离，每个接口可以部署不同数量的实例，单独扩缩容，从而使得整体的部署更经济。

弹性原则

系统部署规模可以随业务量大小自动调整，无需根据事前的容量规划准备固定的软硬件资源。要做到弹性，需要业务做支持水平分区、支持自动化部署(横向可扩展)；业务按功能拆分、做到纵向可降级(纵向可降级)。具体的，

大部分系统部署上线需要根据业务量的估算，准备一定规模的机器，从提出采购申请，到供应商洽谈、机器部署上电、软件部署、性能压测，往往需要好几个月甚至一年的周期。而这期间如果业务发生变化了，重新调整也非常困难。弹性则是指系统的部署规模可以随着业务量的变化自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。好的弹性能力不仅缩短了从采购到上线的时间，让企业不用操心额外软硬件资源的成本支出(闲置成本)，降低了企业的IT 成本，更关键的是当业务规模面临海量突发性扩张的时候，不再因为平时软硬件资源储备不足而说不，保障了企业收益。

可观测原则

可观测指的是：通过抽象指标、日志、Tracing、事件，提供统一监控视图，加强数据关联分析，目标是降低故障的MTTR。具体的，

今天大部分企业的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需要对多个主机上的信息做关联，才可能回答清楚服务为什么宕机、哪些服务违反了其定义的SLO、目前的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等，这些都要求系统具备更强的可观测能力。可观测性与监控、业务探活、分布式追踪等系统提供的能力不同，前者是在云这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次APP点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL请求、节点拓扑、网络响应等，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。

韧性原则

当软件所依赖的软硬件组件出现异常时，软件需要具备抵御能力，这就是韧性；韧性的核心理念，是面向失败的设计；表现形式有切限降熔、重试、重启、回滚等，其中切依赖单元化、多AZ部署、多Region容灾、异地多活等多活基础。具体的，

当业务上线后，最不能接受的就是业务不可用，让用户无法正常使用软件，影响体验和收入。韧性代表了当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，这些异常通常包括硬件故障、硬件资源瓶颈(如CPU/网卡带宽耗尽)、业务流量超出软件设计能力、影响机房工作的故障和灾难、 软件bug、黑客攻击等对业务不可用带来致命影响的因素。韧性从多个维度诠释了软件持续提供业务服务的能力，核心目标是降低软件的MTTR(Mean Time To Recover，平均故障恢复时间)。从架构设计上，韧性包括重试/限流/降级/熔断/反压、服务异步化能力、主从模式、集群模式、AZ 内的高可用、单元化、跨Region容灾、异地多活容灾等。

自动化原则

微服务、Devops、容器、第三方组件的大量应用，迅速提高了技术的复杂度，不自动化只能死路一条。通过配置数据自描述、面向终态的交付，可以实现整个软件交付和运维的自动化，需要遵循标准化、面向终态、关注点分离(不同工种关注不同的事项)、面向失败的设计等原则。具体的，

技术往往是把双刃剑，容器、微服务、DevOps、大量第三方组件的使用，在降低分布式复杂性和提升迭代速度的同时，因为整体增大了软件技术栈的复杂度和组件规模，所以不可避免地带来了软件交付的复杂性，如果这里控制不当，应用就无法体会到云原生技术的优势。通过IaC(Infrastructure as Code)、GitOps、OAM(Open Application Model)、Kubernetes Operator和大量自动化交付工具在CI/CD流水线中的实践，一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化 —— 「通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化」。

自动化系统的执行过程，同样需要遵循人工变更的最佳实践，做到灰度执行、结果可观测、变更可回滚、影响可追溯。

持续演进原则

软件世界是不断变化的，架构也需要继承优秀的既有理念、做叠加式创新。具体的，

今天技术和业务的演进速度非常快，很少有一开始就清晰定义了架构并在整个软件生命周期里面都适用，相反往往还需要对架构进行一定范围内的重构，因此云原生架构本身也应该和必须是一个具备持续演进能力的架构，而不是一个封闭式架构。除了增量迭代、目标选取等因素外，还需要考虑组织(例如架构控制委员会)层面的架构治理和风险控制，特别是在业务高速迭代情况下的架构、业务实现平衡关系。云原生架构对于新建应用而言的架构控制策略相对容易选择(通常是选择弹性、敏捷、成本的维度)，但对于存量应用向云原生架构迁移，则需要从架构上考虑遗留应用的迁出成本/风险和到云上的迁入成本/风险，以及技术上通过微服务/应用网关、应用集成、适配器、服务网格、数据迁移、在线灰度等应用 和流量进行细颗粒度控制。

零信任原则

以身份为中心进行访问控制，对每个访问请求做认证、授权，这是云原生场景下的安全架构设计。具体的，

零信任安全针对传统边界安全架构思想进行了重新评估和审视，并对安全架构思路给出了新建议。其核心思想是，默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，诸如IP地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆，引导安全体系架构从”网络中心化”走向”身份中心化”，其本质诉求是以身份为中心进行访问控制。

零信任第一个核心问题就是Identity，赋予不同的Entity不同的Identity，解决是谁在什么环境下访问某个具体的资源的问题。在研发、测试和运维微服务场景下，Identity及其相关策略不仅是安全的基础，更是众多(资源，服务，环境)隔离机制的基础；在员工访问企业内部应用的场景下，Identity及其相关策略提供了灵活的机制来提供随时随地的接入服务。



Prev     Next