破解阿里云系统的软件_浅析阿里《云原生架构白皮书》

介绍

提前看了《云原生架构白皮书》，一直想着写点东西。 然而我却一直在拖延、拖延。 《白皮书》正式发布已经两天了，我还没有开始做。 我之所以没有开始，是因为我的懒癌又复发了； 另一个原因是《白皮书》覆盖面太广，基本上涉及到了云原生的各个方面，而我在云原生方面的知识基础还不足以支持我写一本书。 一篇好文章。

虽然云原生的概念在2013年就被提出了，但迄今为止大家对它的理解侧重点略有不同。 这里阿里巴巴给出了自己对于云原生的理解。 请看如下所示的《白皮书》目录。 全文从7个章节对云原生架构进行了分析和讲解。 我也将带您快速了解这7个方面......

为什么需要云原生

这部分内容相对较少。 你可以看看《白皮书》是怎么说的。 我理解的重点是：技术发展已经进入云时代，硬件升级，更新速度要求越来越高。 “生产关系”严重制约了“生产力”的发展。 云时代，需要新的技术架构来解决人们越来越高的“生产力”要求。 于是，云原生架构应运而生。

云原生架构 云原生架构定义

从技术角度来看，云原生架构是基于云原生技术的架构原则和设计模式的集合。 旨在最大限度剥离云应用中的非业务代码部分，让云设施接管应用中的原始代码。 大量的非功能性特征（如弹性、复原力、安全性、可观察性、灰度化等）使业务不再受非功能性业务中断的困扰，同时又轻量、敏捷、高度自动化。

利用云服务和提升软件交付能力，进一步加快软件开发
让开发专注于对公司业务最核心的部分，剥离大量非功能性特性
具有高度自动化的软件交付

云原生架构原则： 面向服务原则：将一个大服务拆分为多个小服务，每个小团队负责指定的服务。 各服务之间升级互不影响，加快业务迭代。 弹性原则：弹性是指系统的部署规模能够随着业务量的变化自动扩展和收缩。 可观察性原则：可观察性是指通过log、trace等手段，让一次点击背后的多个服务调用的耗时、返回值、参数清晰可见。 弹性原则：弹性是指当软件所依赖的软硬件组件发生各种异常时，软件承受的能力。 全流程自动化原则：软件技术栈的复杂性和组件规模的增加带来了软件交付的复杂性，通过使用自动化交付工具来实现交付和运维的自动化。 零信任原则：默认情况下，网络内外的任何人/设备/系统都不应该被信任，需要基于认证和授权来重构访问控制的信任基础。 架构持续演进原则：技术和业务仍处于快速变革的时代，云原生架构本身也需要具备持续演进的能力。 主要架构模型： 基于服务的架构模型：基于服务的架构是云时代构建云原生应用的标准架构模型。 需要以应用模块为粒度划分软件，用接口契约（如IDL）定义相互的业务关系，使用标准协议（HTTP、gRPC等）保证相互的互联，并结合DDD（领域模型驱动） 、TDD（测试驱动开发）、容器化部署，提高各接口的代码质量和迭代速度。

Mesh架构模型：Mesh架构将中间件框架（如RPC、缓存、异步消息等）与业务流程分离，进一步将中间件SDK与业务代码解耦。 模式：模式更进一步，将用户从非核心中解放出来，只需要关心核心业务逻辑。 存储与计算分离模式：以不同的方式处理存储等有状态操作和计算等不需要状态的操作。 分布式事务模型：微服务模型提倡每个服务使用私有数据源，而不是像单体应用那样共享数据源。 但在实际使用场景中，总会有一些其他因素需要考虑。 因此，有以下几种适应不同场景的分布式事务模式：XA模式、BASE、TCC模式、SAGA模式、AT模式。 可观察架构：可观察架构包括三个方面： 、 、 。 事件驱动架构：本质上是应用程序/组件之间的集成架构模式。 典型的云原生架构反模式： 庞大的单体应用：庞大的单体应用最大的问题是缺乏依赖隔离，因此需要考虑通过服务化进行一些拆分。 将单体应用“硬拆分”为微服务：服务的拆分需要适度。 过度的面向服务的拆分会导致新架构与组织能力的不匹配。 缺乏自动化能力的微服务：当软件规模变大时，缺乏自动化能力会带来更大的危害。 主要云原生技术 容器技术 容器技术的背景和价值

提出了创新的应用程序打包规范——镜像，将应用程序与运行环境解耦，使应用程序能够跨不同计算环境一致、可靠地运行。 实现开发所需的灵活性、开放性与运维注重的标准化、自动化之间的相对平衡。

容器编排

它已成为容器编排事实上的标准，广泛用于自动部署、扩展和管理容器化应用程序。

提供分布式应用管理的核心能力。

容器编排有几个关键的设计理念：

1. 声明式API
2. 可扩展性架构
3. 可移植性

云原生微服务微服务开发背景

云原生时代，云原生微服务系统将充分利用云资源的高可用和安全体系，为应用提供更有保障的弹性、可用性和安全性。

微服务设计约束

与单体应用相比，微服务架构的架构改造不仅提高了开发部署的灵活性，同时也增加了运维和监控的复杂度。

1 微服务个体约束：当一个微服务修改或发布时，不应影响同一系统中另一个微服务的业务交互。

2 微服务之间的横向关系：主要微服务的可发现性和交互性处理服务之间的横向关系。

3 微服务与数据层的纵向约束：在微服务领域，提倡数据存储隔离的原则。 对于有状态的微服务，通常采用计算和存储分离的方式。

4 全局视角下的微服务分布约束：从微服务系统设计开始，就需要考虑全局视角。

云原生微服务典型架构

第一代微服务架构：

第二代微服务架构：

第三代微服务架构：

第四代微服务架构：

主要微服务技术

Apache Dubbo
Spring Cloud
Eclipse MicroProfile
Tars
SOFAStack
Dapr

1 技术特点

全托管的计算服务
通用性
自动的弹性伸缩
按量计费

2 常见场景

小程序 /Web/Mobile/API 后端服务
大规模批处理任务
基于事件驱动架构的在线应用和离线数据处理
开发运维自动化