万字剖析架构权衡之道！

点击下方“JavaEdge”，选择“设为星标”

  

第一时间关注技能干货！

     免责声明~
   任何文章不要过度深思！
   万事万物都经不起审阅，由于世上没有同样的成长环境，也没有同样的认知程度，更「没有实用于所有人的办理方案」；
   不要急着评判文章列出的观点，只需代入此中，适度审阅一番本身即可，能「跳脱出来从外人的角度看看现在的本身处在什么样的阶段」才不为俗人。
   怎么想、怎么做，全在乎本身「不断实践中探求适合本身的大道」
    00-软件架构权衡-我们为什么以及如何举行权衡？

  对于“软件架构”这个词有许多界说和寄义。而且，“软件开发”、“软件设计”和“软件架构”这三个概念之间存在相当大的重叠，它们在许多方面相互融会。
  从焦点上看，可以将软件架构视为在构建应用步伐时，对不同选择举行权衡的学科。
  1 为什么需要权衡以及我们为什么在意？

  我们在构建软件时必须举行权衡的原因，与其他学科中的权衡原因雷同。计算体系是复杂的，复杂性越高，实现特定体系的全部目标的方式就越微妙。这些目标：
  

• 既可以是功能性的（例如提供用户自助服务的能力、处置惩罚特定变乱、接受某些输入并产生输出）
  
  
• 也可以是非功能性的（例如每秒处置惩罚数百万个哀求、实现零信托安全、提供100毫秒以下的响应时间）
  
  

  如金融投资中，人们普遍明白风险与收益之间的权衡。投资越风险，潜伏的财政回报越大。投资越安全，预期收益就越小。
  同样的规则也实用于计算，特殊是在设计分布式应用步伐时。许多组织遇到的问题不是他们必须做出某些让步或权衡，而是大多数组织要么对本身所做的权衡不了解，要么缺乏体系的、明白的和有用的方法来举行这些权衡。
  本“架构权衡”系列的目标是分析在软件架构的不同原则之间举行权衡时的决策过程以及此类决策的具体技能影响。
  2 我们在权衡什么？

  如上所述，大多数与体系和应用步伐架构相干的决策都涉及某种程度的权衡。
  既然我们已经知道为什么需要讨论、权衡和有意识地思索架构权衡，我们可以谈谈我们现实在体系和应用步伐中举行权衡的方面。
  这些架构权衡有时分为两大类：
  

• 体系的基本架构特性有关（如可扩展性与简洁性）
  
  
• 与具体技能、机制和架构风格有关（如同步通信与异步通信、Kafka与消息总线等）。前者更为广泛的权衡种别也决定了更具体的权衡
  
  

  本文重点讨论第一类架构权衡——底子架构特性。
  因此，当我们谈论架构权衡时，我们现实上是在讨论我们希望支持哪些架构特性并将其纳入我们的重要目标。另一方面，我们也在辨认那些我们有意识地决定不太关注或完全放弃的架构特性，以便更加重视那些我们认为更重要的特性。
  下面是一些架构特性和一些常见的权衡场景。
  3 架构特性

  当谈论体系或应用步伐架构的固有或底子特性时，我们现实上是指一组关键属性，这些属性界说了特定的体系或应用步伐。以下是这些特性的一小部分示例。这绝不是一个详尽的列表，另有许多其他的架构特性。
  

• 可扩展性
  
  
• 可观测性
  
  
• 可审计性
  
  
• 弹性
  
  
• 响应性
  
  
• 可测试性
  
  
• 互操作性
  
  
• 可维护性
  
  
• 可支持性
  
  

  这些特性有时被称为“体系属性”、“架构属性”或干脆称为“后缀-ility”属性。
  这些体系特性或属性乍看之下似乎是独立的，但现实上，它们中的许多是相互交织的，可能有直接或反向关系。
  4 互操作性 vs 可扩展性、弹性和响应性

  让我们以互操作性为例。为了使体系具备互操作性，它需要可以大概轻松地与其他体系举行交互和通信。这通常意味着所有这些体系都需要使用通用协议。它们需要使用共同商定的标准，而且这些标准还需要设计得易于未来的体系也能相对轻松地“插入”到这种通信中。
  然而，如果一个体系优先考虑互操作性，这很可能会影响体系的可扩展性。
  举个具体的例子，假设现有的应用步伐使用REST协议（依赖HTTP）举行通信。假设我们要引入一个新体系。为了使这个新应用步伐与现有的应用步伐互操作，我们决定该应用步伐的所有进出通信都通过REST/HTTP举行。这看起来很合理。
  然而，如果将新体系的通信限定在依赖HTTP上，可能会限定其响应能力和可扩展性，尤其是在需要处置惩罚大量哀求的环境下。假设这个新体系需要每秒处置惩罚数百万个哀求，而且是异步的（即调用者无需等候应用步伐确认其已处置惩罚哀求）。这种环境下，由于需要异步通信且Kafka协议（理论上）比HTTP开销更小，这种场景可能更适合使用变乱驱动技能如Kafka。
  换句话说，在这种环境下，互操作性与响应性以及可扩展性呈反比关系。
  5  简朴性、易上手性和可支持性 vs 响应性

  另一个可能不太技能性、更具组织性的权衡发生在决定以易于支持作为重要架构驱动因素时。这可能意味着使用技能团队认识的技能。这也可能意味着使用行业内广泛使用和已知的技能和范式，以便新团队成员可以更快更高效地上手。
  将可支持性作为重要任务听起来是显而易见的，由于谁不想要一个易于明白、支持而且易于向新开发人员先容的体系呢？然而，仍然存在成本和权衡。
  基于技能或范式的选择是否为大量专业人员所熟知，可能会阻碍架构的许多其他特性。可扩展性、响应性、弹性、可用性、安全性以及体系的许多其他方面很可能会被放在第二位。
  例如，考虑需要设计一个处置惩罚和存储生意业务性和强关系数据的金融应用步伐。假设实施该应用步伐的团队认识NoSQL数据存储如MongoDB。虽然MongoDB是一个适合疏松关联的文档型数据的优秀选择，但它不适合具有严格和复杂关系的数据。
  对于不同实体之间具有复杂关系且需要暂时复杂查询来检索这些数据的数据，通常不太适合像MongoDB这样的存储。这类数据通常更适合“传统”的关系数据库如Postgres或MySQL。
  如果我们将可支持性作为这个应用步伐的重要架构驱动因素，最终很可能会导致应用步伐失败，并引发一系列挑战，最终导致应用步伐完全无法扩展，数据库成为瓶颈（这是常见的问题）。
  6 可维护性 vs 弹性和容错性

  一样平常而言，体系越简朴、移动部件越少，越容易维护。使用的技能和摆设环境越少，体系运行和维护的速度和难度越低。
  例如，在托管云运行服务中运行单实例应用步伐要比分布在不同节点、不同集群、云区域和地区的分布式集群应用步伐更容易维护。一些组织甚至通过跨多个云环境摆设其体系来确保业务一连性、容错性和劫难恢复（迅速盛行但有些争议的多云模式）。
  由于每个云（Azure、AWS、GCP、IBM、Oracle等）提供商都有一套独特的功能、摆设模子和机制，在多个云上维护一组应用步伐成为一个明显挑战（通常是无法维持的）。
  7 找到平衡点

  上述的三个架构权衡示例可能更方向极端环境。然而，它们代表了许多团队和组织在规划和选择正确的架构权衡路径时所面临的一些非常现实的挑战。
  好消息是，您不必在二者之间做出选择。软件架构权衡以及软件开发的现实要更加复杂，现实上是一个选择的渐变。在这里，您可以选择在肯定程度上实现可扩展性，同时在肯定程度上实现简朴性和互操作性。
  关键在于如何找到不同架构特性之间的平衡，以及如何做出知情的、有意识的选择。
  8 有意识地了解架构权衡

  如我们在开头所说，许多，甚至可以说大多数组织，都是偶然识地做出权衡。这每每导致这些组织做出错误的权衡，给其业务和底线带来长期且倒霉的影响。
  依赖数字体系的企业必须有一个恰当的计划和流程来做出软件架构和技能决策以及权衡。在没有建立正确的架构权衡意识的环境下，这些组织承担着不合理的风险，其影响和可能明显减缓组织进展的概率很大，在最坏的环境下甚至可能造成无法修复的侵害。
  接下来的部分将讨论如何举行架构权衡的推理和规划，以及一些具体和常见的环境。
  01-软件架构权衡-偶然识决策的问题

  0 前言

  错误的技能决策常常会回过头来困扰我们，原因并不在于决策本身是错误的，而是由于做出该决策的人并未充分明白其全部影响，或更常见的，决策者甚至不知道本身在做决策。这是一种偶然识的决策。换句话说，问题焦点在于缺乏意识或缺乏决策的审慎。稍后详细讨论这问题。
  先澄清“技能决策”寄义。这些决策涉及编码/实现、软件设计、架构、供应商选择和与第三方集成，另有非技能性的决策——即产品和业务决策，同样重要。本文以及整个架构权衡系列重点关注技能方面及其与业务的交集。
  先统一术语：
  

• MVP（最小可行产品）
  
  
• POC（概念验证）
  
  
• Monolith（单体架构）：独立应用步伐，执行全部或大部分功能
  
  
• Serverless（无服务器）：应用步伐运行时和摆设重要由云管理
  
  
• Microservices（微服务）：细粒度、解耦、独立摆设的应用步伐，每个应用步伐负责特定功能
  
  

  虽然本文重要提到初创企业，但大多数内容实用于任何技能团队或组织。
  1 这是什么？

  如何增强对技能决策的信心是一个很少被讨论但绝对关键的话题，它对建立一个可以大概随着组织扩展和增长而提供服务的康健技能和架构战略至关重要。
  看典型初创企业的生命周期，这个企业经受住市场挑战，并踏上增长道路。有许多盛行的模子形貌了这一生命周期的不同阶段，每个模子都有其独特的视角。
  下面的心理模子帮助直观明白这种生命周期，重点是决策通常在哪些阶段做出。初创企业的生命周期：
  

  上述体现，我们在MVP阶段开始做出大部分长期的技能决策。
  注意，这是开始做出这类决策的阶段。决策过程永久不会停止。MVP阶段（及之后）的决策与POC阶段（及之前）的决策的区别在于：POC阶段的决策通常是暂时的。它们只是为尽快推出某种产品的初步雏形。通常，这些产品甚至不是完全功能性的，而更多是展示最闭幕果的视觉表示。
  MVP阶段的技能决策必须开始关注。这就是技能决策意识发挥作用的地方。该阶段的技能决策通常产生长期影响，由于这些决策将成为后续决策的底子，并将影响组织发展方向（至少在技能方面）。
  2 错误的决策总是问题的根源吗？

  记着，我在开头提到的问题不肯定是决策本身的问题，而是缺乏意识和决策的审慎吗？只管这可能看起来违背直觉，但错误决策常常可以最小业务影响来办理。若能实时、流通辨认并办理问题，并有一个明白流程来调整决策，其影响不会像原本那么剧烈。
  这只有在决策是以有意识的方式做出，并意识到决策正在被做出及其方式时才会发生。
  3 示例

  假设一个初创企业处早期MVP阶段。团队正开发SaaS，该产品聚合某种数据并将其袒露给外部。
  因此，团队须决定如何摆设SaaS。底子设施咋样的？应用步伐咋构建？有许多方式构建应用步伐和摆设产品，选择许多。
  团队面临选择（假设使用AWS作为云提供商）：
  3.1 单体架构

  将服务结构化为单体应用步伐。将所有功能都放在一起。摆设在托管的容器编排服务中：
  

• 一个数据库
  
  
• 一个应用步伐
  
  

  

  3.2 微服务

  从一开始就将服务设计为由微服务构成。有多个服务和多个数据库。所有内容都摆设在容器编排服务中。
  

  3.3 无服务器/函数即服务

  现在非常盛行的方法。可用AWS Lambda运行应用步伐，使用DynamoDB作为数据库。AWS负责运行所有这些的重任。
  

  4 指导方针

  团队应选哪种方案？选择的影响是啥？影响多大？应投入多少精神分析每种选择？这些都是潜伏在行间的问题。别的，在每个选择中另有更多细节选择！
  现在正是关键时刻，团队需做出一个有意识的和有理由的选择。注意，这不肯定是正确选择，由于可能有多个正确选择，而且“正确”可能随未来更多背景的变化而改变。
  通常，团队会隐含、偶然识或在不了解影响的环境下做出决定。
  那团队该咋做？他们咋确保他们的选择能最好服务于组织？幸好我们站在牛顿肩膀上，请遵照如下指导方针：
  4.1 保持记录

  若你从本文中只学到一件事，那必须是这点。看起来这应该是最容易做到的事情，但我见过的团队，很少能认真记录其技能决策。
  我明白，文档很枯燥无趣，尤其当你专注于构建下一个大项目时。然而，它只需要很少时间，而清晰记录技能决策的巨大好处显而易见，它将不断地为你带来十倍、百倍、千倍回报。
  每劈面临技能决策并做任何重要选择时，记录何时及为何做出该选择。不需要是一份庞大的文件或复杂东西。
  以下内容即可：
  ✅ 做出决定的时间
  ✅ 选择有哪些
  ✅ 每种选择的优缺点
  ✅ 为何选择特定选项
  ✅ 潜伏担心
  在一个成熟团队/组织中，你可能需要使用更正式东西，如ADR（架构决策记录）。然而，对MVP级项目，上述内容足够。
  这样的记录将允许你回顾并明白为何做出这些决策，并在以后防止混淆。它还将帮助你及早发现这些决策的任何陷阱。这引出下一要点：
  4.2 定期重新审阅你的决策

  做出“正确”选择每每不如做出“有意识”选择重要，由于本日的“正确”选择可能是明年的“错误”选择。定期重审技能决策，重新评估，与团队一起头脑风暴，你将始终掌握组织技能状态的脉搏。
  让这些成为定期的节奏。每月举行一两次集会。或每两个月一次集会。或每季度一次全天集会。无论哪种方式，重要的你要一连举行这些集会，并答应将其作为定期的脉搏检查，以辨认哪些技能办理方案仍然有用，哪些无效。
  实在另有许多...
  4.3 始终提出问题（尤其是当出现问题时）

  质疑你的技能选择。根据公司目标举行预测，并查察这些目标如何与当前的技能状态对齐。是否能改进？咋改进？
  在这里最有帮助的是对产品遇到的技能问题有敏锐意识。是否存在可扩展性问题？生产的错误率高吗？
  用户等候20s才能加载网站？底子设施每周一、周四都瓦解？
  这些问题是最好的指示，表明要做出改变了，而且需要重新审阅和/或做出一些技能决策。
  关注这些问题，记录它们，并扣问咋办理它们（希望也能记录下你的发现）是开始这一过程的好方法。
  5 结论

  最终，你无法保证本日做出的决策或技能选择能永久为组织服务。在技能和业务需求不断变化的环境中，组织转向、市场趋势和其他因素的影响下，很难正确预测这些选择将如何塑造组织的未来技能状态。
  然而，制定一个清晰、直观和简化的决策过程，可以优化这些决策，并在环境变化时提供调整和改变的途径。
  这个过程将确保我们所做的架构权衡在我们所处的时间和条件下是正确的。
  02-软件架构权衡-架构特性

  本系列00文重点讨论啥是架构权衡以及为什么它们很重要。01文，阐述了在软件架构中举行有意识决策过程的须要性。
  本文总结讨论具体的架构特性及为啥明白这些特性对体系至关重要。为做到这点，需明白：
  

• 啥是架构特性
  
  
• 选择关注某一特性有时会迫使我们在另一特性上做出权衡
  
  

  换句话说，架构特性是指你的体系总体能力的具体方面，这就是架构的“ability”（属性），你很快就会明白为什么。
  以下是一些常见的架构特性。这绝不是一个详尽的列表——只是一些你在设计和构建应用步伐时最常遇到的特性，也是我在全职职业生涯和咨询实践中最常见的特性。
  我试图在这里做的是辨认特性，指出它在何时最有可能重要，关注它时我们在做什么权衡，以及一些实现该特性的方法。固然，这统统都是非常高层次的，每一个具体点上另有更多内容可以讨论。
  1 架构特性

  1.1 可审计性（Auditability）

  这是啥？

  你的体系在运行，变乱在流转。用户启动动作并导致事情发生。许多环境下，你希望有一个明白记录，记录这些事情的发生。即你希望记录某个用户在特定时间发起了某个特定的动作，以及该动作的具体环境。
  何时重要？

  

• 金融等受监管行业
  
  
• 服从内部和外部标准（ISO、PCI、SOC、SOX）
  
  
• 出于安全原因，以便你可以辨认和观察未经授权的活动
  
  

  我们在做啥权衡

  

• 体系的复杂性增长
  
  
• 测试变得更复杂，由于你需要测试审计变乱在整个体系中是否被正确记录
  
  

  一些实现方式

  

• 将审计变乱日志与应用日志分开记录。这可以存入数据库、独立日志流、第三方日志聚合体系或另一种永久云存储（例如AWS的S3）。
  
  
• 制定明白的数据保留和扫除计谋（金融数据通常需要保留7年）。
  
  
• 注意成本——大部分数据可以移到较少频繁使用的存储层（冷存储），由于这些数据可能不需要即时检索。
  
  

  1.2 可观测性（Observability）

  这是什么？ 通常，人们对监控和可观测性之间的区别感到困惑。确实，这两个概念有许多重叠之处，常常被互换使用。一个常见的区分方式是，可观测性指的是在问题发生前辨认体系潜伏问题的能力。监控是通过日志、指标、跟踪、警报和仪表板查察体系内部发生的环境的能力。监控是实现可观测性的一部分。
  在本文中，我将监控和可观测性都纳入可观测性的范畴。
  何时重要？

  任何现实体系都需要肯定程度的可观测性。体系越复杂，使用频率越高，可观测机制就越复杂。
  我们在做啥权衡

  

• 可观测性增长体系复杂性
  
  
• 根据可观测性的程度和摆设的机制，它也可能影响应用性能
  
  
• 成本——实现第三方/现成的办理方案 or 内部构建
  
  
• 可扩展性——可观测体系需要随业务应用扩展。这是一个常见但易被忽视的问题，特殊是内部/当地摆设的可观测体系
  
  

  一些实现方式

  

• 使用云原生或第三方APM（应用性能监控）和可观测工具，如Datadog、New Relic、Dynatrace、Honeycomb等
  
  
• 确保你的应用记录重要信息
  
  
• 对分布式体系（如微服务）——使用跟踪来保持跨多个体系的哀求的可见性
  
  
• 使用AIOps工具（通常作为上述第三方办理方案的一部分）发现和预测应用行为
  
  
• 使用OpenTelemetry等开放标准
  
  
• 确保根据袒露的指标、日志和跟踪配置警报、仪表板、陈诉。换句话说，确保有可监控和实时操作的有意义的工件。
  
  

  1.3 可伸缩性/弹性（Scalability/Elasticity）

  这是什么？

  应用步伐支持增长的流量/更多哀求或用户的能力。你的体系如何从每秒10次生意业务（TPS）调整到每秒1000次生意业务？当用户群从1万增长到100万时会发生什么？
  在某些环境下，可伸缩性与弹性的概念可以互换使用，而在其他环境下，这两个概念表示体系的不同方面。正确地说：
  

• 可伸缩性，指体系团体在较长时间内顺应不断增长的负载的能力
  
  
• 弹性，指体系在特定时间内顺应波动负载/流量的能力
  
  

  为简化，这里将这两个概念归并。
  何时重要？

  

• 如果你的应用预期会随着时间的推移而增长，需考虑可扩展性。这实用于大多数摆设在生产环境中面向外部用户的体系
  
  
• 唯一不需要担心可扩展性的环境是，如果你知道体系使用会被限定在肯定范围内（例如内部公司应用）。这包括用户群已知非常小且不需要增长的生产应用
  
  

  我们在做啥权衡

  

• 体系的复杂性增长
  
  
• 可摆设性变得更困难。处置惩罚一个容器的摆设要比处置惩罚1000个容器容易得多——即使你在使用容器编排框架。
  
  
• 体系越可扩展，维护可观测性就越困难，由于需要观察、跟踪和观察的组件更多。
  
  
• 可测试性可能更具挑战性，测试用例需要覆盖应用的分布式特性
  
  

  一些实现方式

  

• 使用容器编排体系（如Kubernetes）动态调整所需计算程度（容器数目）
  
  
• 使用云环境中的无服务器服务，大部分扩展由云本身负责
  
  
• 开发应用使其易于扩展。对于“单线程”运行时（如Node），意味着不要壅闭变乱循环凌驾须要时间。对于多线程应用，意味着以最佳方式使用并发（避免死锁，使用非壅闭锁等）
  
  
• 尽可能采取无状态范式，只有在须要时才维护和传递状态。
  
  
• 通过频繁运行负载、压力和流量测试来辨认瓶颈。
  
  
• 优先扩展横向伸缩而非纵向伸缩
  
  

  1.4 响应性（Responsiveness）

  这是什么？

  应用步伐的响应能力是其在合理时间内对调用方提供某种响应的能力——即使在应用步伐负载明显增长时。换句话说，应用可以大概处置惩罚并响应用户操作，而用户不会感到延迟。这实用于前端和后端应用。
  何时重要？

  

• 当应用是面向用户时——即现实有用户在等候某些事情发生。
  
  
• 当你的用例对应用的响应性没有太多容忍度时。例如，某人在银行网站申请贷款，可能对延迟的容忍度更高（由于别无选择），而某人使用服务获取实时股票报价举行日间生意业务时，容忍度则较低。
  
  

  做啥权衡

  

• 通常，响应性与可扩展性直接相干。体系越可扩展，响应性越可能越好。然而，应用步伐还需要通过设计确保响应性。
  
  
• 应用步伐的内部设计复杂性增长。
  
  
• 可测试性变得更复杂，以覆盖可能限定响应性的潜伏用例。
  
  
• 在某些环境下，我们需要在响应性和正确性之间举行权衡。例如，考虑从服务A和服务B获取数据的环境，但服务B不可达。你可能希望返回服务A的数据，而不是无限期等候服务B，由于这会影响体系的响应性。这样做的结果是，你快速返回数据（来自服务A），但由于没有服务B的数据，响应不完整。
  
  

  一些实现方式

  

• 优雅降级
  
  
• 断路器
  
  
• 异步处置惩罚
  
  

  1.5 容错性（Fault Tolerance）

  这是什么？

  体系在其一个或多个组件发生故障时继续运行的能力。
  容错性也与应用响应性相干。区别在于，响应性更多是确保终端用户体验，而容错性关注的是体系在仅有部分组件工作的环境下，仍能继续运行并产生结果。
  何时重要？

  

• 任务关键体系
  
  

  做啥权衡

  

• 就像响应性一样，我们可能会为了体系团体的运行能力而牺牲体系输出的正确性。
  
  

  一些实现方式
  

• 优雅降级
  
  
• 备用副本（计算和存储）
  
  
• 自动/自动或自动/被动摆设
  
  
• 通过架构设计尽量减少关键组件的中断
  
  
• 监控故障
  
  
• 使用BASE事务取代ACID事务
  
  

  1.6 可扩展性（Extensibility）

  这是什么？

  轻松向体系添加新功能和新集成的能力。
  何时重要？

  

• 当我们知道应用可能会以意想不到的方式增长和转变时
  
  
• 当需要添加新组件时
  
  

  做什么权衡

  

• 当可扩展性是我们的目标时，需要提前举行大量规划，使体系架构易于扩展。
  
  

  一些实现方式

  

• 模块化软件——创建解耦、高内聚、封装的服务，彼此之间没有依赖（包括代码和架构）
  
  
• 使用开放标准和最佳实践。例如，使用REST或盛行的消息队列框架毗连微服务
  
  
• 使用清晰的API契约
  
  
• 解耦数据存储/数据库，不同的领域数据使用不同的数据存储
  
  

  1.7 可测试性（Testability）

  这是什么？

  体系可以大概轻松地举行手动和自动测试，无论是团体测试还是组件测试。
  何时重要？

  

• 当我们希望测试覆盖尽可能多的应用流程时
  
  

  做什么权衡

  

• 体系复杂性增长。尤其是对于分布式体系和异步流程，通常很难甚至不可能实现。
  
  
• 体系需要设计和架构为允许组件举行隔离测试（包括代码和底子设施）。
  
  

  一些实现方式

  

• 可测试的代码（即模块化代码，便于单元测试、集成测试）
  
  
• 模块化，使应用功能可以模拟
  
  
• 确保尽可能多的测试可以自动化
  
  

  1.8 性能（Performance）

  这是什么？

  性能与可扩展性和弹性密切相干，之间有许多重叠之处。区别在于，可扩展性和弹性通常指体系顺应不断增长的负载的能力。而性能则讨论体系在合理时间内处置惩罚所有负载的能力。
  何时重要？

  

• 大多数面向用户的体系需要足够高的性能以提供积极的用户体验。什么是“足够高的性能”取决于应用的上下文。例如，对于大多数网站来说，凌驾几秒钟的响应时间通常被认为是糟糕的用户体验（只管这取决于网站的功能）。
  
  

  做什么权衡

  确保性能需要体系在设计上可以大概预见并消除瓶颈。这还需要在关键点举行过细优化。这意味着需要投入足够的精神来设计体系，一连监控并辨认问题区域。
  一些实现方式

  

• 非壅闭I/O
  
  
• 异步编程和架构（消息传递、变乱流）
  
  
• 解耦体系
  
  
• 优化长时间运行的过程和CPU密集型操作
  
  
• 优化应用代码
  
  
• 选择具有低网络开销的技能（即那些在堆栈较低协议上通信的技能，而不是HTTP）
  
  
• 使用具有已知性能保证的云原生服务（只要这些服务按规定使用）
  
  

  写在最后

     公众号：JavaEdge 专注分享软件开发全生态相干技能文章、视频教程资源、热点资讯等，如果喜欢我的分享，给