软考高级-系统分析师-案例分析-系统设计
系分-案例分析-系统设计
- 结构化设计SD
-
- 内聚（高内聚低耦合）
- 耦合
- 业务流程建模
-
- IDEF（建模仿真）
- 面向对象的设计OOD
-
- 设计原则
- 设计模式分类
- 人机界面设计
- 架构设计
-
- Zachman 架构框架
- Zachman 架构框架（案例）
- 面向服务的架构SOA
- 微服务
-
- 微服务（案例）
- 多层架构
- 轻量级架构
- MVC
- MVP 与 MVVM
- MDA 模型驱动架构
- 系统设计（web结构）
-
- Web 架构知识点
- 单台机器 到 数据库与 Web 服务器分离
- 应用服务器集群
- 负载均衡
- Redis
-
- Redis与Memcache能力比较
- Redis集群切片的常见方式
- Redis分布式存储方案
- Redis数据分片方案
- Redis数据类型
- Redis持久化
- Redis内存淘汰机制
- Redis常见难题
- 负载均衡技术
- 静态与动态算法
- Session 共享机制
- 有状态与无状态
- 持久化技术 ORM
- CND 内容分发网络
- XML 与 JSON
-
- XML
- JSON
- Web 应用服务器
- REST
- 响应式 Web 设计
- 中台
- 云计算
- 边缘计算
- Web 系统分层
- 物联网架构
- 大数据架构
- 案例 - 系统架构（web）
结构化设计SD
内聚（高内聚低耦合）
模块的内聚类型通常可以分为 7 种，根据内聚度从高到低排序：
| 内聚类型 | 描 述 |
|---|---|
| 功能内聚 | 完成一个单一功能，各个部分协同工作，缺一不可。 |
| 顺序内聚 | 处理元素相关，而且必须顺序执行 |
| 通信内聚 | 所有处理元素集中在一个数据结构的区域上 |
| 过程内聚 | 处理元素相关，而且必须按特定的次序执行 |
| 瞬时内聚 | 所包含的任务必须在同一时间间隔内执行（如初始化模块） |
| 逻辑内聚 | 完成逻辑上的相关的一组任务 |
| 偶然内聚 | 完成一组没有关系或松散关系的任务 |
耦合
模块的耦合类型通常也分为 7 种，根据耦合度从低到高排序
| 耦合类型 | 描 述 |
|---|---|
| 非直接耦合 | 没有直接联系，互相不依赖对方 |
| 数据耦合 | 借助参数表传递简单数据 |
| 标记耦合 | 一个数据结构的一部分借助于模块接口被传递 |
| 控制耦合 | 模块间传递的信息中包含用于控制模块内部逻辑的信息 |
| 外部耦合 | 与软件以外的环境有关 |
| 公共耦合 | 多个模块引用同一个全局数据区 |
| 内容耦合 | 一个模块访问另一个模块的内部数据，一个模块不通过正常入口转到另一模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口 |
业务流程建模
- 标杆瞄准
- IDEF（一系列建模、分析和仿真方法的统称）
- DEMO（组织动态本质建模法）
- Petri网
- 业务流程建模语言
- 基于服务的BPM
IDEF（建模仿真）
列举几个比较常考的
- IDEF0 业务流程（功能）建模
- IDEF1 信息建模
- IDEF1X 数据建模（如ER模型）
- IDEF2 仿真建模设计
- IDEF4 面向对象设计
- IDEF12 组织结构建模
面向对象的设计OOD
面向对象设计的基本过程
设计原则
| 设计原则 | 描述 |
|---|---|
| 单一职责原则 | 设计目的单一的类 |
| 开放-封闭原则 | 对扩展开放，对修改封闭优先使用扩展 |
| 李氏替换原则 | 子类可以替换父类当重写时就不能替换父类 |
| 依赖倒置原则 | 要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程。 |
| 接口隔离原则 | 使用多个专门的接口比使用单一的总接口要好 |
| 组合重用原则 | 要尽量使用组合，而不是继承关系达到重用目的 |
| 迪米特原则（最小知识法则） | 一个对象应当对其他对象有尽可能少的了解。 |
设计模式分类
参考另外一篇文章：
链接: 软考高级-系统分析师-案例分析-系统维护与设计模式
人机界面设计
置于用户控制之下
- 以不强迫用户进入不必要的或不希望的动作的方式来定义交互方式
- 提供灵活的交互
- 允许用户交互可以被中断和撤销
- 当技术级别增加时可以使交互流水化并允许定制交互
- 使用户隔离内部技术细节
- 设计应允许用户和出现在屏幕上的对象直接交互
减少用户的记忆负担
- 减少对短期记忆的要求
- 建立有意义的缺省
- 定义直觉性的捷径
- 界面的视觉布局应该基于真实世界的隐喻
- 以不断进展的方式提示信息
保持界面的一致性
- 允许用户将当前任务放入有意义的语境
- 在应用系列内保持一致性
- 如过去的交互模式已建立起了用户期望，除非有迫不得已的理由，不要改变它
架构设计
Zachman 架构框架
- Zachman 框架综合考虑企业业务架构中不同角色的不同观点，提出了一个多视角、多维度的企业架构，是许多大公司用来理解、表述企业信息基础设施的一种可以理解的信息表述，为企业现在以及未来的信息基础设施建设提供蓝图和架构。
- 其纵向的功能视图包括目标范围、业务模型、系统模型、技术模型、详细展现和功能系统，横向的关注点包括数据、功能、网络、人员、时间和动机。
Zachman 架构框架（案例）
某集团下属煤矿企业委托软件公司开发―套煤炭运销管理系统，该系统属于整个集团企业信息化架构中的业务层，系统针对煤矿企业开发，包括合同管理、磅房管理、质检化验、运费结算等功能。部分业务详细描述如下：
（1）合同管理：合同签订、合同查询、合同跟踪等。
（2）磅房管理：系统可以从所有类型的电子磅自动读数；可以自动从电子磅上读取车辆皮重、毛重，计算出净重；可根据合同内容自动减少相应提货单剩余数量，如果实际发货量超过合同额则拒绝发货。
（3）质检化验：根据过磅单、车号，生成化验分析委托单，而后生成化验分析报告。
（4）运费结算:依据过磅单上的净重、化验单、合同规定，自动计算出原料结算单、运费结算单。
煤矿企业根据集团的工作计划制订本企业的业务计划，煤矿企业根据集团划拨指标和提供的原料生产煤炭，所生产的煤炭交由集团统一管理并销售给客 5 卢。软件公司采用 Zachman 框架对企业业务架构和业务过程进行分析，结果如下表所示。
【问题 1】
Zachman 框架是什么：请在上表中（a）~（e）位置补充企业业务架构中的信息类别。
1）Zachman 框架综合考虑企业业务架构中不同角色的不同观点，提出了一个多视角、多维度的企业架构，是许多大公司用来理解、表述企业信息基础设施的一种可以理解的信息表述，为企业现在以及未来的信息基础设施建设提供蓝图和架构。
2）（a) What/数据（b）How/功能/行为（c）Where/位置/网络（d）Who/人员/组织（e）Why/动机
【问题 2】
项目组在该煤炭企业业务架构分析中完成了四项主要工作：数据流图、实体联系图、网络拓扑结构和计划时间表。这四项工作在上表中处于什么位置？请用表的位置编号表示。
（1）数据流图：A32
（2）实体联系图：A31
（3）网络拓扑结构：A53
（4）计划时间表:A25
【问题 3】
据题目所述业务描述，请分别给出表中 A11 和 A23 位置应该填入的内容。(物流关系用“→”表示)。
（1）A11 项目关键元素：合同/合同管理、过磅/磅房管理、质检/质检化验、
结算/运费结算
（2）A23 业务物流网络：煤矿企业←→集团→客户。
面向服务的架构SOA
- SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。关于服务，一些常见的设计原则有:明确定义的接口、自包含和模块化、粗粒度、松耦合、互操作性。
- SOA 紧密相关的技术主要有 UDDI、WSDL、SOAP 和 REST 等，而这些技术都是以 XML 为基础而发展起来的。
| UDDI | 统一描述、发现和集成，提供了一种服务发布、查找和定位的方法，是服务的信息注册规范，以便被需要该服务的用户发现和使用它。 |
|---|---|
| WSDL | Web服务描述语言是对服务进行描述的语言。 |
| SOAP | 简单对象访问协议定义了服务请求者和服务提供者之间的消息传输规范。SOAP用XML来格式化消息，用HTTP来承载消息。通过SOAP，应用程序可以在网络中进行数据交换和远程过程调用RPC。 |
| REST | 表述性状态转移是一种只使用HTTP和XML进行基于web通信的技术，可以降低开发的复杂性，提高系统的可伸缩性。REST提出了如下一些设计概念和准则：（1）网络上的所有事物都被抽象为资源。（2）每个资源对应一个唯一的资源标识。（3）通过通用的连接件接口对资源进行操作。（4）对资源的各种操作不会改变资源表示。（5）所有的操作都是无状态的。 |
微服务
微服务有以下优势：
- 通过分解巨大单体式应用为多个服务方法解决了复杂性问题。它把庞大的单一模块应用分解为一系列的服务，同时保持总体功能不变。
- 让每个服务能够独立开发，开发者能够自由选择可行的技术，提供 API服务。
- 微服务架构模式是每个微服务独立的部署。开发者不再需要协调其他服务部署对本服务的影响。这种改变可以加快部署速度。
- 微服务使得每个服务独立扩展。你可以根据每个服务的规模来部署满足需求的规模。甚至可以使用更适合于服务资源需求的硬件。
微服务架构带来的挑战如下：
- 并非所有的系统都能转成微服务。
- 部署较以往架构更加复杂，系统由众多微服务搭建，每个微服务需要单独部署，从而增加部署的复杂度，容器技术能够解决这一问题。
- 性能问题，由于微服务注重独立性，互相通信时只能通过标准接口，可能产生延迟或调用出错。
- 数据一致性问题，作为分布式部署的微服务，在保持数据一致性方面需要比传统架构更加困难。、
在微服务中，应用网关 API 的作用：
- 提供统一入口
- 可以进行权限身份认证等安全管理
- 可以根据流量进行限流
- 数据缓存
- 性能监控等
- 异常重试
- 服务降级
微服务（案例）
某公司拟开发一个自由，可定制性强、用户界面友好的在线调查系统，以获取员工在课程学习、对公司重人事件的看法、对办公室环境的建议等相关反馈。因需要调查的内容各异，可选择的调查方式多样，故本在线调查系统应满足以下需求：
1）支持编辑和视图两种模式，编辑模式只对调查发起者可见，视图模式对接受调查者可见。
2）调查问卷具有可定制性，因调查的内容各异，需要多样的信息采集方式，可设置的调查问题类型包括单选、多选、矩阵类单选、矩阵类多选和开放性问题。
3）操作简单，调查者可以方便地新建和编辑各种问题类型，接受调查者可对每个问题和每个调查问卷给出评论。
4）系统支持显示调查统计结果，以及导出统计结果。 针对以上需求，经项目经讨论，拟采用 REST 架构风格设计实现该在线调查系统。
【问题 1】分析该在线调查系统的业务流程，填写下图中（1）~（5）的内容。
- 编辑模式//调查发起者
- 视图模式/接受调查者
- 是否保存调查问卷
- 已保存的调查问卷
- 显示（查看）调查问卷
【问题 2】
REST 架构风格的核心是资源抽象。在系统设计中，项目组拟将系统中的每一个实体抽象 成一种资源。皆列举出该系统中的 5 种资源。
（1）调查发起者
（2）接受调查者
（3）调查问卷
（4）调查问卷类型
（5）调查问卷评论
【问题 3】
基于 REST 架构风格对系统进行设计，请简要叙述 REST 风格的 5 条关键原则。
（1）网络上所有事物都被抽象为资源。
（2）每个资源对应一个唯一的资源标识；
（3）对资源的各种操作不会改变资源的标识；
（4）通过通用的连接件接口对资源进行操作；
（5）无状态通信
多层架构
二层 C/S 结构为单一服务器且以局域网为中心，所以难以扩展至大型企业广域网或 Internet；软、硬件的组合及集成能力有限；它的缺点主要有：
- 服务器的负荷太重，难以管理大量的客户机，系统的性能容易变坏。
- 数据安全性不好。因为客户端程序可以直接访问数据库服务器，那么，在客户端计算机上的其他程序也可想办法访问数据库服务器，从而使数据库的安全性受到威胁。
在三层 C/S 架构中，增加了一个应用服务器。可以将整个应用逻辑驻留在应用服务器上，而只有表示层存在于客户机上。这种客户机称为瘦客户机。三层 C/S 架构将应用系统分成表示层、功能层和数据层三个部分。
与传统的二层架构相比，三层 C/S 架构具有以下优点：
- 允许合理地划分三层的功能，使之在逻辑上保持相对独立性，从而使整个系统的逻辑结构更为清晰，能提高系统的可维护性和可扩展性。
- 允许更灵活、有效地选用相应的平台和硬件系统，使之在处理负荷能力上与处理特性上分别适应于结构清晰的三层，并且这些平台和各个组成部分可以具有良好的可升级性和开放性。
- 系统的各层可以并行开发，各层也可以选择各自最适合的开发语言，使之能并行且高效地进行开发，达到较高的性能价格比。对每一层的处理逻辑的开发和维护也会更容易些。
- 利用功能层可以有效地隔离表示层与数据层，未授权的用户难以绕过功能层而利用数据库工具或黑客手段去非法地访问数据层，这就为严格的安全管理奠定了坚实的基础。
BS 浏览器/服务器（Browser/Server，B/S） 架构是三层 C/S 架构的一种实现方式，其具体结构为“浏览器/Web 服务器/数据库服务器”。B/S 架构利用WWW 浏览器技术，结合浏览器的多种脚本语言，用通用浏览器就实现了原来需要复杂的专用软件才能实现的强大功能，并节约了开发成本
轻量级架构
| 表现层 | 用户界面的逻辑位于最顶层。表现层负责把用户要求的业务逻辑处理结果以可视化的友好的方式返回给用户，并提供接受用户命令的接口和表现层页面控制逻辑的代码。 |
|---|---|
| 业务逻辑层 | 业务逻辑层负责处理问题领域的业务规则和根据用户需求进行的业务处理以满足用户的功能需求。通常情况下，业务逻辑层处理使用的实体对象由持久层提供。 |
| 持久层 | 数据通过持久层进行持久化。所谓持久化，即把数据（如内存中的对象)保存到可永久保存的存储设备中(如磁盘)。 |
| 数据库 |
持久层的设计，使得业务逻辑层只需要负责业务逻辑的实现，而把对数据的操作交给了持久层。持久层对数据及对数据操作的封装有以下几个优点：
- 屏蔽数据库平台的变化对业务逻辑层的影响。当数据库变化时，只需修改持久层操作数据库的代码，而持久层提供给业务逻辑的对象模型没有变化，从而避免了业务逻辑的修改。
- 通过持久层的封装处理，可以在持久层实现支持多种数据库平台，而对业务逻辑层提供统一的接口。
- 代码可重用性高，能够完成所有的数据库访问操作。
- 通过持久层的设计，将复杂的业务逻辑和数据逻辑分离，降低系统的耦合程度，从而在开发时更明确地进行分工，维护工作也更容易进行，系统的体系结构也变得更加清晰。
MVC
- 模型：执行业务流程（不包括输入输出），存储业务数据。模型不依赖于视图和控制器，提高了架构的灵活性。
- 视图：展示模型中的数据，用户的同一份数据可以通过不同的视图以不同的方式展示。视图必须了解模型中的数据结构，对模型有很强的依赖性，但是模型对于视图则没有依赖性。
- 控制器：把模型接收的事件和用户输入的数据转化为对模型方法的调用。控制器对用户的行为作出解释，并决定调用模型的哪个方法。
使用 MVC 模式来设计表现层，可以有以下的优点：
- 允许多种用户界面的扩展。在 MVC 模式中，视图与模型没有必然的联系，都是通过控制器发生关系，这样如果要增加新类型的用户界面，只需要改动相应的视图和控制器即可，而模型则不需发生改动。
- 易于维护。控制器和视图可以随着模型的扩展而进行相应的扩展，只要保持—种公共的接口，控制器和视图的旧版本也可以继续使用。
- 功能强大的用户界面。用户界面与模型方法调用组合起来，使程序的使 5思界清晰，可将友好的界面发布给用户。
MVP 与 MVVM
MVP 的优点包括：
- 低耦合。模型与视图完全分离，可以修改视图而不影响模型。
- 可以更高效地使用模型，因为所有的交互都发生在一个地方一 Presenter内部。
- 复用性好。可以将一个 Presenter 用于多个视图，而不需要改变Presenter 的逻辑。这个特性非常的有用，因为视图的变化总是比模型的变化频繁。
- 可测试性好。如果把逻辑放在 Presenter 中，就可以脱离用户接口来测试这些逻辑(单元测试)。
MVVM 是由 MVP 进化而来，MVVM 模式基本上与 MVP 相同，只是把MVP 中的 P 变成了 VM，即 ViewModel，MVM 中的数据可以实现双向绑定，当 Model 变化时，View-Model 会自动更新，View 也会自动变化。很好做到数据的一致性，不用担心，在模块的这一块数据是这个值，在另一块就是另一个值了。所以 MVM 模式有些时候又被称作：model-view-binder 模式。因此 MVVM 框架比较适合逻辑复杂的前端项目，比如一些管理系统等。
MDA 模型驱动架构
MDA（Model Driven Architecture）是模型驱动架构，它是由 OMG 定义的一个软件开发框架。它是一种基于 UML 以及其他工业标准的框架，支持软件设计和模型的可视化、存储和交换。
基于 MDA 的软件开发方法的主要过程是抽象出与实现技术无关、完整描述业务功能的核心平台无关模型（Platform Independent Model，PIM），然后针对不同实现技术制定多个转换规则，通过这些转换规则及辅助工具将PIM 转换成与具体实现技术相关的平台相关模型（Platform Specific Model，PSM），最后将经过充实的 PSM 转换成代码。
MDA 的优点：
- 使用平台无关的建模语言来搭建平台无关的模型 PIM，然后根据特定平台和实现语言的映射规则，将 PIM 转换以生成平台相关的模型 PSM，最终生成应用程序代码和测试框架。因此 MDA 方法可移植性比较好。
- MDA 方法中提供了模型转换标准，以及对象约束语言，工具厂商可以开发自动化的工具，开发人员只需关注于业务建模，开发 PIM。从 PIM 到最后面向具体技术平台的可执行的应用程序，都由自动化的 MDA 工具来解决，很好地实现了平台互操作性。(3)在 MDA 中代码是由模型生成的，可以保证文档和代码的一致性。
系统设计（web结构）
Web 架构知识点
高性能、高可用、可维护、应变、安全
| 维度 | 涉及技术内容 |
|---|---|
| 从架构上看 | MVC，MVP，MVVM，REST，Webservice，微服务 |
| 从缓存上看 | MemCache，Redis，Squid |
| 从并发分流来看 | 集群（负载均衡）、CDN |
| 从数据库来看 | 主从库（主从复制），内存数据库，反规范化技术，NoSQL，分区（分表）技术，视图与物化视图 |
| 从持久化来看 | Hibernate，Mybatis |
| 从分布存储来看 | Hadoop，FastDFS，区块链 |
| 从数据编码看 | XML，JSON |
| 从Web应用服务器来看 | Apache，WebSphere，WebLogic，Tomcat，JBOSS，IIS |
| 其他 | 静态化，有状态与无状态，响应式Web设计 |
单台机器 到 数据库与 Web 服务器分离
应用服务器集群
应用服务器集群，将产生如下问题：
- 用户的请求由谁来转发到具体的应用服务器
- 用户如果每次访问到的服务器不一样，那么如何维护 session 的一致性
（负载均衡和有无状态问题）
负载均衡
Redis
Redis与Memcache能力比较
Redis集群切片的常见方式
Redis分布式存储方案
Redis数据分片方案
Redis数据类型
Redis持久化
Redis内存淘汰机制
Redis常见难题
缓存雪崩
缓存穿透
负载均衡技术
应用层负载均衡
-
http 重定向
HTTP 重定向就是应用层的请求转发。用户的请求其实已经到了 HTTP重定向负载均衡服务器，服务器根据算法要求用户重定向，用户收到重定向请求后，再次请求真正的集群。
特点：实现简单，但性能较差。 -
反向代理服务器
在用户的请求到达反向代理服务器时（已经到达网站机房），由反向代理服务器根据算法转发到具体的服务器。常用的 apache、nginx 都可以充当反向代理服务器。
特点：部署简单，但代理服务器可能成为性能的瓶颈。
传输层负载均衡
-
DNS 域名解析负载均衡
DNS 域名解析负载均衡就是在用户请求 DNS 服务器，获取域名对应的IP 地址时，DNS 服务器直接给出负载均衡后的服务器 IP。
特点：效率比 HTTP 重定向高，减少维护负载均衡服务器成本。但一个应用服务器故障，不能及时通知 DNS，而且 DNS 负载均衡的控制权在域名服务商那里，网站无法做更多的改善和更强大的管理。 -
基于 NAT 的负载均衡
基于 NAT 的负载均衡将一个外部 IP 地址映射为多个 IP 地址，对每次连接请求动态地转换为一个内部节点的地址。
特点：技术较为成熟，一般在网关位置，可以通过硬件实现。像四层交换机一般就采用了这种技术。
静态与动态算法
静态算法（不考虑动态负载）
- 轮转算法，轮流将服务请求（任务）调度给不同的节点（即：服务器）。
- 加权轮转算法，考虑不同节点处理能力的差异。
- 源地址哈希散列算法，根据请求的源 IP 地址，作为散列键从静态分配的散列表找出对应的节点。
- 目标地址哈希散列算法，根据请求目标 IP 做散列找出对应节点。
- 随机算法，随机分配，简单，但不可控。
动态算法（考虑动态负载）
- 最小连接数算法，每个节点处理能力相同的情况下，新请求分配给当前活动请求数量最少的节点。
- 加权最小连接数算法:考虑节点处理能力不同，按最小连接数分配。
- 加权百分比算法:考虑了节点的利用率、硬盘速率、进程个数等，使用利用率来表现剩余处理能力。
硬件负载均衡：F5
软件负载均衡：LVS、Nginx、HAprox
Session 共享机制
有状态与无状态
-
无状态服务（stateless service）对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库),服务器本身不存储任何信息。
-
有状态服务（stateful service）则相反，它会在自身保存一些数据，先后的请求是有关联的。
持久化技术 ORM
ORM (Object Relational Mapping），对象与关系数据之间的映射。
- 映射关系表
| 面向对象 | 关系数据库 |
|---|---|
| 类（class） | 数据库的表（table） |
| 对象（object） | 记录（record，行数据） |
| 对象的属性（attribute） | 字段（field） |
- 实现技术对比表
| 维度 | Hibernate | MyBatis |
|---|---|---|
| 对比 | 强大、复杂、间接、SQL 无关（HQL 语句） | 小巧、简单、直接、SQL 有关 |
| 可移植性 | 好（不关心具体数据库） | 差（根据数据库 SQL 编写） |
| 复杂多表关联 | 不支持 | 支持 |
CND 内容分发网络
CDN 的全称是 Content Delivery Network，即内容分发网络。其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输得更快、更稳定。
XML 与 JSON
XML
扩展标记语言（Extensible Markup Language，XML），用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言。
优点：
- 格式统一，符合标准。
- 容易与其他系统进行远程交互，数据共享比较方便。
缺点：
- XML 文件庞大，文件格式复杂，传输占带宽。
- 服务器端和客户端都需要花费大量代码来解析 XML，导致服务器端和客户端代码变得异常复杂且不易维护。
- 客户端不同浏览器之间解析 XML 的方式不一致，需要重复编写很多代码。
- 服务器端和客户端解析 XML 花费较多的资源和时间。
JSON
JSON（JavaScript 0bject Notation）一种轻量级的数据交换格式，具有良好的可读和便于快速编写的特性。可在不同平台之间进行数据交换。
优点：
- 数据格式比较简单，易于读写，格式都是压缩的，占用带宽小。
- 易于解析，客户端 JavaScript 可以简单的通过 eval()进行 JSON 数据的读取。
- 支持多种语言，包括 ActionScript、C、 C#、ColdFusion、Java、JavaScript、Perl、PHP、Python、Ruby 等服务器端语言,便于服务器端的解析。
- 因为 JSON 格式能直接为服务器端代码使用，大大简化了服务器端和客户端的代码开发量，且完成任务不变，并且易于维护。
缺点：
- 某些领域 XML 更通用。
Web 应用服务器
Web 应用服务器可以理解为两层意思：
- WEB 服务器，其职能较为单一，就是把浏览器发过来的 Request 请求返回 Html 页面。
- 应用服务器，进行业务逻辑的处理。
- Apache：Web 服务器，市场占有率 60%左右。它可以运行在几乎所有的 Unix、Windows、Linux 系统平台上。
- IIS，早期 Web 服务器，目前小规模站点仍有应用。
- Tomcat，开源、运行 Servlet 和 JSP Web 应用软件的基于 Java 的 Web应用软件容器。
- JBOSS，JBOSS 是基于 J2EE 的开放源代码的应用服务器。一般与Tomcat 或 Jetty 绑定使用。
- WebSphere，一种功能完善、开放的 Web 应用程序服务器，它是基于Java 的应用环境，用于建立、部署和管理 lnternet 和 Intranet Web 应用程序。
- WebLogic，BEA WebLogic Server 是一种多功能、基于标准的 web 应用服务器，为企业构建自己的应用提供了坚实的基础。
- Jetty， Jetty 是一个开源的 servlet 容器，它为基于 Java 的 web 内容，例如 JSP 和 servlet 提供运行环境。
REST
REST (Representational State Transfer，表述性状态转移）是一种通常使用HTTP 和 XML 进行基于 Web 通信的技术，可以降低开发的复杂性,提高系统的可伸缩性。
REST 的 5 个原则：
- 网络上的所有事物都被抽象为资源。
- 每个资源对应一个唯一的资源标识。
- 通过通用的连接件接口对资源进行操作。
- 对资源的各种操作不会改变资源标识。
- 所有的操作都是无状态的。
响应式 Web 设计
响应式 Web 设计是一种网络页面设计布局，其理念是：集中创建页面的图片排版大小，可以智能地根据用户行为以及使用的设备环境进行相对应的布局。例如，满足手机端，平板，PC 端等多种设备下的全部适应。
方法与策略：
- 采用流式布局和弹性化设计：使用相对单位，设定百分比而非具体值的
方式设置页面元素的大小。 - 响应式图片：不仅要同比的缩放图片，还要在小设备上降低图片自身的
分辨率。
中台
中台是一套结合互联网技术和行业特性，将企业核心能力以共享服务形式沉淀，形成“大中台、小前台”的组织和业务机制，供企业快速低成本的进行业务创新的企业架构。中台又可以进一步细分，比如业务中台、数据中台、XX 中台。本质上，都是对企业通用能力在不同层面的沉淀，并对外能力开放。
例如阿里中台：
业务中台：提供重用服务，例如学员中心、课程中心之类的开箱即用可重用能力。
数据中台：提供数据整合分析能力，帮助企业从数据中学习改进，调整方向。
技术中台：提供技术重用组件能力，帮助解决基础技术平台的复用。如，中间件、分布式存储、AI、负载均衡等基础设施。
业务中台 vs 数据中台
- 多个电商渠道使用一个下单服务，一个订单接口同时为多个前台系统提供服务。
- 多个前台系统，根据一个用户的手机号，获取对应的画像、用户的标签。
- 将多个支付通道,抽象建立成一个支付 API，暴露给前台业务系统。
- 通过一个订单编号，来获取可能的商品推荐清单，从而做到交叉销售。
数据中台必备的 4 个核心能力：
- 数据汇聚整合能力
- 数据提纯加工能力
- 数据服务可视化
- 价值变现方面
云计算
云计算是集合了大量计算设备和资源，对用户屏蔽底层差异的分布式处理架构，其用户与提供实际服务的计算资源是相分离的。
优点：超大规模、虚拟化、高可靠性、高可伸缩性、按需服务、成本低
【前期投入低、综合使用成本也低】。
按照服务类型分类：
- Saas（软件即服务），基于多租户技术实现，直接提供应用程序。
- Paas（平台即服务），虚拟中间件服务器、运行环境和操作系统。
- laaS（基础设施即服务），包括服务器、存储和网络等服务。
按照部署方式分类：
- 公有云，面向互联网用户需求，通过开放网络提供云计算服务。
- 私有云，面向企业内部提供云计算服务。
- 混合云，兼顾以上两种情况的云计算服务，公有云和私有云通过网络进行数据与应用的交互。
架构图如下：
- 管理层，提供对所有层次云计算服务的管理功能。
- 用户访问层，方便用户使用云计算服务所需的各种支撑服务，针对每个层次的云计算服务都需要提供相应的访问接口。
- 应用层，提供软件服务，如：财务管理、客户关系管理、商业智能。
- 平台层，为用户提供对资源层服务的封装，使用户可以构建自己的应用。
- 资源层，提供虚拟化的资源，从而隐藏物理资源的复杂性。如：服务器、存储。
边缘计算
边缘计算是指在靠近物或数据源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台，就近提供最近端服务，其本质是计算处理职能的本地化。
Web 系统分层
物联网架构
- 应用层，应用服务智能终端。
- 平台层，操作系统软件开发设备管理平台连接管理平台。
- 网络层，接入网核心网业务网专有网络通信标准/协议。
- 感知层，传感器芯片通信模组感知类智能设备/装置。
大数据架构
案例 - 系统架构（web）
请用 200 字以内的文字描述什么是“响应式 Web 设计”，并列举 2 个响应式 Web 设计的实现方式。
响应式 web 设计是指我们设计与开发的页面可以根据用户的行为和不同的设备环境做出相应的响应来调整页面的布局，以提供用户可感知的、流畅的阅读和操作体验。
实现方式：（1）流式布局（2）弹性布局，如弹性图片（3）媒体查询
根据李工的提议，新的 B2C 商品交易平台引入了主从复制机制。请针对B2C 商品交易平台的特点，简要叙述引入该机制的好处。
- 提升性能，交易平台要求高并发，主从复制方式一主多从，不同的用户请求可以从不同的从数据库读取数据，提高并发度
- 可扩展性更优，如果采用单台数据库服务器，则访问量持续增加时，数据库瓶颈暴露，且无法迅速解决问题。而主从结构可以快速增加从服务器数量，以满足需求。
- 提升可用性，一主多从，一台从服务器出现故障不影响整个系统正常工作。
- 相当于负载均衡，一主多从分担任务,相当于负载均衡。
- 提升数据安全性，系统中的数据冗余存放多份，不会因为某台机器硬件故障而导致数据丢失。