解决方案架构师修炼之道

2021-12-01 19:55:07 浏览数 (1)

推荐序二

  • 在IT领域里，解决方案架构师的培养成本也是极高的，架构的优劣决定着企业IT的建设和运营成本，架构设计上的漏洞可能会给企业带来巨大的损失。一名优秀的解决方案架构师在成长的道路上，要学习各类IT知识，在项目中摸爬滚打，总结经验教训，从实践中提炼方法论

推荐序四

  • 我们介入后，围绕发布目标，反向梳理了三大模块工作细节及其配合关系，包括功能性开发与测试、非功能性开发与验证、产品运营与推广等，帮助产品相关的几十人的业务与技术团队就目标形成共识，包括帮助团队明确和调整优先级，舍弃一些不太重要的功能，提升安全相关模块开发、性能测试、用户体验验证的优先级
  • 《数字化转型：企业破局的34个锦囊》

本书赞誉

  • 《架构之道：软件构建的设计方法》
  • 架构师的价值就是教团队以正确的方式开发产品。架构师其实有许多种，比如系统架构师、应用架构师、数据架构师、安全架构师等。如果说哪一种架构师既懂技术，又懂产品，还懂业务，那一定就是解决方案架构师
  • 解决方案架构师的重要性越来越受到行业的关注。这个角色由企业架构领域的应用架构师与IT架构师发展而来，它的兴起与演进，契合了当下从“架构适配业务的内部视角”到“业务驱动架构的外部视角”关注点变化的趋势
  • 每个公司内部都面临着各种各样的业务问题，面对这些棘手的问题，解决方案架构可以帮助识别、理解、解决业务中出现的各类问题。在这个过程中，我们首先需要对解决方案架构的定义达成共识，并对解决方案架构的发展有深刻理解

译者简介

  • 《AI重新定义企业：从微软等真实案例中学习》
  • 《回顾活动引导：24个反模式与重构实践》

第1章 解决方案架构的含义

  • 解决方案架构不仅要考虑业务需求，还要处理关键的非功能性需求，如可伸缩性、高可用性、可维护性、性能、安全性等
  • 解决方案架构师需要进行概念验证和原型开发以评估各种技术平台，然后采取最佳策略来实施解决方案
  • 会在整个解决方案开发过程中对团队进行指导，并提供上线后的指导方针，以维护和规模化最终产品
  • 解决方案架构从战略和战术的视角，对业务解决方案的方方面面进行定义和展望

图11　解决方案架构环形图

  1. 全球分布式团队：在这个全球化的时代，几乎每个产品都会有分布在全球各地的用户，以及负责满足客户需求的利益相关者团队
  2. 全球合规性要求：当在全球范围内部署解决方案时，每个国家和地区都有其法律和合规制度，这些都是解决方案需要遵守的
  3. 成本和预算：解决方案架构能够很好地估计项目的总成本，这有助于确定预算。预算包括资本支出（CapEx），即前期成本，以及运维支出（OpEx），即持续成本
  4. 解决方案实施组件：解决方案架构预先提供了产品不同实施组件的高层次概述，这有助于计划执行过程
  5. 业务需求：解决方案架构考虑了所有的业务需求，包括功能性需求和非功能性需求
  6. IT基础设施需求：解决方案架构决定了项目执行需要的IT基础设施
  7. 技术选型：在解决方案设计过程中，解决方案架构师会进行概念验证和原型开发，考虑企业需求，然后推荐合适的实施技术和工具
  8. 终端用户需求：解决方案架构特别关注终端用户的需求，因为他们将是产品的实际消费者
  9. 解决方案维护：解决方案架构不仅涉及解决方案的设计与实施，还需要负责上线后的活动，例如解决方案的可伸缩性、灾难恢复、卓越运维等
  10. 项目时间表：解决方案架构设计根据每个组件的复杂性布局其细节，通过提供资源估算和相关风险信息，进一步帮助确定项目里程碑和时间表
  11. 创建解决方案架构的两种主要情况如下：
  12. 增强现有应用程序的技术，可能包括硬件更新或软件重构
  13. 从头创建一个新的解决方案，这样可以更加灵活地选择最适合的技术来满足业务需求
  • 一个好的解决方案架构不仅要满足功能性和非功能性需求，还要能解决系统的可伸缩性和长期维护问题
  • 解决方案架构可以解决各种解决方案需求，保持业务上下文的完整性。它指定并记录了技术平台、应用程序组件、数据需求、资源需求以及许多重要的非功能性需求，如可伸缩性、可靠性、性能、吞吐量、可用性、安全性和可维护性
  • 解决方案架构考虑所有的解决方案，并通过创建能够适应所有业务和技术限制的概念验证，来寻求最佳方案

图12　解决方案架构的有益属性

  1. 技术价值与需求：解决方案架构决定了投资回报率，可以通过特定的技术选型以及市场趋势来选择解决方案
  2. 业务目标：解决方案架构设计的主要任务是满足利益相关者的需求，并适应他们的需求变更
  3. 目标日期：解决方案架构师与所有的利益相关者（包括业务团队、客户和开发团队）持续合作
  4. 市场机遇：解决方案架构涉及分析和持续评估市场最新趋势的过程
  5. 预算和资源配置：为了获得更准确的预算，我们一般建议在估算方面进行适当的投资
  6. 项目时间表：定义准确的项目时间表对于解决方案的实施非常关键
  • 在产品开发的生命周期中，最具挑战性的阶段是确定需求的性质，特别是当所有的需求都需要作为高优先级来处理，而且它们一直都在快速变化时。当不同的利益相关者对同一需求有不同的看法时，这种挑战就更加严峻
  • 在这种情况下，解决方案架构有助于消除分歧，并定义一个所有成员都能理解的标准
  • 持续获得反馈并根据反馈进行调整，是高质量交付的关键，应该在解决方案设计和开发的所有阶段予以遵循
  • 解决方案架构师应该对所有的需求进行仔细验证，然后通过创建产品的工作模型作为原型，用多个参数对结果进行评估和研究，以找到最适合产品开发的解决方案
  • 根据业务需求评估，以及应用程序的敏捷性、速度和安全性来构建原型，从而实现最佳技术平台的选择
  • 对于经过深思熟虑获得的解决方案架构，最常见的问题一般与非功能性需求有关。对于产品开发生命周期，资源和预算是有帮助的
  • 在解决方案架构的初始阶段需要进行大量的规划
  • 在通常情况下，你必须处理应用程序中的非功能性需求（NonFunctionalRequirement，NFR）
  • 例如安全性、可用性、延迟问题、维护、日志、隐藏机密信息、性能问题、可靠性、可维护性、可伸缩性、易用性等。如果不及时考虑这些问题，就会影响项目的交付

图13　解决方案架构的非功能性属性

图14　云计算模式的类型

  • 好的解决方案架构不仅可以解决功能性需求，还能长期考虑并满足非功能性需求，如可伸缩性、性能、韧性、高可用性、灾难恢复等。解决方案架构可以找到最优解决方案，以适应成本、资源、时间表、安全性和合规性等方面的限制

第2章 组织中的解决方案架构师

  • 解决方案架构师了解组织的需求和目标。通常，解决方案架构师会参与团队的工作。所有的利益相关者、流程、团队和组织管理都会影响解决方案架构师角色及其工作
  • 敏捷思维对于解决方案架构师来说非常重要
  • 除了解决方案设计外，解决方案架构师还需要处理各种约束，以评估风险并规划应对方案。另外，质量管理也起着不容忽视的重要作用。在整个解决方案的生命周期（从需求收集、解决方案设计、解决方案实施到测试和发布）中，解决方案架构师都扮演着至关重要的角色
  • 在应用发布后，解决方案架构师也需要定期参与相关事务，以确保解决方案的可伸缩性、高可用性和可维护性。对于更广泛的消费类产品，解决方案架构师还需要与销售团队合作，通过在各种论坛上发布内容和公开演讲，成为产品的技术布道者
  • 对于大型项目，应该配有专门的解决方案架构师。方案的成败就取决于解决方案架构师

图21　解决方案架构师的类型

  • 解决方案架构师可以分为通才型与专业型
  • 企业架构师负责整个组织的解决方案设计，与股东和领导层一起制订长期计划和解决方案。其中最重要的一个方面是确立公司应该使用哪些技术，并确保公司使用这些技术时保持其一致性和完整性
  • 企业架构师职责的另一个重要方面是定义业务架构
  • 关于如何组织和交付解决方案，解决方案架构师发挥着至关重要的作用。解决方案架构师设计整体系统，以及不同的系统如何在不同的组别中集成
  • 解决方案架构师在项目管理中也发挥着重要作用，提供有关资源、成本和时间表估算的建议
  • 技术架构师也可以称为应用架构师或软件架构师，负责软件的设计和开发。技术架构师在工程方面与组织合作，更侧重于定义团队软件开发的技术细节
  • 云架构师能够制定云迁移策略，并开发混合云架构。云架构师可以建议内部应用程序如何连接到云，以及不同的传统产品如何适应云环境
  • 为了提高整体目标受众的平台采用率，架构师布道者会撰写公开内容，如博客、白皮书和文章。他们会在行业峰会、技术讲座和会议等公共平台上发表演讲
  • 基础设施架构师是专业型架构师，主要致力于企业IT基础设施设计、安全防护和数据中心运维。他们与解决方案架构师紧密合作，以确保组织的基础设施战略与其整体业务需求相一致，并通过分析系统需求和现有环境来规划适当的资源能力来满足需求。他们能帮助减少用于运维支出的资本支出，以提高组织效率和投资回报率
  • 网络架构师需要对网络策略、网络运维、使用V**的安全连接、防火墙配置、网络拓扑、负载均衡配置、DNS路由、IT基础设施连接等有非常深入的了解
  • 数据架构师开发数据模型并设计数据湖，以捕获业务的关键绩效指标（KeyPerformanceIndicator，KPI）并实现数据转换。他们确保整个组织的数据性能和数据质量保持一致
  • 数据架构师需要了解不同的数据库技术、BI工具、数据安全性和加密技术，才能做出正确的选择
  • 安全架构师需要使用各种工具和技术来了解、设计并指导与数据、网络、基础设施和应用程序安全相关的各个方面
  • 自动化可以应用在任何地方，无论是测试和部署应用程序，还是启动基础设施，甚至是确保安全性。自动化起着至关重要的作用，DevOps架构师可以让一切都实现自动化
  • 解决方案架构师是技术领导者，也是面向客户的角色，承担了许多职责。解决方案架构师的主要职责是将组织的业务愿景转化为技术解决方案，并作为企业和技术利益相关者之间的联络人

图22　解决方案架构师的职责模型

  • 解决方案架构师设计的应用程序可能会影响整体的业务产出。这使需求分析成了解决方案架构师应该具备的关键技能。好的解决方案架构师需要具备业务分析师的技能以及与不同利益相关者合作的能力
  • 解决方案架构师具有广泛的业务经验。他们不仅是技术专家，而且对业务领域也有很深入的理解。他们要与产品经理和其他业务利益相关者紧密合作，以了解需求的各个方面
  • 对用户和客户来说，非功能性需求（NonFunctionalRequirement，NFR）可能并不直观，但它们的缺失可能对整体的用户体验产生负面影响，并阻碍业务的开展

图23　解决方案设计中的NFR

  • 好的解决方案架构师的主要责任是传达NFR的重要性，并确保它们作为解决方案交付的一部分得到实施
  • 他们拥有出色的沟通能力和谈判技巧，这有助于找出解决方案的最佳路径，同时让每个人都参与其中
  • 架构约束是解决方案设计中最具挑战性的属性之一。解决方案架构师需要仔细管理架构约束，并能够在它们之间进行协调以找到最佳解决方案

图24　解决方案设计中的架构约束

  • 在资源有限的情况下实现进度可能会影响质量，而质量又会因为不必要的bug修复而增加成本。所以，在成本、质量、时间和范围之间找到平衡点是非常重要的。范围蔓延是最具挑战性的情况之一，因为它会对所有其他约束产生负面影响，并增加解决方案交付的风险
  • 处理范围蔓延对项目的按时交付有很大帮助
  • 解决方案架构师需要为解决方案确定适合的技术。解决方案架构师需要在技术层面具备广度和深度，才能做出正确的决策，因为所选择的技术栈会影响产品的整体交付
  • 创建原型可能是作为解决方案架构师最有趣的部分。为了选择一个经过验证的技术，解决方案架构师需要在各种技术栈中开发概念验证（ProofOfConcept，POC），以分析它们是否适合解决方案的功能性和非功能性需求
  • 开发POC的思路是实现关键功能的一部分来评估技术，这可以帮助我们根据其能力来决定技术栈。它的生命周期很短，并且仅限于由团队或组织内的专家进行评审
  • 解决方案设计POC是指解决方案架构师试图弄清楚解决方案的基础构件

图2-5所示的流程图显示了解决方案交付生命周期。解决方案架构师参与了解决方案设计和交付的所有阶段

  • 解决方案架构师不仅仅负责解决方案的设计，他们还帮助项目经理进行资源和成本估算，定义项目的时间表和里程碑、项目的发布及其支持计划。解决方案架构师的工作贯穿解决方案生命周期的不同阶段，从设计到交付及发布都有参与。解决方案架构师通过提供专业知识和对项目广泛的了解，帮助开发团队克服重重障碍和壁垒
  • 敏捷方法主张通过保持客户和利益相关者的密切参与来寻求持续反馈，让他们参与产品开发的每一个阶段，将反馈调整为需求，评估市场趋势，并与他们一起确定利益相关者的优先级
  • 解决方案架构师处理各种项目约束，如成本、质量、范围和资源，并在它们之间寻找平衡。
  • 解决方案架构师帮助项目经理估算成本和资源，确定时间表，并贯穿项目从设计到发布的全过程。在项目实施过程中，解决方案架构师要确保满足利益相关者的期望，并担任技术团队与业务团队之间的联络人。解决方案架构师参与发布后的应用程序监控、告警、安全性、灾难恢复和扩展等相关工作

第3章 解决方案架构的属性

  • 可伸缩性一直以来都是设计解决方案时的主要考虑因素
  • 可伸缩性意味着系统能够处理不断增长的工作负载，并且可以应用于架构的不同层次，例如应用服务器、Web应用程序和数据库
  • 按需扩容和收缩。而公有云让这一切变得非常简单
  • 在应用程序的不同层上实现弹性
  • 应用程序宕机是组织不愿意看到的，它会导致业务和用户的信任度受到损失，这使得高可用性成为设计解决方案架构时的主要考虑因素之一
  • 要实现高可用性（HighAvailability，HA）架构，最好将工作负载分布在数据中心相互隔离的区域中
  • 解决方案架构需要考虑的另一个因素是韧性。当应用程序出现故障或者面临断断续续的问题时，应当采取自我修复原则，这意味着应用程序应该能够在没有人工干预的情况下自行恢复
  • 如以上架构所示，负载均衡器将监控实例的运行状况。一旦某个实例停止接收请求，负载均衡器就会将它从服务器机群中删除，并通知自动伸缩程序启动新的服务器进行替换
  • 100%容错的架构会因为增加的冗余度导致高额的成本。容错能力的规划取决于应用程序的重要性
  • 始终从最小的权限开始，根据用户角色的要求进一步提供访问权限
  • 通过将所有内容部署在公司防火墙后并尽可能地避免互联网访问来将系统暴露降至最低
  • 对服务器的逻辑访问必须通过网络安全来保护，这可以通过配置恰当的防火墙策略来实现
  • 必须建立一种机制以在任何安全漏洞发生时立刻识别并采取行动
  • 在软件开发生命周期中，DevSecOps将最佳实践应用于实现安全需求与安全响应的自动化，它也因此被越来越多的组织所采用
  • 所有的活动都需要记录并在需要时发送给审计师。任何个人身份信息（PersonalIdentifiableInformation，PII）数据（例如客户电子邮件ID、电话号码和信用卡号）都需要加密

第4章 解决方案架构的设计原则

  • 要获得出色的性能，请在架构设计的每一层中使用缓存。缓存可以将数据保留在用户的本地存储，或将数据保存在内存中，以提供超快响应
  1. 通过用户系统中的浏览器缓存来加载频繁请求的网页
  2. 使用DNS缓存可以快速查询网站地址
  3. 通过CDN在用户位置附近缓存高分辨率图像和视频
  4. 在服务器层面，最大限度地利用内存缓存来服务用户请求
  5. 使用Redis和Memcached之类的缓存引擎来处理缓存层的频繁查询
  6. 使用数据库缓存来处理内存中的频繁查询
  7. 注意每一层的缓存过期和缓存逐出情况
  8. 谈到面向服务的思想，解决方案架构师总是倾向于采用SOA。最流行的两种SOA分别是基于SOAP（SimpleObjectAccessProtocol，简单对象访问协议）服务的架构和基于RESTful服务的架构

图47　单体架构与微服务架构

  • 解决方案架构师在进行数据存储选型时需要考虑众多因素，以满足相应的技术要求
  1. 耐久性要求：应如何存储数据以防止数据损坏？
  2. 数据可用性：哪个数据存储系统可以被用来传递数据？
  3. 延时要求：数据应该在多短的时间内返回？
  4. 数据吞吐量：数据读写的需求是什么？
  5. 数据大小：数据存储的需求是什么？
  6. 数据负载：需要支持多少并发用户？
  7. 数据完整性：如何保持数据的准确性和一致性？
  8. 数据查询：数据查询的特征是什么？

表41　数据类型及其示例与存储类型

  • 在选择存储时，需要考虑数据的温度（数据根据温度可以分为热数据、温数据和冷数据）：
  1. 对于热数据，必须使用缓存并且延迟达到亚毫秒级的缓存数据存储。股票交易和实时产品推荐数据都是热数据
  2. 对于温数据（例如财务报表编制或产品性能报告数据），因为可以承受一定的延迟（从几秒到几分钟），应该使用数据仓库或关系型数据库
  3. 对于冷数据（例如出于审计需要而存储3年的财务记录），可以以小时为单位规划延迟，并将其存储在存档中
  • 作为解决方案架构师，你不仅要考虑应用程序设计，还要考虑整体的业务价值定位，这与应用程序的其他因素息息相关，它有助于提高客户满意度并最大化投资回报率。数据就是黄金，对数据的深入了解可以极大地提升组织的盈利能力
  • 主要的约束包括成本、时间、预算、范围、排期和资源。如何克服这些约束是设计解决方案时需要考虑的重要因素之一
  • MoSCoW是一种流行的需求优先级排序法，可以将客户的需求分为以下几类：
  1. Mo（Musthave，必须具备）：对客户来说至关重要，没有的话产品将无法发布
  2. S（Shouldhave，应该具备）：一旦客户开始使用该应用程序，它们就是客户最想要
  3. Co（Cloudhave，可以具备）：锦上添花的需求，但是没有它们也不会影响应用程序该有的功能
  4. W（Won’thave，不需要具备）：即便没有也不会引起客户关注的需求

你需要为客户规划包含Mo需求的最小价值产品（MinimumViableProduct，MVP）版本，然后在接下来的迭代中交付S需求。使用这种分阶段交付的方式，你可以充分利用各种资源并克服时间、预算、范围和资源方面的挑战。MVP方法可帮助你更好地确定客户需求

  • 采取敏捷方法可帮助你克服各种约束并构建以客户为中心的产品。在设计原则方面，应将一切约束视为挑战而非障碍，并寻找解决方案
  1. 安全是解决方案设计最重要的方面之一，安全上的任何差池都可能对业务和组织的未来造成毁灭性的影响
  2. 数据中心的物理安全：数据中心的所有IT资源都应受到保护，以防未经授权的访问
  3. 网络安全：网络应该是安全的，以防止未经授权的服务器访问
  4. 身份和访问管理（IdentityandAccessManagement，IAM）：只有经过身份验证的用户才能访问应用程序，用户可以根据自己的授权进行相应的操作
  5. 数据传输安全：通过网络或互联网进行数据传输时，数据应该是安全的
  6. 静态数据安全：存储在数据库或任何其他存储中的数据应该是安全的
  7. 安全监控：任何安全突发事件都应该被捕获，并提醒团队采取行动
  • 任何可重复执行的任务都应该被自动化，以释放宝贵的人力资源，这样团队成员就可以将时间花在更激动人心的工作上，并专注于解决实际问题。这样也有助于提高团队士气
  1. 应用程序测试：应用程序的每次更新都需要测试，以确保没有任何功能被破坏。另外，人工测试非常耗时，并且需要大量资源。最好对可重复的测试用例进行自动化，以加快产品部署和发布的速度。应对生产环境的伸缩进行自动化测试，并使用滚动部署技术（如金丝雀测试和A/B测试）来发布变更
  2. IT基础设施：可以通过基础设施即代码（InfrastructureasCode，IaC）脚本（例如Ansible、Terraform和AmazonCloudFormation）来实现基础设施的自动化。基础设施的自动化能够在数分钟（而非数天）内完成环境的搭建
  3. 日志、监控和告警：监控是系统的重要组件，你肯定希望每时每刻都能监控到所有内容。你可能还希望通过监控来实现其他自动化措施，例如系统的自动伸缩或自动提醒团队采取行动
  4. 部署自动化：部署是一项重复的工作，并且非常耗时，很多应急场景下，都因部署问题导致了上线紧急关头的延迟。通过CI/CD（持续集成和持续部署）搭建自动化的部署流水线，可以让你更加敏捷，并通过频繁的部署来快速迭代产品功能
  5. 安全自动化：在对一切自动化的同时，不要忘了对安全进行自动化。如果有人试图侵入应用程序，你肯定想要立即知道并迅速行动。你希望自动监控系统边界上的流入流量和流出流量，以便采取预防措施，并在可疑活动发生时得到告警

第5章 云迁移和混合云架构设计

  • 有了云，企业不仅可以在全球范围内快速地获得基础设施，还可以使用前所未有的各种技术。包括使用以下各种尖端技术：
  1. 大数据
  2. 分析
  3. 机器学习
  4. 人工智能
  5. 机器人学
  6. 物联网（IoT）
  7. 区块链
  • 在云计算思维下，你将遵循“按需付费”模式。你需要适当地优化工作负载并只在需要时运行服务器
  • LiftandShift是最快的迁移方式，因为只需要最小的工作量即可迁移应用程序。但是它没有利用云原生的优势
  1. 最常见的LiftandShift策略是重新托管（Rehost）、更换平台（Replatform）及重新部署（Relocate），它们通常只需要对应用程序进行最小的变更，就可以完成迁移
  2. Rehost方法速度快、可预测、可重复并且经济实用，这使其成为迁移上云的最优选择。Rehost是最快的云迁移策略之一，它将本地环境中的服务器或应用程序直接整体迁移到云上。在迁移过程中，只需要对应用程序进行最小的更改
  3. 使用Replatform迁移策略时，可能需要在目标环境中重新安装应用程序，这将导致应用程序变更
  4. 在本地数据中心，你可能会采用容器或VMware虚拟设备来部署应用程序。你可以使用名为Relocate的加速迁移策略将此类工作负载移到云上。Relocate可以在几天之内迁移上百个应用程序。你可以以最小的工作量和最简的方式将基于VMware和容器技术的应用程序快速重新部署到云上
  5. Refactor需要更多的时间和资源来重写应用程序，并进行重新架构，然后才能迁移上云。具有丰富云经验或高级技术人员的组织通常使用这种方式
  6. 当IT资源和项目都迁移到云上后，可能需要为某些服务器或应用程序购买与云兼容的许可证或发行版
  7. Retain：本地环境中可能会存在一些对业务至关重要，但由于技术原因（例如，云平台上不支持某个操作系统或应用程序）不适合迁移的应用程序。在这种情况下，可以让它们继续运行在本地环境中
  8. 对于即将停用的主机和应用程序，可以采用Retire策略

第7章 性能考量

  • 吞吐量=（平均I/O大小）×IOPS
  • 如果磁盘IOPS是20000，I/O大小是4KB（4096字节），那么吞吐量将是81.9MB/s

第10章 卓越运维考量

  • 新服务器的启动或服务的开启和停止这类工作应该通过基础设施即代码（InfrastructureasCode，IaC）来实现自动化。最重要的是应该使用自动化来主动发现和响应安全威胁，这样运维团队也可以得到解放
  • 一定要建立相应的流程，让系统运维不依赖具体的人，而且要记录运维流程的所有环节
  • 运维手册中需要记录所有以前的事件和团队成员为解决这些事件所采取的行动，这样有利于新的团队成员在系统运维时快速解决类似事件
  • 设计运维时，请参考以下最佳实践：
  1. 使用脚本自动化运维手册，以减少人为错误，因为人为错误会增加运维负担
  2. 根据定义好的（资源标识）标准（例如环境、版本、应用程序所有者和角色），使用资源标识机制来执行各种操作
  3. 将事件响应流程自动化，以便在发生故障的情况下，系统不需要太多人为干预即可开始自我修复
  4. 使用各种工具和功能来自动管理服务器实例和整个系统
  5. 在实例上创建脚本，以便在服务器启动时自动安装必需的软件和安全补丁。这些脚本也称为引导脚本
  • 卓越运维的设计原则。这些原则倡导自动化运维、持续改进、增量变更、故障预测和响应准备。另外，还介绍了实现卓越运维的各个阶段以及相应的技术选型。对于规划阶段，介绍了IT资产管理，它可以跟踪IT资源的库存资产；还介绍了配置管理，它可以确定资产之间的依赖关系
  1. 对于执行阶段，探讨了告警和监控，通过各种示例介绍了不同的监控类型，其中包括基础设施、应用程序、日志、安全和平台监控。此外，论述了告警的重要性，并介绍了如何定义告警的严重级别和与之对应的响应
  2. 对于改进阶段，介绍了如何通过大数据流水线来进行IT运维分析，如何使用“五问”（5Why）法来执行RCA，以及审计的重要性。审计可以使系统免受任何恶意行为和未被注意到的威胁的侵害

第12章 DevOps和解决方案架构框架

  • 每个团队都有自己的一套工具、流程和方法，这样不仅非常多余，有时，它们之间还会产生冲突
  • DevOps有助于在不影响质量、可靠性、稳定性、韧性或安全性的情况下完成交付
  • 在DevOps（开发运维的简称）方法中，开发团队和运维团队在软件开发生命周期的构建和部署阶段协同工作，分担责任，并提供持续反馈。在整个构建阶段，软件构建会在类生产环境中被频繁地测试，这样有助于及早发现缺陷
  • DevOps实践鼓励软件开发工程师和专业运维人员更好地合作。这有助于更密切的合作和沟通，从而缩短产品推向市场的时间（TimeToMarket，TTM），让发布更加可靠，提高代码质量，使系统更易于维护
  • DevOps是文化和实践的结合。它要求组织改变其文化，打破产品开发和交付生命周期中所有团队之间的壁垒。DevOps不仅仅涉及开发和运维，还涉及整个组织，包括管理层、业务/应用负责人、开发人员、QA工程师、发布经理、运维团队和系统管理员。DevOps作为首选的运维文化，越来越受欢迎，特别是对于那些涉及云计算或分布式计算的组织
  • DevOps的工具和自动化将开发及系统运维结合在一起。以下是DevOps实践的关键组成部分：
  1. 持续集成和持续交付（CI/CD）
  2. 持续监控和改进
  3. 基础设施即代码（IaC）
  4. 配置管理（CM）
  • 在IaC的实践中，基础设施是通过代码和CI来配置和管理的
  • Ansible、Terraform和AWSCloudFormation是时下流行的基础设施即代码的脚本工具
  • 在追求完全自动化的过程中安全是当务之急。为了避免人为错误，组织正在利用DevOps实施严格的安全实施和监控，俗称DevSecOps
  • 我们现在比以往任何时候都更加注重安全。在很多情况下，安全是赢得客户关注的唯一途径。DevSecOps关注自动化安全和规模化安全实施
  • DevSecOps则需要在整个流程中确保应用程序的安全
  • DevOps是为了提高效率以加快产品发布，而DevSecOps则是在不减慢产品发布周期的情况下验证所有构件

图12-4　DevSecOps和CI/CD

  1. 编码阶段，扫描所有代码，以确保没有密码或访问密钥被硬编码在代码中
  2. 在构建阶段，标记所有安全工件，如加密密钥和访问令牌管理等
  3. 在测试阶段，扫描配置，通过安全测试确保满足所有安全标准
  4. 在部署和环境准备阶段，确保所有安全组件都已注册。执行校验，确保构建物没有被篡改
  5. 在监控阶段，监控所有违反安全标准的情况，以自动化的方式执行持续审计和验证

第13章 数据工程和机器学习

  • 在数据架构中，数据流水线一般以数据为起点，以洞见为终点。如何从起点到终点，取决于一系列的因素

如图13-1所示，大数据流水线的标准工作流程包括以下步骤：

  1. 通过合适的工具收集数据（摄取）
  2. 持久化存储数据
  3. 数据处理或分析。从存储中获取数据，对其进行操作，然后将处理后的数据再次存储
  4. 数据被其他处理/分析工具使用，或者被同一工具再次处理，从数据中获得进一步的结果
  5. 为了使结果对业务用户有用，使用商业智能（BI）工具将结果可视化，或者将结果输入机器学习算法中进行预测
  6. 一旦将合理的结果呈现给用户，这就为他们提供了对数据的洞见，然后他们可以采用这些数据进行进一步的业务决策

图132　大数据架构设计中的工具与流程

  • 数据湖是结构化和非结构化数据的集中存储库。数据湖正在成为在集中存储中存储和分析大量数据的一种流行方式。它按原样存储数据，使用开源文件格式来实现直接分析。由于数据可以按当前格式原样存储，因此不需要将数据转换为预定义的模式，从而提高了数据摄取的速度
  • 数据湖的好处如下：
  1. 从各种来源摄取数据
  2. 采集并高效存储数据
  3. 随着产生的数据量不断扩展
  4. 将分析方法应用于不同来源的数据

图13-5　数据湖的对象存储

图136　使用数据湖ETL流水线处理数据

  • 假设你的公司想为新玩具的上市向潜在客群发送营销优惠，你需要设计一个系统来识别营销活动的目标客群。客群可能是数以百万计的用户，你需要对他们进行预测分析，而ML可以帮助你解决这一复杂问题
  • ML就是利用技术手段根据历史数据来发现趋势、模式，并计算数学预测模型。ML可以帮助解决以下复杂问题：
  • 当你可能不知道如何创建复杂的代码规则来做决定时。例如，如果你想从图像和语音中识别人们的情绪，但无法通过简单的方法编写实现逻辑
  • 当你需要人类的专业知识分析大量的数据来进行决策，但数据量太大，人类无法高效完成时。例如，虽然人类可以检测垃圾邮件，但数据量太大，人工快速完成不切实际
  • 当你需要根据个人数据调整和个性化用户行为让相关信息动态有效时。例如个性化的产品推荐或网站个性化
  • 当有很多任务和很多可用数据，但你无法快速跟踪信息来做出有规则的决策时。例如，欺诈检测和自然语言处理
  • 机器学习背后的主要思想是将一个训练数据集提供给机器学习算法，让它从新的数据集中预测一些东西

例如，将一些股市趋势历史数据提供给机器学习模型，让它预测未来6个月到1年的市场波动情况

  • 机器学习就是与数据打交道。训练数据和标签的质量对ML模型的成功至关重要。高质量的数据能让ML模型更准确，预测更正确
  • 在现实世界中，数据往往存在多种问题，如缺失值、噪声、偏差、离群值等。数据科学的部分作用就是对数据进行清洗，让它为机器学习做好准备
  • 要进行数据准备，首先要了解业务问题。数据科学家通常非常渴望直接沉浸到数据里，开始编写模型，产生洞见

如图13-8所示，机器学习工作流程包括以下阶段：

  1. 预处理：在这个阶段，数据科学家对数据进行预处理，并将其划分为训练、验证和测试数据集。ML模型使用训练数据集进行训练，并使用验证数据集进行评估。一旦模型就绪，就可以使用测试数据集来测试它。考虑到数据量和业务用例，一般需要将数据划分为训练集、测试集和验证集，可以将70%的数据用于训练，10%用于验证，20%用于测试
  2. 学习：在学习阶段，要根据业务用例和数据选择合适的机器学习算法。学习阶段是机器学习流程中的核心，会在训练数据集上训练ML模型。为了获得精准的模型，你需要对各种超参数进行实验，并进行模型选择
  3. 评估：一旦ML模型在学习阶段得到训练，就要用已知的数据集来评估其准确性。使用预处理阶段保留的验证数据集来评估模型。如果模型预测精度没有达到可分辨验证数据确定的异常的程度，则需要根据评估结果对模型进行必要的调整
  4. 预测：预测也被称为推理。在这个阶段，部署模型并进行预测。这些预测可以实时进行，也可以按批次进行
  • 当模型过拟合时，它将无法泛化。当模型在训练集上表现良好，但在测试集上表现不佳时，就可以确定模型过度拟合。这通常表明模型对于训练数据量来说过于灵活，这种灵活性使它除了能够记住数据外，还记住了噪声。过拟合对应的是高方差，训练数据的微小变化会导致结果的巨大差异
  • 当模型欠拟合时，模型无法捕获训练数据集中的基本模式。通常情况下，欠拟合表明模型太简单或解释变量太少。欠拟合的模型灵活度不够，无法对真实模式进行建模，对应的是高偏差，这表明结果在某个区域显示出系统性的拟合不足

图13-9　模型的过拟合与欠拟合

  • 机器学习算法是整个机器学习工作流程的核心，可以分为监督学习和无监督学习

第14章 遗留系统架构设计

图14-1展示了遗留系统给企业带来的巨大挑战

  1. 难以满足用户需求
  2. 更高的维护和更新成本
  3. 技能和文档的缺失
  4. 存在安全隐患
  5. 无法与其他系统兼容
14.1.1　难以满足用户需求
  • 以客户为中心是业务成功的关键，无法赶上最新的技术趋势将给业务带来巨大的伤害
  • 在当前技术日新月异、竞争激烈的环境下，用户有着非常高的要求。企业必须根据用户的条件作出应变，因为他们有多种需求
14.1.2　维护和更新费用较高
  • 遗留系统中有大量的专有软件，让许可费大大增加。除此之外，老旧的软件不再得到供应商的支持，在软件生命周期外购买额外的支持可能会非常昂贵
  • 由于利益相关者看不到现代化改造的直接效益，因此获取遗留系统现代化改造的资金会面临很大的挑战
14.1.3　缺乏技能和文档
  • 遗留技术（如大型机）有多个相互依赖的复杂组件。这些组件通常都是昂贵的专用服务器，而且不容易得到，所以很难自己培训这些技能。企业很难留住应用开发人员，而雇用具备旧技术和旧操作系统实践经验的人则难上加难
  • 这些系统没有适当的文档来记录这些年的工作。当老员工与新员工轮换时，有可能流失大量的知识。由于缺乏知识和未知的依赖，变更系统的风险更高。由于系统的复杂性和技能的短缺，任何微小的功能需求都难以被满足
14.1.4　存在安全风险
  • 对于遗留应用的系统健康检查往往被忽略，这使得它们更容易成为安全攻击的目标
  • 系统运行于不安全的环境。仅仅一个漏洞就会导致很高的风险，使你的应用程序、数据库和关键信息暴露在攻击者面前
14.1.5　无法兼容其他系统
  • 难以改变的遗留系统如果坚持使用旧的格式，可能会导致系统无法兼容，你的供应商和合作伙伴可能不想使用这样的系统。无法适应标准会导致企业采用复杂的变通方案，降低生产力，从而让企业承担更大的风险
  • 旧的系统往往建立在单体架构上，添加任何新功能都意味着要重建和测试整个系统
  • 将单体应用拆分为微服务，可以解决伸缩挑战，有助于应对需求的变化

14.2　遗留系统现代化改造策略

14.2.1　系统现代化改造的好处
  • 应用现代化改造的显著优势如下：
  1. 客户满意度
  2. 与时俱进的业务战略：现代化改造的应用能让你更加敏捷，具备创新能力。团队可以舒适地适应业务的变化需求，并与新技术一起发展
  3. 在竞争中保持领先
  4. 高可靠性和好性能
  5. 使用前沿技术的能力
  6. 节省成本
14.2.2　遗留系统的评估
  • 在进行评估时，解决方案架构师需要关注以下几方面：
  1. 架构评估：为了让架构能够与时俱进，你需要对它有整体的了解。可能会出现这样的情况：你决定在技术上进行小幅升级，但整体架构是单体的，无法伸缩。你应该从可伸缩性、可用性、性能和安全性等方面审视架构
  2. 代码和依赖性评估
14.2.3　现代化改造方案
  • 现代化改造方法如下：
  1. 架构驱动现代化改造：架构驱动方法需要实现最大的敏捷性。通常，架构调整会采用与语言无关和与平台无关的面向服务的架构模式，这为开发团队提供了更多创新的灵活性
  2. 采取微服务的方式能获得可伸缩性，确保与其他系统更好地集成
  3. 系统重建：解决方案架构师需要深入了解遗留系统，并实施逆向工程，建立新的现代化应用
  4. 你需要建立一种机制，让遗留模块和升级模块同时存在，并能以混合方式进行通信
  5. 迁移和增强：如果现有系统运行得比较好，但存在硬件和成本限制，那么可以采取迁移和小范围的增强方法
14.2.4　文档和支持

图14-4　遗留系统现代化改造技术

14.3.1　封装、重新托管和重新平台化
  • 封装是最简单的方法，如果系统对业务很关键，并且需要与运行采用最新技术的其他应用进行通信，那么你可能会想采取这种方法。在封装方法中，你需要围绕遗留系统构建API封装器，这将允许其他业务应用与遗留应用通信
  • 重新托管也是最直接的方法之一，通过此方法，你可以将应用迁移到另一个硬件供应商，如云上，而不需要对代码进行任何更改。与封装一样，由于供应商合同的原因，重新托管方案可以节省一些成本
  • 重新平台化可能会比重新托管更加复杂，并能直接发挥新操作系统优势。当服务器即将寿终正寝（EOL），供应商不再提供支持和必要的安全补丁更新时，组织通常会选择这种方法
  • 在重构方法中，你可以重构代码来适应新系统。在重构时，整体架构不会变化，只是升级代码使其更适合最新版本的编程语言和操作系统
  • 在重新架构方法中，你会尽可能地重新利用现有代码来改变系统架构
  • 重新设计最复杂，但能获得最大的效益。如果遗留系统已经完全过时，完全无法适应业务需求，则可以选择这种方法

图14-5　遗留大型机系统现代化改造上云

  • 重新设计遗留系统是一项长期的工作，需要付出大量的努力和更高的成本。在开始大规模的现代化改造之前，作为解决方案架构师，你应该仔细分析是否有任何软件即服务（SaaS）产品或商业成品软件（CommerciallyAvailableOfftheShelf，COTS）能以相对较低的成本满足业务需求。在进行重新设计之前，必须先进行重新设计与购买的成本效益分析（CBA）
  • SaaS产品是基于订阅的，并按用户许可证收费，所以如果用户数量较少，它们可以是很好的选择。对于拥有数千名用户的庞大企业来说，选择自建系统可能成本效益更高

14.4　遗留系统的云迁移策略

图14-6　遗留系统现代化改造的云迁移路径

  • 从升级中得到的结果取决于你投入的投资和精力。在确定现代化改造方法之前，必须彻底了解遗留系统。你需要从技术、架构、代码等各个维度评估和了解目标系统

第15章 解决方案架构文档

  • 为了成功地交付应用程序，保持一致的沟通非常重要。解决方案架构师需要将解决方案的设计传达给所有的技术和非技术利益相关者
  • 解决方案架构文档（SolutionArchitectureDocument，SAD）提供了一种端到端的应用程序视图，解决了与应用程序开发相关的所有利益相关者的需求，并帮助大家达成共识
  • SAD有助于实现以下目的：
  1. 向所有的利益相关者传达端到端的应用程序解决方案
  2. 提供高层次架构和不同的应用程序设计视图，以满足应用程序的服务质量要求，如可靠性、安全性、性能和可伸缩性
  3. 提供解决方案对业务需求的可追溯性，并关注应用程序如何满足所有的功能性和非功能性需求（NFR）
  4. 提供设计、构建、测试和实施所需的解决方案的所有视图
  5. 定义解决方案的影响，以便于评估、规划和交付
  6. 定义解决方案的业务流程、延续和运维，以便系统上线后不间断运行

图15-1　SAD视图

  1. 业务视图：架构设计就是为了解决业务问题，明确业务目的。业务视图显示了整体解决方案和产品的价值主张。为了简化起见，解决方案架构师可以选择识别出与业务相关的高级场景，并将其以用例图的形式展现出来。业务视图还描述了利益相关者和执行项目所需的资源。业务视图也可以被定义为用例图
  2. 逻辑视图：它展示了系统上的各种程序包，以便业务用户和设计人员可以明了系统的各种逻辑组件。逻辑视图提供了它所应当构建的系统的时间顺序。它显示了系统的多个组件是如何连接的，以及用户如何与它们交互
  3. 流程视图：它呈现更多的细节，显示系统的关键流程如何协同工作。这一切也可以用状态图来反映。如果想要展示更多的细节，还可以创建序列图。在银行应用程序中，流程视图可以显示贷款或账户的审批情况
  4. 部署视图：它展示了应用程序如何在生产环境中工作，以及系统的不同组件（例如网络防火墙、负载均衡器、应用服务器、数据库等）是如何连接的。解决方案架构师应当创建简单的框图，便于业务用户理解，还可以在UML部署图中添加更多细节，向技术用户（如开发团队和DevOps团队）展示各种节点组件及其依赖关系。部署视图可以展示系统的物理布局
  5. 实现视图：SAD的核心，体现了架构上和技术上的选择。解决方案架构师需要把架构图设置在这里，例如，显示出它是3层、N层架构，还是事件驱动的架构，以及其背后的理由。你还需要详细说明技术选择，例如，Java与Node.js的使用对比，以及它们各自的利弊。你需要在实现视图中说明执行项目所需的资源和技能
  6. 数据视图：由于大多数应用程序都是数据驱动的，因此数据视图尤为重要。数据视图显示了数据如何在不同组件之间流动，以及如何存储。它还可以用来解释数据安全性和数据完整性。解决方案架构师可以使用实体关系（EntityRelationship，ER）图来显示数据库中不同表和模式之间的关系。数据视图还可以对所需的报告和分析进行说明
  7. 运维视图：它解释了系统在启动后如何进行维护。通常情况下，需要定义SLA、告警和监控功能、灾难恢复计划，以及系统的支持计划。运维视图还提供了有关如何进行系统维护的详细信息，包括修复bug、打补丁、备份和恢复、处理安全事件等
运维 编程算法 数据湖 数据库 数据安全

0 人点赞