系统架构设计师教程第14章 14.2 云原生架构内涵笔记

z2014z

于 2024-10-07 09:30:00 发布

阅读量1.1k

点赞数 20

分类专栏：系统架构设计师文章标签：系统架构云原生架构

本文链接：https://blog.csdn.net/z2014z/article/details/142724260

版权

系统架构设计师专栏收录该内容

37 篇文章 1 订阅

订阅专栏

14.2 云原生架构内涵 ★★★★☆

14.2.1 云原生架构定义

云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等)，具备轻量、敏捷、高度自动化的特点。由于云原生是面向“云”而设计的应用，技术部分依赖于传统云计算的3层概念，即基础设施即服务 (IaaS)、平台即服务 (PaaS) 和软件即服务 (SaaS)。

云原生的代码通常包括三部分：业务代码、三方软件、处理非功能特性的代码。其中

业务代码指实现业务逻辑的代码；

三方软件是业务代码中依赖的所有三方库，包括业务库和基础库；

处理非功能性的代码指实现高可用、安全、可观测性等非功能性能力的代码。

特点：

1.代码结构发生巨大变化

2.非功能性特性大量委托

3.高度自动化的软件交付

14.2.2 云原生架构原则

1.服务化原则

代码规模超过一定范围时，需要进行拆分，包括拆分为微服务架构、小服务 (MiniService) 架构，通过服务化架构把不同生命周期的模块分离出来，分别进行业务迭代，避免相互影响，从而加快整体的进度和稳定性。同时服务化架构以面向接口编程，服务内部的功能高度内聚，模块间通过公共功能模块的提取增加软件的复用程度。

使用基于服务流量(而非网络流量)的控制策略

2.弹性原则

弹性则是指系统的部署规模可以随着业务量的变化而自动伸缩，无须根据事先的容量规划准备固定的硬件和软件资源。

3.可观测原则

可观测能力是在云这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，使得一次点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、 SQL请求、节点拓扑、网络响应等，可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。

4.韧性原则

韧性代表了当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，异常通常包括硬件故障、硬件资源瓶颈(如 CPU/ 网卡带宽耗尽)、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件bug、黑客攻击等。

韧性是软件持续提供业务服务的能力，核心目标是提升软件的平均无故障时间 (Mean Time Between Failure,MTBF)。

从架构设计上，韧性包括服务异步化能力、重试/ 限流/降级/熔断/反压、主从模式、集群模式、 AZ 内的高可用、单元化、跨region 容灾、异地多活容灾等。

5.所有过程自动化原则

通过 IaC(Infrastructure as Code)、GitOps、OAM(Open Application Model)、Kubernetes Operator和大量自动化交付工具在CI/CD 流水线中的实践，一方面标准化企业内部的软件交付过程，另一方面在标准化的基础上进行自动化，通过配置数据自描述和面向终态的交付过程，让自动化工具理解交付目标和环境差异，实现整个软件交付和运维的自动化。

6.零信任原则

核心思想：默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础

零信任第一个核心问题就是身份 (Identity), 赋予不同的实体不同的身份，解决是谁在什么环境下访问某个具体的资源的问题。

7.架构持续演进原则

云原生架构是一个具备持续演进能力的架构，除了增量迭代、目标选取等因素外，还需要考虑组织层面的架构治理和风险控制，特别是在业务高速迭代情况下的架构、业务、实现平衡关系。