系统架构设计之云原生架构

云原生架构

一. 云原生技术介绍
二. 传统架构模式 VS 云原生架构模式
三. 云原生架构反模式
四. 云原生架构设计原则

在这里插入图片描述

其它相关推荐：
软考系统架构之案例篇(架构设计相关概念)
系统架构之微服务架构
系统架构设计之微内核架构
鸿蒙操作系统架构

所属专栏：系统架构设计师

一. 云原生技术介绍

【云原生】：是基于分布部署和统一运营的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。

云原生在技术部分上依赖于在传统云计算的3层概念：基础设施即服务（IaaS）、平台即服务（PaaS）和软件即服务（SaaS）。
在这里插入图片描述

二. 传统架构模式 VS 云原生架构模式

首先看一下两者对比图：
传统架构与云原生架构区别
传统架构建立在本地基础设施上，侧重于单体应用程序和垂直扩展。而云原生架构是专为云环境设计的，强调容器化、微服务、自动化和横向扩展。这两种架构之间有着明显的区别和优劣势。

云原生架构模式:

服务化架构模式
典型代表【微服务】，服务拆分使维护压力大增。
Mesh化架构模式
把中间件框架(RPC、缓存、异步消息)从业务进程中分离，由Mesh进程完成。
Serverless模式
非常适合于事件驱动的数据计算任务。
存储计算分离模式
各类暂态数据(如session)用云服务保存。
为什么要分离？即无状态和有状态应用架构的区别
无状态应用架构是指服务请求和所在的服务器完全无关，即使请求涉及数据相关的逻辑，也是从外部获取，服务器本身不存储任何信息；
有状态应用架构是指请求和对应服务器相关，如请求的数据在服务器上、会话数据在服务器内存中、对个请求相关联时将中间状态保存在服务器的内存或持久化存储中。
分布式事务模式
解决微服务模式中多数据源事务问题。
可观测架构
可观测性主要是指了解程序内部运行情况的能力。作为开发不希望应用发布上线后，对应用的内部一无所知。
可观测架构设计主要涉及三部分：日志（Logging）、度量（Metrics）和追踪（Tracing）。
事件驱动架构
其本质上是一种应用/组件间的集成架构模式。
事件驱动架构采用了松耦合的方式，事件的生成源并不知道哪些系统正在监听这些事件，而且事件也不知道自己所产生的结果，这是区别于 API 调用的，API 调用都能知道预期的结果。
既然事件驱动架构对结果的处理存在不确定性，还选择他的原因也是因为越来越多的分布式应用架构正在采纳松耦合和异步化。

三. 云原生架构反模式

反模式＝架构设计中的陷阱，反模式也是随着项目的推进演变而来的，主要的原因如重大需求调整，但架构没有对应的变化，性能和安全需求对当前架构的硬性改变，团队或组织强行调整技术等。

庞大的单体应用
需要多人开发的业务模块，考虑通过服务化进行拆分，并让组织与架构匹配
单体应用“硬拆”为微服务(服务拆分要适度)
小规模软件的服务拆分(为拆而拆)、数据依赖(服务间数据依赖)、性能降低
缺乏自动化能力的微服务
手动维护大量微服务是不现实的

四. 云原生架构设计原则

服务化原则：使用微服务
弹性原则：可根据业务变化自动伸缩
可观测原则：通过日志、链路跟踪和度量
韧性原则：面对异常的抵御能力
所有过程自动化原则：自动化交付工具
零信任原则：默认不信任网络内部和外部的任何人/设备/系统
架构持续演进原则：业务高速迭代情况下的架构与业务平衡

总结：

云原生架构的出现和逐渐普及，是对传统架构的一种革新和进步。它不仅改变了软件开发和IT基础设施的方式，也影响了企业的竞争力和业务发展。云原生架构的灵活性、可靠性、成本效益和持续交付的优势，使其成为当今企业和组织必备的技术和发展方向。

在一个日益变化和竞争激烈的市场环境中，企业需要将IT架构和开发方法进行现代化转型。云原生架构提供了更加适应云环境的解决方案，使得企业能更好地适应变化、提高效率并降低成本，因此，它已经成为现代企业的不可或缺的一部分。

在这里插入图片描述