后端架构与需求分析

description:

要交(应付)技术创新作业,仔细一写,发现写得还好,就在这存放一下

background

在当前互联网时代,前端技术已经成为人们日常生活中难以分割的一部分,如web网页、Android等。然而这些技术只是互联网中的一个很小的部分,与这些技术相比,后端的各种技术更接近日常生活中的各种需求、更像是“技术”、也更难理解。本次课题通过鱼骨分析法整理出后端技术与各种需求的关系。

content

通过整理型鱼骨分析法得出一下脉络:
后端架构与需求分析_第1张图片

账号安全

  1. 密码存放
    密码可以明文存放也可以密文存放,密文存放要比明文安全许多,有的人在多个不同平台的账号都采用一个密码,如果在传输过程中密码被泄漏,那该用户可能要遭受巨大的损失。
  2. 登录验证
    登录验证有三种:短信验证、邮箱验证和密码验证,其中短信验证可能要收取一定的费用,对于高级别的验证可以采用双重验证。
  3. 多点登录
    多点登录就是一个账号在多个不同的设备登录,多点登录可以给用户带来许多便利,但也会增加一些安全性问题
  4. 验证效率
    如果服务器要对所有的请求都进行身份验证,必将给cpu带来一些压力,这可能会使得服务器无法应对高并发情况。

静态数据

静态数据一般指:网页、图片、视频、音频,处理这些请求不需要多少计算量,速度较快,但对io的要求高,因此后端一般将静态数据与动态请求分离,将io性服务器用来应对静态请求,但也有静态和动态混合在一起的,如jsp技术。

视图

url由协议、域名和路径组成,视图可以仅由其中的路径组成、也可以由域名加路径组成。约在十年前,url还多加了个#号,#号后面的部分是与浏览器相关的,与后端无关。视图可以表示一个静态页面也可以表示一个POST请求的路径。当前流行的rest Api风格将多个相同类型的请求用同一个路径表示,采用请求类型来区分它们。

数据库

数据库用来存放数据,数据库中的表结构一般在项目开发的前期就应该设计好绝大部分。
当前的许多主流后端框架都采用的对象映射思想,将一个对象表示一张表,对象的属性表示表中的字段。
有些数据库需要应对高并发请求,如大型游戏服务器中数据库,这是可以采用redis技术。

处理动态请求

处理动态请求必将遇到的一个问题就是高并发,使用同步的方式已经无法处理高并发请求,一般用异步和协程或者两者一起来实现高并发。一般会在网关节点和处理动态请求的节点之间搭建一个缓存节点来缓存所有的请求以缓解服务器的压力。

节点监听

当后端业务量大或者遇到服务器性能瓶颈时就需要搭建集群、将程序放在集群环境下运行。这时对集群、程序的管理就成为了一个问题,微元架构是目前处理这种问题的最好方案。它的思想就是极大程度解耦。拿一个网购网站来说,网站中有:商品信息、商家信息、用户信息、用户评论信息、账单信息…对与商品信息,采用一个节点来处理与它相关的动态请求、静态请求、数据库,其他节点也这样。这样,当需要添加或删除一个节点时就不会影响其他节点。

你可能感兴趣的:(架构,需求分析,服务器)