环球科创网

以业务需求为中心的云原生架构体系建设

更新时间:2022-06-13 01:34:54

导读 云原生的概念在国内被提及的越来越多,但大多数人对云原生的认识仅限于容器、微服务、DevOps等等。将容器、微服务、DevOps等同于云原生显然

云原生的概念在国内被提及的越来越多,但大多数人对云原生的认识仅限于容器、微服务、DevOps等等。将容器、微服务、DevOps等同于云原生显然是错误的。CNCF从自己的角度定义了云原生技术:云原生技术使企业能够在现代动态环境中构建和运行可扩展的应用,如公共云、私有云和混合云环境。包括容器、服务网格、微服务、不可改变的基础设施和声明式API等。这些技术可以实现系统的松耦合性、灵活性、可管理性和可观察性。它还可以与自动化相结合,以最小的工作量实现频繁和可预测的功能更改。

云计算提供了敏捷、自助服务、不可改变的基础设施等。将云应用于业务应用逐渐成为共识。但是,不重构云原生架构就直接上云,可能很危险。传统的业务应用架构无法在云上灵活扩展和响应,无法有效利用云计算的特性为企业赋能。因此可能需要对传统架构业务系统的分布式微服务进行拆分重构,部署运行在容器云平台等。运用DevOps理念,通过CI、CD等不断提高交付效率。等等。应用自创建以来,就具有云的特性,为云而生。它是充分利用云计算的分布式和弹性扩展特性,使之能够满足或适应在云上部署和运行的要求,也可以用云的思想、方法和工具直接在云中创建,它天生就具有云的特性。因此,cloud native可以看作是基于云构建和运行云应用的方法论和技术体系。云原生技术和方法用于构建和运行管理云应用。

Matt Stine在2015年出版的《迁移到云原生架构》一书中,定义了符合云原生架构的特征:12元素应用、微服务、自助式敏捷基础设施、基于API的协作、脆弱性等。云原生系统的内容没有明确的定义,但一般认为云原生技术体系和方法论包括微服务、容器、DevOps、持续交付、ServiceMesh、不可变基础设施、声明式API、混沌工程、安全、基于移动的客户体验等等。

图1云原生技术系统

十二要素的应用为云原生应用的设计提供了原则指导;微服务架构为云原生应用架构设计、分布式部署、敏捷变更等提供解决方案。容器为云原生应用提供弹性伸缩和环境一致的能力,并结合微服务支持应用按需扩展;自助式敏捷基础设施为云原生应用的持续交付提供了基础设施资源等保障,可以与容器化的PaaS平台协同工作,支持云原生应用的自动弹性扩展、可视化监控、自动化智能运维,用户无需关注基础设施资源、基础设施资源运维、应用部署位置等。服务网格支持服务的管理和治理;混沌工程不断增强系统的韧性和稳定性;Ops优化组织间的协作,满足彼此的关切,引导C ICD的落地和持续交付,实现应用生命周期管理;Statement A PI实现了标准化服务发布和服务之间的协作;安全涉及云原生架构的方方面面,如deveops安全、容器镜像安全、网络安全、应用安全、A PI安全、认证授权、访问控制等。所有这些技术、方法和原理都可以满足客户随时随地的需求,简化客户操作,提升客户体验。

基于对云原生架构体系的学习和理解,我认为一个比较完整的云原生架构体系包括以下内容:

图2云原生架构系统

随着移动通信技术的发展和移动设备的普及,人们的工作、生活、社交和投资方式发生了显著变化。目前,人们基本上可以通过手机随时随地满足需求。用户可能在不同时间(7x 24)通过不同终端、不同操作系统、不同版本、不同地点等访问业务应用系统。这不仅需要APP客户端的便捷操作和友好交互,还需要后端服务和系统的敏捷响应。手机App应用的体验可能会直接决定用户是否会继续使用。在移动互联网时代,用户的移动体验需求是应用设计的关键驱动力。

云应用12描述了云应用的原型,是云应用(可独立部署单元)的设计原则和方法论。它通过强调声明性配置、水平扩展无状态/共享流程以及与部署环境的整体松散耦合来关注速度、安全性和可伸缩性。Kevin Hoffman在《Beyond the 12-factor App》中对云原生应用的12个要素进行了重新描述和扩展,增加了三个要素:API优先级、遥测、认证和授权。新加入的元素结合了API协作、可视化监控、安全等内容,在指导云原生应用的设计上更加完善。

微服务架构是一种应用分布式架构,它将一个整体的应用拆分成若干个可独立部署的具有单一能力的服务,即微服务。通常是微服务代表

一种业务能力,或是提供业务价值的最小的“原子”服务单元。它解决了紧耦合的单体巨石系统难以变更难以更新的问题,实现轻量、敏捷变更。

  图片图 3 单体架构演化到微服务架构

  中台本质也是一种架构方式,其核心是实现复用。中台一直被当作是一种企业架构,没有很明确讨论复用的粒度,所以其落地没有明确的方式方法和标准。从应用架构角度来说,中台和应用的前、中、后端层次划分没有本质区别,算不上一种新的架构方式。微服务分解架构从横向将系统进行分解,中台分层架构从纵向将系统分层,从而实现微服务在不同层次的复用和共享。从单个应用系统扩展到企业所有的系统,最终可以融合成一个分层分解的企业级系统,这就是笔者一直所提的 “ 系统融合 ” 思路。

  容器是一种内核轻量级的操作系统层虚拟化技术,在流程级别提供隔离,为单一的应用程序提供运行一致的运行环境。每个应用程序及其环境都可以在隔离的环境中运行。容器特性和微服务架构非常契合,因此微服务通常部署在容器中,实现敏捷部署、自动化弹性伸缩、环境一致性等能力。但容器依然是相对底层的运行单元,众多容器的管理和治理是个难题。Kubernetes(也称为K8s)是一个开源容器管理和调度框架,用于自动化容器应用程序的部署、扩展和管理。它将构成应用程序的容器分组到逻辑单元中,以便于管理和发现。容器云平台是采用容器和容器管理及调度技术而构建的应用管理部署运行平台,支持不同租户的容器应用管理和治理能力。基于容器云而把日志、监控、认证、权限、配置、中间件、工具平台,以及算法等统一部署维护,提供企业级平台服务能力,构建轻量化P aaS平台,结合自动化、智能化实现自服务敏捷响应基础设施能力。

  图 4 容器云架构

  云原生的核心是云原生应用。自服务敏捷响应基础设施为云原生应用的自动化环境准备、构建、部署、监控、反馈、健康检查、故障自愈、资源调度、弹性伸缩、动态路由和负载均衡等提供支撑, 实现自主服务平台进行云原生应用的部署和运行,使配置管理自动化、基础设施资源透明,无需关注应用运行在什么地方;将IaaS和PaaS最终融合在一起,提供更流畅的、一致的体验;企业内部可通过基础设施资源管理(多云管理平台)实现异构资源的管理,统一的资源服务;实现持续交付,提升可用性、可扩展性、可管理性。

  DevOps是一种理念和方法论,目的是为了协调和理顺开发和运维团队之间的关切,提升协作效率。DevOps旨在实现开发运维一体化,通过自动化、智能化等工具实现应用全生命周期管理和组织之间的高效协同。基于D evOps方法论和理念所构建的平台也称为 D evOps平台,通常要用自动化流水线等实现持续集成 C I、持续交付CD等能力。Google SRE是DevOps的一种具体实践,它通过系统工程的思想来解决软件工程的问题, 使运维自动化和智能化。运维人员不低于 5 0%的时间做运维工具的研发,让研发人员专注于业务应用的研发。Google SRE使用错误预算来协调研发和运维之间的关切,一旦错误预算用尽,则运维将拒绝业务应用的发布部署,从而使研发要关注业务应用的稳定性和健壮性。

  服务网格(ServiceMesh )实现微服务东西向流量的管理和治理。其区别于API网关对服务南北向流量的管理和治理。其通常应用于容器环境,以sidecar的方式代理流量管理、可观测性和安全能力。服务网格总体架构由流量代理组件和管理组件组成, 代理组件被称为数据平面,直接处理入站和出站数据包,转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。管理组件被称为控制平面,负责与代理通信,下发策略和配置。笔者一直跟踪着服务网格发展但一直没有采用,原因在于一方面感觉其不够成熟,另一方面其加层的方式会带来延迟,和笔者推崇的简单方式解决复杂问题思路有悖。

  抗脆弱性由Naasim Taleb在《Antifragile》书中提出,将故障随机注入到生产环境中,目的是为了识别和消除架构中的缺陷,找到应用架构中的弱点,并强制进行修复,架构会随着时间的推移而变得强壮,提升其稳定性、可用性、耐久性等。在国内也称之为混沌工程(Chaos Engineering)。中国信通院于2 020年开始组织 进行混沌工程技术研究,提出了应用混沌工程方法来验证云原生系统的韧性架构,同时成立混沌工程项目组。2 021年 发布《混沌工程测试平台能力》标准纲要,并发布行业标准《混沌工程平台能力要求》。

  云原生应用之间的交互是通过已发布和版本化的API来实现的,通常采用HTTP Rest 风格序列化JSON数据。通过API 可以提供一层可重用接口层。同时API封装了业务逻辑内部细节,消费者不能直接访问API服务内部数据,也在一定程度上增强了数据安全。

  安全是任何系统不可或缺的部分。风险无处不在,云原生架构体系中内容众多,每个组件每个服务都可能带来风险和安全问题(因此要通过 “ 减层 ” 方法最小化组件和服务,严格遵循 “ 非必要不采用原则 ” )。从云原生应用生命周期过程来说,云原生安全可以简单分为 “ 设计时安全 ” 和 “ 运行时安全 ” 两段。设计时以静态检测分析为主,比如代码分析、镜像漏洞扫描等;运行时以动态和交互式检测、防护、分析为主,比如入侵检测、病毒查杀、网络微隔离等。云原生安全可以利用传统的安全技术和方法,比如认证授权、访问控制、加密解密、合规检测、静态安全检测、动态安全检测、网络隔离等等,重点是通过可用的安全机制增强云原生安全能力。虽然我们提倡安全左移,尽可能将安全风险消除在设计时段,但运行时安全一样不可少,安全漏洞随时都可能出现,采用微服务、容器的云原生架构也为运行时带来了更多的风险点,安全防控更加不易。需要不断提升系统可见性、错误隔离等能力提升安全管控能力。云原生安全和传统网络安全的分安全域模式不同,它需要动态的自动化和智能化的管控能力。云原生未来可能逐渐通过软件定义边界、增强的身份认证、微隔离等技术实现动态的网络安全管控。

  

  云原生架构体系内容比较庞大,深入到每一个部分都有很多的工作。不过在对云原生体系架构和体系内容有全面的了解之后,认识到彼此之间的联系和局限,才能真正构建满足客户需求、支持移动化随时随地随需的服务、具备云计算特性弹性扩展、敏捷响应、安全稳定的云原生应用。

免责声明:本文由用户上传,如有侵权请联系删除!