系统架构案例分析具体知识点，涉及架构风格、软件架构评估、系统设计建模、设计模式、数据存储、系统安全、高并发、敏捷开发、微服务等等

数据流风格：包含批处理序列和管道-过滤器，其每一步处理都是独立的顺序执行的，适用于简单的线性流程；
调用/返回风格：包括主程序/子程序风格、面向对象风格、层次结构风格，其进一步降低系统耦合度，明确系统层次；
独立构件风格：包括进程通信、事件驱动系统（隐式调用），其构件特点为软件复用提供了支持；
虚拟机风格：包括解释器、基于规则的系统风格，其具有良好灵活性，可自定义规则；
仓库风格：包括数据库系统风格、超文本系统风格、黑板系统风格，其以数据为中心。

除了这些架构风格，近几年面向服务架构、微服务架构在各大中型项目中得到广泛应用。

面向服务架构中每一个功能都能通过服务来提供，服务定义了明确的可调用接口，服务之间的编排调用完成一个完整的业务，具有松耦合粗粒度的好处；

微服务是对面向服务的升华，强调按照领域进行拆分应用，拆分后的应用可以敏捷开发和部署。微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。

【其他扩展风格】

C2风格：可以概括为通过连接件绑定在一起按照一组规则运作的并行构件网络。
客户/服务器风格

即C/S风格，二层结构风格

三层C/S结构风格

瘦客户端方式，三层C/S结构风格将应用功能分成表示层、功能层、和数据层三个部分

B/S风格

相比于CS风格，BS有以下优点：

1、系统安装、修改和维护升级全在服务端解决        
2、开发简单、共享性强、扩展简单方便
3、分布性强，客户端零维护

不足之处：

1、BS安全性较难以控制
2、用户体验比cs差些
3、速度比cs慢
4、处理能力相较于cs单一

MVC架构风格

定义：

MVC架构风格：用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。

MVC架构将整个软件系统划分成模型、视图、控制器3个部分。

模型应用程序的主题部分。模型表示业务数据和业务逻辑。负责维护并保存具有持久性的业务数据，实现业务处理功能，并将业务数据的变化情况及时通知视图；

视图用户看到并与之交互的界面。负责呈现模型中包含的业务数据，响应模型变化通知，更新呈现形式，并向控制器传递用户的界面动作；

控制器 接受用户的输入并调用模型和视图去完成用户的请求。负责将用户的界面动作映射为模型中的业务处理功能，并实际调用之，然后根据模型返回的业务处理结果选择新的视图。

web应用架构设计

详见：web应用架构设计

软件架构评估

质量属性

系统架构质量属性

非功能性需求

系统架构非功能性需求

质量属性与非功能性需求的关系与区别

非功能性需求通常被看做是能力，主要跟服务质量有关，也就是一个软件的质量属性

风险点、敏感点、平衡点

概念定义

风险点：架构设计中潜在的、存在问题的架构决策带来的隐患，从而影响系统的某种质量属性
非风险点：在一个范围内，可接受的影响某种质量属性
敏感点：为了实现某种特定的质量属性，一个或多个组件所具有的特性
权衡点：影响多个质量属性的特性，是多个质量属性的敏感点

软件可靠性设计

系统的可靠性是系统在规定时间内及规定的环境条件下，完成规定功能的能力，也就是系统无故障运行的概率。为了保证系统的可靠性，需要对系统进行可靠性设计与管理。

提高软件可靠性一般采用以下3类技术：

(1) 容错技术
(2) 检错技术
(3) 降低复杂度设计

软件容错技术主要有：恢复块、N版本程序设计、冗余设计

系统设计建模

DFD

数据流图参考

数据流图

DFD：数据流图，是一种图形化的系统模型，在一张图中展示信息系统的数据流向，即系统的输入与输出数据分别是什么，数据从哪里去并最终到哪里去，以及数据存储在什么地方。

基本图形元素

外部实体：定义位于项目范围之外，但与正在被研发的系统有交互关系的人、部门、外部系统或组织。
数据流：运动中的数据，表示到一个过程的数据输入，或者来自一个过程的数据输出。
加工：在输入数据流或条件上执行，或者对输入数据流或条件做出响应的工作。
数据存储：静止的数据，表示系统中需要保存的数据。

需求分析阶段，为了获得读新系统的框架认识、概念性认识，需要对新系统建模。

如何画数据流程图

确定系统的输入与输出
由外向里画系统的顶层数据流图
自顶向下逐层分解，绘出分层数据流图

UML

UML通过图形化的表示机制从多个侧面对系统的分析和设计模型机型刻画。

UML共定义了9种视图，并分为如下4类:

用例图：从外部用户的角度描述系统的功能并指出功能的执行者，强调这个系统是什么，而不是怎么工作
静态图：类图、对象图、包图。
- 类图描述了系统的静态结构；
- 对象图是类图的一个实例；
- 包图描述系统的分解结构
行为图：交互图、状态图、活动图。它们从不同的侧面刻画系统的动态行为；
- 交互图描述对象之间的消息传递；
- 状态图描述类的对象的动态行为，包含对象的所有可能的状态及事件；
- 活动图描述系统为完成某项功能而执行的操作序列，包含信息流和控制流
实现图：构件图、部署图。描述软件实现系统的组成和分布状况。
- 构件图描述软件实现系统中各组成部件及它们之间的依赖关系；
- 部署图描述作为软件系统运行环境的硬件及网络的物理体系结构。

交互图还可以细化为顺序图和合作图

参考：https://www.jianshu.com/p/0786d8f9a037

UML9大视图关系

用例图：告诉我们系统是什么
类图：静态的，告诉我们产生什么影响，但不知道什么时候
对象图：是类图的具体实例图
包图：为了简单的表示出类图，把类组合成包packages
交互图：动态的，描述了对象间的交互，常用的顺序图，对象、消息、生命线组成，横向轴代表在协作中的类对象，纵轴是时间轴
状态图：描述了对象或场景的状态及相应行为，比如登录有初始、登录、成功、失败等状态
活动图：活动图更像是多个活动对象流程交互图，活动图也可以理解成泳道图
构件图：是类图的物理实现
部署图：运行环境的硬件及网络的物理体系结构

活动图与状态图的关系

状态图主要用于描述一个对象在其生存期间的动态行为，表现一个对象所经历的状态序列，引起状态转移的事件（event），以及因状态转移而伴随的动作（action）。

活动图可以用于描述系统的工作流程和并发行为。活动图其实可看作状态图的特殊形式，活动图中一个活动结束后将立即进入下一个活动（在状态图中状态的转移可能需要事件的触发）。

两者最大的区别是：状态图侧重于描述行为的结果，而活动图侧重描述行为的动作。其次活动图可描述并发行为，而状态图不能。

用例之间的关系

用例：

用例是对一个活动者使用系统的一项功能时所进行的交互过程的一个文字描述序列。

用例是系统、子系统或类和外部的参与者交互的动作序列的说明，包括可选的动作序列和会出现异常的动作序列。

一般采用动宾结构或主谓结构命名

比如：取款机使用、验证账号

注：个人通俗的理解为场景，软件工程里常说用例场景

一个用例图是角色、用例、和他们之间的联系的集合。

用例之间的关系：

泛化：代表一般和特殊的关系，子用例继承了父用例的行为与含义，泛化关系使用空心三角形箭头的实线表示，箭头指向父用例
包含：两个用例之间的关系，其中一个用例的行为包含了另一个用例的行为，包含是比较特殊的依赖关系，取款机使用包含验证账户用例。使用带箭头的虚线表示，箭头指向包含用例，同时<<include>>附加在虚线上
扩展：基本含义与泛化类似。但在扩展关系中，对于扩展用例有更多的规则限制。使用带箭头的虚线表示，箭头指向基本用例，同时<<extend>>标记在虚线上

类及类之间的关系

概念

类：是具有相似结构、行为、关系的一组对象的抽象。

使用三个格子的长方形表示：类名、属性、操作

类之间的关系

依赖：两个元素，修改元素A导致元素B的修改。虚线+实心三角形表示
关联：表示两种类的实例间的关系。用两个类之间的连线表示。
聚合：一种特殊形式的关联。聚合表示类之间整体与部分的关系。用一个带空心菱形的实心连线，空心菱形指向具有整体性质的类。
组合：是一种特殊的聚合，组合关系中的整体与部分具有同样的生存期。可以约等于聚合+依赖关系。实心菱形+实心连线表示。
泛化：定义了一般和特殊元素之间的关系，也就是OOP中所说的类与类之间的继承关系。用空心三角形的实心连线表示泛化关系，三角形指向具有父类性质的类。
实现：接口与类之间的关系

注：除了依赖是虚线表示，其他都是实线；空心菱形是聚合，实心菱形是组合，空心三角形是泛化；依赖是实心三角形+虚线；

类之间的关系示例

类University与类Student之间的关系是：聚合关系。
类University与类Department之间的关系是：组合关系。
类Student与类Course之间的关系是：关联关系。
依赖关系：一个事物发生变化影响另一个事物。
泛化关系：特殊/一般关系。
关联关系：描述了一组链，链是对象之间的连接。
聚合关系：整体与部分生命周期不同。
组合关系：整体与部分生命周期相同。
实现关系：接口与类之间的关系。

UML有哪几种类

1.边界类，描述外部与系统内部交互的类；
2.控制类，控制其他类；
3.实体类，存储信息和相关行为的类；

参考：https://www.cnblogs.com/dandanlovehamhamzo/p/4967980.html

设计模式

设计模式原则

开闭原则：对扩展开放，对修改关闭
单一职责原则：每个类的职责单一
里氏替换原则：任何基类可以出现的地方，子类也可以出现
依赖倒置原则：面向接口/抽象编程，依赖于抽象而不依赖于具体
接口隔离原则：每个接口中不存在子类用不到，却必须实现的方法，如果不然就要拆分接口。不要大综合接口，建议分离。
迪米特法则：也叫最少知道原则，一个类对自己依赖的类知道越少越好，不要去关心被依赖类的复杂度。
合成复用原则：尽量使用聚合/组合的关系，而不是使用继承。

注：开闭、单一里氏、依赖接口、迪米特、合成复用

三大类型

创建型：主要用于创建对象，为设计类实例化新对象提供指南。对应5种设计模式
- Factory Method 工厂方法
- Abstract Factory 抽象工厂
- Builder 建造者
- Prototype 原型
- Singleton 单例
1、工厂方法（FactoryMethod）模式：定义一个用于创建产品的接口，由子类决定生产什么产品。

2、抽象工厂（AbstractFactory）模式：提供一个创建产品族的接口，其每个子类可以生产一系列相关的产品。

3、建造者（Builder）模式：将一个复杂对象分解成多个相对简单的部分，然后根据不同需要分别创建它们，最后构建成该复杂对象。

4、原型（Prototype）模式：将一个对象作为原型，通过对其进行复制而克隆出多个和原型类似的新实例。

5、单例（Singleton）模式：某个类只能生成一个实例，该类提供了一个全局访问点供外部获取该实例，其扩展是有限多例模式。
结构型：主要用于处理类或对象的组合，对类如何设计形成更大的结构提供指南。对应7种设计模式
- Proxy 代理模式
- Adapter 适配模式
- Bridge 桥接模式
- Decorator 装饰模式
- Facade 外观模式
- Flyweight 享元模式
- Composite 组合模式
1.代理（Proxy）模式：为某对象提供一种代理以控制对该对象的访问。即客户端通过代理间接地访问该对象，从而限制、增强或修改该对象的一些特性。

2.适配器（Adapter）模式：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。

3.桥接（Bridge）模式：将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现的，从而降低了抽象和实现这两个可变维度的耦合度。

4.装饰（Decorator）模式：动态地给对象增加一些职责，即增加其额外的功能。

5.外观（Facade）模式：为多个复杂的子系统提供一个一致的接口，使这些子系统更加容易被访问。

6.享元（Flyweight）模式：运用共享技术来有效地支持大量细粒度对象的复用。

7.组合（Composite）模式：将对象组合成树状层次结构，使用户对单个对象和组合对象具有一致的访问性。
行为型：主要用于描述类或对象的交互及职责的分配，并对类之间的交互及职责分配的方式提供指南
- Template Method 模板方法模式
- Strategy 策略模式
- Command 命令模式
- Chain of Responsibility 责任链模式
- State 状态模式
- Observer 观察者模式
- Mediator 中介者模式
- Iterator 迭代子模式
- Vistor 访问者模式
- Memento 备忘录模式
- Interpreter 解释器模式
1.模板方法（Template Method）模式：定义一个操作中的算法骨架，将算法的一些步骤延迟到子类中，使得子类在可以不改变该算法结构的情况下重定义该算法的某些特定步骤。

2.策略（Strategy）模式：定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的改变不会影响使用算法的客户。

3.命令（Command）模式：将一个请求封装为一个对象，使发出请求的责任和执行请求的责任分割开。

4.职责链（Chain of Responsibility）模式：把请求从链中的一个对象传到下一个对象，直到请求被响应为止。通过这种方式去除对象之间的耦合。

5.状态（State）模式：允许一个对象在其内部状态发生改变时改变其行为能力。

6.观察者（Observer）模式：多个对象间存在一对多关系，当一个对象发生改变时，把这种改变通知给其他多个对象，从而影响其他对象的行为。

7.中介者（Mediator）模式：定义一个中介对象来简化原有对象之间的交互关系，降低系统中对象间的耦合度，使原有对象之间不必相互了解。

8.迭代器（Iterator）模式：提供一种方法来顺序访问聚合对象中的一系列数据，而不暴露聚合对象的内部表示。

9.访问者（Visitor）模式：在不改变集合元素的前提下，为一个集合中的每个元素提供多种访问方式，即每个元素有多个访问者对象访问。

10.备忘录（Memento）模式：在不破坏封装性的前提下，获取并保存一个对象的内部状态，以便以后恢复它。

11.解释器（Interpreter）模式：提供如何定义语言的文法，以及对语言句子的解释方法，即解释器。

常用具体模式

工厂方法：
抽象工厂：DB案例

工厂模式分抽象工厂与工厂方法，题目中的场景适合采用抽象工厂设计模式。

抽象工厂设计模式提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类。其优点是可以非常方便的创建一系列的对象，其使用场景也是创建系列对象的情况。在本题中，可以针对Oracle、MySQL、SQLServer分别建立抽象工厂，若指定当前工厂为Oracle工厂，则创建出来的数据库连接，数据集等一系列的对象都是符合Oracle操作要求的。这样便于数据库之间的切换。
单例模式：懒汉与饿汉模式，详见：11-单例模式
适配器

适配器模式（Adapter）的定义如下：将一个类的接口转换成客户希望的另外一个接口，使得原本由于接口不兼容而不能一起工作的那些类能一起工作。

解决方案：增加一个类作为适配器，转换类的接口到客户端类期望的另一个接口。实现一个适配器类，这个类为系统的其他部分提供了一个不变的方法供调用，为了集成不同商品供应商提供的税率计算类，编写一个适配器类的子类，包含调用购买类所需的代码。该子类将系统的调用映射到某个供应商的税率计算类。如果要更换供应商，那么只需要写一个新的适配器子类，其他保持不变。

该模式的主要优点如下。客户端通过适配器可以透明地调用目标接口。复用了现存的类，程序员不需要修改原有代码而重用现有的适配者类。将目标类和适配者类解耦，解决了目标类和适配者类接口不一致的问题。

其缺点是：对类适配器来说，更换适配器的实现过程比较复杂。
桥接

优点：

（1）分离抽象接口及其实现部分。

（2）桥接模式有时类似于多继承方案，但是多继承方案违背了类的单一职责原则（即一个类只有一个变化的原因），复用性比较差，而且多继承结构中类的个数非常庞大，桥接模式是比多继承方案更好的解决方法。

（3）桥接模式提高了系统的可扩充性，在两个变化维度中任意扩展一个维度，都不需要修改原有系统。

（4）实现细节对客户透明，可以对用户隐藏实现细节。
策略方法

在具有公共接口的独立类中定义每个计算。可以利用该模式创建各种促销类，它们从同一个超类继承。每个类都有相同名称的标准接口方法，用于根据订单编号计算将要折扣的金额总数。
模板方法

该模式的主要优点如下:

它封装了不变部分，扩展可变部分。它把认为是不变部分的算法封装到父类中实现，而把可变部分算法由子类继承实现，便于子类继续扩展。

它在父类中提取了公共的部分代码，便于代码复用。部分方法是由子类实现的，因此子类可以通过扩展方式增加相应的功能，符合开闭原则。

该模式的主要缺点如下: 对每个不同的实现都需要定义一个子类，这会导致类的个数增加，系统更加庞大，设计也更加抽象。

父类中的抽象方法由子类实现，子类执行的结果会影响父类的结果，这导致一种反向的控制结构，它提高了代码阅读的难度。

详见：

23种设计模式全解析

概要设计模式

数据存储

文件系统、关系数据库、内存数据库对比

文件系统-关系数据库-内存数据库比较

数据库设计

范式

第一范式：每一列（属性）不可再分割（列具有原子性）
第二范式：满足1nf，且属性完全依赖于主键（不产生不依赖于主键的冗余列）
第三范式：满足2nf，且属性不传递（间接）依赖于主键（可拆分列去冗余）

范式的缺点

虽然范式为数据库节省了存储空间，但范式越高，表数量越多，关联查询越多，性能越低

反范式

反范式也就是意味着，可以不满足3nf及更高的范式，不满足2nf，但一定会满足1nf

需求>性能>表结构

首先数据库设计要满足功能要求，再满足性能要求，最后才关心表结构（空间相关考虑）

我们可以适当的数据冗余，利用空间来换取时间，将部分数据冗余到其他表中，减少或避免不必要的表关联

反范式缺点

虽然反范式在查询效率上明显提升，但在写入数据时，需要考虑写入相关表数据，而不像范式只要将数据写入一个地方。（牺牲写入效率换取高性能读取）

反范式技术

(1) 增加冗余列：在多个表中保留相同的列，通过增加数据冗余减少或避免查询时的连接操作；

(2) 增加派生列：在表中增加可以由本表或其他表中数据计算生成的列，减少查询时的连接操作并避免计算或使用集合函数；

(3) 表水平分割：根据一列或多列数据的值，把数据放到多个独立的表中，主要用于表数据规模很大、表中数据相对独立或数据需要存放到多个介质上时使用；

(4) 表垂直分割：对表进行分割，将主键与部分列放到一个表中，主键与其他列放到另一个表中，在查询时减少I/O次数。

mysql

主从、优化方案、分区等

数据库主从复制
优化方案详见：数据库与缓存
目前mysql的版本，建议分表，不建议分区，分区带来部分索引及列不能解决的问题

数据库分区

数据分区是一种物理数据库的设计技术，它的目的是为了在特定的SQL操作中减少数据读写的总量以缩减响应时间。

分区并不是生成新的数据表，而是将表的数据均衡分摊到不同的硬盘，系统或是不同服务器存储介子中，实际上还是一张表。另外，分区可以做到将表的数据均衡到不同的地方，提高数据检索的效率，降低数据库的频繁IO压力值，分区的优点如下：

1、相对于单个文件系统或是硬盘，分区可以存储更多的数据；

2、数据管理比较方便，比如要清理或废弃某年的数据，就可以直接删除该日期的分区数据即可；

3、精准定位分区查询数据，不需要全表扫描查询，大大提高数据检索效率；

4、可跨多个分区磁盘查询，来提高查询的吞吐量；

5、在涉及聚合函数查询时，可以很容易进行数据的合并；

采用水平分区机制可根据用户标识将用户数据进行水平分割，用户操作时先将请求分发到不同数据库分区，再进行具体数据库操作，以提高数据库访问效率。

垂直分区方式一般来说是通过对表的垂直划分来减少目标表的宽度，使某些特定的列被划分到特定的分区，每个分区都包含了其中的列所对应的行。

主从复制机制好处

1、避免数据库单点故障：主服务器实时、异步复制数据到从服务器，当主数据库宕机时，可在从数据库中选择一个升级为主服务器，从而防止数据库单点故障。

2、提高读写效率：根据系统数据库访问特点，可以使用主数据库进行数据的插入、删除及更新等写操作，而从数据库则专门用来进行数据査询操作，从而将査询操作分担到不同的从服务器以提高数据库访问效率。

3、数据实时备份，避免意外数据丢失的可能性。

引入主从复制机制的好处

1、提升性能

交易平台要求高并发，主从复制方式一主多从，不同的用户请求可以从不同的从数据库读取数据，提高并发度。

2、可扩展性更优

如果采用单台数据库服务器，则访问量持续增加时，数据库瓶颈暴露，且无法迅速解决问题。而主从结构可以快速增加从服务器数量，以满足需求。

3、提升可用性

一主多从，一台从服务器出现故障不影响整个系统正常工作。

4、相当于负载均衡

一主多从分担任务，相当于负载均衡

5、提升数据安全性

系统中的数据冗余存放多份，不会因为某台机器硬件故障而导致数据丢失。

cache与DB的对比

参考：关系数据库与内存数据库

###　引入缓存后系统访问数据的过程

系统需要读取后台数据时，先检查数据是否存在与缓存中
若存在缓存则直接读取缓存
若不存在则从数据库中读取，并保存到缓存中
当数据库中发生数据库更新时，需要将更新后的内容同步到缓存中

redis相关

集群cluster：相当于web服务的负载均衡器
主从方案：每个redis节点最好都要有一个备用节点，可以随时顶替主节点
切片方案：

参考：Redis-Cluster集群

memcache与redis对比

参考：Redis和Memcache区别，优缺点对比

性能：redis使用单核，memcache使用多核，memcache在性能上略高于redis
存储空间：memcache可以修改最大内存采用LRU算法，但局限于物理内存；redis增加了vm的特性，突破了物理内存的限制
数据结构：memcache数据结构单一，redis支持更多数据结构，也可以在服务端进行复杂的操作
可靠性：memcache不支持持久化，重启后数据丢失；redis支持数据持久化和数据恢复，允许单点故障，但也同时付出性能上的代价；memcache不支持事务，操作过程中可能产生数据的不一致性。
应用场景：都可以在动态系统中减轻数据库负载，提升性能，做缓存适合多读少写；redis更适合对读写效率高，且数据业务处理复杂及对安全性要求较高的系统

从本质上说：memcache是一个单一key-value的内存cache，redis则是一个数据结构内存数据库，支持多种数据结构，单纯缓存作用外，还能做一些简单的逻辑运算，还可以当做数据库使用

redis切片方案

1.客户端切片，即在客户端就通过key的hash值对应到不同的服务器。

2.对数据根据key散列到不同的slot上，不同的slot对应到不同服务器。

增加数据库访问层的原因

（1）由于涉及到多种异构数据库平台，数据访问复杂性增加，不宜与业务逻辑混合在一起

（2）数据管理变复杂之后，需要使用的代码量增加，分单独层次有利于让逻辑更清晰。

（3）业务逻辑应以相同的方式对接异构的数据库，此时需要单独的数据访问层屏蔽差异性。

ORM

概念：

ORM：对象关系映射，用于在关系数据库和业务实体对象之间作一个映射。

从效果上说，它更像是创建了一个可在编程语言里使用的虚拟对象数据库。

说白了就是把关系数据库封装成业务实体对象，这样在具体的操作业务对象的时候，就不需要再去和复杂的sql语句打交道，只需要简单操作对象的属性和方法。

ORM提供了概念性的易于理解的模型化数据的方法。

ORM与JDBC：

jdbc是java操作数据库的规范接口

orm是一种思想，对象关系映射

jdbc：是从底层访问数据库服务器，一般银行、金融行业为安全起见，直接使用jdbc

orm：是对象关系映射，如hibernate，让你以面向对象的方式去编程，封装了jdbc

数据持久层

持久化

即把数据保存到可永久保存的存储设备中。比如将内存中的数据存储到关系数据库中。

持久层

持久层即专注于实现数据持久化应用领域的某个特定系统的一个逻辑层面，将数据使用者和数据实体相关联。

好处：

(1)分离业务逻辑层和数据层，降低两者之间的耦合；

(2) 通过对象/关系映射向业务逻辑提供面向对象的数据访问；

(3) 简化数据层访问，隐藏数据库链接、数据读写命令和事务管理细节。

ORM方式与传统数据库访问方式对比

传统数据库访问方式优点：

性能比ORM更好
可以处理更为复杂的sql语句

传统数据库访问方式缺点：

要开发熟练sql语句
修改与维护相对困难

ORM方式优点：

使用ORM可以大大降低学习及开发成本
大大提供开发效率及减少代码量
降低维护成本的同时，提高了代码质量
业务与数据解耦

ORM方式缺点：

不好处理复杂的sql语句
性能相对原生sql差些

系统安全

安全保障措施

防止重放攻击：挑战/应答认证
传输过程的完整性
数据一致性、不可否认性

安全与加解密

对称加解密与非对称加解密

对称加解密

机密性：发送者利用对称密钥对要发送的数据进行加密，只有拥有正确密钥的接收者才能将数据正确解密，从而提供机密性
完整性：发送者根据要发送的数据生成消息认证码或摘要，利用对称密钥对消息认证码/摘要进行加密并附加到数据上发送（生成摘要-摘要加密-附加到发送数据）；接收者使用相同密钥将对方发送的消息认证码/摘要解密，并根据接收的数据重新生成消息认证码/摘要，比较两个认证码是否相同以验证数据的完整性（摘要解密-重新生成摘要-摘要比对-验证结束）。

非对称加解密

机密性：发送者利用接收者的公钥对要发送的数据进行加密，只有拥有对应私钥的接收者才能将数据正确解密，从而提供机密性。
完整性：发送者根据要发送的数据生成消息认证码/摘要，使用自己的私钥对消息认证码进行加密，并附加到数据上发送；接收者使用发送者的公钥解密消息认证码，并根据接收到数据重新生成消息认证码，比较两个消息认证码以验证数据的完整性

其他

java构建技术

java2概述

jvm->jre->j2se->j2ee->j2me

5大构件

Applet、Servlet/JSP、JavaBean、EJB、客户端构件

EJB构件中的3中Bean

EJB中的Bean分三种类型：Session Bean、Entity Beans 和 Message-Driven Bean。

Session Bean的职责是：维护一个短暂的会话
Entity Beans 的职责是：维护一行持久稳固的数据
Message-Driven Bean的职责是：异步接受消息

相关关键词

RMI、分布式对象模型、CORBA、JMS、JDBC、JTA、JTS、DAO

企业集成架构设计

数据集成

为平台上运行的各种应用、系统或服务，提供具有完整性、一致性、安全性的数据访问、信息查询及决策支持服务。
- 数据关联
- 数据复制
- 基于接口数据集成
应用集成

应用计划才能是指两个或多个应用系统根据业务逻辑的需要而进行的功能之间的相互调用和相互操作。
- 适配器集成模式
- 信使集成模式
- 面板集成模式
- 代理集成模式
企业集成

单层到N层的企业应用软件系统架构
- 前端集成
- 后端集成
- 混合集成

企业集成关键应用技术：

数据交换格式
- EDI
- XML
- STEP
- PDML
- JSON
分布式应用集成基础框架
- CORBA
- COM+ / RPC
- J2EE
- Web Service(XML/UDDI/WSDL/SOAP)

高并发优化

在客户端与web服务之间引入 CDN
在客户端与web服务之间引入 负载均衡器
在web服务与应用层之间引入 异步消息队列
在数据层引入DB扩展机制，如分库、分表、分区、主从复制、索引优化等
在应用层与数据库之间引入 缓存机制

web响应式设计

概念、实现方式

响应式不是自适应

自适应根据设备的不同提供不同的多套用户界面（比如www与m），响应式只有一套用户界面

移动优先：从2014年开始移动设备使用访问率超过pc
渐进增强：通常先实现一个基础版本，在大部分设备满足基本功能后，针对性的兼容添加新功能新特性，再逐步拓展应用
屏幕：响应式就是响应屏幕尺寸

物理尺寸：屏幕对角线，单位英寸逻辑尺寸：相对于物理尺寸，也叫分辨率，单位像素，使用宽x高的方式表示分辨率

与物理像素相对应的CSS像素

响应式实现方案

流动布局+弹性布局
媒体查询

敏捷开发过程

详见：敏捷方法入门

PHP与java的对比

参考：https://www.cnblogs.com/liangxiaofeng/p/5255181.html

SOA