四 软件架构风格、质量属性、Web架构设计

目录

一、软件架构的概念 

1.1概念

1.2 软件架构模型

二、软件架构风格 

2.1 分类（传统分类）数调独虚仓

2.2 数据流风格

2.3 调用/返回风格

2.4 独立构件风格

2.5 虚拟机风格。

2.6 仓库风格

三、五类架构以外的架构

3.1 闭环控制架构（过程控制）

3.2 C2风格

3.3 混合架构

3.4 MVC架构风格

3.5 基于服务的架构 SOA

3.6 微服务

四、特定领域软件架构 

五、 基于架构的软件开发 

六、架构描述语言ADL 

七、软件质量属性 

八、软件架构评估 

十、构件与中间件技术 

十一、J2EE 分布式多层应用程序

十二、Web架构设计 

---

一、软件架构的概念 

1.1概念

体系结构=架构。

架构设计就是需求分配，即将满足需求的职责分配到组件。

软件架构放在需求分析之后，架构设计之前。

架构风格为软件系统提供结构、行为、属性的高级抽象。

软件架构是项目干系人员进行交流的手段。

软件架构使推理和控制更加简单，有助于循序渐进的原型设计，可以作为培训的基础。

软件架构是可传递和可复用的模型，通过研究软件架构可能预测软件的质量。

软件架构风格是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一类架构所共有的结构和语义特性，主要包括架构定义、架构词汇表和架构约束。

1.2 软件架构模型

结构模型（构件、连接件、其他概念刻画结构）

框架模型（更注重整体）

动态模型（系统大颗粒行为性质）

过程模型（步骤和过程）

功能模型（功能构建层次组成）

4+1模型（架构发展到高级阶段）

• 逻辑视图:关心功能需求。用户，功能需求。对应UML逻辑视图。
• 开发视图:关心源代码，组件，DLL。编程人员，软件管 理。UML实现视图。
• 进程视图:关心性能，并发。系统集成人员，性能，扩充，吞吐量。UML进程视图。
• 物理视图:软件到硬件的映射。系统工程师，安装部署。UML部署视图。
• 场景:UML用例视图。

对象模型、动态模型、功能模型区别：

对象模型描述了系统的静态结构，一般使用对象图来建模。对象模型是整个体系中最基础，最核心的部分。

动态模型描述了系统的交互次序，一般使用状态图来建模。

功能模型描述了系统的数据变换，一般使用数据流图来建模。

对象模型描述了动态模型和功能模型所操作的数据结构，对象模型中的操作对应于动态模型中事件和功能模型中的函数；

动态模型描述了对象模型的控制结构，告诉我们哪些决策是依赖于对象值，哪些引起对象的变化，并激活功能；

功能模型描述了由对象模型中操作和动态模型中动作所激活的功能，而功能模型作用在对象模型说明的数据上，同时还表示了对对象值的约束。

二、软件架构风格 

2.1 分类（传统分类）数调独虚仓

五类：数据流风格、调用/返回风格、独立构件风格、虚拟机风格、仓库风格。

• 数据流风格包括: 批处理序列，管道-过滤器。
• 调用/返回风格:主程序/子程序，数据抽象，面向对象，层次结构。
• 独立构件风格:进程通信，事件驱动系统（隐式调用）
• 虚拟机风格:解释器，基于规则的系统。强调自定义。
• 仓库风格:数据库系统，超文本系统，黑板系统

口诀：数调独虚仓

1、数 : 批处理序列，管道过滤器。

理解：以数据的方式向前传递，每一步处理都是独立的，顺序执行的，适合线性流程的处理。

2、调:主子数面层。（主程序/子程序、数据抽象、面向对象、层次结构）

理解：主要思想将复杂庞大的系统分解为一系列的子系统，降低系统的复杂性，提高可修改性，明确层次结构，以降低系统耦合度。

3、独:进程通信，事件驱动

理解：增强软件系统的可复用性。

4、虚拟机:解释器，基于规则的系统。

理解：具备良好的灵活性，可定义规则。

5、仓:数据库，超文本系统，黑板。

理解：以数据为中心，善于处理数据信息，适用于大数据的应用系统和复杂的逻辑系统。

2.2 数据流风格

数据处理，较为严格的流程。数据包的处理。没有清晰地说明用户与系统的交互。

• 批处理序列。一堆数据，数据是完整的，以整体方式处理。
• 管道-过滤器。数据流的处理。早期编译器，一步一步处理。

2.3 调用/返回风格

目前最广泛，目前系统都离不开。

• 主程序/子程序。结构式时代。
• 数据抽象。
• 面向对象。对象交互，函数和过程调用。
• 层次结构。

1. 层次结构优点:复杂问题简化。不同层次处于不同的抽象级别。每一层最多影响两层，相邻层提供接口，软件复用。降低耦合。
2. 层次结构缺点:并不是每个系统很容易分层，层次多带来效率低，建议三到五层。

2.4 独立构件风格

• 进程通信。构件独立，连接件是消息传递。
• 事件驱动系统（隐式调用）。牵一发而动全身，构件不直接调用过程，而是触发调用隐式调用其他过程。优点软件复用性提高，构件演化和维护带来方便；缺点构件放弃了对系统计算的控制。例如断点调试，变量值进行刷新。

在基于构件的软件开发中，逻辑构件模型用功能包描述系统的抽象设计，用接口描述每个服务集合，以及功能之间如何交互以满足用户需求，它作为系统的设计蓝图以保证系统提供适当的功能。

物理构件模型用技术设施产品、硬件分布和拓扑结构，以及用于绑定的网络和通信协议描述系统的物理设计，这种架构用于了解系统的性能、吞吐率等许多非功能性属性。

构件和对象对比

构件的特性是:

1. 独立部署单元；
2. 作为第三方的组装单元；
3. 没有（外部的）可见状态。一个构件可以包含多个类元素，但是一个类元素只能属于一个构件。将一个类拆分进行部署通常没什么意义。

对象的特性是：

1.一个实例单元，具有唯一的标志。

2.可能具有状态，此状态外部可见。

3.封装了自己的状态和行为。

2.5 虚拟机风格。

适用自定义的场景。

• 解释器。解释工作的解释引擎。
• 基于规则的系统。规则集，规则解释器，规则/数据选择器，工作内存。一般用于人工智能领域和DSS中。

2.6 仓库风格

以数据库，语法树为中心的风格。仓库风格分两种:中央数据结构，保存系统当前状态。独立构件，对中央数据存储进行操作。现代集成编译环境采用该风格，例如idea。

• 数据库系统。
• 黑板系统。偏向于数据的共享和传递交互，基于先有的数据经验知识，进行问题域定位或解。例如信号（语音）处理，问题规划，编译器优化。
• 超文本系统。

对于采用层次化架构风格的系统，划分的层次越多，系统完成某项功能需要的中间调用操作越多，其性能越差。

对于采用管道-过滤器架构风格的系统，可以通过引入过滤器的数据并发处理可以有效提高系统性能。

对于采用面向对象架构风格的系统，可以通过减少功能调用层次提高系统性能。

对于采用过程调用架构风格的系统，将显式调用策略替换为隐式调用策略能够提高系统的灵活性，但会降低系统的性能。

三、五类架构以外的架构

3.1 闭环控制架构（过程控制）

软件与硬件之间可以粗略的表示一个反馈循环。适用于嵌入式系统，涉及连续的动作与状态。开环控制系统，例如遥控器；闭环控制系统，给定值和当前值（环境值）进行变频调节，到给定值形成闭环，例如空调，还有定速巡航。

3.2 C2风格

并行构件网络，构件和连接件都有一个顶部和底部，构件之间不运行直连，一个连接件可以多连接构件和连接件，两个连接件直连时，必须其中一个是底部，一个是顶部。

3.3 混合架构

演化过程:两层C/S,三层C/S,三层B/S,混合架构，

两层C/S:表示层（客户端业务处理），数据层（数据存取和数据请求）。缺点:升级更新，成本大。

三层C/S:新增一个功能层来处理业务逻辑。手机app。

三层B/S:解决不用安装客户端。表现层（mvc,mvp,mvvm）,中间层，数据访问层（orm,例如mybits），数据架构层（数据库）。

混合架构:外部B/S，内部C/S。

客户机/服务器系统开发时可以采用不同的分布式计算架构：

• 分布式表示架构是将表示层和表示逻辑层迁移到客户机，应用逻辑层、数据处理层和数据层仍保留在服务器上；
• 分布式数据架构是将数据层和数据处理层放置于服务器，应用逻辑层、表示逻辑层和表示层放置于客户机；
• 分布式数据和应用架构是将数据层和数据处理层放置在数据服务器上，应用逻辑层放置在应用服务器上，表示逻辑层和表示层放置在客户机上。

3.4 MVC架构风格

• Model（模型）:处理应用程序数据逻辑的部分。entity bean,session bean。
• View（视图）:处理数据显示部分。jsp。
• Controller（控制器）:处理用户交互部分.servlet。

MVP架构风格：Mvc的变种，实现V和M之间的解藕，更好支持单元测试，界面事件V,业务逻辑P。

MVVM架构风格：view，viewModel, model。两次间交互，不跨层交互。

富互联网应用 RIA：结合c/s和b/s架构结合，简化b/s架构的用户交互，数据能够被缓存到客户端。

3.5 基于服务的架构 SOA

构造多个服务，服务与服务之间采用服务总线ESB（中介者）进行通信。例如webservice。

特点:松散耦合，粗粒度，标准化接口。

粒度排序：对象最低，构件，服务最高。

实现方式:服务提供者，服务请求者（包含服务和服务描述），服务注册中心（服务描述）。

关键技术:

功能                  协议

发现服务           UDDI,DISCO

描述服务           WSDL,XML Schema

消息格式层         SOAP,REST

编码格式层         XML

传输协议层         HTTP,TCP/IP,SMTP

• UDDI（Universal Description，Discovery＆Integration），UDDI用于Web服务注册和服务查找；
• WSDL（Web Service Description Language），WSDL用于描述Web服务的接口和操作功能；
• SOAP（Simple Object Access Protocol），SOAP为建立Web服务和服务请求之间的通信提供支持。
• BPEL（Business Process Execution Language For Web S ）多个单一web服务组装成有机应用。

企业服务总线 ESB

功能：服务位置透明性，传输协议转换，消息格式转换，消息路由，安全性，监控与管理。

• 总线提供一个服务，支持其他服务使用来进行数据转换，多种消息传递，动态路由。
• 支持多种传输协议和数据格式。
• 提供位置透明性消息路由和寻址，
• 提供服务注册和命名规范管理功能，
• 提供日志和监控功能。

3.6 微服务

单一程序划分为一组小的服务，松散耦合独立部署，服务之间相互协调、相互配合。服务与服务之间采用轻量级的通信机制相互沟通，通常基于http协议的RESTful API。

优势:技术异构性，弹性，扩展，简化部署（前提实现自动化部署），与组织结构相匹配，可组织性，可替代性的优化强。

挑战:分布式系统的复杂性，运维成本，部署自动化，服务间依赖测试，服务间依赖管理。

3.7 MDA 模型驱动架构

使用模型完成代码的分析，设计，构建，部署，维护等开发活动。模型推动开发，模型映射能自动生成代码。

目标:可移植性，互通性，可重用性。

3种核心模型:

• 平台独立模型（PIM）:高层次，独立于任何实现技术的模型。
• 平台相关模型（PSM）:通过实现构造来描述系统模型，PIM会被转换成一个或多个PSM。
• 代码code:每个PSM都可以转换成代码。

PIM经过变换工具到PSM,再经过变换工具到code。

四、特定领域软件架构 

特定领域软件架构 DSSA

某个领域行业的开发，同一类系统行业的共性进行分析形成特定领域架构。即行业解决方案。

基本活动:

• 领域模型:建立领域模型。
• 领域设计:获得DSSA。
• 领域实现:开发和组织可复用信息。

逐步求精的过程。

领域分析机制

• 领域专家:有经验的用户，软件工程师，即相当于有该领域的知识的顾问。主要任务提供领域中系统需求规范和实现的知识。给建议，知识层面提供者。
• 领域分析人员:领域分析，组织到领域模型，产生模型。系统分析员。
• 领域设计人员:进行设计，开发出DSSA,软件设计人员。
• 领域实现人员:产生基础架构，程序开发。

领域软件架构建立过程:定义领域范围，领域特定元素，特定设计和实现需求约束，领域模型和架构，生产搜集可复用产品单元。

DSSA三层模型

• 领域开发环境。核心部分开发共性，领域架构师。
• 领域特定的应用开发环境。利用共性根据客户需求个性化调整，应用工程师。
• 应用执行环境。操作员。

五、 基于架构的软件开发 

基于架构的软件设计ABSD

Adsb能很好的支持软件的复用

ADSB方法是架构驱动，强调业务，质量，功能需求组合驱动架构设计。

ABSD以架构风格和质童属性为中心，强调由商业、质量和功能需求的组合驱动软件架构设计。ABSD方法有三个基础：功能分解、选择架构风格实现质量及商业需求和软件模板的使用。

设计活动可以从项目总体功能框架明确开始，意味需求获取和分析未完成，就开始了软件设计。

三个基础:功能分解，通过架构风格来实现质量和业务需求，软件模块的使用。

整个过程是递归的。

视角和视图:不同视角有不同的视图。描述软件架构。

用例来捕获功能需求，特定场景来捕获质量需求（可靠性，性能，维护性等）。

用例和质量场景描述需求。

基于架构的软件设计的开发过程。过程有迭代。

步骤:架构需求，架构设计，架构文档化，架构复审，架构实现，架构演化。

• 架构需求。三阶段:需求获取（需求库），标识构件（生成类库，对类分组，类打包成构件），需求评审。多轮迭代。
• 架构设计。其实就是构件框进来，考虑关系。提出架构模型，映射构件，分析构件相互关系，产生构件，设计评审。
• 架构文档化。架构文档化主要输出结果架构规格说明书，测试架构需求的质量设计说明书。文档的完整性和质量是软件架构成功的关键因素。关于文档三大注意事项:从使用者角度编写；必须分发给所有系统有关人员；必须保证开发者手上的文档是最新的。
• 架构复审。架构复审的目的是标识潜在的风险，及早发现架构设计中的缺陷和错误。
• 架构实现。架构复用或者架构实现组装系统测试。
• 架构演化。需求变化归类，架构演化计划，架构变动组装测试，技术评审，最终形成演化后的架构。

六、架构描述语言ADL 

架构的描述语言 ADL

三要素:构件，连接件，架构配置。

例如: aesop,c2,sadl,unicon,wright

七、软件质量属性 

1、性能。性能指系统的响应能力。

代表参数:响应时间、吞吐量。

设计策略:优先级队列，资源调度。增加计算资源、改善资源需求(减少计算复杂度等)、资源管理(并发、数据复制等)和资源调度(先进先出队列、优先级队列等)

2、可用性。正常运行的时间比例。

代表参数:故障间隔时间，多久完成备用切换。

设计策略:冗余（多台灾备等），心跳线（两台服务器心跳监控进行起备用），Ping/Echo、心跳、选举、异常和主动冗余等

3、安全性。合法用户使用服务，阻止非法用户使用服务。

分为机密性，完整性，不可否认性，可控制性。

代表参数:授权。

设计策略:追踪审计（日志等追踪审查）、抵御攻击(授权、认证和限制访问等)、攻击检测(入侵检测等)、从攻击中恢复(部分可用性策略)和信息审计等。

4、可修改性。快速地以较高性价比对系统进行变更修改的能力。

代表参数:多久完成新增或修改。功能性的修改。

主要策略:信息隐藏，设计高内聚低耦合，接口实现分离。软件模块泛化、限制模块之间通信、使用中介和延迟绑定等。

5、可靠性。

软件系统在应用或系统方面，意外情况或错误使用下维持功能的基本能力。主要考虑容错，健壮性。

代表参数:MTTF,MTBF。

设计策略:冗余，心跳线。

可靠性决定可用性。

6、功能性。完成所期望的工作能力。

7、可变性。框架，整个平台变迁。体系结构扩展或变更成为新体系结构能力。

8、互操作性。程序和其他软件系统的交互作用。

9、易用性。界面一致，方便使用。

八、软件架构评估 

为什么要进行架构评估?

架构到底评估什么?

架构评估怎么评?

• 风险点:系统架构风险是指架构设计中潜在，存在问题的架构决策所带来的隐患。业务逻辑不清楚等带来风险。
• 敏感点:为了实现某种特定的质量属性，一个或多个架构存在具有的特性。例如:调整某个属性，对其结果影响较大。单个纬度。
• 权衡点:影响多个质量属性的特性，是多个质量属性的敏感点。一个平衡的过程。例如:安全和性能两个冲突时，提高安全时，降低性能效率；验证码等。多个纬度。
• 非风险点。什么是可接受的。

架构评估方法:基于问卷（检查表）的方法，基于度量的方式（指标打分，根据标准打分，偏向理论），基于场景的方式。

基于场景的评估方法（架构进行评估）

• 软件架构分析法 SAAM。最初用来分析架构的克修改性，后扩展到其他质量属性。多个架构进行对比分析。
• 架构权衡分析法 ATAM。主要关注系统的需求说明。在SAAM基础发展而来，主要针对性能，实用性（可用性），安全性和可修改性，在系统开发之前，对这些质量参数进行评价和折中。第一阶段:场景和需求收集。收集场景，需求，约束，环境。第二阶段:架构视图和场景实现。描述架构视图和实现场景。第三阶段:属性模型构造和分析。特定属性分析（优秀单一理论）第四阶段:折中。标志折中、敏感度。

ATAM被分为四个主要的活动领域（或阶段） ，分别是场景和需求收集、体系结构视图和场景实现、属性模型构造和分析中。

SAAM分析评估体系结构的过程包括五个步骤，即场景开发、体系结构描述、单个场景评估、场景交互和总体评估。SAAM的主要输入问题是问题描述、需求声明和体系结构描述。

• 成本效益分析法 CBAM

九、软件产品线

DDSA特定领域架构演化而来。软件工程，软件架构，领域过程，DSSA组合形成软件产品线。适合做行业级系统开发。

• 软件产品线的过程模型，双生命周期模型。系统工程和应用工程。领域工程坐共性，应用工程做个性化，两个的阶段互相连结起来。
• 软件产品线的方式。基于现有产品，全新产品线，演化方式，革命方式，四种方式组合。基于现有产品的演化方式:稳；全新产品线的革命方式:高风险。
• 软件产品线的组织结构。组织结构类型:设立独立的核心资源小组，不设立独立的核心资源小组，动态的组织结构。

要成功实施产品线，主要取决的因素:

• 对该领域具备长期和深厚的经验。
• 一个用于构建产品的好的核心资源库。
• 好的产品线架构
• 好的管理（软件资源，人员组织，过程）支持

十、构件与中间件技术 

中间件是构件的一种。

软件构件是一种组装单元，具备规范的接口规范和显式的语境依赖。软件构件可以独立不是并由第三方任意组装。

构件的特性:独立部署单元，作为第三方组装单元，没有外部的可见状态。

对象的特性:一个实例单元，具有唯一标识，具有状态（外部可见），封装了自己的状态和行为。

模块的特性:结构化开发的产物。比如过程和函数。

颗粒度从上到下三个一次变小。

构件的复用。过程:检索与提取构件，理解和评估构件，修改构件，组装构件。

中间件: 一种独立的系统软件或者服务程序，可以帮助分布式应用软件在不同的技术之间共享资源。

优点:提高开发效率。

• 面向需求。设计师集中精力于业务逻辑。
• 业务的分割和包容性。
• 设计与实现隔离。
• 隔离复杂的系统资源。
• 符合标准的交互模型。
• 软件复用。
• 提供对应构件的管理。

中间件技术-corba（公共对象请求代理体系结构）

客户端（对象引用）--逻辑连接（代理）-- 服务端（corba对象）

• 伺服对象（Servant）:corba对象真正实现的东西，负责完成客户端请求。
• 对象适配器（object adapter）:用于屏蔽orb（对象请求代理）内核的实现细节，为服务器对象实现者提供抽象接口，以便使用orb内部功能。
• 对象请求代理（object request broker）:解释调用并负责查找实现该请求的对象，参数给到找到的对象并且返回结果。客户方不需要了解服务对象的位置，通信方式，实现，激活或存储机制。

Corba包含的主要内容:

对象请求代理，对象服务，公共设施，应用接口，领域接口。

十一、J2EE 分布式多层应用程序

EJB对应spring中的模型（M）。

Bean运行在EJB容器之中，分为三类:

• 会话bean sessionBean:描述客户端的一个会话。
• 实体bean entityBean:持久化数据，o/r映射。
• 消息驱动bean:会话bean+JMS,客户把消息发送给jms目的地，jms提供者和ejb容器协作，把消息发送给消息驱动bean。支持异步消息。

J2EE核心组成:

容器:applet container,application container,web container,ejb container

组件:applet,application,jsp/servlet,ejb

服务:http,jdbc,jms,jndi,jaxp

浏览器 Applet ->web服务 servlet ->EJB容器（ sessionBean->entityBean ）->DB

EJB分为会话Bean、实体Bean和消息驱动Bean。
1.会话Bean：用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当客户端请求时，容器就会选择一个会话Bean来为客户端服务。会话Bean可以直接访问数据库，但更多时候，它会通过实体Bean实现数据访问。 客户端与服务端交互。
2.实体Bean：用于实现O/R映射，负责将数据库中的表记录映射为内存中的实体对象，事实上，创建一个实体Bean对象相当于新建一条记录，删除一个实体Bean会同时从数据库中删除对应记录，修改一个实体Bean时，容器会自动将实体Bean的状态和数据库同步。数据持久化简化数据库端开发。
3.消息驱动Bean是EJB3.0中引入的新的企业Bean，它基于JMS消息，只能接收客户端发送的JMS消息然后处理。MDB实际上是一个异步的无状态会话Bean，客户端调用MDB后无需等待，立刻返回，MDB将异步处理客户请求。这适合于需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个方法调用直到返回结果。处理并发和异步操作。

十二、Web架构设计 

从架构来看:mvc,mvp,mvvn,rest,webservice,微服务，中台。

从缓存来看:memcache,redis,squid。

从并发分流来看:集群（负载均衡），cdn。

从数据库来看:主从库，内数据库，反规范化技术，noSQL，分区分表，视图和物化视图。

持久层来看:hibernate,mybits。

分布存储来看:hadoop,fastdfs,区块链。

数据编码来看:json,xml。

Web应用服务器来看:apache,webservice,weblogic,tomat,jboss,iis。

其他:静态化，有无状态，响应式web设计。

负载均衡技术

• 基于特定软件的负载均衡（http重定向）（应用层）。实现简单，但是性能较差。
• 反向代理负载均衡（应用层）。部署简单，但是代理服务器可能成为性能的瓶颈。请求转到代理进行分发。
• 基于dns的负载均衡（传输层）。效率比http重定向高，减少维护负载均衡服务器成本。但是一个应用服务器故障，nds管理修改，有生效时间（dns有缓存）。网站无法做更多的改善和更强大的管理。
• 基于nat的负载均衡（传输层）。地址端口映射的机制，将对个n外部ip映射为多个ip地址。技术较为成熟，一般在网关位置，可以通过硬件实现。比如四层交换机。
• 混合型负载均衡

算法支撑:

• 静态算法:轮转，加权轮转，换地址哈西散列，目标地址哈西散列，随机算法。
• 动态算法（考虑负载的性能）:最小连接数算法，加权最小连接数，加权百分比算法。

软硬件代表:

• 硬件负载均衡: F5。
• 软件负载均衡:nginx,lvs,haproxy。

应用服务器集群

负载均衡:用户的请求转发到具体的应用服务器。

如何保持用户每次访问服务端都一致，维护session一致性问题?

1.携带session的cookie。session服务器暂存数据，cookie存在客户端本地的信息。

2.redis缓存。session存在redis。

3.服务器之间同步cookie。

有无状态服务

无状态服务:单词请求处理，不依赖其他服务。

有状态服务:自身保存一些数据，先后的请求有关联。

数据库读写分离

主从策略。主库（一个）写，从库（多个）度，主从进行同步。

缓存缓解数据库压力。(IO层面优化，硬盘的效率瓶颈)

数据库数据存在在磁盘，效率低。缓存存到内存，并且存入的是结果 KV。

Redis和Memcached比较。reids范围更广，支持数据持久化，可灾难恢复，Memcached不支持，不可恢复。Memcached只是单纯的kv存储。

Redis常见问题

• 缓存雪崩。大部分缓存失效，数据库奔溃。解决方案:缓存高可用，缓存降级，redis备份，提前演练,设置不同的过期时间。
• 缓存击穿。查询无数据返回，直接查询数据库。解决方法:设置缓存空或者默认值，设置布隆过滤器。
• 缓存穿透。缓存宕机。

zset 是一种采用数据分数来排序的结构，完美当排名用的 数据库和redis数据同步的常见方案有两种

1. 被动同步：通常应用程序会在读取数据前检查缓存是否有，如果没有则加载数据库并写入缓存，可以在修改时删除缓存让读取时去数据库获取(有不同步问题，可以通过延迟双删解决)

2. 主动同步：启动个额外服务去读取数据库binlog文件，通过解析binlog文件来确定数据库发生了什么样的更改从而去更新redis

CDN（内容分发网络）:最近距离请求。从本地站点先请求，就进请求服务。例如京东仓库。

Xml和JSON 扩展标记语言

Xml优点:

• 格式统一，符合标准。
• 容易与其他系统进行远程交互，数据共享比较方便。

缺点:

• 文件庞大，文件格式复杂，传输占宽带。
• 花费大量代码解析，标签过多，烦杂。
• 解析格式可能不一样。
• 解析花费较多时间和资源。

JSON优点:

• 格式简单，容易读写，格式是压缩的，占用宽带小。
• 容易解析支持多种语言。
• 可以直接作为服务端代码使用，简化服务端和客户端开发，易于维护。

缺点:

没xml格式深入人心和推广，没有xml通用性广。（不见得吧）

Web应用服务器

Web服务器:智能单一，浏览器请求，返回html页面。

应用服务器:进行业务逻辑的处理。

rest 表述性状态传递。获取网络资源的标准形式。

5个原则:

• 网络上的所有事物都被抽象为资源。
• 每个资源对应一个唯一的资源标识。
• 通过通用的连接件接口对资源进行操作。
• 对资源的各种操作不会改变资源的标识。
• 所有操作都是无状态的。

响应式web设计

根据不同布局，智能根据用户行为以及适用的设备环境进行相对应的布局。

方法和策略:

• 采用流式布局
• 弹性化设计。使用相对单位，设定百分比而非数值。
• 响应式图片。不仅要同比缩放图片，还要在小设备上降低图片自身分辨率。
• 媒体查询

中台

一套结合互联网技术和行业特性，共享服务形式沉淀，形成大中台，小前台的组织和业务机制。中台可进行优化。分为业务中台和数据中台。