软件架构设计

层次型软件架构（⭐⭐⭐⭐）

软件架构贯穿于软件研发的整个生命周期内，具有三方面的重要影响：

1. 利益相关人员之间的交流。
2. 系统设计的前期决策。
3. 可传递的系统级抽象。

C/S与B/S架构

层次架构是最通用的架构，常作为初始架构。其关注分离，即每层只负责本层的工作。

污水池反模式：请求流简单地穿过几个层，每层基本没做（或很少做）业务逻辑处理。根据二八原则，如果系统中超过20%的请求都是这样简单穿过，则应该考虑让一些层变成开放的，即允许某些层之间直接交互，绕过中间的一些层，减少不必要的层次穿透带来的性能开销，简化系统设计。

表现层

MVC

• Model【模型层】：应用问题域中包含的抽象领域知识，即应用程序的主体部分。一个模型可为多个视图提供数据，提高应用的可复用性。

• View【视图层】：用户看到并与之交互的界面。接受用户输入数据，向用户展示数据，但它不进行任何实际的业务处理。

• Controller【控制层】：接受用户输入并调用模型和视图去完成用户的需求，是用户界面与模型的接口。一方面解释视图的输入，将其解释为系统能够理解的对象，同时识别用户运作，将其解释为对模型特定方法的调用。另一方面处理来自模型的事件和模型逻辑执行的结果，调用适当的视图为用户提供反馈。

从上图可看到，控制器接收用户的请求，并决定应该调用哪个模型来处理；然后模型根据用户请求进行相应的业务逻辑处理，并返回数据；最后，控制器调用相应的视图来格式化模型返回的数据，并通过视图呈现给用户。

MVC 模式的优点：

1. 允许多种用户界面的扩展。
2. 易于维护
3. 功能强大的用户界面。

在 J2EE 体系中：

• 模型：Session Bean、Entity Bean
• 视图：JSP、JSF
• 控制层：Servlet

MVP

MVP是MVC的变种，其优点如下：

• 模型和视图完全分离，可以修改视图而不影响模型。
• 可以更高效地使用模型，因为所有交互都发生在一个地方内部（Presenter）。
• 可以将一个 Presenter 用于多个视图，而不需要改变 Presenter 的逻辑。
• 如果把逻辑放在 Presenter 中，就可以脱离用户接口来测试这些逻辑（单元测试）。

特点：各部分是双向通信的。

主要应用场景：Android 开发。

MVVM

MVVM 为解决 MVP 中 UI 种类变多导致接口也会不断增加的问题。

• 视图模型：通过 DataBinding 实现 View 和 Model 之间的双向绑定，其内容包括数据状态处理、数据绑定以及数据转换。

使用场景：数据驱动，数据操作特别频繁的场景。如 Vue 和 Angular 框架。

UIP框架

UIP 框架把表现层分为：

• UIC（User Interface Componets）：原来的表现层，用户看到的和进行交互的都是这个组件，它负责获取用户的数据并且返回结果。
• UIP（User Interface Process Components）：这个组件用于协调用户界面的各部分，使其配合后台的活动，例如导航和工作流控制，以及状态和视图的管理。用户看不到这一组件，但是这些组件为 UIC 提供了重要的支持功能。

表现层动态生成设计思想

基于XML界面管理技术，包括界面配置、界面动态生成、界面定制三部分。

中间层【业务层】

业务逻辑层工作流设计

业务逻辑层框架

数据访问层【持久层】

数据访问模式

• 在线访问：每个数据库操作都会通过数据库连接不断地与后台的数据源进行交互。
• DAO（Data Access Object）：底层数据访问操作与高层业务逻辑分离。
• DTO（Data Transfer Object）：跨不同的进程或是网络的边界来传输数据。
• 离线数据模式：从数据源获取数据后，存放到本地处理。
• 对象/关系映射（ORM）：应用系统中的对象与数据库中的数据表形成映射关系。

数据访问层设计

ORM（Object Relational Mapping）：对象与关系数据之间的映射。

映射关系表：

面向对象	关系数据库
类（class）	表（table）
对象（Object）	记录（record，行数据）
对象的属性（Attribute）	字段（Field）

Java ORM实现技术对比：

维度	Hibernate	MyBatis
简单对比	强大、复杂、间接、SQL无关	小巧、简单、直接、SQL相关
可移植性	好（不关心具体数据库）	差（根据数据库SQL编写）
复杂多表关联	不支持	支持

SpringBoot开发

分层	SpringBoot
表现层	Controller
业务层	Service
访问层	ORM
数据层	MySQL、PostgreSQL等数据库

使用 ORM 框架：

• 定义模型：Pojo、Entity、Bean、Domain 都可以简单理解为模型。
• 定义接口：通常是 xxxMapper.java
• Mapper资源文件：通常是 xxxMapper.xml

School.java

@Data
public class School {
    @Schema(title = "主键")
    Integer id;

    @Schema(title = "学校名称")
    String name;

    @Schema(title = "学校所在城市")
    String city;
}

SchoolMapper.java

public interface SchoolMapper {
    School read(Integer id);

    List<School> readMulti(String name, String city);

    void create(School school);
}

SchoolMapper.xml

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "https://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="org.wgj.ssm.mapper.SchoolMapper">

  <select id="read" resultType="org.wgj.ssm.bean.School">
    select * from school where id=#{id}
  </select>
  <select id="readMulti" resultType="org.wgj.ssm.bean.School">
    select * from school
    <where>
      <if test="name != '' and name != null">
        name=#{name}
      </if>
      <if test="city != '' and city != null">
        city=#{city}
      </if>
    </where>
  </select>

  <insert id="create">
    insert into school(name, city) values(#{name}, #{city})
  </insert>
</mapper>

SchoolService.java

@Service
public class SchoolService
{
    @Autowired
    private SchoolMapper schoolMapper;

    public getSchoolById(Integer id)
    {
      return schoolMapper.read(id);
    }

    public getSchoolList(String name, String city)
    {
        return schoolMapper.readMulti(name, city);
    }

    public createSchool(School school)
    {
        schoolMapper.create(school);
    }
}

SchoolController.java

@RestController
@RequestMapping("school")
@Tag(name = "School", description = "学校相关接口")
public class SchoolController {

    private SchoolService schoolService;

    @Operation(summary = "根据ID查询", description = "根据ID查询学校")
    @GetMapping("/{id}")
    public School read(@PathVariable Integer id) {
        return schoolService.getSchoolById(id);
    }

    @Operation(summary = "查询多条", description = "查询学校")
    @GetMapping("")
    public List<School> readMulti(
        @Parameter(description = "学校名称") String name,
        @Parameter(description = "城市") @RequestParam(value = "city", required = false) String city)
    {
        return schoolService.getSchoolList(name, city);
    }

    @Operation(summary = "创建")
    @PostMapping("")
    public void create(@RequestBody School school) {
        schoolService.createSchool(school);
    }
}

物联网分层架构

分层	描述	设备
应用层	解决信息处理和人机交互问题	应用服务、智能终端
平台层		操作系统、软件开发、设备管理平台、连接管理平台
网络层	传递信息和处理信息	网络、通信标准/协议
感知层	解决数据获取问题	传感器、芯片、通信模组、感知类智能设备/装置

大数据分层架构

RIA架构（⭐⭐）

RIA（Rich Internet Applications，富互联网应用）架构是一种通过在客户端（通常是Web浏览器）上运行富客户端应用程序来增强用户体验和应用程序性能的Web应用架构。它旨在结合传统桌面应用程序的响应性和互动性与Web应用程序的可访问性和易更新性。

RIA架构的主要特点

优点：反应速度快、易于传播、交互性强

典型例子：Google Docs，在浏览器上编辑Word文档、Excel等。国内的腾讯文档 Web 端应该也属于 RIA 架构。

面向服务的软件架构（⭐⭐⭐⭐）

SOA

面向服务架构（Service Oriented Architecture，SOA）可视为组件模型，其将系统整体拆分为多个独立的功能模块，模块之间通过调用接口进行交互，有效整合了应用系统的各项业务功能，系统各个模块之间是松耦合的。

SOA的优点：

SOA 架构以企业服务总线 ESB 作为核心基础设施，链接各个子系统，是集中式的技术架构。

SOA 架构的服务实现方式有 Web Service 和 RESTful API 等。

Web Service

3种角色：服务注册中心、服务提供者、服务请求者

3种操作：发布、查找、绑定

3种技术：

• SOAP：通信协议，用于以服务的方式在互联网上发布有用的程序模块，SOAP = HTTP + XML
• WSDL（Web Services Description Language）：基于XML，用于描述WebService及其函数、参数和返回值等，为用户提供详细的接口说明。
• UDDI（Universal Description Discovery and Integration）：提供一种统一发布、查找和定位web服务的方法。

RESTful

REST（Representational State Transfer，表述性状态转移）是一种软件设计风格。

RESTful 是人们借助 HTTP、JSON、URI、HTML等 Web 服务开发中广泛使用的标准和协议，同时使用不同的编程语言编写客户端和服务端，通过 HTTP 方法操作资源状态，最后遵循 REST 设计原则实现的应用程序或服务架构，其可以降低开发的复杂性，提高系统的可伸缩性。

• 资源：每一个对象、实体或数据都被抽象为一个资源。例如，用户、文章等都可以作为资源。
• 表述：资源某一时间的状态，呈现形式有HTML、JSON、XML
• 状态转移：使用GET、POST等方法
• 超链接：通过超链接可与其它资源联系

5个原则：

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

微服务

微服务属于面向服务架构（SOA）的一种，是在SOA基础上进一步发展的产物，去除了 ESB 企业服务总线，是一个真正意义上去中心化的分布式架构。

微服务体现在细粒度，主要用到容器技术。传统单体架构将所有功能放到一个进程中，而微服务每个功能放入一个独立进程中。

微服务的优点：

• 复杂应用解耦：将单一模块应用分解为多个微服务，同时保持总体功能不变。每个服务专注于单一功能，通过良好的接口清晰表述服务边界。由于功能单一、复杂度低，易于小团队开发，提高开发效率且易于维护。
• 独立性：独立开发、测试、部署以及独立运行（每个服务独立在其独立进程中）。
• 技术选型灵活：微服务是去中心化的，每个开发团队可以根据自身应用的业务需求发展状况选择合适的体系架构与技术，从而更方便地根据实际业务情况获得系统应用最佳解决方案。支持异构（如每个服务使用不同的数据库），架构转型或技术升级风险低。
• 容错：传统单体架构下，某一模块发生故障，可能导致整个系统瘫痪。而微服务架构下，服务之间相互独立，故障被隔离在单个服务中，系统其他微服务可通过重试、平稳退化等机制实现应用层的容错。
• 松耦合，易扩展：传统单体架构通过将整个应用复制到不同节点，从而实现横向扩展。当系统应用的不同组件在扩展需求上存在差异时，会导致系统的水平扩展成本很高。而微服务架构中每个服务之间是松耦合的，可根据实际需求实现独立扩展。

微服务面临的问题和挑战：

• 分布式特点带来的复杂性，使服务发现与服务调用链跟踪变得困难。
• 分区数据库体系下，受限于 CAP 理论而不得不放弃传统数据库的强一致性，转而追求最终一致性。
• 测试复杂性：服务间的依赖关系使测试变得复杂。
• 运维的复杂性：在监控、管理、分发及扩容等方面存在巨大挑战。

微服务与SOA的区别：

微服务	SOA
能拆分就拆分	整体的，服务能放在一起的都放在一起
细粒度	粗粒度
使用轻量级的通信方式，如HTTP	ESB
类似独立子公司	类似大公司里面划分了一些业务单元（BU）
纵向业务划分	水平分多层
由单一组织负责	按层级划分不同部门的组织负责
业务逻辑存在于每一个服务中	业务逻辑横跨多个业务领域
组件小	存在较复杂的组件

微服务架构模式方案

聚合器微服务

主要用于组合多个独立的微服务的响应，向客户端返回统一的聚合结果，减少客户端与多个微服务之间的交互，降低网络开销。聚合器微服务可直接组合结果返回，也可做业务处理后返回，它有自己的缓存和数据库。

比如电商的订单详情页有订单数据、商品数据、用户数据等。客户端只需要调用一个接口，该接口通过并发请求订单服务、商品服务、用户服务，将结果聚合返回给客户端。

聚合器微服务的变种——代理微服务：仅进行委派请求和数据转换工作。

聚合器微服务的扩展——分支微服务：通常根据不同的条件或参数值来执行不同的业务流程，允许同时调用两个或多个微服务链。

链式微服务

这个容易理解，需注意该模式下，所有服务调用都采用同步消息传递方式，在一条完整地服务链调用完成之间，客户端或调用服务会一直阻塞。因此，使用链式微服务要避免调用链过长，每个服务接口耗时也不宜过长。

数据共享微服务

该模式通常用于单体架构转换到微服务架构的过渡阶段。

异步消息传递微服务

链式微服务的同步消息传递容易造成阻塞，此时可以使用异步消息传递微服务模式，加快系统响应速度。例如客户端调用 A 服务，服务 A 将数据写入消息队列后就可以立即返回，耗时的逻辑处理可以由另外的一个或多个（如 Kafka 的消费组提供并发消费能力）服务来处理，处理完之后将结果保存并通知客户端来获取结果。

该模式可能会降低系统可用性，并增加系统复杂性，高可用的消息队列选型是关键。

微服务设计

微服务设计约束：

1. 微服务个体约束：每个微服务都是独立的，修改一个微服务不能影响另一个微服务。
2. 微服务与微服务之间的横向关系：通过第三方服务注册中心来满足服务的可发现性。
3. 微服务与数据层之间的纵向约束：数据是微服务的“私产”，访问时需要通过微服务。
4. 全局视角下的微服务分布式约束：高效运维整个系统。

微服务设计应注意的问题：

1. 对于服务粒度的控制：通常来说，对于将暴露在整个系统外部的服务推荐使用粗粒度的接口，而相对较细粒度的服务接口用于企业系统架构的内部。
2. 对于无状态服务的设计：服务不应该依赖于其他服务的上下文和状态。

微服务技术

Apacha Dubbo

用于解决微服务架构下的服务治理与通信问题。支持Istio服务网格部署。

Spring Cloud

为开发人员提供快速构建分布式系统中常见模式的工具，如配置管理、服务发现、断路器、智能路由等。

Spring Cloud Alibaba

使用阿里云开源中间件，提供微服务开发的一站式解决方案。

功能	组件
注册中心&配置中心	Nacos、Zookeeper、Consul
流控防护	Sentinel
消息队列	RabbitMQ、RocketMQ、Kafka、Pulsar（资料较少）
分布式事务	Seata
分布式定时任务	Spring SchedulingTasks、 xxl-job、 elastic-job

Spring Cloud 由 Spring 官方团队维护，Spring Cloud Alibaba 由阿里云维护，只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里分布式应用解决方案，通过阿里中间件来迅速搭建分布式应用系统。

云原生架构（⭐⭐⭐⭐）

云计算

云计算是集合了大量计算设备和资源，对用户屏蔽底层差异的分布式处理架构，其用户与提供实际服务的计算资源是相对隔离的。

优点：超大规模、虚拟化、高可靠性、高可伸缩性、按需付费、成本低（前期投入低，综合使用成本也低）

分类

按服务类型分类：

• FaaS【函数即服务】：无服务器函数计算，仅需要编写函数代码。如 Amazon Lambda、Google Cloud Functions、Microsoft Azure Functions 等。这里说的无服务器并不是说程序不需要服务器运行，而是指开发不需要关注服务器底层资源。
• BaaS【后端即服务】：用户只需要调用运营商提供的API即可完成相应功能。比如阿里云上提供的身份验证接口，短信接口等。
• SaaS【软件即服务】：提供给客户的服务是运营商运行在云计算基础设施上的应用程序，用户可直接通过客户端使用（如浏览器），不需要管理任何软硬件。如腾讯文档，腾讯负责维护服务器和存储等，客户直接使用浏览器就可使用。
• PaaS【平台即服务】：提供应用开发和部署平台，用户不需要管理和控制云计算底层基础设施，省去服务器运维。如开发一个网站，将网站前后端代码部署到平台。
• IaaS【基础设施即服务】：提供给客户的服务是对所有设施的利用，包括存储、网络和其它基本的计算资源，用户能够部署和运行任意软件，包括操作系统和应用程序。主要功能是将底层硬件资源以服务的方式对外暴露，为上层提供服务。如自定义 Linux 服务器来运行程序。

简单理解，从云服务商角度，IaaS 只负责提供服务器、网络等硬件资源；PaaS 在 IaaS 基础上提供操作系统、网络环境等，用户只需要部署自己的应用程序；SaaS 则是直接提供应用服务，用户直接使用即可。

按部署方式分类：

• 公有云：面向互联网用户需求，通过开放网络提供云计算服务。
• 私有云：面向企业内部提供云计算服务，提供对数据安全、服务质量和基础设施的最有效控制，能充分利用现有硬件资源和软件资源，不影响IT管理流程。
• 混合云：兼顾以上两种情况的云计算服务。

架构

• 管理层：提供对所有层次云计算的管理能力
• 用户访问层：方便用户使用云计算服务所需的各种支撑服务，针对每个层次的云计算服务都需要提供相应的访问接口。
• 应用层：提供软件服务。如：财务管理、客户关系管理、商业智能
• 平台层：为用户提供对资源层服务的封装，使用户可以自己构建自已的应用。
• 资源层：提供虚拟化的资源，从而隐藏物理资源的复杂性。如：服务器、存储等。

云原生架构

云原生是基于分布式部署和统一运管的分布式云，以容器、微服务、DevOps等技术为基础建立的一套云技术产品体系。

本质：Oncloud ==> Incloud

之前是将应用部署到云上（Oncloud），现在是云原本就提供该应用（Incloud）。

云原生设计原则

1. 服务化原则：使用微服务
2. 弹性原则：可根据业务变化自动伸缩
3. 可观测原则：通过日志、链路跟踪和度量
4. 韧性原则：面对异常的抵御能力
5. 所有过程自动化原则：自动化交付工具
6. 零信任原则：默认不信任网络内部和外部的任何人/设备/系统
7. 架构持续演进原则：业务高速迭代情况下的架构与业务平衡

云原生架构模式

服务化架构模式

要求以应用模块为颗粒度划分一个软件，以接口契约（如 IDL） 定义彼此业务关系，以标准协议（HTTP、gRPC等）确保彼此的互联互通，结合 DDD（领域模型驱动）、TDD（测试驱动开发）、容器化部署提升每个接口的代码质量和迭代速度。

Mesh化架构模式

Mesh化架构是把中间件框架从业务进程中分离，让中间件 SDK 与业务代码进一步解耦，把分布式架构的通用模块（如熔断、限流、降级、重试）放到 Mesh 进程中。

服务网格（Service Mesh）作为服务间通信的基础设施层，是个轻量级高性能网络代理，提供安全的、快速的、可靠地服务间通讯，与实际应用部署在一起，但对应用是透明的。应用作为服务的发起方，只需要用最简单的方式将请求发送给本地的服务网格代理，然后网格代理会进行后续操作（如服务发现，负载均衡等），最后将请求转发给目标服务。

服务网格核心功能：

• 服务发现
• 安全认证
• 负载均衡
• 流量控制
• 故障恢复
• 监控和追踪（可观测性）

Istio 框架：开源服务网格框架，在逻辑上分为数据平面和控制平面。

• 数据平面：是一组代理，用于调解和控制微服务之间的所有网络通信。这些代理还可以收集和报告所有网格流量的可观测数据。
• 控制平面：管理和配置数据平面中的这些代理。

Serverless模式

无服务器技术屏蔽了服务器的各种运维复杂度，让开发人员专注于业务逻辑设计与实现，逐渐成为云原生主力技术。其特征如下：

1. 全托管的计算服务：客户只需要编写代码构建应用，无需关注同质化、负担繁重的基于服务器基础设施的开发、运维、安全、高可用等工作。
2. 通用性：结合云上 BaaS API 能力，能够支撑云上所有重要类型的应用。
3. 自动弹性伸缩：让用户无需为资源使用提前进行容量规划。
4. 按量计费：让企业使用成本降低，无需为闲置资源付费。

技术关注点：

1. 计算资源弹性调度
2. 负载均衡和流控
3. 安全性

存储计算分离模式

分布式环境中的 CAP 困难主要是针对有状态应用，因为无状态应用不存在 C（一致性）这个维度，因此可以获得很好的 A（可用性）和 P（分区容错性），因而获得更好的弹性。在云环境中，推荐把各类暂态数据（如session）、 结构化和非结构化持久数据都采用云服务来保存，从而实现存储计算分离。

分布式事务模式

微服务模式提倡每个服务使用私有的数据源，而不是像单体这样共享数据源，但往往大颗粒度的业务需要访问多个微服务，必然带来分布式事务问题，否则数据就会出现不一致。架构师需要根据不同的场景选择合适的分布式事务模式。

可观测架构

可观测架构包括 Logging、Tracing、Metrics 三个方面：

• Logging：提供不同等级的日志跟踪，由应用开发者主动提供。
• Tracing：提供一个请求从前端到后端的完整调用链路跟踪。
• Metrics：提供对系统量化的多维度度量，如请求处理时间、错误率、吞吐量等。

事件驱动架构

事件驱动架构（EDA,Event Driven Architecture）本质上是一种应用/组件间的集成架构模式。EDA 不仅用于微服务解耦，还有以下使用场景：

1. 增强服务韧性：下游的处理异常不会对上游有影响。
2. CQRS（Command Query Responsibility Segregation）：把对服务状态有影响的命令用事件来发起，而对服务状态没有影响的查询才使用同步调用的 API 接口。
3. 数据变化通知：比如用户订单完成后，积分服务、信用服务等都需要得到事件通知并更新用户积分和信用等级。
4. 构建开放式接口：事件的提供者并不用关心有哪些订阅者，不像服务调用的场景——数据的产生者需要知道数据的消费者在哪里并调用它，因此保持了接口的开放性。
5. 事件流处理：处理大量事件流的数据分析场景，典型如基于 Kafka 的日志处理。

云原生架构反模式

1. 庞大的单体应用：需要多人开发的业务模块，考虑通过服务化进行拆分并让组织与架构匹配。
2. 单体应用“硬拆”为微服务（服务拆分要适度）：小规模软件的服务拆分（为拆而拆）、数据依赖（服务间数据依赖）、性能降低。
3. 缺乏自动化能力的微服务：手动维护大量微服务是不现实的。

容器技术

Docker容器基于操作系统虚拟化技术，共享操作系统内核、轻量、没有资源损耗、秒级启动，极大提升了系统的应用部署密度和弹性。

对比项	虚拟机技术	容器技术
镜像大小	包含GuestOS，G量级以上	仅包含运行Bin/Lib，M量级
资源要求	CPU与内核按核、按G分配	CPU与内存按单核、低于G量级分配
启动时间	分钟级	毫秒级
可持续性	跨物理机迁移	跨操作系统平台迁移
弹性伸缩	VM伸缩，CPU和内存手动伸缩	实例自动伸缩、CPU内存自动在线伸缩
隔离策略	操作系统，系统级别	Cgroups，进程级别

Kubernetes【k8s】提供了分布式应用管理的核心能力：

• 资源调度：根据请求资源量在集群中选择合适的节点来运行应用。
• 应用部署与管理：支持应用的自动发布与应用的回滚。
• 自动修复：当宿主机或者OS出现故障，节点健康检查会自动进行应用迁移。
• 服务发现与负载均衡：结合DNS和负载均衡机制，支持容器化应用之间的相互通信。
• 弹性伸缩：可以对这个业务进行自动扩容。
• 声明式API：开发者可以关注于应用自身，而非系统执行细节。
• 可扩展性架构：所有k8s组件都是基于一致的、开放的API实现和交互。
• 可移植性：k8s通过一系列抽象如 LoadBalance Service【负载均衡服务】、CNI【容器网络接口】、CSI【容器存储接口】，帮助业务应用屏蔽底层基础设施的实现差异，实现容器灵活迁移的设计目标。

传统应用与云原生应用：

传统开发与云原生开发对比：

边缘计算

边缘计算是指靠近物或源头的一侧，采用网络、计算、存储、应用核心能力为一体的开放平台，就近提供最近端服务。本质是计算处理职能的本地化。

边缘计算的类型：

• 云边缘：云服务在边缘侧的延伸。
• 边缘云：在边缘侧构建中小规模云服务能力。
• 边缘网关：以云化技术与能力重构原有嵌入式网关系统。

边云协同的分类：

• 资源协同：边缘节点有基础设施资源的调度管理能力，可与云端协同。
• 数据协同：边缘节点采集数据并初步分析，再发给云端做进一步处理。
• 智能协同：分布式智能，云端做集中式模型训练，再将模型下发到边缘节点。
• 应用管理协同：边缘节点提供应用部署与运行环境，云端主要提供应用开发、测试环境。
• 业务管理协同：边缘节点提供模块化、微服务化的应用/数字孪生/网络等应用实例；云端主要提供按照客户需求实现应用/数字孪生/网络等的业务编排能力。
• 服务协同：边缘节点按照云端策略实现部分ECSaaS服务，通过ECSaaS与云端SaaS的协同实现面向客户的按需SaaS服务；云端主要提供SaaS服务在云端和边缘节点的服务分布策略，以及云端承担的SaaS服务能力。

大型网站架构演化（⭐⭐⭐⭐⭐）

维度	涉及技术
架构	MVC、 MVP、 MVVM、 REST、 WebService、 微服务
并发分流	集群（负载均衡）、CDN
缓存	MemCache、Redis、Squid
数据	主从复制、反规范化技术、NoSQL、分区技术、视图与物化视图
ORM	Hibernate、Mybatis
分布式存储	Hadoop、FastDFS、区块链
数据编码	XML、JSON
Web应用服务器	Apache、WebSphere、WebLogic、Tomcat、JBOSS、ISS
安全性	SQL防注入
其它	静态化、有状态和无状态、响应式Web设计、中台

第一阶段：单体架构

第二阶段：垂直架构

第三阶段：使用缓存

详细参考缓存设计

第四阶段：使用服务集群提高并发处理能力

服务集群带来的问题：

1. 用户的请求如何转发到具体的应用服务器？答：负载均衡
2. 用户每次访问不同的服务器，如何维护session的一致性？答：Session共享机制

Session共享机制

第五阶段：数据库读写分离

主从数据库特点：

1. 一般是一主多从，也可以多主多从
2. 主库写，从库读

主从复制步骤：

1. 主库更新数据完成前，将操作写入binlog日志文件。
2. 从库打开I/O线程与主库连接，获取binlog日志并将写入中继日志。
3. 从库读取中继日志，并解析成具体的操作执行，保持与主库一致。

第六阶段：使用反向代理和CDN加速

内容分发网络（Content Delivery Network, CDN）：基本思路是尽可能避免互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输得更快、更稳定。

第七阶段：使用分布式文件系统和分布式数据库

第八阶段：使用NoSQL和搜索引擎

第九阶段：业务拆分

第十阶段：分布式服务

其它考点

Web应用服务器

Web应用服务器可以理解为两层意思：

1. Web服务器：其职能较为单一，就是根据浏览器发过来的请求，响应HTML页面。
2. 应用服务器：进行业务逻辑的处理。如：EJB、Corba、COM+等。

web相关服务器介绍：

• Apache：Web服务器，市场占有率60%左右。可以运行在所有Unix、Windows、Linux系统平台上。
• Nginx：Web服务器，性能高，支持负载均衡。
• Tomcat：基于Java的、开源、运行servlet和JSP Web的应用软件容器。
• Jetty：基于java的开源servlet容器。
• JBOSS：基于J2EE的开源应用服务器。一般与Tomcat和Jetty绑定使用。
• WebSphere：基于java的、功能完善、开放的web应用服务器，用于建立、部署和管理web应用程序。
• WebLogic：BEA WebLogic Server是一种多功能、基于标准的web应用服务器，为企业构件自己的应用提供坚实的基础。
• IIS：早期的Web服务器，目前很少用了。

响应式Web设计

一种网页设计布局，可智能地根据用户行为以及使用的设备环境进行相应地布局。

方法和策略：

1. 流式布局和弹性布局：使用相对单位，设定百分比而非具体值的方式设置页面元素的大小。
2. 响应式布局：如媒体查询

JWT

JWT（Json Web Token）是一种用于身份验证和授权的开放标准。它是一种轻量级的、基于Json的令牌，可以在客户端和服务器之间传递信息。

JWT由三部分组成：

• 头部：包含令牌类型和所使用的算法。
• 载荷：包含用户信息和其他元数据。
• 签名：用于验证令牌的完整性和真实性。

JWT的应用场景：信息交换和授权。不需要服务器端存储状态，安全地传递非敏感信息。

中台

中台是一套结合互联网技术和行业特性，将企业核心能力以共享服务形式沉淀，形成“大中台、小中台”的组织和业务基础，供企业快速低成本的进行业务创新的企业架构。

• 业务中台：提供重用服务，例如学员中心、课程中心之类的开箱即用可重用能力。

• 数据中台：提供数据整合分析能力，帮助企业从数据中学习改进，调整方向。

  必备的4个核心能力：

  1. 数据汇聚整合能力
  2. 数据提纯加工能力
  3. 数据服务可视化
  4. 数据价值变现

• 技术中台：提供技术重用组件能力，帮助解决基础技术平台的复用。如：中间件、分布式存储、AI、负载均衡等基础设施。

各种分类本质上是对企业通用能力在不同层面的沉淀，并对外开放。

Web系统分层