云原生架构设计论文参考资料.docx

《云原生架构设计论文参考资料.docx》由会员分享，可在线阅读，更多相关《云原生架构设计论文参考资料.docx（11页珍藏版）》请在第一文库网上搜索。

1、一、为什么需要云原生架构？企业内部IT建设如果都基于最底层IDC设施独自向上构建,都需要单独分配硬件资源,这就造成资源被大量占用且难以被共享。但是上云之后，由于云厂商提供了统一的IaaS能力和云服务，大幅提升了企业IaaS层的复用程度，使资源、产品可被不断复用，从而能够进一步降低企业运营成本。二、云原生架构定义应用的开发人员不用在其代码中处理节点宕机前如何把本地保存的内容同步到远端（云存储，如对象存储，文件存储，块存储等）的问题，也不用处理当业务峰值到来时如何对存储节点进行扩容（HPA）的问题。非功能性特性的大量委托任何应用都提供两类特性，功能性特性和非功能性特性。功能性特性是真正为业务带来价

2、值的代码，比如如何建立客户资料、如何处理订单、如何支付等等；即使是一些通用的业务功能特性，比如组织管理、业务字典管理、搜索等等也是紧贴业务需求的。非功能性特性是没有给业务带来直接业务价值，但通常又是必不可少的特性，比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等等。以大家最头疼的高可用为例，云产品在多个层面为应用提供了解决方案：虚机：当虚机检测到底层硬件异常时，自动帮助应用做热迁移，迁移后的应用不需重新启动而仍然具备对外服务的能力，应用对整个迁移过程都不会有任何感知；容器：有时应用所在的物理机是正常的，只是应用自身的问题（比如bug、资源耗尽等）而无法正常对外提供

3、服务。容器通过监控检查探测到进程状态异常，从而实施异常节点的下线、新节点上线和生产流量的切换等操作，整个过程自动完成而无需运维人员干预；云服务：如果应用把“有状态”部分都交给了云服务（如缓存、数据库、对象存储等），加上全局对象的持有小型化或具备从磁盘快速重建能力，由于云服务本身是具备极强的高可用能力，那么应用本身会变成更薄的“无状态”应用，因为高可用故障带来的业务中断会降至分钟级；如果应用是N-M的对等架构模式，那么结合LoadBalancer产品可获得几乎无损的高可用能力！高度自动化的软件交付软件一旦开发完成，需要在公司内外部各类环境中部署和交付，以将软件价值交给最终客户。软件交付的困难在于

4、开发环境到生产环境的差异（公司环境到客户环境之间的差异）以及软件交付和运维人员的技能差异，填补这些差异的是一大堆安装手册、运维手册和培训文档。容器以一种标准的方式对软件打包，容器及相关技术则帮助屏蔽不同环境之间的差异,进而基于容器做标准化的软件交付。对自动化交付而言，还需要一种能够描述不同环境的工具，让软件能够“理解”目标环境、交付内容、配置清单并通过代码去识别目标环境的差异，根据交付内容以“面向终态”的方式完成软件的安装、配置、运行和变更。基于云原生的自动化软件交付相比较当前的人工软件交付是一个巨大的进步。以微服务为例，应用微服务化以后，往往被部署到成千上万个节点上，如果系统不具备高度的自动

5、化能力，任何一次新业务的上线，都会带来极大的工作量挑战，严重时还会导致业务变更超过上线窗口而不可用。三、云原生架构原则1、服务化原则2、弹性原则3、可观测原则今天大部分企业的软件规模都在不断增长，原来单机可以对应用做完所有调试，但在分布式环境下需要对多个主机上的信息做关联，才可能回答清楚服务为什么宕机、哪些服务违反了其定义的SLO、目前的故障影响哪些用户、最近这次变更对哪些服务指标带来了影响等等，这些都要求系统具备更强的可观测能力。可观测性与监控、业务探活、APM等系统提供的能力不同，前者是在云这样的分布式系统中，主动通过日志、链路跟踪和度量等手段，让一次APP点击背后的多次服务调用的耗时、返

6、回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL请求、节点拓扑、网络响应等，这样的能力可以使运维、开发和业务人员实时掌握软件运行情况，并结合多个维度的数据指标，获得前所未有的关联分析能力，不断对业务健康度和用户体验进行数字化衡量和持续优化。4、韧性原则当业务上线后，最不能接受的就是业务不可用，让用户无法正常使用软件，影响体验和收入。韧性代表了当软件所依赖的软硬件组件出现各种异常时，软件表现出来的抵御能力，这些异常通常包括硬件故障、硬件资源瓶颈（如CPU/网卡带宽耗尽）、业务流量超出软件设计能力、影响机房工作的故障和灾难、软件bug、黑客攻击等对业务不可用带来致命影响的因素。韧性从多

7、个维度诠释了软件持续提供业务服务的能力，核心目标是降低软件的MTBF（MeanTimeBetweenFai 1 ure,平均无故障时间）o从架构设计上，韧性包括服务异步化能力、重试/限流/降级/熔断/反压、主从模式、集群模式、AZ内的高可用、单元化、跨region容灾、异地多活容灾等。5、所有过程自动化原则6、零信任原则7、架构持续演进原则今天技术和业务的演进速度非常快，很少有一开始就清晰定义了架构并在整个软件生命周期里面都适用，相反往往还需要对架构进行一定范围内的重构，因此云原生架构本身也应该和必须是一个具备持续演进能力的架构，而不是一个封闭式架构。四、主要架构模式云原生架构有非常多的架构模

8、式，这里选取一些对应用收益更大的主要架构模式进行讨论。1、服务化架构模式服务化架构的典型模式是微服务和小服务（MiniService）模式，其中小服务可以看做是一组关系非常密切的服务的组合，这组服务会共享数据，小服务模式通常适用于非常大型的软件系统，避免接口的颗粒度太细而导致过多的调用损耗（特别是服务间调用和数据一致性处理）和治理复杂度。2、Mesh化架构模式如服务网格（ServiceMesh）oMesh化架构是把中间件框架（比如RPC、缓存、异步消息等）从业务进程中分离，让中间件SDK与业务代码进一步解耦，从而使得中间件升级对业务进程没有影响，甚至迁移到另外一个平台的中间件也对业务透明。分离

9、后在业务进程中只保留很“薄”的Client部分，Client通常很少变化，只负责与Mesh进程通讯，原来需要在SDK中处理的流量控制、安全等逻辑由Mesh进程完成。容器/主机业务进程业务代码I SDK协议/标准协议Mesh进程I（流量控制、安全策略、微隔离|新协议、加密、染色Mesh化架构3、Serverless 模式和大部分计算模式不同，Serverless将“部署”这个动作从运维中“收走”，使开发者不用关心应用在哪里运行，更不用关心装什么OS、怎么配置网络、需要多少CPU从架构抽象上看，当业务流量到来/业务事件发生时，云会启动或调度一个已启动的业务进程进行处理，处理完成后云自动会关闭/调度

10、业务进程，等待下一次触发，也就是把应用的整个运行时都委托给云。4、存储计算分离模式分布式环境中的CAP困难主要是针对有状态应用，因为无状态应用不存在C （一致性）这个维度，因此可以获得很好的A （可用性）和P （分区容错性），因而获得更好的弹性。在云环境中，推荐把各类暂态数据（如session）,结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。但仍然有一些状态如果保存到远端缓存，会造成交易性能的明显下降，比如交易会话数据太大、需要不断根据上下文重新获取等，则可以考虑通过采用EventLog+快照（或Checkpoint）的方式，实现重启后快速增量恢复服务,减少不可用对业务的影

11、响时长。5、分布式事务模式微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源，但往往大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。传统采用XA模式，虽然具备很强的一致性，但是性能差；基于消息的最终一致性(BASE)通常有很高的性能，但是通用性有限，且消息端只能成功而不能触发消息生产端的事务回滚；TCC模式完全由应用层来控制事务，事务隔离性可控，也可以做到比较高效；但是对业务的侵入性非常强，设计开发维护等成本很高；SAGA模式与TCC模式的优缺点类似但没有try这个阶段，而是每个正向事务都对应一

12、个补偿事务，也是开发维护成本高；开源项目SEATA的AT模式非常高性能且无代码开发工作量，且可以自动执行回滚操作，同时也存在一些使用场景限制。6、可观测架构可观测架构包括Logging、Tracing. Metrics三个方面。其中Logging提供多个级别(verbose/debug/warning/error/fatal)的详细信息跟踪，由应用开发者主动提供；Tracing提供一个请求从前端到后端的完整调用链路跟踪，对于分布式场景尤其有用；Metrics则提供对系统量化的多维度度量。架构决策者需要选择合适的、支持可观测的开源框架(比如OpenTracing .OpenTelemetry),

13、并规范上下文的可观测数据规范(例如方法名、用户信息、地理位置、请求参数等)，规划这些可观测数据在哪些服务和技术组件中传播，利用日志和tracing信息中的spanid/traceid,确保进行分布式链路分析时有足够的信息进行快速关联分析。由于建立可观测性的主要目标是对服务SLO (ServiceLevelObjective)进行度量，从而优化SLA,因此架构设计上需要为各个组件定义清晰的SLO,包括并发度、耗时、可用时长、容量等。7、事件驱动架构五、主要云原生技术主要有容器技术，云原生微服务，以下分别说明六、容器技术1、容器技术背景与价值在过去几年，容器技术获得了越发广泛的应用的同时，三个核心

14、价值最受用户关注：敏捷容器技术提升企业IT架构敏捷性的同时，让业务迭代更加迅捷，为创新探索提供了坚实的技术保障。比如疫情期间，教育、视频、公共健康等行业的在线化需求突现爆发性高速增长，很多企业通过容器技术适时把握了突如其来的业务快速增长机遇。据统计，使用容器技术可以获得310倍交付效率提升，这意味着企业可以更快速的迭代产品，更低成本进行业务试错。弹性可移植性2、容器编排Kubernetes已经成为容器编排的事实标准，被广泛用于自动部署，扩展和管理容器化应用。Kubernetes提供了分布式应用管理的核心能力：资源调度：根据应用请求的资源量CPU、Memory,或者GPU等设备资源，在集群中选择

15、合适的节点来运行应用；应用部署与管理：支持应用的自动发布与应用的回滚，以及与应用相关的配置的管理;也可以自动化存储卷的编排，让存储卷与容器应用的生命周期相关联；自动修复：Kubernetes可以会监测这个集群中所有的宿主机，当宿主机或者OS出现故障，节点健康检查会自动进行应用迁移；K8s也支持应用的自愈，极大简化了运维管理的复杂性；服务发现与负载均衡：通过Service资源出现各种应用服务，结合DNS和多种负载均衡机制，支持容器化应用之间的相互通信；弹性伸缩：K8s可以监测业务上所承担的负载，如果这个业务本身的CPU利用率过高,或者响应时间过长，它可以对这个业务进行自动扩容。Kubernetes的控制平面包含四个主要的组件：APIServer、Controllerx Scheduler以及etcdo如下图所示:kubectlNode 1CloudProviderNetword EdgePods1,2.nNode 2PodsSystem ServicesContainer Runti