1.1. Web技术演化¶
1.1.1. 简单网站¶
1.1.1.1. 静态页面¶
Web技术在最初阶段，网站的主要内容是静态的，大多站点托管在ISP上，由文字和图片组成，制作和表现形式也是以表格为主。当时的用户行为也非常简单，基本只是浏览网页。
1.1.1.2. 多媒体阶段¶
随着技术的不断发展，音频、视频、Flash等多媒体技术诞生了。多媒体的加入使得网页变得更加生动形象，网页上的交互也给用户带来了更好的体验。
1.1.1.3. CGI阶段¶
渐渐的，多媒体已经不能满足人们的请求，于是CGI (Common Gateway Interface) 应运而生。CGI定义了Web服务器与外部应用程序之间的通信接口标准，因此Web服务器可以通过CGI执行外部程序，让外部程序根据Web请求内容生成动态的内容。
在这个时候，各种编程语言如PHP/ASP/JSP也逐渐加入市场，基于这些语言可以实现更加模块化的、功能更强大的应用程序。
1.1.1.4. MVC¶
随着Web应用开发越来越标准化，出现了MVC等思想。MVC是Model/View/Control的缩写，Model用于封装数据和数据处理方法，视图View是数据的HTML展现，控制器Controller负责响应请求，协调Model和View。
Model，View和Controller的分开，是一种典型的关注点分离的思想，使得代码复用性和组织性更好，Web应用的配置性和灵活性也越来越好。而数据访问也逐渐通过面向对象的方式来替代直接的SQL访问，出现了ORM (Object Relation Mapping) 的概念。
除了MVC，类似的设计思想还有MVP、MVVM等。
1.1.2. 数据交互¶
1.1.2.1. 简单数据交互¶
在Web技术发展最初，前后端交互大部分都使用Web表单、XML、SOAP等较为简单的方式。
1.1.2.2. Ajax¶
在开始的时候，用户提交整个表单后才能获取结果，用户体验极差。于是Ajax (Asynchronous Javascript And XML) 技术逐渐流行起来，它使得应用在不更新整个页面的前提下也可以获得或更新数据。这使得Web应用程序更为迅捷地回应用户动作，并避免了在网络上发送那些没有改变的信息。
1.1.2.3. RESTful¶
在CGI时期，前后端通常是没有做严格区分的，随着解耦和的需求不断增加，前后端的概念开始变得清晰。前端主要指网站前台部分，运行在PC端、移动端等浏览器上展现给用户浏览的网页，由HTML5、CSS3、JavaScript组成。后端主要指网站的逻辑部分，涉及数据的增删改查等。
此时，REST (Representation State Transformation) 逐渐成为一种流行的Web架构风格。
REST鼓励基于URL来组织系统功能，充分利用HTTP本身的语义，而不是仅仅将HTTP作为一种远程数据传输协议。一般RESTful有以下的特征：
- 域名和主域名分开
api.example.com
example.com/api/
- 带有版本控制
api.example.com/v1
api.example.com/v2
- 使用URL定位资源
GET /users 获取所有用户
GET /team/:team/users 获取某团队所有用户
POST /users 创建用户
PATCH/PUT /users 修改某个用户数据
DELETE /users 删除某个用户数据
- 用 HTTP 动词描述操作
GET 获取资源，单个或多个
POST 创建资源
PUT/PATCH 更新资源，客户端提供完整的资源数据
DELETE 删除资源
- 正确使用状态码
使用状态码提高返回数据的可读性
默认使用 JSON 作为数据响应格式
有清晰的文档
1.1.2.4. GraphQL¶
部分网络服务场景的数据有复杂的依赖关系，为了应对这些场景，Facebook 推出了 GraphQL ，以图状数据结构对数据进行查询存储。部分网站也应用了 GraphQL 作为 API 交互的方式。
1.1.2.5. 二进制¶
随着业务对性能的要求提高，前后端开始使用HTTP/2、自定义Protocol Buffer等方式来加快数据交互。
1.1.3. 架构演进¶
随着业务的不断发展，业务架构也越来越复杂。传统的功能被拆分成不同的模块，出现了中间件、中台等概念。代理服务、负载均衡、数据库分表、异地容灾、缓存、CDN、消息队列、安全防护等技术应用越来越广泛，增加了Web开发和运维的复杂度。
客户端的形态越来越多，除了Web之外iOS、Android等其他场景也出现在Web服务的客户端场景。
较早的关系型数据库MySQL、PostgreSQL等已经不能满足需求，出现了Redis/Memcached缓存数据库等一类满足特定需求的数据库。
为了满足特定的业务需求，出现了Lucene/Solr/Elasticsearch搜索应用服务器，Kafka/RabbitMQ/ZeroMQ消息系统，Spark计算引擎，Hive数据仓库平台等不同的基础架构。
1.1.3.1. 中间件¶
中间件是独立的软件程序，用于管理计算资源和网络通信。常用的功能有过滤IP、合并接口、合并端口、路由、权限校验、负载均衡、反向代理等。
1.1.3.2. 分布式¶
随着数据量的不断提高，单台设备难以承载这样的访问量，同时不同功能也被拆分到不同的应用中，于是出现了提高业务复用及整合的分布式服务框架(RPC)。
1.1.4. 云服务¶
云计算诞生之前，大部分计算资源是处于“裸金属”状态的物理机，运维人员选择对应规格的硬件，建设机房的 IDC 网络，完成服务的提供，投入硬件基础建设和维护的成本很高。云服务出现之后，使用者可以直接购买云主机，基础设施由供应商管理，这种方式也被称作 IaaS (Infrastructure-as-a-Service) 。
随着架构的继续发展，应用的运行更加细粒度，部署环境容器化，各个功能拆成微服务或是Serverless的架构。
1.1.4.1. Serverless¶
Serverless 架构由两部分组成，即 Faas (Function-as-a-Service) 和 BaaS (Backend-as-a-Service) 。
FaaS是运行平台，用户上传需要执行的逻辑函数如一些定时任务、数据处理任务等到云函数平台，配置执行条件触发器、路由等等，就可以通过云平台完成函数的执行。
BaaS包含了后端服务组件，它基于 API 完成第三方服务，主要是数据库、对象存储、消息队列、日志服务等等。
1.1.4.2. 微服务¶
微服务起源于2005年Peter Rodgers博士在云端运算博览会提出的微Web服务 (Micro-Web-Service)，根本思想类似于Unix的管道设计理念。2014年，由Martin Fowler与 James Lewis共同提出了微服务的概念，定义了微服务架构风格是一种通过一套小型服务来开发单个应用的方法，每个服务运行在自己的进程中，并通过轻量级的机制进行通讯 (HTTP API) 。
微服务是一种应用于组件设计和部署架构的软件架构风格。它利用模块化的方式组合出复杂的大型应用程序：
各个服务功能内聚，实现与接口分离。
各个服务高度自治、相互解耦，可以独立进行部署、版本控制和容量伸缩。
各个服务之间通过 API 的方式进行通信。
各个服务拥有独立的状态，并且只能通过服务本身来对其进行访问。
1.1.4.3. API网关¶
API网关是一个服务器，客户端只需要使用简单的访问方式，统一访问API网关，由API网关来代理对后端服务的访问，同时由于服务治理特性统一放到API网关上面，服务治理特性的变更可以做到对客户端透明，一定程度上实现了服务治理等基础特性和业务服务的解耦，服务治理特性的升级也比较容易实现。
1.1.5. 软件开发¶
1.1.5.1. CI/CD¶
持续集成 (Continuous Integration, CI) 是让开发人员将工作集成到共享分支中的过程。频繁的集成有助于解决隔离，减少每次提交的大小，以降低合并冲突的可能性。
持续交付 (Continuous Deployment, CD) 是持续集成的扩展，它将构建从集成测试套件部署到预生产环境。这使得它可以直接在类生产环境中评估每个构建，因此开发人员可以在无需增加任何工作量的情况下，验证bug修复或者测试新特性。