架构设计的核心：从多个维度理论分析

@[TOC]

一、如何实现高内聚低耦合的架构

内聚就是，一个模块之间，各个组件、各个类之间的关系，耦合就是一个模块和另一个模块或者多个模块之间的交互关系。

1、确定边界

边界分多层，包含系统边界、领域边界；子系统（子域）边界、模块边界、聚合边界；分层边界。

确定边界有多种方式，方式之一就是领取驱动的边界划分，通过业内普适的领域进行边界的划分： 方式之二就是需求驱动的边界划分，通过对用户需求的分析，进行边界的划分：

可以通过DSSA、ABSD、定制的方式对边界进行划分。

2、内聚的分类

内聚的七大类：从左往右内聚性由高变低，模块独立性由强到弱。

（1）功能内聚：功能模块中，每一个组成部分都执行同一个功能并且只执行这一个功能。

（2）顺序内聚：功能模块中，前一组成部分完成后，后一组成部分继续。同时他们之间还有关联关系：前一模块的输出是后一个模块的输入。 比如注册用户流程，注册完用户之后自动执行登录流程。再比如大数据Map-Reduce，Map过程和Reduce就是顺序内聚在一个功能模块中。

（3）通信内聚：模块各部分使用相同输入或输出数据，本身两个部分并没有什么相同的功能。 比如说通过ID查询用户的基本信息和用户的订单信息，输入是相同的。

（4）过程内聚：模块各部分受同一控制流支配。

（5）时间内聚：模块各组成部分在同一时间段内执行（通常见于定时任务中），模块整体在特定时间内完成。

（6）逻辑内聚：模块内各组件逻辑功能类似，逻辑的处理由传输给模块的判断参数来确定（flag字段标识）。

（7）偶然内聚：模块中各组成部分彼此没有关联。

3、耦合的分类

耦合的七大类：从左到右的耦合性由低到高，模块独立性由强到弱。 （1）非直接耦合：两个模块之间没有任何关系，独立性非常强。通常来说一个系统中不存在两个模块非直接耦合的，但是A耦合B，B耦合C，C与A就是非直接耦合，但是这是理想的状态。

（2）数据耦合（推荐）：两个模块之间，用数据值（参数）进行耦合。 可以是应用的直接调用，可以是API的发送，可以是消息队列的沟通。这种耦合是模块间影响非常小的耦合。

（3）标记耦合：两个模块之间传输一些标记（通常来说与同一个数据结构相关的内容，比如说指针、引用）。 比如说以下实例，计算水费和电费，都携带了用户详情的内容： 可以进行优化，互相传输的标记省去，只传输关键参数，共享的数据结构进行拆解：

（4）控制耦合：两个模块之间传输控制信息（如开关、标志等）。这样一来，调用模块需要知道被调用模块的内部逻辑。

（5）外部耦合：一组模块都与外部环境（变量、值）相关联，这组模块访问同一个全局变量。 外部耦合有时候必不可少，但应尽量减少此类模块数量。

（6）公共耦合：一组模块都访问同一全局数据区。公共耦合是一种不良耦合，它给模块维护、修改带来障碍。 公共耦合的弊端：软件可理解性降低，模块间关系复杂；公共软件可维护性降低，修改变量名和属性困难；软件可靠性降低，公共区域和全部变量无保护措施。

最糟糕的就是如下图，如果避免不了公共耦合，那就尽量使用松散的公共耦合，而不是A和B反复修改公共变量的紧密公共耦合：

（7）内容耦合：一个模块直接操作或修改另一模块的内部数据。这就意味着一个模块不通过正常入口访问另一个模块，这是最糟糕的耦合清空，必须避免。

4、如何实现高内聚低耦合

（1）耦合关注点

一个模块对另一个模块的调用。 一个模块向另一个模块传递的数据量。 一个模块施加到另一个模块的控制的多少。 模块之间接口的复杂程度。

（2）低耦合原则

多用接口隐藏实现的细节。 遵循一个定义只在一个地方出现。（公共的model最好放在公共模块中） 少用全局变量。 少用public，多用private关键字，对外减少暴露。 多用设计模式。 避免直接用SQL语句操作数据库，尽量封装一个Dao层。 避免直接操作或调用其他模块或类（内容耦合），如果要调用尽量用API方式。 尽量使用数据耦合，少用控制耦合。 限制公共耦合的范围。

（3）高内聚原则

模块的功能划分尽可能的单一（单一职责原则）。 模块只对外暴露最小限度的接口（接口隔离原则）。 一切向功能内聚靠拢，杜绝偶然内聚。

二、如何实现可扩展性的架构

1、扩展性：核心方法论

（一）X轴：无脑克隆。这就意味着一个系统进行扩展，需求不断增加时，我不断地堆服务器、堆系统、堆模块。这意味着业务简单可复制。 （二）Y轴：功能分割。当需求不断变化时，每一个功能都对应独立的一套服务器。分割责任、功能和数据，并且根据业务模块进行组件的划分。 （三）Z轴：客户分割。对于不同的客户群体，对应着不同的服务器，根据用户类别提供优先级服务、就近服务。

2、扩展性：应用扩展

（1）X轴：横向克隆

对于无状态应用来说，多个节点进行克隆复制，通过负载均衡器可以很容易的进行服务器的扩展。 对于有状态应用，我们可以先将状态剥离（比如说Session使用redis共享）。

使用横向克隆的方案，可以很轻松的实现应用的弹性扩缩容，根据当前服务器压力动态扩缩容； 实现性能规划，测试环境1台服务器支持1000QPS，生产上就意味着10台服务器支持1wQPS； 实现业务解耦，业务规模扩大可以扩充服务器来进行支撑； 实现环境同构，测试环境与生产环境参数一致，不存在环境不一致的情况。

（2）Y轴：服务分割

前端应用，对URL进行拆分，也就是微前端。 后端应用，拆分为子系统、模块、聚合，实现应用的解耦。 后台数据相应的进行Y轴分割。

使用服务分割，可以实现服务互不干扰，实现服务互相隔离。 实现资源迭代分配，应用的功能逐渐完善，服务器资源也对应着慢慢增加。 实现数据一致性，相同的业务都将数据分配在相同的服务器上，所以数据一致性可以得到保障。 但是缺点，业务耦合性强，需要根据不同的业务进行动态调整。

（3）Z轴：特征分割

根据用户UserId分割（hash或者其他），多节点水平复制。 根据地理位置分割，Set单元化。 根据产品ID分割，SPU/SKU。

使用特征分割，可以加速查询搜索。 Z轴也可以支持有状态服务。 实现业务解耦。 实现环境同构。

（4）多维度扩展

通常来说，真正落地时，X、Y、Z轴一起扩展。

3、扩展性：数据扩展

（1）X轴：水平复制

传统的关系型数据库，如果采用强一致性，但是只能扩展有限的几个节点。如果想要实现数据库的水平复制，通常来说会实现读写分离，或者1写多读（binlog+cdc）。 NoSQL数据库，天生就支持多副本replica。 缓存读取也可以支持多副本横向扩展，比如redis。

水平复制可以通过CAP（最终一致性）、CDC便捷复制来实现数据的高可用。但是多副本会造成存储空间的浪费，相当于用空间来换可用性。

（2）Y轴：库表分割

配合应用，对业务进行库表分割。表、库享有独立的数据库集群/节点。 库表分割有点相似于微服务的按业务分割，相当于数据跟着服务走。

通过库表分割，可以实现数据故障隔离、对资源进行迭代分配，数据的强一致性。但是业务耦合性很强，每个库与业务强绑定。

（3）Z轴：哈希取模

通过各种key的id，通过哈希取模来决定数据存放在哪一个数据区。

比如说传统的关系型数据库，分库分表可以使用的MyCat。 非关系型NoSQL数据库，天然支持多分片（shard/chunk）。

通过哈希取模的方式，可以加速查询搜索，扩展无上限，不需要考虑业务，每一个分片都是强一致性。

（4）多维度数据扩展

通常来说，生产环境会通过XYZ轴混合使用。

对于Elasticsearch来说，可以完美实现XYZ轴的扩容：

4、扩展性：组织

（1）康威定律

康威定律是马尔文·康威在1967提出的，写在论文里发表出来。它的出名是被"软件开发神书"《人月神话》引用并总结成四条定律，成为软件架构设计的神律。

第一定律，设计系统的架构受制于产生这些设计的组织的沟通结构。 沟通成本 = N（N-1）/ 2，N代表沟通的总人数 沟通的问题会影响系统设计，软件架构最终会是沟通（组织）结构的映射。

第二定律，时间再多一件事情也不可能做的完美，但总有时间做完一件事情。 时间永远不够，人力永远不足，事情永远做不完，一件一件慢慢来来。 这个定律是敏捷管理的先驱，先把事情做了，再去逐步逼近完美。所以敏捷管理主张持续交付，快速迭代，及时反馈，立刻验证，持续优化。

第三定律，线性系统和线性组织架构间有潜在的异质同态特性。 什么样的系统对应什么样的组织，什么样的组织设计出什么样的系统。 架构由组织关系决定，架构服务于技术，同样服务于组织中的人

第四定律，大的系统组织总是比小系统更倾向于分解。 系统越复杂，越需越多的人手，需要越多的沟通，需要更高的成本。 分而治之，以结构化、模块化的方式架构和设计系统，以小团队形式进行开发和沟通。

（2）披萨组织

亚马逊的"两块披萨"团队机制。

组织中的人，每天目标一致：吃披萨。

组织人员较少：贝索斯推荐幸运数字：6、12

配合应用和数据的Y轴，通过业务的分割，对组织也进行扩展。

（3）Spotify组织架构

符合敏捷开发的理念。

问题类型	结构类型	结构细节	优势	缺点
小队	以团队为基础	-- Spotify 的核心组织单位是"小队"。 小队是小型的跨职能团队，负责特定的功能或项目。 每个小组都是自治和自组织的，负责产品的特定方面。	-- 班组成员的高度自主权和主人翁精神。 -- 快速开发和部署功能。 -- 鼓励创新和创造力。	-- 球队之间可能出现重复工作或冲突。 -- 确保与公司整体战略保持一致可能具有挑战性。
部落	矩阵	-- 小队根据其关注领域或产品领域分为"部落"。 每个部落都有与公司战略目标一致的使命。 部落为部落内的小队提供支持、资源和联盟。	-- 促进小队围绕共同任务进行协调。 -- 允许跨小队共享专业知识和资源。 -- 保持班组和公司整体战略之间的联系。	-- 由于矩阵结构而增加了复杂性。 -- 部落之间潜在的冲突或资源分配挑战。
章节和行会	功能网络	-- 在 Spotify 的组织结构中，"章节"根据职能专业知识或角色对员工进行分组（例如，开发人员、设计师）。 分会作为实践社区，提供技能发展和知识共享的机会。	-- 鼓励特定领域内的技能发展和专业知识。 -- 促进同行学习和知识交流。 -- 为班组成员提供支持和指导。	-- 平衡小队职责和分会/行会活动之间的时间可能具有挑战性。 -- 在参加分会/行会时保持与小队任务的一致性可能需要付出努力。
公会	非正式网络	-- "行会"是跨越小队和部落的非正式网络，将具有共同兴趣或热情的员工联系起来。 行会是自愿性质的，是员工协作、分享想法和探索共同兴趣的论坛。	-- 培养具有共同兴趣的员工之间的社区意识和协作意识。 -- 促进创新和思想的交叉授粉。 -- 提供自下而上的方法来识别改进机会。	-- 公会参与可能需要小队职责之外的额外时间投入。 -- 在参加公会的同时保持与小队任务的一致性可能需要付出努力。 -- 拥有众多行会的大型组织中的协调挑战。

（4）可扩展责任矩阵：RASCI

元素	产品描述	分析	启示	项目范例
负责人 (R)	确定负责该任务的人员或团队。	确定确保任务正确完成的关键人物。	明确角色并消除任务所有权方面的混乱。	在软件开发项目中，开发人员编写新功能的代码。
负责（一）	确定对任务成功负责的人员或角色。	定义最终决策者或签署任务的人。	确保明确的责任并防止与任务相关的瓶颈。	在同一个软件项目中，产品经理负责功能交付。
支持 (S)	表彰为任务提供支持的个人或团队。	确定谁向任务所有者提供资源或帮助。	确保有必要的资源来完成任务。	质量保证团队支持软件项目的测试阶段。
咨询 (C)	确定需要咨询意见或专业知识的个人或角色。	确定在任务期间需要咨询谁以获得有价值的见解。	避免忽视关键观点并收集相关意见。	在软件项目的设计阶段咨询用户体验设计师。
知情（一）	认识那些需要了解任务进展的人。	确定谁应该了解最新情况但不直接参与。	确保团队内部的透明度和有效沟通。	定期向软件项目的利益相关者提供项目更新。

5、扩展性：流程

（1）通用的流程扩展之道

ITIL流程管理、ITSM服务管理、CI/CD、JAD联合架构设计、6 西格玛、ARB架构评审会。

（2）CMMI软件成熟度模型

CMM是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级：一级为初始级，二级为可重复级，三级为已定义级，四级为已管理级，五级为优化级。

CMM/CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征： (1)初始级(initial)。工作无序，项目进行过程中常放弃当初的计划。管理无章法，缺乏健全的管理制度。开发项目成效不稳定，项目成功主要依靠项目负责人的经验和能力，他一旦离去，工作秩序面目全非。 (2)可重复级(Repeatable)。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。 初步实现标准化，开发工作比较好地按标准实施。 变更依法进行，做到基线化，稳定可跟踪，新项目的计划和管理基于过去的实践经验，具有复现以前成功项目的环境和条件。 (3)已定义级(Defined)。开发过程，包括技术工作和管理工作，均已实现标准化、文档化。建立了完善的培训制度和专家评审制度，全部技术活动和管理活动均可控制，对项目进行中的过程、岗位和职责均有共同的理解 。 (4)已管理级(Managed)。产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。已建立过程数据库。已实现项目产品和过程的控制。可预测过程和产品质量趋势，如预测偏差，及时纠正。 (5)优化级(Optimizing)。可通过采用新技术、新方法，集中精力改进过程。具备防缺陷、识别薄弱环节以及改进的手段。可取得过程有效性的统计数据，并可据此进行分析，从而得出最佳方法。

（3）SMART原则

SMART原则（S=Specific、M=Measurable、A=Attainable、R=Relevant、T=Time-bound）是为了利于员工更加明确高效地工作，更是为了管理者将来对员工实施绩效考核提供了考核目标和考核标准，使考核更加科学化、规范化，更能保证考核的公正、公开与公平。

1. 绩效指标必须是具体的（Specific）
2. 绩效指标必须是可以衡量的（Measurable）
3. 绩效指标必须是可以达到的（Attainable）
4. 绩效指标是要与其他目标具有一定的相关性(Relevant)
5. 绩效指标必须具有明确的截止期限（Time-bound） 无论是制定团队的工作目标还是员工的绩效目标都必须符合上述原则，五个原则缺一不可。

制定的过程也是自身能力不断增长的过程，经理必须和员工一起在不断制定高绩效目标的过程中共同提高绩效能力。

6、扩展实战

三、如何实现高性能的架构

1、性能参数

交易业务：QPS、TPS、响应延时、出错率。 流业务：吞吐量（1GB/s = 8Gbps）、处理窗口、滞后时间。 系统 ：CPU、内存、存储、网络。

响应延时金字塔：

2、高性能流程

（1）容量规划

目标设定：业务指标（UV、PV、交易量），系统目标（CPU、内存、磁盘、网络），应用目标（TPS、QPS、Session、并发数）。

规划方法：容量评估方法（基线、水位）。（在此不展开讨论，后续单独成篇讨论）

实战：压测、监控和预测。

（2）性能测试：负载测试

测试目标：正常运行压力下的响应时间、资源利用率、稳定性。

测试手段：标准（历史为基），环境（QA、准生产、生产），定义（测试案例），执行（自动化），分析（统计），报告（录入），迭代（反复）。

测试核心思想：负载测试是一个长期的过程。

（3）性能测试：压力测试

测试目标：发现系统的拐点（失效点）、远高于正常负载。

测试手段：目标，关键服务（关键服务、负载测试瓶颈），负载（ 大量测试数据），环境（减少差异），监视，执行，分析（录入）。

测试核心思想：关注拐点 ------ 服务行为、响应时间、CPU内存磁盘利用率、线程、SQL、交易失败率。

（4）APM监控

性能监控：（利用普罗米修斯）时序数据，纬度聚合，性能指标，报表告警。

链路监控：全局唯一ID------TraceID、SpanID、DyeID等，出错归因，延时瓶颈。

业务追踪：业务、应用、系统关联、告警去重。

（5）弹性扩缩容

APM监控 + 扩缩容决策引擎（Auto Scale策略） + 资源管理（虚拟机、容器、网络负载、Serverless）。

3、使用缓存

（1）读缓存vs写缓存

通常我们把读缓存成为Cache，写缓存称为Buffer。

什么是写Buffer？比如说每次写100字节的一个IO，我们可以把十个写Buffer合成一个，也就是1k，一次性写进去，这就是写缓存的一个技术实现。 写缓存三大技术：网络缓存、应用缓存、对象缓存。能用网络缓存就用网络缓存解决，不行才用应用缓存，最后才是对象缓存。

什么是读缓存呢？读缓存的技术比写缓存远远复杂的多，也是我们主要他讨论的。

（2）网页缓存

网页缓存：在用户浏览器中缓存的网页数据（Cache-Control），用户打开浏览器不需要访问网站，直接从浏览器读取到缓存打开网页。

（3）CDN缓存（CDN内容分发网络）

CDN缓存：边缘缓存（Edge），CDN根据用户所在的位置，解析到最近的机房的IP地址，访问最近的服务器，提高响应速度。 在CDN节点上做缓存，也是一种缓存的实现方式。

（4）应用缓存

在反向代理服务器可以存储静态文件缓存，比如说html静态页面。

（5）对象缓存

使用本地对象缓存+缓存服务器缓存（redis等）。

4、使用异步

使用异步，可以： 减少等待：磁盘、SQL、API、URL； Y轴扩展：微服务解耦、Y轴扩展更随意； 削峰填谷：泊松分布、排队等待。

5、使用分布式系统

X轴扩展：吞吐能力和QPS明显提升； Y轴扩展：出错率明显降低； Z轴扩展：延时降低、TPS/QPS明显提升。

6、高性能的代价

（1）成本代价

使用缓存：需要搭建CDN、多机房、额外的内存消耗等等，提高了大量的成本。 使用异步、分布式：需要额外拆分新的服务，使用新的中间件，增加了系统的复杂性，提高了开发成本、维护成本、服务器成本。

（2）降低成本：使用队列

在CND之前实现流量排队： 在应用之前实现流量排队： 在应用内部实现流量排队： 在应用内部实现流量排队的玩法就非常多了，可以基于楼桶算法和令牌桶算法（基于Redis或者其他手段），来实现流量排队。

（3）降低成本：熔断降级

将不重要的功能暂停，以全力应对关键业务。

四、如何实现高可用的架构

1、本地高可用

（1）CAP理论

CAP理论，指的是在一个分布式系统中，Consistency(一致性)、Availability(可用性)、Partition Tolerance(分区容错性)，不能同时成立。

虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。如果我们选择了 CA 而放弃了 P，那么当发生分区现象时，为了保证 C，系统需要禁止写入，当有写入请求时，系统返回 error（例如，当前系统不允许写入），这又和 A 冲突了，因为 A 要求返回 no error 和 no timeout。因此，分布式系统理论上不可能选择 CA 架构，只能选择 CP 或者 AP 架构。

对于多数大型互联网应用的场景，主机众多、部署分散，分区容忍性是基本要求，否则就失去了价值，而且现在的集群规模越来越大，所以节点故障、网络故障是常态，而且要保证服务可用性达到N个9，即保证P和A，舍弃C（退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流程的严重程度。

对于涉及到金钱财务这样的不能有一丝让步的场景，C必须保证。网络发生故障宁可停止服务，这是保证CA，舍弃P。 还有一种是保证CP，舍弃A。例如网络故障是只读不写。所以说到底如何权衡CAP，没有定论，只能根据场景定夺，适合的才是最好的。

（2）集群架构（CA）

应用集群：Unix（PowerHA）、Linux（RedHat Cluster Suite）、第三方（Veritas Cluster Server） 中间件集群：WebLogic、WebSphere 数据集群：Oracle RAC、DB2 pureScale、General Parallel File System、磁盘RAID阵列

（3）分布式架构（AP）

分布式应用、分布式中间件、分布式数据库。

需要解决一致性、脑裂、雪崩、击穿等问题。

（详细内容后续再谈）

（4）影响高可用真正的因素

之前有这样一个报告，企业内的系统对外发生的短暂不可用，其中百分之85的原因是人为造成的，比如说维修、升级等等。计划外的非天然事件，虽然只占了百分之15，但是影响面却非常大，其中又分为三种场景，其中硬件故障很难避免，但是流程或人为错误和软件错误，占了很大的一部分，所以，我们真正做高可用，主要是为了避免这两种情况造成的系统不可用。

（5）数据逻辑保护

第一道防线：预防。经常做数据备份、快照数据，应用与系统架构需要非常演进，N与N-1版本共存，彻底的变更审核。 第二道防线：发现。全自动的系统监控，全自动的脚本，检测应用于系统的正常、异常行为。 第三道防线：修复。应用与系统的回滚，一键恢复、自动恢复、快速数据恢复。

2、异地容灾

（1）同城多活

用户所有的业务系统同时在同城的两个数据中心运行，同时为用户提供服务，当某个数据中心的应用系统出现问题时，有另一个数据中心的应用来持续的提供服务。好处是服务能力是双倍的，且对用户来说不可感知。

（2）网络双活

将同一个网络扩展到多个数据中心，并且实现服务器和应用的虚拟化数据中心互联技术：随着高可用远程集群技术以及虚拟机迁移技术在数据中心容灾以及计算资源调配方面的广泛应用，在数据中心间需要大二层网络连接。（比如说移动+联通双活）

（3）存储双活

是一种独特的存储技术，使信息能在数据中心内部以及数据中心之间共享、存取或移动，从而将各种不同的存储系统联合成为单一资源。它允许位于地理上分离站点的存储系统同时进行数据存取，对客户透明，且保证了数据可靠性和可用性。

（4）异地双活

异地之间采用双活目前不够现实。因为尚无很好的技术能够实现远距离的实时数据同步。当两个站点距离超过100公里以上，数据同步只能采用数据异步的存储数据复制的方式。

（5）数据库双活

指两个数据库系统可以在相隔比较远的情况下同时运行、支持相同的应用负载，并且在一方出现故障时能够迅速切换到另一方（分钟级），保证业务高可用。

技术路线选择：SAN网络层容灾。优势是数据一致性通过SAN层数据复制功能保证、适用于异构存储环境、多平台存储汇聚资源池统一管理、不占用主机资源及性能、对上层应用及数据库透明、远程异步FCIP。但是缺陷是可能是新的故障节点、可能产生性能瓶颈。（小型项目用）

技术选择路线：存储层容灾。数据一致性由存储控制器数据复制机保证、不占用主机资源及性能、对上层应用及数据库透明。

两地三中心：

（6）应用双活

在应用处理层面上实现了完全冗余，交易通过负载均衡自动路由到不同的应用服务器，但是，应用层面上还是依赖在某一个数据库。

（7）容灾规划：DRP

（8）容灾演练

纸上谈兵：核查性测试（看文档）、结构化的排练（读文档）。 大事化小：模拟测试（非生产）、并行测试（生产）。 搞大了：全中断测试（切换和回切）。

（9）BCP文档和流程

DRP：BCP的绝对主体。 其他专题：本地高可用、数据逻辑保护、系统安全运营。 非技术性：人员、沟通、财务、损失估算。

（10）高可用流程

SRE文化、混沌工程、监控、错误预算、业务高可用评估、系统高可用评估。

五、如何实现高安全性的架构

1、流程安全性

（1）安全基本原则

可用性（Avaliability）、完整性（Integrity）、机密性（Confidentiality）。

（2）安全框架

Zachman、P2DR、Sabsa、IPDRR、IATF。

自适应安全、网络韧性、COBIT、NIST、ITIL、六西格玛。

（3）安全评估方法

安全测试：SAST静态测试、IAST交互式测试、安全扫描。 威胁模型：攻击树分析、DREAD风险评估。 渗透测试：红蓝对抗、白帽黑帽。

2、架构安全性

（1）物理安全

人员安全（保安）、访问控制（锁、墙）、入侵检测（摄像头、看门狗）。

（2）数据安全

访问权限：责任分层、最小特权。 数据加密：对称秘钥、非对称秘钥、数字签名。 数据保护：数据逻辑保护、数据高可用。

（3）通信安全

网络攻击：DDoS拒绝服务、DNS劫持、重放攻击、ARP地址解析欺骗。 网络防御：WAF应用防火墙、IDS/IPS入侵检测和防御、VPN/IPSEC安全通道加密、PGP邮件加密、TLS HTTP隧道加密。

（4）身份安全

Authentication认证：目录管理、用户认证。 Authorization授权：MAC、RBAC、OAuth第三方授权。 Audit审计：审计管理控制、审计技术控制。

（5）软件安全

操作系统安全：病毒、蠕虫、特洛伊木马、零日攻击、补丁。 数据库安全：防止SQL注入、防止推理攻击。 Web应用安全：防止XSS跨站点脚本攻击、防止重放攻击。

3、安全性实现方案

AES对称加密、PKI基础架构、JWT签名、WAF应用防火墙、IDS入侵检测、RBAC访问控制、SAML安全断言、SQL注入预防、XSS跨站点攻击防治。

六、如何实现伸缩性架构

1、伸缩性的主要场景：电商的秒杀和抢购

热点业务：支付、下单、添加购物车、商品详情页、搜索。 热点数据：秒杀产品、动态数据、静态数据。 思路：时间与空间转化、系统伸缩性、缓存预热。

2、微服务伸缩

基础设施（云平台或者虚拟机）、系统资源（容器）、网络引流（人才）。

3、无状态应用弹性伸缩

（1）无服务器化：Serverless

应用无状态； 常见编程方式为函数式编程、响应式编程； 常见业务模式：事件驱动、流驱动； 从0资源 ->无穷大。

（2）Serverless实现方式

观察（CPU等资源）、决策、执行（资源扩展）。

（3）Kubernetes弹性伸缩

HPA：水平Pod扩展（根据应用负载等，自动添加pod） cronHPA：定时Pod扩展（指定时间添加pod） Autoscaler：调度云平台API，实现快速增加节点。

（4）Istio+Knative（弹性伸缩容解决方案）

4、有状态应用弹性伸缩

将有状态应用进行区分：共享磁盘模式和Share Nothing模式。 共享磁盘模式 ->变成无状态应用。 Share Nothing模式 ->采用合适的集群管理方式和CAP目标。

（1）共享磁盘模式：向无状态应用转移

结构化数据 ->考虑共享数据库。 非结构化数据 -> 考虑共享缓存、对象存储、搜索引擎等。 减少文件系统依赖（如CDN直接对接对象存储等）。

（2）Share Nothing架构

CAP - 优化可用性和分区性，弱化一致性。 集群管理 - 优化枚举、仲裁、阶段提交、副本、分片管理。 资源预配置。