【新版】系统架构设计师 - 案例分析 - 架构设计＜Web架构＞

个人总结，仅供参考，欢迎加好友一起讨论

架构 - 案例分析 - 架构设计＜Web架构＞

Web架构知识点

高性能、高可用、可维护、应变、安全

单台机器 到 数据库与Web服务器分离

应用服务器集群

应用服务器集群，将产生如下问题：

• 用户的请求由谁来转发到具体的应用服务器
• 用户如果每次访问到的服务器不一样，那么如何维护session的一致性（负载均衡和有无状态问题）

负载均衡

负载均衡技术

应用层负载均衡

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）则相反，它会在自身保存一些数据，先后的请求是有关联的。

判断以下构件是有状态服务还是无状态服务：

• ldentification Bean（身份认证构件）
• ResPublish Bean（资源发布构件）
• ResRetrieval Bean（资源检索构件）
• onlineEdit Bean（在线编辑构件）
• Statistics Bean（统计分析构件）

持久化技术ORM

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

映射关系表

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

实现技术对比表

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

数据库技术

详细请跳转案例数据库分析，请移步以下连接：
案例分析 - 数据库设计

CDN内容分发网络

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应用服务器

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

• 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中台。本质上，都是对企业通用能力在不同层面的沉淀，并对外能力开放。

中台的践行者

Supercell，芬兰移动游戏巨头，2015年世界游戏前10占5席，员工仅200多人，因使用中台，具有小团队快速开发能力，后被腾讯86亿美金收购。

阿里，2015年参观Supercell，而后推行中台。

例如阿里中台：

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

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

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

业务中台 vs 数据中台

• 多个电商渠道使用一个下单服务，一个订单接口同时为多个前台系统提供服务。
• 多个前台系统，根据一个用户的手机号，获取对应的画像、用户的标签。
• 将多个支付通道,抽象建立成一个支付API，暴露给前台业务系统。
• 通过一个订单编号，来获取可能的商品推荐清单，从而做到交叉销售。

数据中台必备的4个核心能力：

• 数据汇聚整合能力
• 数据提纯加工能力
• 数据服务可视化
• 价值变现方面

云计算

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

优点：超大规模、虚拟化、高可靠性、高可伸缩性、按需服务、成本低【前期投入低、综合使用成本也低】。

按照服务类型分类：

• Saas（软件即服务），基于多租户技术实现，直接提供应用程序。
• Paas（平台即服务），虚拟中间件服务器、运行环境和操作系统。
• laaS（基础设施即服务），包括服务器、存储和网络等服务。

按照部署方式分类：

• 公有云，面向互联网用户需求，通过开放网络提供云计算服务。
• 私有云，面向企业内部提供云计算服务。
• 混合云，兼顾以上两种情况的云计算服务，公有云和私有云通过网络进行数据与应用的交互。

架构图如下：

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

云原生架构

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

云原生架构设计原则：

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

云原生架构模式：

• 服务化架构模式： 典型代表 【微服务】，服务拆分使维护压力大增。
• Mesh化架构模式： 把中间件框架（RPC 、 缓存、异步消息）从业务进 程中分离， 由Mesh进程完成。
• Serverless模式： 非常适合于事件驱动的数据计算任务。
• 存储计算分离模式： 各类暂态数据（如session）用云服务保存。
• 分布式事务模式： 解决微服务模式中多数据源事务问题。
• 可观测架构： 包括Logging 、Tracing 、Metrics三个方面。
• 事件驱动架构： 本质上是一种应用/组件间的集成架构模式。

云原生架构反模式：

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

微服务设计约束：

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

边缘计算

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

Web系统分层

物联网架构

应用层，应用服务智能终端。

平台层，操作系统软件开发设备管理平台连接管理平台。

网络层，接入网核心网业务网专有网络通信标准/协议。

感知层，传感器芯片通信模组感知类智能设备/装置。

大数据架构