什么是系统(什么是系统风险和非系统风险)

最近有很多朋友都想得到什么是系统的回答。还有网友想了解什么是系统风险和非系统风险。对此,壹贰信息网整理了相关的教程,希望能为你解除疑惑。

从今天开始,我们进入了技术架构模块,所以,这一讲,我想先和你谈谈技术架构要解决什么问题。


对于开发人员,我们每天都在使用科技。但是你必须知道,我们写的代码,它实际上只是系统的一小部分,我们知道的技术,它只是系统的一小部分。深入掌握技术架构,我们需要了解整个系统。


面对一个复杂的系统,我想你可能经常有以下烦恼:


  1. 我不知道系统的整个流程,当系统出错时,不知道如何有针对性的排查问题。
  2. 当设计系统时,经常忽略非业务功能的需求,尚不清楚如何实现这些目标,往往是在付出了惨痛的教训之后,为了弥补。


我想知道你是否记得,在第一堂课上“建筑的本质”中,我已经说过了,技术架构是从物理层面定义系统,保证系统的稳定运行。所以今天,我将首先分析系统的物理组成部分,让你从全局的角度来看一个系统;然后再和你讨论,技术架构将面临哪些硬件和软件挑战,它的目标是什么,让你深入了解技术架构。


系统的物理模型

对于大多数开发人员来说,我们的主要工作是写业务相关的代码,确保正确的业务逻辑、准确的业务数据,然后,在打包和部署这些业务代码之后,成为实际的操作应用。但是我们写的代码只是冰山一角,为了确保应用程序的正常运行,我们需要从端到端系统的角度来分析。


我们先来看下一个系统的具体构成,这里我给你提供一个系统的简化物理模型,可以大致知道一个系统包含哪些部分。

从用户请求的处理过程来看,该系统主要包括五个部分。


首先是准入制度,它负责接收用户的请求,然后将用户的请求分发到某个 Web 用于处理的服务器,接入系统主要包括 DNS 域名解析、负载均衡、Web 服务器组件。


接下来,Web 服务器将把请求交给应用系统进行处理。一般而言,我们基于特定的开发框架开发应用程序,比如 Java 应用程序通常基于 Spring MVC 框架。


此时此刻,开发框架将首先介入请求的处理,比如对 HTTP 分析协议,然后按照要求 URL 和服务参数,转移到我们写的商业方法。接下来,我们的应用代码,会调用开发语言提供的库和各种第三方库,比如 JDK 和 Log4j,共同完成业务逻辑处理。在这里,我们将把开发框架、应用代码,这些库打包在一起,形成应用系统,作为一个独立的过程 Web 用于部署和操作的服务器。


到这里,整个系统会完蛋吗?


还没有,在我们的申请制度下,和基础平台,它由几个部分组成:首先是每种语言的运行时,比如说 JVM;然后是容器或虚拟机;下面还有操作系统;底层是硬件和网络。


接入系统、应用系统、基础平台构成了最简单的系统。

在大多数情况下,系统还需要大量的外部中间件来实现功能和落地数据,比如数据库、缓存、信息排队,以及 RPC 沟通框架等。这里,我把它们统称为核心组件,他们也是系统不可或缺的一部分。


此外,还有大量的外围支持系统支持应用的正常运行,包括日志系统、配置系统,还有很多运维体系,他们提供监控、安全、资源调度等功能,它们与其核心组件的区别在于,这些系统通常不参与实际的用户请求处理,但是他们默默的保证了系统的正常运行。


到这里,你可以找到,端到端系统非常复杂,它包含许多硬件和软件。为了确保我们应用程序代码的正常运行,我们需要确保这里的每个组件都不会出错,否则,一旦组件出现问题,可能会导致整个系统不可用。


技术架构的挑战

应用程序代码是如何组织的(比如模块划分,服务分层),这主要是关于业务架构,这部分之前已经讨论了很多了;和技术架构的责任,首先,它负责系统所有组件的技术选择,然后确保这些组件正常工作。


我们知道,该系统由硬件和软件组成。接下来,我们分别从硬件和软件的角度来看,技术架构将面临哪些挑战,我们需要为此做些什么。


硬件问题

硬件是系统最基本的部分,负责真正的工作,但是它有两个问题。


第一,硬件的处理能力有限。 对于服务器来说,它的 CPU 频率、内存储器容量、磁盘速度等等都是有限制的。虽然根据摩尔定律,随着制造技术的发展,关于其他的 18 个月,硬件性能可以提高一倍,但是仍然跟不上快速增长的系统处理能力的要求,尤其是目前很多互联网平台,这一切都是为了满足群众的需要 C 端用户,可以说系统的处理能力没有上限。


从技术架构的角度来看,一般有两种方法可以提高硬件的处理能力。

  • Scale Up

也就是垂直扩张,简单来说就是升级硬件提高处理能力。CPU 不够快,升级内核号;内存不足,升级容量;网络带宽不足,升级带宽。所以说,Scale Up 其实就是提高硬件质量。

  • Scale Out

也就是水平扩展,通过增加机器数量来提高加工能力。一台机器是不够的,增至 2 台、4 台,还有更多,通过大量廉价设备的叠加,增强整个系统的处理能力。所以说,Scale Out 就是增加硬件量。


垂直扩张是最简单的方法,对于系统来说,它看到的是一个更强大的组件,不需要任何技术改造。如果您遇到性能问题,纵向扩张是我们的首选,但它有一个物理瓶颈或成本问题。硬件的物理限制,这台机器的性能有上限;或者有时候,硬件超出主流配置,其成本将呈指数增长,我们负担不起。


水平扩展通过硬件数量来补偿性能问题,理论上可以应对所有服务器处理能力不足的情况,实现系统处理能力和硬件成本的线性增长关系。


然而,对于水平扩展的系统,它看到了多个组件,比如多套 Web 服务器。如何有效管理大量机器,一方面,从而可以获得相似的性能 1 1=2 的效果;另一方面,让系统各部分有效连接,平稳运行,这不是一项容易的任务。我们需要通过非常复杂的技术架构设计来保证,比如说,通过额外的负载平衡,以支持多个单元 Web 服务器并行工作。


硬件的第二个问题是,不是硬件 100% 的可靠,它本身就会有问题。

比如说,服务器电源已关闭,网线被切断了,甚至各种自然灾害导致机房整体不可用。尤其是大型系统,服务器非常大,网络很复杂,一旦一个节点出现问题,整个系统都可能受到影响,所以,机器的数量增加了,这也加大了系统故障的可能性,导致整个系统的可用性差。当我们设计技术架构时,要充分考虑各种硬件故障的可能性,做好应对计划。例如,对于自然灾害,在有多个机房的不同地方部署系统。


软件问题

接下来我们说下软件问题,这里的软件,主要讲各种中间件和系统级软件,它们与我们的应用程序代码一起工作。


软件是硬件的延伸,主要解决硬件的各种问题,通过进一步打包软件,它给系统带来两个好处。


  • 首先,它弥补了硬件的缺陷。比如 Redis 集群,通过数据碎片,解决了单台服务器内存和带宽的瓶颈问题,实现服务器处理能力的横向扩展;通过多个数据副本和失败的节点传输,解决了单台服务器故障导致的可用性问题。
  • 其次,封装允许我们更有效地访问系统资源。比如说,数据库是文件系统的增强,提高数据访问效率;缓存是对数据库的增强,让热数据访问更加高效。


但是当软件填补硬件中的各种漏洞时,还为系统挖了一个新坑。例如,Redis 集群的多节点,解决了单节点处理能力的问题,但也带来了新的问题,比如节点内部的网络有问题(即网络分区现象),集群的可用性是有问题的;Redis 数据的多个副本,解决了单台服务器故障带来的可用性问题,但也带来了数据一致性的问题。


我们知道,分布式系统具有典型的 CAP 理论,C 表示系统内的数据一致性,A 代码的可用性,P 指示节点之间的网络是否允许出现问题,这三个只能选两个。对于分布式系统,网络问题很常见,所以我们要先选择 P,这意味着我们在休息 C 和 A 只能选择一个。


CAP 该理论仅针对基于小型数据的分布式系统,如果扩大到整个商业系统,C 和 A 选择更加复杂。


例如,有时候,我们直接写订单,这有助于确保数据的一致性 C,但是如果数据库出现故障或者流量过大,写入失败,导致当前业务功能失效,即系统的可用性 A 有一个问题。如果我们不直接去仓库,首先将订单数据发送到消息系统,然后,消费者收到消息并将其放入仓库,即使单个数量很大或者数据库有问题,订单最后还是能落地的,不影响当前订购功能,确保系统的可用性,但也可能不一样(例如缓存和数据库)订单数据存在一致性问题。


你不能两者兼得,系统无法同时满足 CAP 的要求,我们需要结合具体的业务场景,确定最突出的挑战,然后选择适当的组件,并合理地使用它们,最后,保证了系统的稳定运行,不会产生重大的业务问题。


技术架构的目标

好,现在你已经了解了系统的复杂性和软硬件问题,然后技术架构需要对各种软硬件进行选择和组合,结合我们开发的应用程序代码,以解决系统非功能性需求。


系统的非功能需求是什么?这与业务需求相关,所谓的业务需求就是确保正确的业务逻辑,准确的数据。例如,一个订单,我们要确保订单的所有数据都是准确的,订单报价和金额计算逻辑正确。订单页面打开需要多长时间,页面每次都能打开吗,这些和具体的业务逻辑无关,属于系统非功能需求的范畴。产品经理在一般情况下,他们也不会明确提及这些需求。非功能性需求,有时我们称之为系统级函数,和业务功能。


对于那一个系统,技术架构应该解决哪些非功能性需求?

系统的高可用性

可用性的衡量标准是,系统正常工作时间除以总时间,通常有几个 9 来表示,比如 3 个 9 表示系统处于 99.9% 时间内可以买到,4 个 9 表示 99.99% 时间内可以买到,这里的正常运行是指系统能够在相对合理的时间内返回预期的结果。


导致系统可用性问题,一般有两种情况:


  • 一个是硬件和软件本身有缺陷,例如机器电源故障,网络不通。这就要求我们要么及时解决当前的节点故障问题,或者故障转移,尽快启动备用系统。
  • 另一个是高并发导致的系统处理能力不足,当系统的软件和硬件没有足够的处理能力时,直接瘫痪,比如 CPU 100% 的时候,整个系统根本不起作用。这要求我们要么提高处理能力,比如横向扩展、缓存等措施;要么将流量控制在系统能够处理的水平,例如电流限制、降职等措施。


系统的高性能

我们在这里谈论的是高性能,并不代表系统的绝对性能有多高,但是系统应该提供合理的性能。比如说,我们希望确保首页可以显示在 3s 内打开,这使得用户体验更好。


有两种情况可以保证合理的性能:


  • 一个是正常的流量进来,但是系统的内部处理是复杂的,我们需要用技术手段来优化。比如搜索海量商品,我们需要建立一个复杂的搜索系统来支持它。
  • 第二个是高并发流量,系统仍然需要在合理的时间内提供响应,这强调了当我们做建筑设计时,确保系统的处理能力可以整体水平扩展,而不仅仅是某个节点的绝对性能优化,因为流量的增加很难准确预测。


系统的可扩展性和低成本


系统流量处于不同的时间点,有高峰也有低谷,比如餐饮行业,有午高峰和晚高峰,还有电商的大促销现场。我们的架构旨在确保系统处于业务的巅峰,需要快速增加资源来提高系统的处理能力;反之,当生意不景气时,系统资源会迅速减少,保证系统的低成本。


高可用、高性能、可扩展和低成本,这些技术架构的目标并不是孤立的,他们彼此有关系,例如,有大量流量请求进来,如果系统具有良好的可扩展性,它可以水平扩展,确保系统的高性能,同时实现了系统的高可用性性。如果系统的处理能力不能迅速提高,无法保证高性能,那我们还是可以过电流限制的、降职等措施,确保核心系统的高可用性性。


我之前也提到过,这些目标经常发生冲突,或者只能部分实现,当我们设计技术架构时,你不能不顾一切的去实现你所有的目标,但是根据业务特点,选择要实现的最关键的目标。

比如说,新闻阅读系统,它和订单、钱不重要,即使它在短时间内不可用,对用户影响不大。但是当有热点新闻时,系统应该能够支持高并发用户请求。因此,这里的设计,主要考虑的是满足高性能,没有太多的追求 4 个 9 或 5 个 9 的可用性。


总结

这个系统比我们想象的要复杂得多,这里,我和你分享了系统的物理模型,我相信你不再局限于我们自己的代码,而是对系统的整体结构有更清晰的理解。


你还记得吗?当早期引入业务架构时,我跟你分享的是系统 = 模块 关系,在这里介绍技术架构时,我跟你分享的是系统的物理模型。


因为业务架构解决了系统功能的问题,我们更多的是从人开始,更好地理解这个系统;技术架构解决了系统的非功能性问题,我们正在确定企业的绩效、可用性挑战之后,更多的来自于软硬件节点的处理能力,通过合理的技术选择和搭配,实现最终系统的高可用性性、高性能和可扩展性等。通过这个讲座的介绍,相信你当前的技术架构目标和通用解决方案,有了更深的理解。


当然,为了这些不同的目标,技术架构处理的原则和手段也不一样。在接下来的几堂课中,我会瞄准每一个目标,专门为你介绍一下。

版权声明:本文内容部分来源互联网用户自发贡献或其他公众平台,版权归原作者所有,内容仅供读者参考,如有侵权请联系我们,一经查实,本站将立刻删除,如若转载,请注明出处。

发表评论

登录 后才能评论

评论列表(1条)

  • 甘锅雕
    转发了