MadBOK

# 解决方案架构的属性

解决方案架构需充分考虑解决方案的不同属性，并设计应用程序。解决方案架构的设计可能对组织中的多个项目产生影响，因此，在设计解决方案架构时需要仔细评估架构的各种属性并在它们之间寻找平衡。

# 可伸缩性和弹性

可伸缩性一直以来都是解决解决方案时的主要考虑因素，当我们向一个企业了解其现有解决方案和新的设计时，大多数时候它们都会在可伸缩性方面提前做好规划。可伸缩性意味着系统能够处理不断增长的工作负载，并且可以应用于架构的不同层次，例如应用服务器、web应用程序和数据库。

传统的伸缩模式分为以下两种：

  • 水平伸缩：团队通过增加更多实例来处理不断增加的工作负载。
  • 垂直伸缩：团队为同一实例增加额外的计算存储以及内存的能力，以处理不断增加的工作负载。

垂直伸缩模型可能不具备成本效益，当购买具有更多计算和内存容量的硬件时，成本也将成倍的增加，要避免达到阈值后进行垂直伸缩，当单个服务器的性能达到了伸缩的极限，额外的计算和内存容量并不能让它的性能再继续提升。

很多企业会有一个活跃的旺季，这种情况会带来一个有趣的问题，就是一年中的某一段时间，工作负载将急剧增加，传统的本地数据中心面临这种情况，必须提前规划扩展服务器的容量，但是容量过多也意味着IT基础设施在一年中很长时间会处于闲置状态。因此在设计解决方案架构时，要规划弹性的扩展空间，以确保按需的扩展和收缩。常见的伸缩为如下几类：

  • 架构伸缩。用户向复杂均衡器发送请求，负载均衡器将流量路由到web服务器，随着流量的增加，自动伸缩机制会在web和应用程序群中添加更多服务器，当需求量少时，它会删除多余的服务器。
  • 静态内容伸缩。利用CDN来解决静态内容文件过大，导致用户端负载延迟的问题，利用对象存储来扩展源存储，以在内存和计算容量之外进行独立伸缩。
  • 数据库伸缩。对于数据库来说，需要采取预防措施并减少其负载，最好让数据库的主节点仅用于写入和更新数据，并使用额外的只读副本来处理所有的读请求。可以使用Memcached或Redis之类的缓存引擎来为频繁的查询请求提供缓存，从而减少主节点的负载。如果超出数据库的容量，那么就需要重新设计分区策略将其划分为多个分片，这样每个分片都可以独立增长，应用程序也可以根据分片请求的分区键来确定请求将流向哪个分区。

# 高可用性和韧性

应用程序宕机可能会导致业务和用户的信任受到损失，这使高可用性成为设计解决方案架构时的主要考虑因素之一，解决方案架构需要根据应用程序需求来规划高可用性，以避免过度设计。实现高可用架构（High Availability ，HA），最好将工作负载分布在数据中心相互隔离的区域中，这样即便一个区域发生故障，应用程序副本仍然就可以在另一个区域正常工作。

图中有一个Web服务器机群和一个应用服务器机群，它们分散在两个单独的可用区（数据中心的不同物理区域）中。负载均衡器可以在两个可用区之间分配工作负载，当可用区1因电源或网络中断而停机时，可用区2可以继续处理用户流量，这样应用程序仍然可以正常工作。对于数据库而言，可用区2中有一个备用实例，它将执行故障转移并在可用区1出现问题时切换为主实例。主实例和备用实例都持续同步数据。

解决方案架构需要考虑的另一个因素是韧性，当应用程序出现故障或面临问题时，应用采取自我修复原则，应用程序应该能够在没有人干预的情况下自我修复。可以通过监控工作负载并采取主动干预的措施来获取韧性，如以上架构所示，负载均衡器将监控实例的运行状况。一旦某个实例停止接收请求，负载均衡器就会将它从服务器机群中删除，并通知自动伸缩程序启动新的服务器进行替换。你还可以通过监控所有实例运行状态的方法(例如监控实例的CPU和内存利用率并当它们达到阈值后立即启动新的实例）进行主动干预，高可用性和韧性可以通过实现弹性来降低成本。

# 容错和冗余

容错能力是指在发生中断的情况下能够继续处理工作负载而不损害系统性能的能力，容错架构会增加冗余和成本，所以容错能力的规划要取决于应用程序的重要性。

要实现100%的容错能力，需要完全冗余并且维护双倍的服务器数量，这样即便一个区域发生中断，用户也不会受到任何性能问题。在设计有半个月程序架构时， 需要确保容错能力带来的价值可以抵消额外的冗余成本。

# 灾难恢复与业务连续性

有时，数据中心会因为其所在区域发生大规模供电中断或其他不可抗力因素而中断运行，这种情况下，就必须提前制定一个灾难恢复计划，通过在不同地区准备足够的IT资源来规划业务连续性。

在规划灾难恢复时，解决方案架构师必须要了解组织的恢复时间目标（Recovery Time Objective,RTO）和恢复点目标(Recovery Point Objective,RPO)。RTO意味着企业开源在多长的厅级时间内维持业务而不会产生重大影响。RPO表示企业可以承受多少数据丢失。

以下是几种常见的灾难恢复计划：

  • 备份和存储。所有服务器镜像和数据库快照都存储在灾备站点中。一旦发生灾难，团队将尝试从备份中启动受灾站点。
  • Pilot Lite。所有的服务器镜像都作为备份存储，并且在灾备站点中维护了一个小型数据库服务器，并从主站点持续地同步数据。其他关键服务，例如活动目录 (Active Directory, AD)，可能运行在小型实例中。一旦发生交难，团队将尝试从备份的镜像启动服务器并扩展数据库。
  • 热备份。灾备站点中运行着所有的应用服务器和数据库服务器(以较低的容量运行），并持续与主站点同步。一旦发生灾难，团队将尝试扩展所有服务器和数据库。
  • 多站点。灾备站点维护了与主站点相同容量的副本，并主动为用户流量提供服务。当灾难发生时，所有流量都将被路由到备用站点。

# 可扩展性和可重用性

随着业务的发展与演进，应用程序需要持续扩展功能以应对不断增长的用户群，所以解决方案的设计必须要有足够的可扩展性和灵活性，以支持现有功能的修改或新增功能的添加。为了实现解决方案的可扩展性，要尽可能的使用松耦合的架构。

# 易用性与可访问性

如果希望用户用户在使用应用时能够获得无缝的体验，我们可以通过实现应用程序的高易用性来达成此目的。在定义什么是满足易用性的用户体验时，用户调研和用户测试是必不可少的两个方面。

易用性是指用户能否高效的执行任务，应用程序如果不能被有效的使用，那么即便它的逻辑再复杂，功能再丰富，也没有任何意义。可访问性是一系列关于日和使应用程序被所有人使用的特性，在设计应用程序时，需要确保其可以通过低带宽的互联网访问，并兼容各种设备，各种不同的平台及地区。

设计解决方案架构时，应充分的进行用户访谈和调研，通过模拟的前端收集用户反馈，进行用户研究，或者通过A/B测试来建立持续收集用户反馈的机制以改进设计。

# 可移植性与互操作性

互操作性是指应用程序通过某种标准格式或协议，提供与其他应用协同工作的能力。通常，应用程序需要与各种上游系统进行通信以获取数据，或向下游系统通信以提供数据，解决方案架构需要识别和处理系统各种依赖关系。

可移植性使应用程序可以在不同的环境中工作，而无须进行任何更改，或只需要进行少量的变更即可在不同的操作系统和硬件上工作，才能实现更高的易用性。在应用程序设计的过程中，解决方案架构需要选择一种可移植的技术来支撑跨平台的应用程序开发。

# 运维的可维护性

更好的运维可以实现以最小的停机时间为客户提供高质量的同等服务，解决方案架构需要针对运维进行设计，这意味着设计时应该才能够长远考虑如何对工作负载进行部署、更新和运维。对日志、监控和告警进行规划，通过捕获所有事件并快速响应以获得最佳用户体验。无论是部署基础设施还是应用程序的代码变更，都应尽可能的实现自动化，以避免人为错误。

维护可以是主动或者被动的策略，无论采用哪种策略，变更都应该以增量的方式进行，通常可以通过CI/CD（持续集成和持续部署）流水线来自动化更新整个变更过程，还可以通过A/B部署或蓝绿部署进行上线。

# 安全性与合规性

安全性是解决方案设计中最基本的属性之一，其包含如下几个方面：

  • 认证和授权：认证是指谁可以访问系统，授权是指用户进入系统后可以进行哪些操作。如果应用程序仅供公司内部使用，你可能希望用户可以通过统一的组织管理系统（例如Active Directory、SAML2.0或LDAP）进行访问。如果应用程序针对的是诸如社交媒体网站或游戏应用之类的大众用户群体，则可以允许他们通过OAuth 2.0和Open ID进行认证。
  • Web安全。其主要包含跨站脚本（cross-site scripting，XSS）和SQL注入之类的攻击。可以在解决方案架构中规划web应用防火墙来组织恶意软件和SQL注入共计，WAF阻止恶意IP地址的流量，联合CDN预防DDoS攻击。
  • 网络安全。其帮助全面防止组织赫尔应用程序内部的IT资源对外开放，解决方案必须规划如何保护网络安全，帮助防止未经授权的系统访问、主机漏洞和端口扫描。解决方案架构中可以通过将所有内容部署在公司防火墙后并尽可能地避免互联网访问来将系统暴露将至最低。
  • 基础设施安全。如果要维护自己的数据中心，那就要确保基础设施不会被未经授权的用户物理访问。
  • 数据安全。解决方案中可以通过安全证书来保障数据传输过程中的安全性，静态数据可以通过对称和非对称加密机制来保护。DevSecOps将最佳实践应用于实现安全需求和安全响应的自动化工作。

← 解决方案架构的设计原则 →