1. 水在前面

        第一次看到“解决方案架构师”这个词，就把这本书借回家翻了。最近也在网上看点资料，对比起来发现还是出版物内容更完整和更有体系，而且看书真的能让人安静下来。。。

        《解决方案架构师修炼之道》所罗伯·死里瓦斯塔瓦，内拉贾利·斯利瓦斯塔夫著，机械工业出版社出版。

2. 解决方案架构的含义

        解决方案架构从战略和战术的视角，对业务解决方案的方方面面进行定义和展望。它指定并记录了技术平台、应用程序组件、数据需求、资源需求以及许多重要的非功能性需求，如何伸缩性、可靠性、性能、吞吐量、可用性、安全性和可维护行。

        解决方案架构师可以解决的不同方面的问题如下：全球团队、业务需求、全球合规性、预算、解决方案实施、技术选型、基础设施需求、终端用户需求、解决方案维护和项目时间表。

        解决方案架构的演进如下：CS架构-》面向服务的架构（SOA）-》微服务架构

        云计算服务类型如下：基础设施即服务（IaaS）、平台即服务（PaaS）、软件即服务（SaaS）和函数即服务（FaaS）

3. 组织中的解决方案架构师

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

• 企业解决方案架构师：制定组织的IT策略，定义业务架构。
• 解决方案架构师：设计整体系统，以及不同的系统如何在不同的组织中集成。
• 技术架构师：负责软件的设计和开发。
• 云架构师：规划和设计云环境，并负责部署和管理公司的云计算策略。
• 架构师布道者：嗯，就是负责吹牛的。
• 基础设施架构师：企业IT基础设施设计、安全防护和数据中心运维。
• 网络架构师：负责设计计算机网络、局域网、广域网、互联网、内部网和其他通信系统。
• 数据架构师：设计、创建和管理组织中的数据架构。
• 安全架构师：为组织研究和设计强大的安全架构。
• DevOps架构师：嗯，设计DevOps流程的。

3.2. 解决方案架构师的职责

        分析用户需求、定义非功能性需求、与利益相关者的接触和合作（当和事佬）、处理各种架构约束、技术选型、概念验证和原型开发、设计解决方案并持续交付、确保发布后的可操作性和可维护性、担任技术布道者（继续吹牛）。

        感觉除了测试啥都要干。。。

3.3. 敏捷架构

        敏捷也是需要架构的，敏捷架构就是设计可解耦和可扩展的接口。敏捷架构的接触应该是降低变更成本，通过质疑来减少不必要的需求，并创建可以快速扭转不正确需求的框架。

4. 解决方案架构的属性

        个人感觉这个标题翻译的不好，这一章讲的是解决方案中需要解决的问题类型。

• 可伸缩性和弹性：静态内容伸缩（CDN）、服务器机群弹性（NoSql）、数据库伸缩（只读副本）。
• 高可用性：将工作负载分布在数据中心相互隔离的区域中。这样，即使一个区域发生故障，应用程序副本仍然可以在俩一个区域正常工作。杜宇架构而言，可以通过监控工作负载并采取主动干预的措施来获得韧性。
• 容错和冗余：容错能力是指在发生中断的情况下能够继续处理工作负载而不损害系统性能的能力。
• 灾难恢复与业务连续性：备份和存储、Pilot Lite、热备份、多站点。
• 可扩展性与可重用性：需要尽可能地使用松耦合的架构。比较好的做法是创建一个基于RESTful或基于队列的架构，这将有助于模块之间或跨应用程序的松耦合通信。
• 易用性和可访问性：必须充分了解用户才可能实现易用性和可访问性，在实现用户满意度时，可访问性是易用性的一部分，这两点需同时满足。
• 可移植性与互操作性：在设计的过程中需要识别和处理系统的各种依赖关系，以设计应用程序的互操作性。可移植性是应用程序可以在不同的环境中工作，而无需进行任何更改，或只需进行少量变更。
• 卓越运维与可维护性：需要针对运维进行设计，意味着设计时应该从长远考虑如何对工作负载进行部署、更新和运维。
• 安全性与合规性：认证和授权、Web安全（应用安全）、网络安全、基础设施安全、数据安全。
• 成本优化与预算：钱很重要！

5. 解决方案架构的设计原则

        通俗点说就是解决方案架构设计的指导思想。

• 工作负载的伸缩：可预测伸缩和被动伸缩，主要用于系统性能方面的设计考量。
• 构建有韧性的架构：安全上主动防御，应用程序上设计冗余。
• 性能设计：使用缓存。
• 使用可替换资源：将基础设施视为软件而非硬件，并且不要对运行中的系统进行更新。
• ps:金丝雀测试是指软件更新到新服务器上，并将少量流量路由到新服务器，如果没问题，在扩大流量。
• 考虑松耦合：添加中间层、使用基于队列的架构、使用面向服务的架构（SOA）。
• 考虑服务而非服务器：还是SOA。
• 根据合理的需求选择合适的存储：字面意思理解就行。
• 考虑数据驱动的设计：应用程序的根本在于数据，以数据作为设计的源头。
• 克服约束：MoSCoW需求优先级排序法（必须具备、应该具备、可以具备、不需要具备）。
• 安全无处不在：数据中心的物理安全、网络安全、身份和访问管理、数据传输安全、静态数据安全、安全监控。
• 自动化一切：测试、基础设施、日志监控告警、部署、安全等。

6. 云迁移和混合云架构设计

        这一章感觉有点水，而且貌似在给AWS卖广告。

6.1. 云原生架构的好处

        三个词就能概括的事非要写了一整节：灵活可伸缩、省钱、省事（基础设施交给供应商）。

6.2. 创建云迁移策略

        重新托管（相当于换了一台硬件服务器）、更换平台、重新部署（vmware或者Docker）、重构（改成云原生）、重新采购（改成用SaaS）、保留或者停用。

6.3. 云迁移的步骤

• 发现：识别所有涉及云迁移项目的IT资产（包括服务器和应用程序以及他们的依赖关系和性能指标）的过程。
• 分析信息：确定服务器和应用程序的依赖信息。
• 制定迁移计划：目标、策略、成功标准、工作优先级、模式、时间表、团队、工具。
• 设计应用程序：保证迁移成功甚至还可以有点优化。
• 执行：数据怎么迁移、服务器怎么迁移。
• 集成和验证：字面意思
• 运维：DevOps
• 应用程序优化：SOA

6.4. 后面卖广告的

        AWS直连服务、函数即服务还有Azure和GCP。。。

7. 解决方案架构设计模式

7.1. N层架构

        典型的网络三层架构

7.2. 基于SaaS的多租户架构

        一套软件及其配套基础设施可以为多个客户提供服务，主要考虑如何进行数据隔离：数据库级别隔离、表级别隔离和行级别隔离。

7.3. 无状态架构

        通过NoSQL数据库对用户会话进行持久化存储，实现无状态服务。

7.4. SOA

        基于SOAP和RESTful 服务实现面向服务的架构

7.5. 无服务器架构

        卖广告的，AWS Lambda

7.6. 微服务架构

        每个服务划分为一个应用

7.7. 队列架构

        目的是当请求阻塞时，能保留请求信息，等畅通后继续搞事。有队列链模式、作业观察者模式。其中观察者模式可以根据作业数量来计算需要自动分配的资源的规模。

7.8. 事件驱动架构

        实现把一系列的事件衔接在一起完成，有发布者/订阅者模式和事件流模式，其中事件流模式就是通过流服务实现事件的处理。

7.9. 缓存架构

• 重命名分发模式：CDN中不需要等待TTL过期，通过分发新的内容地址实现更新。
• 缓存代理模式：在应用服务器前增加缓存服务器。
• 重写代理模式：NGNIX
• 应用缓存模式：在数据库前增加数据缓存，redis
• 断路器模式：检测到下游依赖项故障时，主动断开服务
• 隔板模式：根据应用服务进行隔离，限制故障范围
• 浮动IP模式：换设备不换IP

7.9. 使用容器

        这个以后估计会有专门的一篇文章来写

7.10. 数据库处理

        读写分离、分片、主备

8. 性能考量

8.1. 架构性能的设计原则

        减低延迟、提高吞吐量、处理并发问题（并行是一个大任务分成多个子任务同时进行，并发是多个任务同时进行）、使用缓存。

8.2. 性能优化技术选型

        又开始打广告了。。。

• 计算能力：选择服务器实例、使用容器（Docker,Kubernetes）、无服务器化（Lambda）
• 存储：SAN\NAS\云存储
• 数据库：关系型数据库（OLTP）、非关系型数据库（NoSQL)、在线分析处理（OLAP）、数据搜索（Elasticsearch）
• 网络：DNS、负载均衡（NGINX）、自动伸缩（模式只能上云）

8.3. 管理性能监控

        第三方监控工具Splunk

9. 安全考量

这一章有点超出我的基础知识储备了，尽量记住能懂的东西。

9.1. 架构安全的设计原则

• 实现认证和授权控制：集中式用户管理，活动目录；
• 安全无处不在：使用深度防御，在应用每一层进行防护，和WAF;
• 缩小爆炸半径：网络分层隔离，在每层上防止负载均衡控制；
• 监控和审计：记录系统的每一项活动日志，定期审计；
• 自动化防护：DevSecOps;
• 数据保护：静态保护和动态保护；
• 事件响应准备：做好应对任何安全事件的准备。

9.2. 架构安全技术选型

• 用户身份和访问管理：SSO，联合身份管理和单点登录，Kerberos，活动目录（AD），AWS目录服务，安全声明标记语言（不懂），OAuth和OpenID。
• 处理网络安全问题：Web应用防火墙（WAF），DDoS WAF三明治缓解策略，使用CDN和DNS服务器。
• 保护应用程序及其基础设施：应用程序和系统加固，软件漏洞和安全准则，网络、防火墙和可信边界（VPC），IDS/IPS。
• 数据安全：数据分类，数据加密，密钥管理，静态数据加密和传输中数据加密（SSL）

9.3. 安全和合规认证

就是过认证。。。

9.4. 云安全责任模型

划分责任边界，出事了该谁背锅

10. 架构可靠性考量

10.1. 设计原则

        系统自愈、自动化（伸缩、配置、执行脚本）、创建分布式系统、容量监控、验证恢复过程。

10.2. 技术选型

• 规划RTO和RPO：恢复事件目标（RTO），恢复点目标（RPO）

• 数据恢复：基于阵列的复制（HP/EMC SAN Copy/NetApp SnapMirror），基于网络复制(NetApp Replication X/EMC RecoverPoint)，基于主机复制（Symantec/commvault/CA/Vision Solution），基于虚拟机的复制（VMware Zerto）
• 规划灾难恢复：备份和恢复（数据备份，NetApp/VMware/Tivoli/Commvault/CloudEndure），指示灯（全备份但不运行，Attunity/Quest/Syncsort/Alooma/JumpMind），暖备（系统可以立马切换但是需要扩容），多站点多活（热备）

10.3. 灾难恢复的最佳实践

        备份-》检查软件许可证-》经常测试解决方案

10.4. 利用云

        这个不说了，花钱搞定

11. 卓越运维考量

11.1. 设计原则

        自动化运维（启动、开启、防护自动化）、进行增量和可逆的变更、预测并响应故障、从错误中学习并改进、持续更新运维手册。

11.2. 技术选型

• 规划阶段：资产管理（SolarWinds/Freshservice/ServiceDesk Plus/Asset Panda/PagerDuty/Jira Service Desk）,配置管理（CMDB，Chef/Puppet/Ansible/Bamboo）
• 执行阶段：系统监控（基础设施、应用程序、日志、安全、数据）、告警处理和事件响应（5级分类）
• 改进阶段：IT运维分析（ITOA）、根因分析（5WHY）、审计和报告。

11.3 公有云。。。

12. 成本考量

        这应该是更高层领导的职责吧，我这种小喽啰就。。。

• 设计原则：计算总拥有成本、规划预算和预测、管理需求和服务目录、跟踪指出、持续成本优化。
• 技术选型：降低架构复杂度、提高IT效率、实现标准化和架构治理、成本监控和报告
• 公有云成本：AWS广告

13. DevOps和解决方案架构框架

• DevOps介绍：DevOps是一种方法论，强调通过促进开发人员和运营团队之间协作和协调来持续交付产品或服务。在DevOps方法中，开发团队和运维团队在软件开发生命周期的构建和部署阶段协同工作，分担责任，并提供持续反馈。
• DevOps好处：提高速度、快速交付、增加可靠性、实现规模化、加强协作和提高安全性
• 组成部分：CI/CD、持续监控和改进、基础设施及代码（Ansible/Terraform）、配置管理(Chef/Puppet/Ansible)。
• 结合DevSecOps和CI/CD：在CI/CD的每一步，都需要嵌入安全检查
• CD策略：就地部署、滚动部署、蓝绿部署、红黑部署、不可变部署
• 流水线测试：在每个阶段持续进行测试
• 工具：代码编辑器（ACE/VSCode/Eclipse）、源代码管理（GitHub，Git）、CI服务器（Jenkins）、代码部署（Chef/Puppet/Jenkins）、代码流水线（Git/Jenkins/Chef/Blazemeter/shell）
• 最佳实践：十二要素方法论

14. 数据工程和机器学习

        本章内容和《企业级数据治理学习总结》基本重合，但是却做了一个很好的归纳：

• 大数据架构不是一种工具就可以搞定的；
• 大数据处理流水线是：数据收集-》数据存储-》处理和分析-》可视化/服务-》人工智能

15. 遗留系统架构设计

        本章阐释了用最少的文字描述了最大的工作量。总的来说归纳为：“用着实在扛不住了，就搞吧。”

• 改造前的评估：技术、架构、代码和依赖性评估
• 改造策略只有两种：推到重来和逐渐过渡
• 改造技术：封装、重新托管、重构、重新平台化
• 最后推荐云迁移策略

16. 解决方案架构文档

• 文档的作用：很重要，特别是工作交接的时候。。。
• 文档视图：可以看下《UML学习体会》。
• 文档结构：敲黑板必考！

17. 软技能

• 售前技能：吹牛、倾听和解决问题、客户公关、团队合作
• 向领导汇报：画饼、多种方案、选择优劣点、建议、计划
• 责任心：该死的责任心会把你熬死
• 定义目标和成果：OKR
• 大局观：就是不怕苦熬憋
• 灵活性和适应性：不要怕麻烦多想想，方法总比困难多
• 设计思维：以客户为中心（客户包括你的上游和下游）
• 写代码：多写代码
• 持续学习：。。。
• 成为导师：继续吹牛B
• 成为技术布道者和思想领袖：继续吹牛，吹大牛

18. 水在最后

        昨天老婆问我最近看书写博客是否有针对性，貌似是灵魂的暴击！前面人生最大的失败就是没有一个明确的目标，混混噩噩就过去了好多年，一晃眼已经到了随时会被淘汰的人生阶段。扪心自问，混得不好，不看书又能干什么呢，追剧睡觉堕落吗。。。