山西做网站的公司,房屋设计软件app自己设计画图,做网站与做软件,软件开发培训机构地址系列文章目录
系统架构设计高级技能 软件架构概念、架构风格、ABSD、架构复用、DSSA#xff08;一#xff09;【系统架构设计师】 系统架构设计高级技能 系统质量属性与架构评估#xff08;二#xff09;【系统架构设计师】 系统架构设计高级技能 软件可靠性分析与设计…系列文章目录
系统架构设计高级技能 · 软件架构概念、架构风格、ABSD、架构复用、DSSA一【系统架构设计师】 系统架构设计高级技能 · 系统质量属性与架构评估二【系统架构设计师】 系统架构设计高级技能 · 软件可靠性分析与设计三【系统架构设计师】
现在的一切都是为将来的梦想编织翅膀让梦想在现实中展翅高飞。 Now everything is for the future of dream weaving wings, let the dream fly in reality. 系统架构设计高级技能 · 云原生架构设计理论与实践 系列文章目录一、 云原生架构内涵1.1 定义1.2 特点1.3 云原生的原则1.4 主要架构模式1.4.1 服务化架构模式1.4.2 Mesh化架构模式1.4.3 Serverless模式1.4.4 存储计算分离模式1.4.5 分布式事务模式1.4.6 可观测架构1.4.7 事件驱动架构 1.5 典型的云原生架构的反模式 二、云原生架构相关技术1.1 容器技术1.2 容器编排技术1.3 微服务1.4 无服务技术1.5 服务网络 一、 云原生架构内涵
1.1 定义
云原生架构 是基于云原生技术的一组架构原则和设计模式的集合旨在讲云应用中的非业务代码部分进行最大化地剥离从而让云设施接管应用中原有的大量非功能特性如弹性、韧性、安全、码部分进行最大化地剥离从而让云设施接管应用中原有的大量非功能特性如弹性、韧性、安全、可观测性、灰度等使业务不再有非功能性业务中断困扰的同时具备轻量、敏捷、高度自动化的特点。
1.2 特点
基于云原生架构的应用特点包括
1 代码结构发生巨大变化不再需要掌握文件及其分布式处理技术不再需要掌握各种复杂的网络技术简化让业务开发变得更敏捷、更快捷。 2 非功能特性大量委托给云原生架构来解决比如高可用能力、容灾能力、安全特性、可运维性、易用性、可测试性、灰度发布能力等。 3 高度自动化的软件交付基于云原生的自动化软件交付可以把应用自动化部署到成千上万的节点上。
1.3 云原生的原则
云原生具有以下原则
1 服务化原则通过服务化架构把不同生命周期的模块分离出来分别进行业务迭代。 2 弹性原则弹性是指系统的部署规模可以随着业务量的变化而自动伸缩。 3 可观测原则通过日志、链路跟踪和度量等手段使得多次服务调用的耗时、返回值和参数都清晰可见。 4 韧性原则软件所依赖的软硬件组件出现各种异常时软件表现出来的抵御能力。 5 所有过程自动化原则让自动化工具理解交付目标和环境差异实现整个软件交付和运维的自动化。 6 零信任原则不应该信任网络内部和外部的任何人/设备/系统需要基于认证和授权重构访问控制的信任基础。 7 架构持续演进原则架构具备持续演进的能力。
1.4 主要架构模式
云原生涉及的主要架构模式。
1.4.1 服务化架构模式
要求以应用模块为颗粒度划分一个应用软件以接口契约例如IDL定义彼此业务关系以标准协议HTTP、gRPC等确保彼此的互联互通结合领域模型驱动Domain Driven DesignDDD、测试驱动开发Test Driven DesignTDD、容器化部署提升每个接口的代码质量和迭代速度。
1.4.2 Mesh化架构模式
Mesh化架构是把中间件框架如RPC、缓存、异步消息等从业务进程中分离让中间件SDK与业务代码进一步解耦从而使得中间件升级对业务进程没有影响甚至迁移到另外一个平台的中间件也对业务透明。
1.4.3 Serverless模式
业务流量到来/业务事件发生时云会启动或调度一个已启动的业务进程进行处理处理完成后云自动会关闭/调度业务进程等待下一次触发。开发者不用关心应用运行地点、操作系统、网络配置、CPU性能等将应用的整个运行都委托给云。Serverless模式适合事件驱动的数据计算任务、计算时间短的请求/响应应用、没有复杂相互调用的长周期任务。
1.4.4 存储计算分离模式
分布式环境中的CAP困难主要是针对有状态应用由于一致性ConsistencyC可用性AvailableA分区容错性Partition ToleranceP三者无法同时满足最多满足其中两个。所以无状态应用不存在一致性这个维度可以获得很好的可用性和分区容错性因而获得更好的弹性。
1.4.5 分布式事务模式
由于业务需要访问多个微服务所以会带来分布式事务问题否则数据就会出现不一致。因此架构师需要根据不同的场景选择合适的分布式事务模式常用的有 1XA模式由于XA规范是实现分布式事务处理的标准通常采用两阶段提交2 Prepare Commit2PC的方法具有很强的一致性但是由于需要两次网络交互所以性能差。 2基于消息的最终一致性BASE在可用性和一致性相冲突的情况下为了权衡二者BASE提出只要满足基本可用BA和最终一致性E接受数据的软状态或未确定状态S来优先实现性能所以这类系统通常具备很高的性能。但是由于应用的特点选择可用性和一致性的妥协方案导致通用性很差。 3TCC模式采用Try-Confirm-Cancel二阶段模式事务隔离行可控高效但需要应用代码将业务模型拆成二阶段所以对业务侵入性强设计开发维护等成本很高。 4SAGA模式每个正向事务都对应一个补偿事务若正向事务执行失败则会执行补偿事务进行回滚。所以开发维护成本高。 5开源项目SEATA的AT模式它将TCC模式中的二阶段委托给底层代码框架并且取消了行锁所以非常高性能且无代码开发工作量且可以自动化执行回滚操作但存在一些使用场景限制。
1.4.6 可观测架构
可观测架构包括Logging、Tracing、Metrics其中Logging提供多个级别跟踪例如INFO/DEBUG/WARNING/ERRORTracing收集一个请求从前端到后端的访问日志聚合形成完整调用链路跟踪Metrics则提供对系统量化的多维度度量包括并发度、耗时、可用时长、容量等。
1.4.7 事件驱动架构
事件驱动架构Event Driven ArchitectureEDA是一种应用/组件间的集成架构模式。适用于增强服务韧性、数据变化通知、构建开放式接口、事件流处理、命令查询的责任分离Command Query Responsibility SegregationCQRS把服务状态有影响的命令用事件来发起而对服务状态没有影响的查询才使用同步调用的API接口等。
1.5 典型的云原生架构的反模式
架构设计有时候需要根据不同的业务场景选择不同的方式常见的云原生反模式有
1 庞大的单体应用缺乏依赖隔离代码耦合责任和模块边界不清晰模块间接口缺乏治理变更影响扩散不同模块间的开发进度和发布时间难以协调一个子模块不稳定导致整个应用都变慢扩容时只能整体扩容而不能达到瓶颈的模块单独扩容等。 2 单体应用“硬拆”为微服务强行把耦合度高、代码质量少的模块进行服务化拆分拆分后服务的数据是紧密耦合的差分后成为分布式调用严重影响性能。 3 缺乏自动化能力的微服务人均负责模块数上升人均工作量增大也增加了软件开发成本。
二、云原生架构相关技术
1.1 容器技术
容器 作为标准化软件基础单元他将应用及其所依赖项打包发布由于依赖项齐备应用不再受环境限制在不同计算环境间快读、可靠地运行。
容器部署模式与其他模式的比较如图传统、虚拟化、容器部署模式比较
1.2 容器编排技术
容器编排技术 包括资源调度、应用部署与管理、自动修复、服务发现与负载均衡、弹性伸缩、声明式API、可扩展性架构、可移植性。
1.3 微服务
微服务模式 将后端单体应用拆分为松耦合的多个子应用每个子应用负责一组子功能。这些子应用成为“微服务”多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这写微服务相对独立通过解耦研发、测试与部署流程提高整体迭代效率。
微服务设计约束如下
1微服务个体约束 一个设计良好的微服务应用所完成的功能在业务域划分上应是相互独立的。与单体应用强行绑定语言和技术栈相比这样做的好处是不同业务域有不同的技术选择权比如推荐系统采用 Python实现效率可能比Java要高效得多。从组织上来说微服务对应的团队更小开发效率也更高。“一个微服务团队一顿能吃掉两张披萨饼”“一个微服务应用应当能至少两周完成一次迭代”,都是对如何正确划分微服务在业务域边界的隐喻和标准。总结来说微服务的“微”并不是为了微而微而是按照问题域对单体应用做合理拆分。进一步微服务也应具备正交分解特性在职责划分上专注于特定业务并将之做好即SOLID原则中单一职责原则 (Single Responsibility Principle,SRP)。 如果当一个微服务修改或者发布时不应该影响到同一系统里另一个微服务的业务交互。
2微服务与微服务之间的横向关系 在合理划分好微服务间的边界后主要从微服务的可发现性和可交互性处理服务间的横向关系。微服务的可发现性是指当服务A 发布和扩缩容的时候依赖服务 A 的服务B 如何在不重新发布的前提下如何能够自动感知到服务A 的变化?这里需要引入第三方服务注册中心来满足服务的可发现性特别是对于大规模微服务集群服务注册中心的推送和扩展能力尤为关键。微服务的可交互性是指服务A 采用什么样的方式可以调用服务 B。 由于服务自治的约束服务之间的调用需要采用与语言无关的远程调用协议比如 REST 协议很好地满足了“与语言无关”和“标准化”两个重要因素但在高性能场景下基于 IDL的二进制协议可能是更好的选择。另外目前业界大部分微服务实践往往没有达到HATEOAS启发式的 REST 调用服务与服务之间需要通过事先约定接口来完成调用。为了进一步实现服务与服务之间的解耦微服务体系中需要有一个独立的元数据中心来存储服务的元数据信息服务通过查询该中心来理解发起调用的细节。伴随着服务链路的不断变长整个微服务系统也就变得越来越脆弱因此面向失败 设计的原则在微服务体系中就显得尤为重要。对于微服务应用个体限流、熔断、隔仓、负载均衡等增强服务韧性的机制成为了标配。为进一步提升系统吞吐能力、充分利用好机器资源可以通过协程、 R x模型、异步调用、反压等手段来实现。
3微服务与数据层之间的纵向约束
在微服务领域提侣数据存储隔离 (Data Storage Segregation,DSS) 原则即数据是微服务的私有资产对于该数据的访问都必须通过当前微服务提供的API来访问。如若不然则造成数据层产生耦合违背了高内聚低耦合的原则。同时出于性能考虑通常采取读写分离(CQRS) 手段。同样由于容器调度对底层设施稳定性的不可预知影响微服务的设计应当尽量遵循无状态设计原则这意味着上层应用与底层基础设施的解耦微服务可以自由在不同容器间被调度。对于有数据存取(即有状态)的微服务而言通常使用计算与存储分离方式将数据下沉到分布式存储通过这个方式做到一定程度的无状态化。
4全局视角下的微服务分布式约束 从微服务系统设计一开始就需要考虑以下因素高效运维整个系统从技术上要准备全自动化的CI/CD流水线满足对开发效率的诉求并在这个基础上支持蓝绿、金丝雀等不同发布策略以满足对业务发布稳定性的诉求。面对复杂系统全链路、实时和多维度的可观测能力成为标配。为了及时、有效地防范各类运维风险需要从微服务体系多种事件源汇聚并分析相关数据然后在中心化的监控系统中进行多维度展现。伴随着微服务拆分的持续故障发现时效性和根因精确性始终是开发运维人员的核心诉求。
1.4 无服务技术
无服务技术的特点
(1)全托管的计算服务客户只需要编写代码构建应用无需关注同质化的、负担繁重的基于服务器等基础设施的开发、运维、安全、高可用等工作
(2)通用性结合云 BaaSAPI的能力能够支撑云上所有重要类型的应用
(3)自动弹性伸缩让用户无需为资源使用提前进行容量规划
(4)按量计费让企业使用成本得有效降低无需为闲置资源付费。
1.5 服务网络
服务网格 (ServiceMesh) 是分布式应用在微服务软件架构之上发展起来的新技术旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施实现应用与平台基础设施的解耦 。这个解耦意味着开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身提升应用开发效率并加速业务探索和创新。换句话说因为大量非功能性从业务进程剥离到另外进程中服务网格以无侵入的方式实现了应用轻量化。
如图服务网格的典型架构 在这张架构图中服务A 调用服务B 的所有请求都被其下的服务代理截获代理服务A 完成到服务B 的服务发现、熔断、限流等策略而这些策略的总控是在控制平面 (Control Plane) 上配置。
