系统架构设计师

• 架构模式是开发一个软件系统时的基本设计决策

• 惯用法是最低层的模式

• 决策支持系统 DSS

  • 支持而不是代替用户决策
  • 解决半结构化或非结构化问题
  • 提高决策的有效性而不是效率

• 专家系统 ES

  • 知识库存储领域知识，综合数据库存储中间结果状态等
  • 推理机就是规则解释器，解释器是面向用户的

• EAI 企业应用集成

  • 4个层次的服务，由高到低：流程控制服务、应用链接服务、信息传递与转化服务、通讯服务
  • 技术架构层次，由高到低：会聚集成、应用集成、数据集成、网络集成

• 系统移植

  • 计划阶段：确定移植方案

• 逆向工程：凡是在软件生命周期内将软件某种形式的描述转换为更抽象形式的活动

• 再工程：在逆向的基础上，修改或重构系统

• 系统改进：不基于逆向，对于现有的改进

• 可修改性包含：可维护性、可扩展性、结构重构

• 软件系统工具

  • 软件开发工具：需求分析工具、设计工具、编码工具与排错工具
  • 软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工具、再工程工具
  • 软件管理与支持工具：项目管理工具、配置管理工具

• 过程能力成熟度模型

  • 二级需要6个关键过程域

• 能力成熟度模型（CMM）专门用于指导软件过程该进的模型

• 处理流程设计

  • 程序流程图（PFD）：描述程序的控制流程
  • N-S盒图：强结构化特征的流程图
  • IPO图：输入处理输出图，可以采用流程图、判定树、判定表
  • 问题分析图PAD：包含顺序、选择、循环等5种基本控制结构，允许递归使用

• 电子政务

  • 政府对政府 GTG
  • 政府对公务员 GTE
  • 政府对企业 GTB
  • 政府对公民 GTC

• IPv6

  • 头部比IPv4简单
  • 寻址方式分为单播地址、组播地址、泛播地址
  • 地址长度128bit

• RAID 5阵列：对于n块不同容量的硬盘，总容量 = (n - 1) * min(n)

• 网络架构数据流图的内容范畴：服务器、客户端及其物理位置‘处理器说明；传输协议

RUP统一过程

• 特点：用例驱动、以架构为中心、迭代和增量
• 9个核心工作流：业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境

项目

• 项目范围的定义包括项目章程、项目范围管理计划、组织过程资产和批准的变更申请
  • 项目范围定义为生产项目计划提供了前提和依据
• 需求变更的流程：问题分析和变更描述、变更分析和成本计算、变更实现
• 配置文档分为两类：
  • 属于产品组成部分的工作成果：需求文档、设计文档等
  • 项目管理和机构支撑过程域产生的
• 配置项的状态：草稿、评审或审批、正式发布

组织信息化

• 战略需求：提升组织竞争力
• 运作需求：实现信息化战略的需求、运营策略的需求、人才培养的需求
• 技术需求

构件

• 基于构建的软件开发模型包括：需求分析定义、体系结构设计、构件库建立应用软件构建、测试和发布
• 构件的组装：顺序组装（按顺序调用）、层次组装（调用接口需要兼容）、叠加组装（合并新构件，整合功能）；
• 构件组装可能的3种不兼容：
  • 参数不兼容
  • 操作不兼容
  • 操作不完备
• 可部署性是指构建必须自包含，可在构件平台独立运行
• 构件包含了一组需要同时部署的原子构件
  • 大多数原子构件都能被单独部署
  • 原子构件通常只属于一个构件家族
  • 一个模块可以看作带有单独资源的原子构件
• CORBA构件模型
  • 可移植对象适配器：在底层传输平台与接收调用并返回结果的对象之间进行协调
  • 伺服对象：最终完成客户请求的服务对象
• 面向构件编程COP所需要的基本支持包括：多态性、模块封装、后期绑定和装载、安全性

测试

• 软件测试阶段：

  • 单元测试：依据【详细设计】，模块内功能、性能
    • 白盒测试：路径覆盖 > 条件/判定覆盖 > 语句覆盖
    • 黑盒测试：等价类划分、边界值分析、判定表（多个复杂逻辑条件下）、因果图
    • 灰盒测试：全都要
  • 集成测试：依据【概要设计】，模块间的接口
  • 系统测试：依据【需求文档】，功能测试、性能测试、验收测试、压力测试、可靠性测试、安装测试、安全测试等
  • 确认测试：依据【需求文档】，验证软件与需求的一致性。内部确认测试、Alpha测试、Beta测试、验收测试

• 回归测试：变更是否引入新的错误

• 测试

  • 负载测试：各种工作模式下
  • 压力测试：超负荷
  • 强度测试：在极限下运行
  • 容量测试：最大用户数

• 集成测试的依据：软件概要设计文档`

• 真实程序、核心程序、小型基准程序、合成基准程序

• 软件维护类型：

  • 正确性维护（修复bug）
  • 适应性维护（使软件适应环境）
  • 完善性维护（额外新需求和改进）
  • 预防性维护（防止被淘汰）

• 产品配置项：被配置管理的文档、代码、测试用例

• 四控三管一协调

  • 四控：进度控制、质量控制、投资控制、变更控制
  • 三管：合同管理、信息管理、安全管理
  • 一协调：协调业主、施工方及其它相关单位的关系

• SDN网络架构：应用层、控制层、数据转发层

架构（Architecture Description Language，ADL）

• 软件架构为软甲系统提供了一个结构、行为和属性的高级抽象
• 架构风格是特定领域的惯用模式，定义了一个词汇表和一组约束
• 架构风格：
  • 数据流风格（管道过滤器）：分阶段做数据处理，交互性差
  • 调用/返回风格（主子程序、面向对象、层次结构）：分层越多性能越差
  • 独立构件风格（进程通信、事件驱动<隐式调用>）：构件是独立的过程，连接件是消息传递
  • 虚拟机风格（解释器、基于规则的系统）：灵活自定义
  • 仓库以数据为中心的风格（数据库系统、黑板系统<语言处理 信号处理>、超文本系统）
• ADL(Architecture Description Language) 架构描述语言是用于精确描述软件系统架构的重要工具
  • 构件：计算数据存储单元
  • 连接件：用于构件间交互建模的规则
  • 架构配置：描述体系结构的构件与连接件的连接图
• DSSA（Domain-Specific Software Architecture，领域专用软件架构）
  • 基本活动：领域分析（建立领域模型）、领域设计（获得DSSA）、领域实现（开发和组织可复用信息）
  • 角色：领域专家、领域分析人员、领域设计人员、领域实现人员
  • 开发基础架构：参考模型、参考需求、参考架构
• ABSD（Architecture-Based Software Design）基于架构的软件设计是一种架构驱动方法
  • 强调由业务、质量和功能需求的组合驱动架构设计
  • 强调用视角与视图来描述软件架构；用用例与质量属性来描述需求；
  • 需求来自：系统的质量目标、系统的商业目标、系统开发人员的商业目标
  • 3个基础：功能的分解，选择架构风格，软件模板的使用
  • 开发过程：
    • 架构需求（需求获取、生成类图、打包成/标识构件、需求评审）
    • 架构设计（提出架构模型、产生架构、设计评审）
    • 架构文档化（从使用者角度编写）
    • 架构复审
    • 架构实现（构件实现、构件组装、系统测试）
    • 架构演化（需求变化归类、架构演化计划、构件变动、更新构件相互作用、构件组装和测试、技术评审）
  • 架构评审
    • 基于软件系统的生命周期，可以将质量属性分为开发期和运行期
    • 场景：从风险承担者的角度
      • 刺激源：生成刺激的实体
      • 刺激：
      • 环境：刺激在哪些条件下发生
      • 介质：受刺激的对象
      • 响应：激励到达后的行为
      • 响应度量：对响应以某种方式进行度量
    • 4类质量属性
      • 性能（响应时间、吞吐量）：优先级队列、资源调度
      • 可用性（故障间隔时间、故障修复时间）：冗余、心跳
      • 安全性：追踪审计
      • 可修改性：信息隐藏<开发时隐藏模块内部细节>
    • 风险点（潜在的隐患）、敏感点（为实现某质量属性，一个或多个构件所具有的特性）、权衡点（影响多个质量属性）
    • SAAM:
    • ATAM 架构权衡分析法 效用树 一种软件架构评估方法
      • 4大阶段：场景和需求收集、结构视图场景实现、属性模型构造和分析、折中
      • 在系统开发之前，要对质量属性进行评价和折中
    • 基于度量的评估方法
      • 质量属性和度量之间的映射
      • 从软件架构文档获得度量信息
      • 推导出质量属性
• 结构化分析：面向数据
  • 数据流图
  • 数据字典
• 面向对象的
  • 分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；
  • 设计模型则包含
    • 以包图表示的软件体系结构图
    • 以交互图（包括顺序图和协作图）表示的用例实现图
    • 完整精确的类图
    • 针对复杂对象的状态图
    • 描述流程化处理过程的活动图；
• 基于体系结构的软件设计方法
  • 采用视角和视图来描述软件架构

UML

• 时序图：强调时间顺序，描述系统中事件的发生顺序，展示交互的时间线，帮助理解系统时间维度的行为
  • 元素：对象（系统中特定职责和行为的实体）、生命线（对象存在的时间线）、激活（对象的操作）、消息、交互片段
  • 消息类型：同步、异步、返回
• 协作图：展示对象的结构关系，描述对象组织结构及如何协作通信和交互
• 状态图：用来描述对象状态和事件之间的关系，强调一个实体基于事件反应的动态行为
• 活动图：强调行为活动的顺序和条件控制，着重表现系统的行为，一个活动结束后立即进入下一个活动，而状态图可能需要事件的触发
• 表示分支的片段：可选片段、条件片段 其它：并行片段、循环片段、中断片段
• 用例之间的关系：包含、扩展、继承
• 类之间的关系：关联、聚合、组合、依赖、泛化、实现

MVC

• Model：模型是应用程序用于处理数据逻辑的地方，从数据库存取数据
• View：视图是根据数据模型创建、负责展示
• Controller：控制器是负责处理用户交互的地方。从视图读取用户输入，并向模型发送数据。
• J2EE架构：JSP（视图）；Servlet（控制器）；Entity/Session Bean（模型）

SOA

• 面向服务的架构：粗颗粒度、松耦合、标准化、整体的服务尽可能放在一起、水平分层
  • UUDI（服务注册）：是web服务集成的一个体系框架，包含了服务描述与发现的标准规范
  • WSDL（描述服务）：服务描述语言，服务做什么/如何访问/位于何处
  • SOAP（连接服务）：XML协议，在分布式环境中交换信息
• BPEL (Business process execution language) 将分散功能单一的web服务组织成一个复杂的有及应用
• 具体实现方案有 Webservice 与 ESB（企业服务总线）
• ESB：充当了服务之间通信的角色，位置透明、消息路由、服务注册命名、消息交换、多传输协议、日志与监控
• 服务网格技术（Service Mesh）与企业服务总线（ESB）的差异
  • 实现原理：Mesh是轻量级的基础设施层; ESB是重量级的中间件；
  • 作用：Mesh是剥离并确保微服务间的通信、安全、监控和治理；ESB是通过消息路由、转换和管理实现服务的集成；
  • 治理能力：Mesh实现熔断、限流、监控等；ESB采用的调用接口；
  • 调用方式：Mesh是透明的分布式代理；ESB服务数量众多、通信复杂且需要高可靠性的云应用

风格

• 面向对象风格：通过编写新的规则实现代码，并通过热启动或热加载添加规则，可修改性稍差；通过策略模式定义规则一程序逻辑实现规则，灵活性差；规则在编译后运行性能好；
• 解释器风格：核心是解释，通过辨析新的规则文件并导入配置添加规则，可修改性好；支持灵活定义规则表达式；需要加载规则、解析规则、运算，性能较差
• 管道过滤器风格：具有高内聚、低耦合、支持软件复用、扩展性好、支持并发；数据驱动机制，处理流程事先确定； 【缺】编写复杂，不适合处理交互应用
• 隐式调用：基于事件触发的思想，支持成勇、改进系统方便等有点； 【缺】有构件放弃了对系统计算的控制，事件传递中数据交换存在问题；语义依赖于被触发事件的上下文
• C2：构件和连接件都有一个顶部和底部、

微服务：细粒度、尽可能拆分、组件小、轻量级的通讯

• 微服务是一种架构风格，将大的单体应用拆分为一组小的服务
• 优势：
  • 解决臃肿复杂问题，更好的团队协作
  • 不限技术栈
  • 独立部署快速迭代
  • 高伸缩性
• 挑战：并非所有系统都是和微服务；服务众多部署结构复杂；服务间通过接口通信带来性能问题；分布式微服务数据一致性问题
• 如何确保微服务间的数据一致性和服务高可用性？
  • 分布式事务：使用两阶段提交2pc或者3pc等分布式事务方案，确保数据一致性，但会带来额外性能开销；
  • 最终一致性：通过消息队列等方式，异步更新数据，在一段时间后达成一致性
  • 服务熔断与降级：当服务的调用失败率达到一定阈值，自动熔断，防止失败进一步扩散。同时实施降级策略，在资源不足或系统负载过高时，提供简化的服务响应
  • 服务注册与发现：使用服务注册中心来管理服务
  • 数据复制与缓存：目的提高数据的可用性和访问速度。如数据库使用主从复制，并使用redis缓存来减少数据库的访问压力
  • API网关提高安全性和可维护性
• RESTful:
  • 提供标准的通信方式，使得微服务间可以基于http通信，简化服务间的集成
  • 所有事物抽象为资源，使用统一的资源标识，是服务间的交互更加直观易于理解
  • 基于http协议，支持无状态通信，支持缓存
  • 易于扩展和使用，通用性强
• gRPC：基于http/2，使用protobuf作为接口定义语言，性能好，支持度不足，易用性不足
• MDA(Model Driven Architecture)是模型驱动架构，是一个软件开发框架
  • 计算无关模型：专注于环境及需求 用例图
  • 平台无关模型：专注于系统内部细节不涉及平台 鲁棒图
  • 平台相关模型：状态图、类图、序列图、数据表模式等
• 负载均衡技术
  • 应用层：http重定向 、反代理服务器
  • 传输层：DNS、NAT
  • 硬件：F5
  • 软件负载均衡：nginx、LVS、HAproxy

数据库

• 数据库设计

  • 需求分析阶段应完成包括数据流图和数据字典在内的文档
  • 概念设计阶段：E-R图，描述实体、属性和实体之间的联系
  • 逻辑设计阶段：关系模式，定义关系数据库中的表结构
  • 物理设计阶段
  • 数据库实施
  • 数据库运行与维护

• 关系型数据库

  • 主从数据库
    • 主库写操作，从库读操作
    • 主从复制的步骤：主库更新完成前，将操作写binlog日志文件，从库连接主库加载操作日志，从库执行日志事件，实现与主库一致
  • 反规范化
    • 技术手段
      • 冗余列：在多个表中增加相同的常用列，避免连接操作
      • 派生列：把可以由表中其余列计算得到的列作为固定列插入表中，检查查询时的计算量
      • 重新组表：如果许多用户需要查看两个表连接出的数据，则把两个表重组为一个表
      • 分割表: 水平分割，用于表数据过大，分割存储；垂直分割，案列分割
    • 优点：连接操作少，检索快，统计快；缺点：数据冗余、插入更新删除开销大、数据不一致
    • 数据不一致问题解决：
      • 批处理：定时运行批处理程序，但实时不高
      • 应用程序处理：在程序的事务逻辑中对设计的所有表进行更新，容易遗漏
      • 触发器：对数据的任何修改立即出发某些列的相应更改，实时性好也易于维护
      • 物化视图：非绝对实时，通过定期刷新保持数据一致，类似批处理
  • 视图的优点：简化用户操作、使用户以不同的方式查询统一数据、对机密数据提供安全保护、对数据库重构提供一定的逻辑独立性
  • 分区和分表
    • 共性：都针对数据表，分布式存储、提升查询效率、降低数据库压力
    • 差异：分区逻辑上还是一张表，分表就是多张表
    • 分区的优势：存储更多数据；数据管理更方便；精准定位分区查询不需要全表扫描；可跨多分区查询来提高查询的吞吐量；
  • Mysql和Elasticsearch差异
    • 索引原理：mysql基于sql查询引擎; ES基于lucene的搜索引擎
    • 索引机制：mysql是B+树等； ES是分词、建立倒排索引；
    • 数据模型：mysql是关系模型； ES面向文档为主的灵活的数据模型；
    • 高可用模式：mysql默认是单机模式，需额外配置主从等高可用模式; ES内置集群功能，默认支持分布和高可用模式；
    • 适用场景：mysql小规模数据的在线事务处理和查询; ES适合大规模数据的全文检索、实时数据分析、日志分析等；
  • ES中的分词原理
    • ES的分词原理是将输入的文本字符串切分成独立的token，以便于在索引和查询时进行有效的匹配。分词通常包括字符过滤（去除标点符号等），词汇切分、归一化（转换为小写）
    • 为实现自定义分词器以满足特定业务需求，可以通过ES的插件机制或配置自定义分析器（字符过滤器、分词器、词汇过滤器）来实现。
  • Mysql到ES的数据同步方法
    • 基于binlog的数据同步，常用如Canal等，灵活性高，可以精确控制需要同步的数据
    • mysql插件
    • 同步双写法：在mysql数据修改时，同时写入ES
    • 异步双写法：。。。，修改操作写入消息中间件
    • 定时任务法：批量

• NoSQL

  • 与关系型数据库对比：特定应用领域；海量数据存储；非结构化数据/二维表结构化数据；高并发/支持但性能有限；弱事务性；向外扩展<增加节点数量>/向上扩展<升级服务器配置>；
  • 分类:
    • KV（Redis，内容缓存，处理高负载访问）：
    • 列存储（Hbase，分布式文件系统）
    • 文档型（MongoDb，与KV类似，value是结构化的）：数据要求不严格，表结构可变，不需要像关系型数据库一样预定义表结构
    • 图形数据库（Neo4J，关系图谱）
  • 与MySql混用时的数据一致性解决方案
    • 实时同步方式：查询时先读缓存，查不到再读数据库，并将结果保存到缓存；更新时，利用事务的特性，先更新数据库，成功后再设置缓存
    • 在缓存中设置标识数据库有无变化的控制位
    • 异步的方式：采用消息中间件
    • 使用专门的数据同步工具，如mysql日志同步工具canal等
  • MongoDB: 将非结构数据以文档的形式存储。通过GeoJson存储空间矢量数据；
    • 分布式文件系统和空间索引，提高了矢量数据存储和处理效率
    • 支持多种空间分析和查询操作，方便数据分析和挖掘
    • 扩展性好，可根据业务需求灵活增加字段
  • Redis
    • 与MemCache比较：丰富的数据结构/简单的KV结构、支持持久化、多种方式的分布式存储/哈希分片、有限支持事务、数据容灾
    • 分布式方案
      • 主从模式：一主多从，故障时手动切换、读写分离 【缺】容错性差，数据一致性问题、在线扩容困难
      • 哨兵模式：有哨兵的一主多从，自动故障转移，监控与通知、简化运维 【却】部署复杂，网络通信频繁、在线扩容困难
      • 集群模式：无中心架构，可用性好、伸缩性好、运维成本低 【缺】配置复杂、数据一致性差、实现复杂
    • 分布式锁：
      • 基于数据库实现：【优势】实现简单、无需额外以来、适用范围管、持久性；【劣势】单点问题，挂掉会导致系统不可用；无失效时间，操作失败会导致锁一直存在
      • 基于Redis: 基于内存性能更好；分布式容错性更好；也会出现死锁可能；
    • 持久化方案：
      • RDB (redis DB) 间隔将内存中的书快照存入磁盘；磁盘更新频率较低；间隔存储，数据可能不一致；重启性能更高；文件更小；
      • AOF (append only fle) 将redis每条命令都追加进文件；保证数据不会丢失，更安全；即使服务器宕机，也可以回复；
    • 定期删除+惰性删除策略：失效：都不完全精确，是中可能存在已过期未删除的key； 内存已满；
    • 内存淘汰机制：
      • 针对已设置过期时间的key/针对所有key采用LRU（最近较少使用）算法
      • LFU(最不经常使用)
      • 随机淘汰

• 分布式数据库中透明的概念

  • 分片透明：指用户不必关注数据是如何分片的
  • 复制透明：。。。
  • 位置透明：指用户不必知道操作的数据的位置
  • 逻辑透明（局部映像透明）：最低层次的透明，该透明提供数据到局部数据库的映像，用户不必关心局部使用哪种数据模型

• 软件复用

  • 机会复用：开发过程中，只要发现可复用资产，就对其进行复用
  • 系统服用：开发前规划已决定哪些需要复用
  • 复用的3个基本过程：构造/获取可复用的软件资产、管理这些资产、从资产中选择可复用的部分
  • 重复使用的软件元素包括：需求分析文档、设计文档、程序代码、测试用例、领域知识

• WPDRRC 信息安全模型

  • 6个环节及能力：预警、保护、检测、响应、恢复、反击
  • 3大要素：人员、策略和技术

• 区块链

  • 4大基础技术支柱：分布式存储、共识机制、智能合约、密码学
  • 关键支撑技术：区块结构（基本数据单元）、P2P网络（去中心化的网络架构）、默克尔树（唯一根哈希，验证数据完整性）

• 存储

  • 内置存储，不通过网络进行连接和管理
  • DAS(直接附加存储)，通过SCSI接口直接连接到服务器
  • SAN(存储区域网络)：专用高速网络连接存储设别，不占贷款
  • NAS（网络附加存储）：以太网接口连接，非专用网络，连接到局域网，占据带宽

嵌入式：

• 工业级器件的工作温度：-40~85℃
• 嵌入式数据库分类：基于内存、基于文件、基于网络
• 大数据：5V 大规模 高速度 多样化 价值密度低 真实性
  • Lambda vs Kappa
    • 复杂度和维护成本：Lambda需要维护两套系统，复杂度高，开发和维护成本搞；Kappa只有一套；
    • 计算开销：Lambda需要一直运行批处理和实时计算，计算开销大；Kappa必要时进行全量计算，开销相对较小；
    • 实时性：满足实时性
    • 使用场景：Lambda支持批处理，更适合对历史数据分析查询的场景，期望尽快得到分析结果，批处理可以直接高效的实现；Kappa不是Lambda的替代架构，而是简化，放弃对批处理的支持，更擅长业务本身为增量数据写入场景的分析需求；
    • 选择依据：根据业务需求、技术要求、系统复杂度、开发成本维护和历史数据处理能力作为依据，计算开销相差不大，不做考虑
  • Lambda
    • 优点：
      • 容错性好：为大数据系统提供了更友好的容错能力，一旦发生错误，可以修复算法或重启试图
      • 灵活度高：批处理层允许针对任何数据进行临时查询
      • 伸缩性：批处理层、加速层、服务层都很容易扩展，是完全分布式的系统
      • 易扩展：秩序给主数据集添加新的函数，就能添加试图
    • 缺点：全场景覆盖带来的编码开销；针对具体场景重新训练一边益处不大；重新部署和迁移成本很高
  • Hadoop主要工作在离线批处理模式下，实时数据处理能力不足；Lambda则能同时处理离线和实时数据
• AI芯片的关键特征：新型计算范式、训练和推断、大数据处理能力、数据精度（降低精度的设计）、可重构的能力、开发工具（软件工具链）
• 数字孪生
  • 3项核心技术：建模、仿真、基于数据融合的数字线程
  • 底层伴生技术：物联网
  • 外围使能技术：云计算、机器学习、大数据、区块链
  • 生态系统：
    • 行业应用层：智能制造、智慧城市
    • 共性应用层：描述、诊断、预测、决策
    • 模型构建和仿真分析曾
    • 数据互动层
    • 基础支撑层：具体设备
• 容器化技术
  • 环境一致性:容器化技术能够将维服务及其所有依赖打包成一个独立运行的单元，可以再不同的平台和系统上运行，并保证一致性；
  • 隔离性：每个微服务都被封装在自己的容器中，实现了资源的隔离，避免冲突；
  • 敏捷性：快速部署和启动
  • 伸缩性：可以根据需求自动扩展或所见容器实例，有效应对峰值流量
  • 减少运维成本
• 企业集成：数据集成、汇聚集成、服务集成、应用集成、界面集成
  • 面向过程的集成强调处理不同系统之间的交互逻辑与核心业务相分离
  • 企业应用集成EAI
• 哈希算法是通过某种算法把输入变化为定长的哈希值；一致性哈希是一种特殊的哈希，可扩展性更好，更好适应数据快速增长；

云原生

• 云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、安全、可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点；
• 主要架构模式：
  • 服务化架构模式：典型模式是微服务和小服务，把代码模块关系和部署关系分离，每个接口都可以有不同数量的实例，单独扩缩容。
  • Mesh化架构模式：把中间件SDK与业务代码进一步解耦，分离后的业务进程中只保留很“薄”、很少变化的的Client层，只负责与Mesh进程通信，原来需要在SDK中处理的流量控制、安全等逻辑由Mesh完成；
  • 存储计算分离模式。在云环境中推荐把各类暂态数据（如session）、结构化和非结构化持久数据都采用云服务来保存，实现存储计算分离。
  • 可观测模式：通过监控、日志、追踪等手段，获取和分析系统运行状态的能力。
  • Serviceless模式：将部署相关的全部委托给云
  • 事件驱动架构
• 架构原则：
  • 服务化原则：拆分为微服务和小服务，分别迭代
  • 弹性原则：系统规模可以随业务量自动伸缩
  • 可观测原则：通过日志、链路跟踪和度量等手段，是的一次点击背后的多次服务调用耗时、返回等
  • 韧性原则：出现异常时的抵御能力
  • 过程自动化原则：标准化企业内部的软件交付流程，同时实现自动化交付、运维自动化
  • 零信任原则：不信任网络内任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础，以身份为中心
  • 架构持续演进原则：具备架构持续演进的能力

加密

• 加密算法
  • 对称加密算法：RC-5
  • 非对称加密算法：RSA、ECC
• 哈希算法：md-5
• 国产密码算法：
  • SM1 对称加密 128bit 电子政务、商务等
  • SM2 非对称加密
  • SM3 杂凑算法 256bit 数字签名
  • SM4 对称加密 无线局域网
  • SM9 标识密码算法 互联网新兴应用，不需要申请数字整书

设计模式

• 适配器模式：解决接口不兼容问题
• 迭代器模式：提供一种顺序访问聚合对象中各个元素的方法，遍历
• 访问者模式：在不改变元素类的前提下，定义这些元素的新操作
• 观察者模式：通知更新