「解决方案架构师修炼之道」

解决方案架构从战略和战术的视角，对业务解决方案的方方面面进行定义和展望，它涵盖了系统的方方面面，包括但不限于系统基础设施、网络、安全、合规性要求、系统运维、成本和可靠性。

定义

需要解决的问题

1. 全球性分布式团队
2. 全球合规性要求
3. 成本和预算
4. 解决方案实施组件
5. 业务需求
6. IT基础设施需求
7. 技术选型
8. 终端用户需求
9. 解决方案维护
10. 项目时间表

演进

1. 胖桌面
2. 面向服务的架构
3. 微服务架构

益处

1. 满足业务需求和交付质量
2. 选择最佳技术平台
3. 处理解决方案的约束和问题
4. 协助资源和成本管理
5. 管理解决方案交付和项目生命周期
6. 解决非功能性需求

组织中的解决方案架构师

解决方案架构师的角色类型

1. 企业解决方案架构师
2. 技术架构师
3. 云架构师
4. 基础设施架构师
5. 网络架构师
6. 数据架构师
7. 安全架构师
8. DevOps架构师

职责

1. 分析用户的需求：方案设计的核心

2. 定义非功能性需求

   1. 性能
   2. 安全性与合规性
   3. 可恢复性
   4. 可维护性
   5. 可靠性
   6. 可用性
   7. 可伸缩性
   8. 易用性

3. 干系人的管理

4. 处理架构约束

   1. 成本
   2. 质量
   3. 时间
   4. 范围
   5. 技术
   6. 风险
   7. 资源
   8. 合规性

5. 技术选型

6. 概念验证和原型开发

7. 设计方案和持续交付

   1. 业务需求和愿景
   2. 需求分析和技术愿景
   3. 原型设计和推荐
   4. 解决方案设计
   5. 开发
   6. 集成与测试
   7. 实现
   8. 运营和维护

8. 确保发布后的可操作性和可维护性

   1. RTO
   2. RPO

9. 技术布道

敏捷组织中的解决方案架构师

敏捷方法论

敏捷流程和术语

1. Scrum团队
2. Scrum Master
3. 产品负责人
4. 开发团队

迭代仪式

1. 待办事项梳理
2. 迭代计划
3. 每日站会
4. 迭代延时
5. 迭代回顾

工具和术语

1. 规划卡牌
2. 燃尽图
3. 产品待办列表
4. 迭代看板
5. 完成标准

敏捷方法与瀑布式方法

敏捷架构

敏捷宣言

1. 个体与交互高于流程和工具
2. 软件高于详尽的文档
3. 客户协作高于合同谈判
4. 响应变化高于遵循计划

解决方案架构的属性

可伸缩性和弹性

1. 水平伸缩
2. 垂直伸缩

架构伸缩

弹性伸缩

静态内容伸缩

CDN

服务器机群弹性

NoSQL数据库：Mongo

数据库伸缩

RDS

高可用性和韧性

1. HA架构的设计
2. 没有人工干预的情况下自行恢复

容错和冗余

容错能力是指在发生中断的情况下能够继续处理工作负载而不损害系统性能的能力。容错能力的规划取决于应用程序的重要性，即用户群在应用程序恢复期间可以承受多大程度的性能下降。

灾难恢复与业务连续性

可扩展性与可重用性

易用性与可访问性

可移植性与互操作性

卓越运维与可维护性

安全性与合规性

1. 认证和授权
2. web安全
3. 网络安全
4. 基础设施安全
5. 数据安全

成本优化与预算

解决方案架构的设计原则

工作负载的伸缩

1. 可预测伸缩
2. 被动伸缩

构建有韧性的架构

1. 尽量让应用程序的工作负载部署在专用网络内部，避免应用程序端点暴露到互联网
   1. CDN
   2. waf
2. 冗余
   1. 负载均衡器
   2. DNS
   3. 自动伸缩
   4. 备用数据库

性能设计

1. 架构设计的每一层都需要考虑性能
2. 选择合理的IOPS
3. 架构设计的每一层中使用缓存
   1. 通过用户系统中的浏览器缓存来加载频繁请求的网页
   2. 使用DNS缓存可以快速查询网站地址
   3. 通过CDN在用户位置附近缓存高分辨图像和视频
   4. 在服务器层面，最大限度利用内存缓存来服务用户请求
   5. 使用redis和memecached之类缓存引擎来处理缓存层的频繁查询
   6. 使用数据库缓存来处理内存中的频繁查询
   7. 注意每一层缓存过期和缓存逐出情况

使用可替换资源

创建不可变的基础设施

1. 创建可替换的服务器，确保应用程序时无状态的，避免对任何服务器的IP或者数据库的DNS名称进行硬编码
2. 将基础实施视为软件而非硬件并且不要对运行中的系统进行更新

金丝雀测试

1. 软件更新部署在新服务器上
2. 应将服务器视为牛马，而不是宠物

松耦合

1. 基于队列的松耦合架构
2. 搭建面向服务的架构

考虑服务而非服务器

1. 模块化可以降低成本、规模和变更风险
2. 服务化的优势是需要维护的代码面较小，并且服务是独立的，所有依赖都被包含在服务内部

合理选择存储

1. 耐久性要求：应如何存储数据以防止数据损坏
2. 数据可用性：那个数据存储可以被用来传递数据
3. 延时要求：数据应该在多短的时间内返回
4. 数据吞吐量：数据读写的需求是什么
5. 数据大小：数据存储的需求是什么
6. 数据负载：需要支持多少并发用户
7. 数据完整性：如何保持数据的准确性和一致性
8. 数据查询：数据查询的特征是什么
9. 数据的温度：根据热数据、温数据、冷数据选择存储

数据驱动的设计

运维和业务决策是围绕数据展开的，需要持续地监控数据并在发生问题时发送告警触发自动修复机制。作为解决方案架构师，不仅要考虑应用程序设计，还要考虑整体的业务价值定位，它有助于提高客户满意度并最大化投资回报率。数据就是黄金，对数据的深入了解可以极大地提升组织的盈利能力。

克服约束

1. MoSCoW需求优先排序法

   1. Mo（Must have，必须具备）至关重要
   2. S（Should have，应该具备）一旦客户开始使用，就是客户最想要的
   3. Co（Cloud have，可以具备）锦上添花的需求
   4. W（Won‘t have，不需要具备）即便没有也不会引起客户关注的需求

2. MVP方法（Minimum Viable Product，最小价值产品方法）

   为客户规划包含Mo需求的最小价值产品版本，然后在接下来的迭代中交付S需求。使用这种分阶段交付的方式，就可以充分利用资源并克服时间、预算、范围和资源方面的挑战。

3. 采用敏捷的方法，应将一切约束视为挑战而非障碍，并寻找解决方案

安全无处不在

1. 数据中心的物理安全
2. 网络安全
3. 身份和访问管理
4. 数据传输安全
5. 静态数据安全
6. 安全监控

自动化一切

1. 应用程序cesium
2. IT基础设施
3. 日志、监控和告警
4. 部署自动化
5. 安全自动化

云迁移和混合云架构设计

认识云原生

云迁移策略

1. 搬迁(Lift and Shift)方法
   1. Rehost：直接整体上云
   2. Replatform：目标环境中重新安装应用程序
   3. Relocate：使用VMotion或者Docker迁移实例
2. 云原生方法
   1. Refactor：对应用程序进行重新架构和重写，使其成为云原生程序
   2. Repurchcase：解决许可证或者发行版问题
   3. Retain ：无法迁移的，可以选择本地保留业务
   4. Retire：下线应用，使用云内置功能替代

云迁移步骤

发现工作负载

迁移项目最大的挑战是确定应用程序之间的依赖关系，尤其是它们在I/O操作与通信上的依赖。

1. 服务器的数量清单
2. 服务器的规格
3. 服务器的利用率和性能指标
4. 服务器的依赖关系
5. 全面的网络详情

分析信息

1. 根据组织的云采用策略，选择服务器后者应用程序的迁移策略
2. 确定其资源迁移上云的优先级
3. 将资源迁移上云的业务驱动因素记录下来，这有助于确定迁移上云的需求和优先级

制订迁移计划

1. 从多个业务和i技术维度评估每一个与迁移潜在相关的应用程序
2. 使用锁定、紧耦合和松耦合之类评级来标识应用程序依赖程度
3. 确定组织所需优先策略，收集关键指标，建立KPI

执行应用程序上云

1. 数据迁移
   1. 从源数据库中提取信息
   2. 在数据库仍处于启动和运行时迁移数据
2. 服务器迁移
   1. OScopy，使用代理克隆主机系统
   2. 灾难恢复
   3. VM copy
   4. User Data Copy
   5. 程序容器化

集成、验证和切换

1. 单元测试、冒烟测试和用户验收测试
2. 灰度发布
3. 实时迁移切换

运维云应用程序

1. ITSM
2. DevOps
3. SRE

云上应用程序优化

1. 只需要为使用的资源付费
2. 设计弹性架构
3. 优化领域：
   1. 成本
   2. 安全
   3. 可靠性
   4. 卓越运维
   5. 性能

创建混合云架构

设计云原生架构

1. 微服务中将单体架构容器化，并创建用于自动部署的CI/CD流水线
2. 使用函数即服务（FaaS）和NoSQL技术构建无服务器应用程序
3. 使用S3存储和托管大数据服务创建无服务器数据湖
4. 使用云原生监控和日志服务
5. 使用云原生审计服务

设计模式

构建多层架构

1. web层，也叫表示层，提供用户界面
2. 应用程，也叫逻辑层，是产品的核心，所有的算法和逻辑都放在逻辑层
3. 数据库层，也叫数据层

创建SaaS多租户架构

多租户的关键在于用户的数据隔离

1. 数据库级别隔离
2. 表级别隔离
3. 行级别隔离

构建有状态和无状态的架构

1. 会话存储机制是无状态和有状态应用程序设计的主要区别
2. 所有用户会话持久化存储在NoSQL数据库中
3. 会话ID应该使用客户端cookie保存

理解SOA

SOA将单体应用程序中的处理逻辑划分为彼此独立的服务，使用SOA的目的是降低应用程序服务间的耦合。

基于SOAP的Web服务架构

SOAP是一种消息传输协议，以XML格式在分布式环境中交换数据。SOAP采用标准的XML格式，它通过SOAP信封的格式进行数据传输。SOAP通常使用HTTP，也可以使用其他协议，比如SMTP。

1. SOAP头：消息方应该如何处理该消息的相关信息
2. 消息体：实际内容

RESTFul Web架构

RESTFul Web服务是一种轻量级的架构，支持不同格式的消息，例如JSON、纯文本、HTML和XML。REST是一种架构风格，它定义了通过HTTP进行数据传输的松耦合应用程序设计的标准。REST侧重于无状态服务器的设计原则。Web服务客户端不需要生成复杂的客户端框架，只需要使用唯一的URI就可以访问WEB服务器资源。客户端可以使用HTTP访问RESTFul资源，并对资源进行标准操作（例如GET、PUT、DELETE和POST）。

无服务器架构

1. FaaS：函数即服务
2. BaaS：后端即服务

微服务架构

1. 创建单独的数据存储
2. 使服务器保持无状态
3. 进行独立构建
4. 部署在容器中
5. 蓝绿部署
6. 监控环境

基于队列的架构

RESTful架构中，服务宕机时，HTTP请求会堵塞API。基于队列的架构通过服务之间添加消息队列来解决问题，由消息队列来为服务保留信息。基于队列的架构提供了完全异步的通信和松耦合的架构。

1. 消息
2. 队列
3. 生产者
4. 消费者
5. 消息代理

队列链表模式

作业观察者模式

创建事件驱动架构

发布者/订阅者模式

发布事件时，系统会向所有订阅者发送通知，每个订阅者都可以根据其数据处理需求进行必要的操作。

事件流模型

在事件流模型中，消费者可以读取来自生成者的连续事件流。

基于缓存的架构

1. 客户端
2. DNS缓存
3. Web缓存
4. 应用程序缓存
5. 数据库缓存

三层Web架构中的缓存分发模式

重命名分发模式

缓存代理模式

重写代理模式

应用缓存模式

1. Lazy Caching
2. Write-through
3. Memcached与Redis

断路器模式

隔板模式

浮动IP模式

容器化APP

处理数据库

避免反模式

不良系统示例：

1. 被动伸缩，需要手动完成实例扩缩容
2. 缺少自动化
3. 服务器长期使用硬编码的IP地址
4. 以单体的方式构建应用程序
5. 应用程序与服务器绑定
6. 将一种类型数据库应用用于各种需求
7. 仅用单个数据库实例为应用程序提供服务，进而导致单点故障
8. 直接从服务器提供静态内容
9. 在没有精细安全策略的情况下开放服务器的访问权限

性能考量

高性能总是伴随高成本，作为解决方案架构师，需要考虑如何取舍，需要根据应用程序的需求，在持久性、一致性、成本和性能之间进行权衡。跟踪和提高性能是一项复杂的任务，需要根据访问模式的差异来正确选择性能优化的手段。

性能设计原则

降低延迟

提高吞吐量

处理并发问题

使用缓存

性能优化的技术选型

算力选型

存储选型

数据库选型

1. 在线事务处理
2. 非关系型数据库
3. 在线分析处理
4. 构建数据搜索功能

网络选型

1. 定义DNS路由策略
   1. 简单路由策略
   2. 故障转移路由策略
   3. 地理邻近路由策略
   4. 延迟路由策略
   5. 加权路由策略
2. 实现负载均衡器
   1. 4层或者网络负载均衡器
   2. 7层或者应用负载均衡器
3. 使用自动伸缩功能

性能监控

1. 主动监控：模拟用户活动
2. 被动监控：收集性能问题的重要指标

安全考量

架构安全的设计原则

1. 实现认证和授权控制
2. 安全无处不在
3. 缩小爆炸半径
4. 时刻监控和审计一切
5. 自动化一切
6. 数据保护
7. 事件响应准备

架构安全的技术选型

1. 用户身份和访问管理
   1. 联合身份管理和单点登陆
   2. Kerberos
   3. 活动目录
   4. AWS目录服务
   5. 安全声明标记语言（SAML）
   6. OAuth和OpenID连接
2. 处理网络安全问题
   1. Web应用安全漏洞
      1. 拒绝服务和分布式拒绝服务攻击DDOS
         1. UDP反射
         2. SYN泛洪
      2. SQL注入
      3. 跨站脚本攻击XSS
      4. 跨站请求伪造攻击CSRF
      5. 缓冲区溢出和内存损坏攻击
   2. 应对WEB安全
      1. web应用防火墙waf
      2. 缓解DDoS攻击
         1. 选择合适的web应用服务器
         2. 使用CDN和DNS服务器
         3. 使用负载均衡器在服务器集群中分配流量
3. 保护应用程序极其基础设施
   1. 应用程序和操作系统加固
   2. 软件漏洞和安全准则
   3. 网络、防火墙和可信边界
   4. IDS/IPS
      1. 基于主机的IDS
      2. 基于网络的IDS
4. 数据安全
   1. 数据分类
      1. 受限数据
      2. 私有数据
      3. 公开数据
   2. 数据加密
      1. 对称加密
      2. 非对称加密
   3. 密钥原理
      1. 信封加密
      2. KMS密钥管理服务
      3. HSM硬件安全模块
   4. 静态数据加密和传输中的数据加密

安全和合规认证

1. 全球合规性要求：ISO9001 ISO27001
2. 美国政府的合规要求： ITAR
3. 行业级合规性要求 PCI DSS、FDA
4. 区域合规性认证：GDPR、DJCP
5. 等级保护认证

云的共享安全责任模型

架构可靠性考量

架构可靠性设计原则

1. 使系统自愈
2. 实现自动化
3. 创建分布式系统
4. 容量监控
5. 验证恢复过程

架构可靠性的技术选型

1. 规划RTP和RPO

2. 数据复制

   1. 同步复制和异步复制
   2. 数据复制方法
      1. 基于阵列的复制
      2. 基于网络的复制
      3. 基于主机的复制
      4. 基于虚拟机的复制

3. 规划灾难恢复

   1. DR场景

      1. 备份和恢复
      2. 指示灯
      3. 暖备
      4. 多站点多活(热备)

   2. 复制和备份：成本最低，数据使用S3或者本地备份

   3. 指示灯：不同区域运行最低数量核心服务，使用负载均衡分配

   4. 暖备：30%~50%性能冗余，实现主备运行

   5. 热备：100%性能冗余，实现双活

4. 灾难恢复的最佳实践

   1. 从小处着手并根据需要进行构建
   2. 检查软件许可证
   3. 经常测试解决方案

利用云来提高可靠性

运维考量

卓越运维的设计原则

1. 自动化运维
2. 进行增量和可逆的变更
3. 预测并响应故障
4. 从错误中学习并改进
5. 持续更新运维手册

卓越运维的技术选型

规划阶段

设计运维的最佳实践

1. 使用脚本自动化运维手册
2. 根据定义好的资源标识标准，使用资源标识机制来执行各种操作
3. 将事件响应流程自动化
4. 使用各种工具和功能来自动管理服务器实例和整个系统
5. 在实例上创建脚本，在服务器启动时自动安装必需软件和安全补丁

运维工具

1. IT资产管理（ISO 19770）
   1. 规划
   2. 采购
   3. 集成
   4. 维护
   5. 停用
2. 配置管理
   1. CMDB
   2. ITIL

执行阶段

系统监控

1. 基础设施监控
   1. CPU利用率
   2. 内存利用率
   3. 网络利用率
   4. 磁盘利用率
   5. 负载均衡器
2. 应用程序监控
   1. 端点：给定时间段内请求次数
   2. 响应时间：完成请求的平均响应事件
   3. 节流：系统容量超限时能处理的有效请求数
   4. 错误：应用程序在响应请求时抛出错误
3. 平台监控
   1. 内存缓存
   2. 关系型数据库
   3. NoSQL数据库
   4. 大数据平台
   5. 容器
   6. BI工具
   7. 消息系统
   8. 搜索
4. 日志监控
5. 安全监控
   1. 网络安全
   2. 用户访问
   3. 应用程序安全
   4. web安全
   5. 服务器安全
   6. 合规性
   7. 数据安全

告警处理和事件响应

1. 定义告警类别
2. 测试关键告警的事件响应

改进阶段

1. IT运维分析
   1. ITOA运维分析系统
   2. 数据的转换和清洗
   3. 机器学习
2. 根因分析（5Why）
   1. 问题
   2. 根本原因
   3. 解决方法
3. 审计和报告

在公有云中实现卓越运维

成本考量

成本优化的设计原则

计算总拥有成本

1. 采购和建设成本
2. 运营和维护成本
3. 人力资源和培训成本

规划预算和预测

管理需求和服务目录

跟踪支出

1. 持续成本优化
2. 成本优化的技术选型
3. 降低架构复杂度
4. 提高IT效率
5. 实现标准化和架构治理
6. 成本监控和报告

DevOps框架

DevOps介绍

组成部分

1. 持续集成和持续交付（CI/CD）

2. 持续监控和改进

3. 基础设施即代码（IaC）

4. 配置管理（CM）

DevSevOps

实施CD策略

1. 就地部署：原地升级
2. 滚动部署：在现有的服务器机群中逐步推出新版本
3. 蓝绿部署：逐步将现有服务器替换为新服务器
4. 红黑部署：瞬间从现有服务器切换到新服务器
5. 不可变部署：完全建立一套新的服务器

持续测试

CI/CD的DevOps工具

最佳实践

1. 定义阶段：开发、集成、系统、用户验收和生产阶段
2. 每个阶段测试类型：单元测试、集成测试、系统测试、UAT、冒烟测试、负载测试和生产阶段的A/B测试
3. 测试的顺序：测试用例可以并行，也可以按顺序进行
4. 监控和报告：监控系统缺陷和故障，并在故障发生时发送通知
5. 基础设施置备
6. 回滚
7. 十二要素方法论

解决方案架构文档

在解决方案架构师进行设计的过程中，为了成功交付应用程序，保持一致的沟通非常重要。解决方案架构师需要将解决方案的设计传达给所有的技术和非技术利益相关者。

文档目的

解决方案架构文档(Solution Architecture Document, SAD),提供了一种端到端的应用程序试图，解决应用程序开发利益相关者的需求，并帮助大家达成共识。

1. 提供端到端的应用程序解决方案
2. 提供高层次架构和不同的应用程序设计视图，以满足服务质量要求，如可靠性、安全性、性能和可伸缩性
3. 提供解决方案对业务需求的可追溯性，并关注应用程序如何满足功能和非功能需求
4. 提供设计、构建、测试和实施所需的解决方案的所有视图
5. 定义解决方案的业务流程、延续和运维

在解决方案设计期间，解决方案架构师通过概念验证(POC)或者市场调研进行评估。SAD应该列出所有的架构评估及影响以及技术选择。SAD展示了解决方案设计当前状态和目标状态的概念视图，并保留更改记录。

文档视图

可以选择标准图来展示各种视图，如统一建模语言(UML)图或者Visio的框图。SAD应当尽可能包括以下视图：

1. 业务视图
2. 逻辑视图
3. 流程视图
4. 部署视图
5. 实现视图
6. 数据视图
7. 运维视图

文档结构

解决方案架构文档示例

解决方案概述

1. 解决方案的目的
2. 解决方案的范围
3. 解决方案的假设
4. 解决方案的限制
5. 解决方案的依赖关系
6. 关键架构决策

业务上下文

1. 业务功能
2. 关键业务需求
3. 关键业务流程
4. 业务利益相关者
5. 非功能性需求

概念解决方案概述

解决方案架构

1. 信息架构
2. 应用程序架构
3. 数据架构
4. 集成架构
5. 基础设施架构
6. 安全架构

解决方案交付

1. 开发
2. 部署
3. 数据迁移
4. 应用系统停用

解决方案管理

1. 运维管理
2. 应用程序的升级、补丁工具
3. 管理系统基础设施的工具
4. 系统监控和告警，运维仪表盘
5. 生产环境支持、SLA和事件管理
6. 灾难恢复和业务流程延续

附录

可以放入支持整体架构和解决方案选择的任何数据。

软技能

掌握售前技能

1. 沟通和谈判技能
2. 倾听和解决问题技能
3. 客户公关技能
4. 团队合作

向高管汇报

1. 所提出的解决方案将如何使我们的客户收益？
2. 针对解决方案做了那些假设？
3. 投资回报率是多少？
4. 如果维持现状而不采取任何行动，会怎么样？
5. 竞争对手对于此解决方案会有什么反应？
6. 你的建议是什么，我如何帮助你？

主人翁意识和责任心

1. 树立主人翁意识，将自己定位为领导者
2. 要对推动结果负责

定义战略执行以及目标与关键成果(OKR)

1. 确定重点
2. 对齐目标
3. 跟踪进展
4. 扩展目标

着眼于大局

1. 永远不要怀疑自己的能力，而应着眼于大局，并设定挑战性目标
2. 获取同行和团队的支持

灵活性和适应性

1. 与团队一起思考各种解决问题的方案，并采取最佳方法
2. 帮助团队成员减轻工作负担
3. 主动补位
4. 能够与不同地点、不同时区的团队进行有效协作

设计思维

1. 强调以人为本
2. 交叉协作
3. 仔细考虑设计过程
4. 演示和讲述
5. 明确定义问题
6. 频繁实验
7. 付诸行动

五阶段模型

1. 同理心
2. 定义
3. 构想
4. 原型
5. 测试

持续学习、不断进步

1. 通过实践来学习新技术、框架和语言
2. 通过阅读书籍和教程来学习新技能
3. 通过阅读网站和博客文章来追踪技术新闻和发展
4. 撰写博客、白皮书和书籍
5. 通过教授他人来巩固知识
6. 参加在线课程
7. 向队友学习
8. 参加用户组、出席会议

成为他人的导师，成为技术布道者和思想领袖