【系统架构设计师】二十、云原生架构设计理论与实践②

帅次

已于 2024-08-09 17:57:53 修改

阅读量676

点赞数 10

分类专栏：系统架构设计师(新版) 文章标签：云原生系统架构设计师 ios android 软考系统架构

于 2024-07-29 08:30:00 首次发布

本文链接：https://blog.csdn.net/g984160547/article/details/140711149

版权

系统架构设计师(新版) 专栏收录该内容

62 篇文章 35 订阅

订阅专栏

8.2 云原生技术助力某汽车公司数字化转型实践

8.3 某快递公司核心业务系统云原生改造

8.4 某电商业务云原生改造

五、云原生架构相关技术

5.1 容器技术

容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境间快速、可靠地运行。

通过容器技术，企业可以充分发挥云计算弹性优势，降低运维成本。一般而言，借助容器技术，企业可以通过部署密度提升和弹性降低50%的计算成本。

        容器编排：
        Kubernetes 已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。
        Kubernetes 提供了分布式应用管理的核心能力，包括：资源调度、应用部署与管理、自动修复、服务发现与负载均衡、弹性伸缩、声明式AP1、可扩展性架构、可移植性。

5.2 云原生微服务

微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微服务”，多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。此外，微服务模式通过分布式架构将应用水平扩展和冗余部署，从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。

5.2.1 微服务设计约束

（1）微服务个体约束：功能在业务域划分上应是相互独立的，低耦合、单一职责。

（2）微服务与微服务之间的横向关系：主要从微服务的可发现性和可交互性处理服务间的横向关系一般需要服务注册中心。

（3）微服务与数据层之间的纵向约束：在微服务领域，提供数据存储隔离原则，即数据是微服务的私有资产，对于该数据的访问都必须通过当前微服务提供的API来访问。

（4）全局视角下的微服务分布式约束：故障发现时效性和根因精确性始终是开发运维人员的核心诉求。

5.2.2 主要微服务技术

Apache Dubbo 作为源自阿里巴巴的一款开源高性能RPC 框架，特性包括基于透明接口的RPC、智能负载均衡、自动服务注册和发现、可扩展性高、运行时流量路由与可视化的服务治理。

Spring Cloud作为开发者的主要微服务选择之一，为开发者提供了分布式系统需要的配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性Token、全局锁、决策竞选、分布式会话与集群状态管理等能力和开发工具。

Eclipse MicroProfile 作为Java微服务开发的基础编程模型，它致力于定义企业Java微服务规范， MicroProfile提供指标、 API文档、运行状况检查、容错与分布式跟踪等能力，使用它创建的云原生微服务可以自由地部署在任何地方，包括服务网格架构。

Tars是腾讯将其内部使用的微服务框架TAF(Total Application Framework)多年的实践成果总结而成的开源项目，它包含一整套开发框架与管理平台，兼顾多语言、易用性、高性能与服务治理，理念是让开发更聚焦业务逻辑，让运维更高效。

SOFAStack(Scalable Open Financial Architecture Stack) 是由蚂蚁金服开源的一套用于快速构建金融级分布式架构的中间件，也是在金融场景里的最佳实践。

DAPR(Distributed Application Runtime, 分布式应用运行时)是微软新推出的一种可移植的、无服务器的、事件驱动的运行时，它使开发人员可以轻松构建弹性，无状态和有状态微服务，这些服务运行在云和边缘上，并包含多种语言和开发框架。

六、无服务器技术

无服务器技术 (Serverless)因为屏蔽了服务器的各种运维复杂度，让开发人员可以将更多精力用于业务逻辑设计与实现，而逐渐成为云原生主流技术之一。 Serverless计算包含以下特征：

（1）全托管的计算服务，客户只需要编写代码构建应用，无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作；
（2）通用性，结合云BaaSAPI的能力，能够支撑云上所有重要类型的应用；
（3）自动弹性伸缩，让用户无需为资源使用提前进行容量规划；
（4）按量计费，让企业使用成本得有效降低，无需为闲置资源付费。

函数计算 (Function as a Service,FaaS) 是 Serverless中最具代表性的产品形态。通过把应用逻辑拆分多个函数，每个函数都通过事件驱动的方式触发执行。同样，通过消息中间件和函数计算的集成，客户可以快速实现大规模消息的实时处理。

无服务器技术的关注点是：计算资源弹性调度（容错、资源利用率、性能、数据驱动）、负载均衡和流控、安全性。

七、服务网格

服务网格 (ServiceMesh)是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，提升应用开发效率并加速业务探索和创新。

在这张架构图中，服务A 调用服务B 的所有请求，都被其下的服务代理截获，代理服务 A 完成到服务B 的服务发现、熔断、限流等策略，而这些策略的总控是在控制平面 (Control Plane)上配置。

服务网格的主要技术：Istio、Linkerd、Consul。

八、云原生架构案例分析

基于云原生架构的应用通常针对云的技术特性进行技术生命周期设计，最大限度利用云平台的弹性、分布式、自助、按需等产品优势。借助以下几个典型实践案例，我们来看看企业如何使用云原生架构解决交付周期长、资源利用率低等实际业务问题。（图可能会在案例分析中出现）

8.1 某旅行公司云原生改造

某旅行公司主要面临两个问题。①由于刚和某网完成公司主体合并不久，必须在技术层面做进一步的收敛，以达到平台统一的目的。②在线旅行业务具有较明显的业务波动特性，在季度、节假日、每日时段上都有比较突出的波峰波谷特性(高并发流量)。

改造第一阶段，某旅行技术团队为了提升集群资源利用率，降低资源使用成本。利用云原生思维重构部分技术体系，将多套旧有系统合并、收拢到一套以云原生应用为核心的私有云平台上，同时将 IDC、物理网络、虚拟网络、计算资源、存储资源等通过laaS、PaaS等，实现虚拟化封装、切割、再投产的自动化流程。

改造第二阶段，基于公有云、私有云和离线专属云集群等新型动态计算环境，某旅行公司的技术团队帮助业务构建和运行具有弹性的云原生应用，促进业务团队开始使用声明式 API, 同时通过不可变基础设施、服务网格和容器服务，来构建容错性好、易于管理和观察的应用系统，并结合平台可靠的自动化恢复、弹性计算来完成整个服务稳定性的提升。

改造第三阶段，通过基础组件、服务的云原生改造、服务依赖梳理和定义等方式，使应用不再需要考虑底层资源、机房、运行时间和供应商等因素。此外，某旅行公司还利用标准的云原生应用模型，实现了服务的跨地域、跨云自动化灾备、自动部署，并向云原生场景下的 DevOps 演进。某旅行公司云原生平台架构图如下图所示：

8.2 云原生技术助力某汽车公司数字化转型实践

战略性构建容器云平台。通过平台实现对某云行 App、二手车、在线支付、优惠券等核心互联网应用承载。以多租户的形式提供弹性计算、数据持久化、应用发布等面向敏捷业务服务，并实现高水平资源隔离。标准化交付部署，快速实现业务扩展，满足弹性要求。利用平台健康检查、智能日志分析和监控告警等手段及时洞察风险，保障云平台和业务应用稳定运行。

数字混合云交付。采用私有云+公有云的混合交付模式，按照服务的敏态/稳态特性和管控要求划分部署，灵活调度公有云资源来满足临时突发或短期高TPS 业务支撑的需求。

深度融合微服务治理体系。实现架构的革新和能力的沉淀，逐步形成支撑数字化应用的业务中台。其云平台架构如下图所示：

8.3 某快递公司核心业务系统云原生改造

        某快递公司核心业务系统原架构基于 Vmware+Oracle 数据库进行搭建。随着搬迁上阿里云，架构全面转型为基于Kubernetes的云原生架构体系。其中，引入云原生数据库并完成应用基于容器的微服务改造是整个应用服务架构重构的关键点。
        引入云原生数据库。通过引入 OLTP 跟 OLAP 型数据库，将在线数据与离线分析逻辑拆分到两种数据库中，改变此前完全依赖Oracle数据库的现状。
        应用容器化。伴随着容器化技术的引进，通过应用容器化有效解决了环境不一致的问题，确保应用在开发、测试、生产环境的一致性。
         微服务改造。通过引入Kubernetes的服务发现，组建微服务解决方案，将业务按业务域进行拆分，让整个系统更易于维护。

综合考虑申通实际业务需求与技术特征，最终选择了“阿里云 ACK+ 神龙+云数据库”的
云原生解决方案，从而实现核心应用迁移上阿里云。如下图展示了最终的上云架构。

基础设施，全部计算资源取自阿里云的神龙裸金属服务器。

流量接入，阿里云提供两套流量接入，一套是面向公网请求，另外一套是服务内部调用。

平台层，基于Kubernetes打造的云原生PaaS 平台优势明显突出。

应用服务层，每个应用都在Kubernetes上面创建单独的一个Namespace,应用和应用之间实现资源隔离。

运维管理，线上 Kubernetes集群采用阿里云托管版容器服务，免去了运维Master结点的工作，只需要制定Worker结点上线及下线流程即可。

8.4 某电商业务云原生改造

通过阿里云原生应用稳定性解决方案以解决业务问题。引入阿里云容器服务ACK、Spring Cloud Alibaba、PTS、AHAS、链路追踪等配套产品，对应用进行容器化改造部署，优化配套的测试、容量评估、扩缩容等研发环节，提升产研效率。下图展示了某最终的核心应用架构方案。

方案的关键点是：
        ● 通过容器化部署，利用阿里云容器服务的快速弹性应对大促时的资源快速扩容。
        ● 提前接入链路追踪产品，用于对分布式环境下复杂的服务调用进行跟踪，对异常服务进行定位，帮助客户在测试和生产中快速定位问题并修复，降低对业务的影响。
        ● 使用阿里云性能测试服务 (PTS)进行压测，利用秒级流量拉起、真实地理位置流量等功能，以最真实的互联网流量进行压测，确保业务上线后的稳定运营。
        ● 采集压测数据，解析系统强弱依赖关系、关键瓶颈点，对关键业务接口、关键第三方调用、数据库慢调用、系统整体负载等进行限流保护。
        ● 配合阿里云服务团队，在大促前进行ECS/RDS/安全等产品扩容、链路梳理、缓存/连接池预热、监控大屏制作、后端资源保障演练等，帮助大促平稳进行。