系统架构设计师-案例分析-Web系统设计
负载均衡技术
应用层负载均衡技术
-
HTTP重定向。HTTP重定向就是应用层的请求转发。用户的请求其实已经到了HTTP重定向负载均衡服务器，服务器根据算法要求重定向，用户收到重定向请求后，再次请求真正的集群。
特点：实现简单，但性能较差
-
反向代理服务器。在用户的请求到这反向代理服务器时，由反向代理服务器根据算法转发到具体的服务器。常用的Apache，Nginx都可以充当反向代理服务器。
特点：部署简单，但代理服务器可能称为性能的瓶颈
传输层负载均衡技术
-
DNS域名解析负载均衡。DNS域名解析负载均衡就是在用户请求DNS服务器，获取域名对应的IP地址时，DNS服务器直接给出负载均衡后的服务器IP。
特点：效率比HTTP重定向高，减少维护负载均衡服务器成本。但一个应用服务器故障，不能及时通知DNS，而且DNS负载均衡的控制权在域名服务商那里，网站无法做更多的改善和更强大的管理。
-
基于NAT的负载均衡。基于NAT的负载均衡将一个外部IP地址映射为多个IP地址，对每次连接请求动态地转换为一个内部节点的地址。
特点：技术较为成熟，一般在网关位置，可以通过硬件实现。像四层交换机一般就采用了这种技术。
CDN
CDN，即内容分发网络，是构件在网络之上的内容分发网络，依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN的关键技术主要有内容存储和分发技术。
CDN的基本原理是广泛采用各种缓存服务器，将这些缓存服务器分布到用户访问相对集中的地区或网络中，在用户访问网站时，利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上，由缓存服务器之间相应用户请求。CDN主要加速静态资源。
REST（表述性状态传递）
REST，即表述性状态转移，是一种针对网络应用设计和开发的架构风格，可以降低开发的复杂性，提高系统的可伸缩性。目的是为了让不同的软件或应用程序在任何网络环境下都可以进行信息的互相传递。
REST的核心思想是，将web应用程序的功能作为资源来表示，使用统一资源标识符（URL）来对这些资源进行操作，并通过HTTP协议（GET、POST、PUT、DELETE等）来定义对这些资源的操作，强调无状态、缓存机制、统一接口、分层系统、客户端-服务器分离等原则。
RESTful是遵循REST原则的Web服务，是REST的形容词。
REST的核心概念：
- 资源。REST是以资源为中心构建，对资源相关数据和表述进行组合，借助URL标识Web上的资源，客户端通过这个URL来访问资源。资源和URL是一对多关系。
- 表述。REST中用表述描述资源在Web中某一个时间的状态。客户端和服务器借助RESTful API传递数据，实际就是在进行资源表述的交互。表述在Web中常用表现形式由HTML、JSON、XML、纯文本等，但是资源表述返回客户端的形式只是统一格式，是开发阶段根据实际需求设计一个统一的表述格式。
- 状态转移。REST定义状态分为两种：应用状态和资源状态。应用状态是对某个时间内用户请求会话相关信息的快照，保存在客户端，由客户端自身维护，可以和缓存配合降低服务端并发请求压力。资源状态在服务端保存，是对某个时间资源请求表述的快照，保存在服务端，如果一段时间内没有对资源状态进行改变，则客户端对同一资源请求返回的表述一致。同时状态转移还要借助HTTP方法来实现，如GET、POST、DELETE方法。
- 超链接。
REST是一种设计风格而不是一个架构。
REST的主要特点：
- 无状态性。服务器不保存客户端的状态信息。每次请求都是独立的，服务器根据请求本身来响应请求。这有助于构建可伸缩的服务器，因为服务器可以轻松地处理大量的并发请求。
- 缓存。REST允许对响应进行缓存。客户端可以缓存GET请求的相应，并在需要时重用这些缓存的响应，而无需再次与服务器通信。这可以显著提高应用程序的性能。
- 统一接口。REST风格要求客户端和服务器之间通过统一的接口进行交互。这包括使用标准的HTTP方法来表示对资源的操作，以及使用标准的HTTP状态码来表示请求的结果。
- 分层系统。客户端不能直接与服务器交互，而是通过一系列的中间层来与服务器通信。这些中间层对客户端是透明的，客户端不需要知道它们的存在。
- 客户端-服务器。REST风格基于客户端-服务器模型，客户端发送请求，服务器接收并处理请求，然后返回响应。客户端和服务器之间的交互是松耦合的，这有助于系统的扩展和维护。
微服务
微服务架构将一个大型的单个应用或服务划分为一组微型、可独立部署的服务，微服务架构围绕业务领域将服务进行拆分，每个服务可以独立进行开发、管理和迭代，彼此之间使用统一接口进行交流，实现了在分散组件中的部署、管理与服务功能，使产品交付变得更加简单，从而达到有效拆分应用，实现敏捷开发与部署的目的。
微服务的优势：
- 复杂应哟解耦。微服务架构将单一模块应用分解为多个为微服务，同时保持总体功能不变。
- 独立。每个微服务可进行独立开发与部署，并具备独立的运行进程。
- 技术选型灵活。开发团队可根据自身应用的业务需求发展状况选择和合适的体系架构与技术。
- 容错。由于各个微服务相互独立，故障会被隔离在单个服务中，并且其他微服务可通过重试、平稳退化等机制实现应用层的容错，从而提高系统应用的容错性。
- 松耦合，易扩展。微服务架构中每个服务之间都是松耦合的，可以根据实际需求实现独立扩展，体现微服务架构的灵活性。
微服务架构带来的挑战：
- 并非所有的系统都能转成微服务。例如一些数据库层的底层操作是不推荐服务化的。
- 部署较以往架构更加复杂。系统由众多服务搭建，每个微服务需要单独部署，从而增加部署的复杂度，容器技术能够解决这一问题。
- 性能问题。由于微服务注重独立性，互相通信只能通过标准接口，可能产生延时或调用出错。例如一个服务需要访问另一个服务的数据，只能通过服务间接口来进行数据传输，如果是频繁访问，则可能带来较大的延迟。
- 数据一致性问题。作为分布式部署的微服务，在保持数据一致性方面需要比传统架构更加困难。
微服务与SOA比较
| 微服务 | SOA |
|---|---|
| 能拆分的就拆分 | 是整体的，服务能放一起的都放一起 |
| 纵向业务划分 | 是水平分多层 |
| 由单一组织负责 | 按层级划分不同部门的组织负责 |
| 细粒度 | 粗粒度 |
| 两句话可以解释明白 | 几百字只相当于SOA的目录 |
| 独立的子公司 | 类似大公司里面划分了一些业务单元（BU） |
| 组件小 | 存在较复杂的组件 |
| 业务逻辑存在于每一个服务中 | 业务逻辑横跨多个业务领域 |
| 使用轻量级的通信方式，如HTTP | 业务服务产总线（ESB）充当了服务器之间通信的角色 |
微服务架构实现与SOA实现对比
| 微服务架构实现 | SOA实现 |
|---|---|
| 团队级，自底向上开展实施 | 企业级，自顶向下开展实施 |
| 一个系统被拆分成多个服务，粒度细 | 服务由多个子系统组成，粒度大 |
| 无集中式总线，松散的服务架构 | 企业服务总线，集中式的服务架构 |
| 集成方式简单（HTTP/REST/JSON） | 集中方式复杂（ESB/WS/SOAP） |
| 服务能独立部署 | 单块结构系统，相互依赖，部署复杂 |
XML和JSON
可扩展标记语言（Extensible Markup Language，XML），用于标记电子文件使其具有结构性的标记语言，可以用来标记数据、定义数据类型，是一种允许用户对自己的标记语言进行定义的源语言
XML的优点
- 格式统一，符合标准。
- 容易与其他系统进行远程交互，数据共享比较方便
XML的缺点：
- XML文件庞大，文件格式复杂，传输占带宽
- 服务器和客户端都需要花费大量代码来解析XML，导致服务器和客户端代码变得异常复杂且不易维护
- 客户端不同浏览器之间解析XML的方式不一致，需求重复编写很多代码
- 服务端和客户端解析XML花费较多的资源和时间。
JSON（JavaScript Object Notation，JSON）是一种轻量级的数据交换格式，具有良好的可读和便于快速编写的而特性，可在不同平台之间进行数据交换。
JSON的优点：
- 数据格式比较简单，易于读写，格式都压缩的，占用带宽小。
- 易于解析，客户端JavaScript可以简单的通过eval()进行json数据的读取
- 支持多种语言，便于服务端的解析
因为JSON格式能之间为服务器端代码使用，大大简化了服务器端和客户端的代码开发量，但完成任务不变，并且易于维护。
JSON的缺点：
没有XML格式这么推广的深入人心和喜用广泛，没有XML通用性强。
有状态和无状态
无状态服务（stateless service）对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到，服务器本身不存储任何信息
有状态服务（stateful service）则相反，它会在自身保存一些数据，先后请求是有关联的。
响应式Web设计
响应式Web设计是一种网络页面设计布局，其理念是：集中创建页面的图片排版大小，可以智能地根据用户行为以及使用的设备环境进行相对应的布局调整，提供最佳的显示效果。
方法与策略：
- 采用流式布局和弹性化设计：使用相对单位，设计百分比而非具体的方式设置页面元素的大小。
- 响应式图片：不仅要同比的缩放图片，还要在小设备上降低图片自身的分辨率。