跳至主要內容

架构设计

HeChuangJun约 3096 字大约 10 分钟

架构设计

软件的开发流程（瀑布模型）

  • 需求调研分析----需求规格说明书
  • 设计阶段（概要设计、详细设计）----页面原型、数据库设计、设计文档
  • 编码阶段
  • 测试阶段
  • 上线和运维

架构总览

5.png
5.png

传统架构(单一应用架构)

  • 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简化增删改查工作量的 数据访问框架(ORM) 是关键。
    1.png

1000并发架构(垂直应用架构 )

  • 需要20台服务器做tomcat集群。当tomcat集群中节点数量增加，服务能力先增加后下降。所以集群中节点数量不能太多，一般也就5个左右。（session共享导致只能5个）
  • 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率。此时，用于加速前端页面开发的 Web框架(MVC) 是关键。
    2.png

10000并发（分布式服务架构 ）

  • 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC) 是关键
  • 需要按照功能点把系统拆分，拆分成独立的功能。单独为某一个节点添加服务器。
  • 需要系统之间配合才能完成整个业务逻辑。叫做分布式。
  • 集群同一个工程部署到多台服务器上。
  • 分布式架构：多个子系统相互协作才能完成业务流程。系统之间需要进行通信。把系统按照模块拆分成多个子系统。
  • 优点：
  • 1、把模块拆分，使用接口通信，降低模块之间的耦合度。
  • 2、把项目拆分成若干个子项目，不同的团队负责不同的子项目。
  • 3、增加功能时只需要再增加一个子项目，调用其他系统的接口就可以。
  • 4、可以灵活的进行分布式部署。
  • 缺点：
  • 1、系统之间交互需要使用远程通信，接口开发增加工作量。
  • 2、各个模块有一些通用的业务逻辑无法共用。
    3.png

100000并发（基于soa的架构）

  • SOA：Service Oriented Architecture面向服务的架构。也就是把工程拆分成服务层、表现层两个工程。
  • 服务层中包含业务逻辑，只需要对外提供服务即可。表现层只需要处理和页面的交互，业务逻辑都是调用服务层的服务来实现。
  • 流动计算架构
  • 当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，
  • 此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。
    = 此时，用于提高机器利用率的 资源调度和治理中心(SOA) 是关键。Dubbo就是资源调度和治理中心的管理工具。
    4.png

LVS集群

  • 术语
    • VS：Virtual Server，Director Server(DS), Dispatcher(调度器)，Load Balancer（lvs服务器）
    • RS：Real Server(lvs), upstream server(nginx), backend server(haproxy)（真实服务器）
    • CIP：Client IP（客户机IP）
    • VIP：Virtual serve IP VS外网的IP
    • DIP：Director IP VS内网的IP
    • RIP：Real server IP （真实IP）
LVS集群.png
LVS集群.png

  • 工作模式

    • VNAT模式:irtual Server via Network Address Translation（VS/NAT）；通过网络地址转换，调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。用户请求和响应报文都会经过Director Server ；本质是多目标IP的DNAT，通过将请求报文中的目标地址和目标端口修改为某处的RS的RIP和PORT实现转发
    • RIP和DIP应在同一个IP网络，且应使用私网地址；RS的网关要指向DIP
    • 请求报文和响应报文都必须经由Director转发，Director易于成为系统瓶颈
    • 支持端口映射，可修改请求报文的目标PORT
    • VS必须是Linux系统，RS可以是任意OS系统
      LVS集群的NAT模式.png

  • 直接路由：Virtual Server via Direct Routing（VS/DR）；通过改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。同VS/TUN技术一样，VS/DR技术可极大地 提高集群系统的伸缩性。这种方法没有IP隧道的开销，对集群中的真实服务器也没有必须支持IP隧道协议的要求，但是要求调度器与真实服务器都有一块网卡连 在同一物理网段上。

  • 采用半开放式的网络结构，与 TUN 模式的结构类似，但各节点并不是分散在各地，而是与调度器位于同一个物理网络。

  • 负载调度器与各节点服务器通过本地网络连接，不需要建立专用的 IP 隧道

  • LVS默认模式,应用最广泛,通过请求报文重新封装一个MAC首部进行转发，源MAC是DIP所在的接口的MAC，目标MAC是某挑选出的RS的RIP所在接口的MAC地址；源IP/PORT，以及目标IP/PORT均保持不变
    LVS集群的直接路由模式.png

  • IP隧道：Virtual Server via IP Tunneling（VS/TUN）:采用NAT技术时，由于请求和响应报文都必须经过调度器地址重写，当客户请求越来越多时，调度器的处理能力将成为瓶颈。为了解决这个问题，调度器把请求报 文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。由于一般网络服务应答比请求报文大许多，采用 VS/TUN技术后，集群系统的最大吞吐量可以提高10倍。

  • RIP和DIP可以不处于同一物理网络中，RS的网关一般不能指向DIP,且RIP可以和公网通信。也就是说集群节点可以跨互联网实现。DIP, VIP, RIP可以是公网地址。

  • RealServer的通道接口上需要配置VIP地址，以便接收DIP转发过来的数据包，以及作为响应的报文源IP

  • DIP转发给RealServer时需要借助隧道，隧道外层的IP头部的源IP是DIP，目标IP是RIP，而RealServer响应给客户端的IP头部是根据隧道内层的IP头分析得到的，源IP是VIP，目标IP是CIP

  • 请求报文要经由Director，但响应不经由Director,响应由RealServer自己完成

  • 不支持端口映射

  • RS的OS须支持隧道功能

  • 一般来说，隧道模式常会用来负载调度缓存服务器组，这些缓存服务器一般放置在不同的网络环境，可以就近折返给客户端。在请求对象不在Cache服务器本地命中的情况下，Cache服务器要向源服务器发送请求，将结果取回，最后将结果返回给用户。
    LVS集群的隧道模式.png

  • LVS工作模式总结和比较
    |对比项|NAT|TUN DR|
    |-|-|-|
    |优点|端口转换|WAN|性能最好|
    |缺点|性能瓶颈|服务器支持隧道模式|不支持跨网段|
    |真实服务器要求|any Tunneling|Non-arp device|
    |支持网络|private（私网）|LAN/WAN（私网/公网）| LAN（私网）|
    |真实服务器数量|low (10~20)|High (100)| High (100)|
    |真实服务器网关|lvs内网地址|Own router（网工定义）| Own router（网工定义）|

  • LVS中，Director Server容易发生单点故障，HA+keepAlived方案，支持使用VRRP协议，使用ipvsadm 工具配置Director Server

  • 网站架构图
    网站架构图.png

高性能设计

高性能设计.png
高性能设计.png
  • 串行无锁：Nginx/Redis的reactor模型，主线程负责处理 I/O 事件，并将读到的数据压入队列，工作线程则从队列中取出数据进行处理，这种半同步/半异步模型需要对队列进行加锁，可以优化成当 MainReactor accept 一个新连接之后从众多的 SubReactor 选取一个进行注册，通过创建一个 Channel 与 I/O 线程进行绑定，此后该连接的读写都在同一个线程执行，无需进行同步。
  • 结构无锁：使用CAS
  • 序列化：当将数据写入文件、发送到网络、写入到存储时通常需要序列化（serialization）技术，从其读取时需要进行反序列化（deserialization），又称编码（encode）和解码（decode）。序列化作为传输数据的表示形式，与网络框架和通信协议是解耦的。如网络框架 taf 支持 jce、json 和自定义序列化，HTTP 协议支持 XML、JSON 和流媒体传输等。
    • 分类
      • 内置类型：指编程语言内置支持的类型，如 java 的 java.io.Serializable。这种类型由于与语言绑定，不具有通用性，而且一般性能不佳，一般只在局部范围内使用
      • 文本类型：一般是标准化的文本格式，如 XML、JSON。这种类型可读性较好，且支持跨平台，具有广泛的应用。主要缺点是比较臃肿，网络传输占用带宽大。
      • 二进制类型：采用二进制编码，数据组织更加紧凑，支持多语言和多平台。常见的有 Protocol Buffer/Thrift/MessagePack/FlatBuffer 等。
    • 衡量序列化/反序列化主要有三个指标： 1）序列化之后的字节大小； 2）序列化/反序列化的速度； 3）CPU 和内存消耗；
    • 冗余请求指的是同时向后端服务发送多个同样的请求，谁响应快就是使用谁，其他的则丢弃。这种策略缩短了客户端的等待时间，但也使整个系统调用量猛增，一般适用于初始化或者请求少的场景。公司 WNS 的跑马模块其实就是这种机制，跑马模块为了快速建立长连接同时向后台多个 ip/port 发起请求，谁快就用谁，这在弱网的移动设备上特别有用，如果使用等待超时再重试的机制，无疑将大大增加用户的等待时间。
  • 调用异步化
    • Callback异步回调通过注册一个回调函数，然后发起异步任务，当任务执行完毕时会回调用户注册的回调函数，从而减少调用端等待时间。这种方式会造成代码分散难以维护，定位问题也相对困难。
    • Future：当用户提交一个任务时会立刻先返回一个 Future，然后任务异步执行，后续可以通过 Future 获取执行结果。对 1.4.1 中请求并发，我们可以使用 Future 实现，伪代码如下：
    • CPS:(Continuation-passing style) 可以对多个异步变成进行编排，组成更复杂的异步处理，并以同步的代码调用形式实现异步效果。CPS 将后续的处理逻辑当作参数传递给 Then 并可以最终捕获异常，解决了异步回调代码散乱和异常跟踪难的问题
  • 异步流程：使用MQ
  • 缓存使用场景
    • 一旦生成后基本不会变化的数据
    • 读取密集型或存在热点数据
    • 计算代价大的数据
    • 千人一面的数据
  • 不适合使用缓存的场景
    • 写多读少，更新频繁
    • 对数据一致性强