前端,把 api 封装到一个文件夹到底有没有必要

*近在改一个 vue 项目,看了很多 api 接口封装的文章,似乎这是主流的处理方式?

于是尝试了一下发现了几个问题。

首先,管理是集中了,不过有点类似于 vuex 的思维方式。看过很多人不提倡把请求放在 vuex 里,而使用就近原则,不过本题的 api 接口封装,虽然只是把一些基本实例写好在导入到模板文件中,但是还是让人感觉到了 vuex 那个味。

其次,修改起来感觉没有独立方便,导入还有改名什么的有点麻烦了,感觉 api 端口修改频率都不如参数的修改高。尤其是需要改名的时候,忘记改一个地方的情况经常发生。

所以想问问,这种方案真的是主流的处理方式嘛?真的有必要嘛?

API vuex 封装 修改24 条回复 • 2021-08-30 16:35:37 +08:00
hackyuan 1
hackyuan 6 小时 53 分钟前
选中函数名 F2
acthtml 2
acthtml 6 小时 48 分钟前
抽象出来,放在一个独立的文件夹主要解决:

1. 多个前端组件可能对同一个 [后端服务复用] 。
2. 组件不依赖于服务,而是依赖于服务的产生的数据,方便 [前端组件的复用] 。
3. 结构清晰,如果后端服务改动,可以很容易做修改。
zarvin 3
zarvin 6 小时 45 分钟前
vue 开发全局搜索用得多,看了几个开源项目好像都是这样
shzx1994529 4
shzx1994529 6 小时 41 分钟前
一个路由一个 api.js 呗,这玩意无所谓啊,能让别人看懂就行
Yooe 5
Yooe 6 小时 40 分钟前
我怎么记得之前好像看到过这个帖子?= =
Kusoku 6
Kusoku 6 小时 40 分钟前 ❤️ 1
小的项目放在一起就是为了方便统一维护,根据模块拆分到不同的小文件也是为了按需要引入,这种组织方式可以适应*大部分项目的需要。如果按模块划分子文件夹,然后再每个子文件夹再划分各种小文件夹,有部分公共请求也需要单独拿出来,实际上还不如单独用一个文件夹来放请求接口配置的内容,区分公共部分和模块部分,这样清楚明晰方便定位。
chenluo0429 7
chenluo0429 6 小时 39 分钟前
api 接口封装就是为了对组件屏蔽后端的具体实现,同时统一处理接口的变更。
如果有参数变更,封装反而可以通过默认值等手段来快速适配。如果有破坏性的变更需要全部修改,封装的你都能忘记,独立的你就一定改得全?
mozhizhu 8
mozhizhu 6 小时 38 分钟前
你经历过后端改请求方式吗?经历过后端改路由吗?
cydysm 9
cydysm 6 小时 33 分钟前
不同项目有不同的处理方式,没有银弹,写得多了就知道怎么办了。
netwjx 10
netwjx 6 小时 24 分钟前 ❤️ 2
没有显著必要, 曾经多年 java 和 dotnet, 熟悉各种 MVC, ORM

在前端领域, 将 ajax 调用抽取成函数, 99%是脱裤子放屁

因为 ajax 请求的代码量很少, 后端是因为这部分业务逻辑比较多, 必须复用

前端就算写 3 遍 ajax 调用, 重复的只有 1~2 行, 所谓封装, 只是将这部分重复的代码, 变成了重复的函数调用, 并没有实质意义, 反而增加了一层映射关系(函数名 -> ajax URL)

不重复的部分是如何生成不同的 ajax 请求参数, 而切实有效的封装, 是真能减少重复业务逻辑的

比如根据业务逻辑

– 规整各种 ajax 请求参数: id 必须转换成有效数字, 而不能是字符串
– 处理 ajax 响应参数: 转换成适合前端使用的格式

另一类需要集中处理的逻辑, 用 ajax 模块插件实现

– 认证和授权, 引导到登录界面, 申请权限界面
– 异常处理, 上报和用户友好提示
– 接口缓存
– 并发控制

libook 11
libook 6 小时 20 分钟前
抛开场景谈对错都是耍流氓。

一个 Vue 项目是由各种类别的模块组成的(如组件、服务、路由……),对于不同项目来说;不同类别的模块规模不同,比如可能营销项目路由路由巨多、组件和服务很少,后台项目路由很少、组件和服务巨多;模块之间的对应关系也不一样,比如有的项目服务可以被所有组件复用,也有的项目服务是从属于各个组件的,不可跨组件使用。
Vue 提供了项目文件结构的灵活性,那么自然在不同场景下可以设计成不同的文件结构,*终都是服务于开发效率。
Biwood 12
Biwood 5 小时 55 分钟前 ❤️ 1
我也觉得有些多余,明明 request 工具在组建里面直接请求就行了,还要多封装一层,而且这些请求函数复用性特别低,*大部分都只在一个模块用到了一次而已。真有复用的情况,也是跟着组件一起,而不是单独调用。有种过度设计的感觉。

@libook
楼主说的应该是那种纯粹的 api 封装,只是提前固定了路径和 method 而已,不携带具体的业务数据,你说的“服务”的概念其实已经在 api 基础上做了其他业务逻辑了。
lin07hui 13
lin07hui 5 小时 55 分钟前
我这边之前的人封装的
// src/api/index.js
export * from “./xxx.js”;

// src/api/xxx.js
export const xxxDetail = (id) => { … };
export const xxxList = ({ page, … }) => { … };
export const xxxSave = ({ id, … } ) => { … };

// src/store/modules/xxx.js
import { xxxDetail, xxxList, xxxSave } from “@/utils/api”;
import { createState } from “@/utils/state”;

const options = createState({ detail: { api: xxxDetail, … }, list: { api: xxxList, … }, save: { api: xxxSave, … });

export default {
namespaced: true,
…options
};

// src/utils/state — 248 行代码
// createState
/**
* Create a store options
* @param {Promise} list.api – 获取分页列表数据接口
* @param {Object} list.params – 发送给接口的参数
* @param {Function} list.beforeSet – 设置数据之前执行,beforeSet(接口数据)
* @param {Promise} detail.api – 获取单条数据接口
* @param {Object} detail.params – 发送给接口的参数
* @param {Promise} save.api – 保存接口
* @param {Function} save.success – 保存成功后运行:success({ commit, state, dispatch }, record)
* ….还有很多
*/
Biwood 14
Biwood 5 小时 53 分钟前
当然,如果是 TypeScript 项目,这样写比较方便提前约定前后端字段的对应关系,类似于 adapter 的概念
lin07hui 15
lin07hui 5 小时 51 分钟前
@lin07hui #13 import { xxxDetail, xxxList, xxxSave } from “@/api”;
ansenJ 16
ansenJ 5 小时 51 分钟前
初期多人开发的时候 别说 API 了 Store Router 都是每人一个文件, 等项目稳定了再汇总的。多人操作一个文件的那位, 你是爱上解决 git 冲突吗?
fernandoxu 17
fernandoxu 3 小时 52 分钟前
按领域组织更好,
Sapp 18
Sapp 3 小时 12 分钟前
现在 api 不都是自动生成函数么?还有人手写???
chairuosen 19
chairuosen 3 小时 6 分钟前 ❤️ 2
说不需要的都没写过大项目?
cloudzqy 20
cloudzqy 2 小时 37 分钟前
现在基本 typescript 了,基本都封,定义类型比较方便。
kennhuang 21
kennhuang 2 小时 16 分钟前 via iPhone
写 unit tests 的同学就知道封装出来的好处了?
hitaoguo 22
hitaoguo 1 小时 52 分钟前
我用装饰器做的封装,代码类似这样。

然后页面里就直接这样用

ccraohng 23
ccraohng 1 小时 25 分钟前
api 配置对象配合 ts 输出 一个类似 service 的对象
chairuosen 24
chairuosen 52 分钟前
不封在一起,所有请求通用的:鉴权、域名配置、封装协议解构、异常判断、日志、重试、超时、token 过期重拿、mock 、监控、、、、、等等等等写在哪里。后端换个域名、path 、封装协议,甚至接口实现要所有地方挨个找么?

按道理,所有非你项目代码实现的部分,都不应该直接在业务逻辑里调(比如 http 接口,RN 里的客户端接口,SDK 的接口),应该有个 adapter 层来做对接,都是不可信的,没准哪天对方心情不好想改就改的,他改了你不可能全局搜代码改吧。

后端如何学前端?不求精,求快就行

*近需要接触一些前端的代码,无奈一直写后端,受不了 js 的各种奇葩问题、另类语法、各种封装。。。。

语法 另类 封装 奇葩54 条回复 • 2021-07-28 13:45:29 +08:00
erenming 1
erenming 16 小时 10 分钟前 via iPhone
同求
jiyinyiyong 2
jiyinyiyong 16 小时 5 分钟前
我看聊天时候听到的是说后端直接找个牛逼的全家桶的框架然后直接学框架, 然后框架连 JavaScript 的语法都封装掉…. 然后就不用碰 React 那些奇奇怪怪的设计了.

问下楼主后端的, 学的哪些语言?
learningman 3
learningman 16 小时 2 分钟前
前端是吧,直接 vue
js 都不会都能写 vue
TypeError 4
TypeError 15 小时 52 分钟前
JS 框架加上 UI 框架?
falcon05 5
falcon05 15 小时 51 分钟前 via iPhone
我以前也很排斥,但发现用上 es6 之后,js 写得还挺爽的…
harde 6
harde 15 小时 49 分钟前
技术发展到今天,前端的碎片化比后端严重得多,你得告诉大家你想学哪方面的?
Kaciras 7
Kaciras 15 小时 41 分钟前 ❤️ 1
JS 尽量用新特性,能避免大部分坑
kiracyan 8
kiracyan 15 小时 27 分钟前
直接上手做
limbo0 9
limbo0 15 小时 18 分钟前
ant design pro 上手比较快, 建议试试
letking 10
letking 15 小时 11 分钟前 ❤️ 6
别狭隘地把自己局限于前端、后端或某种语言。
面对新东西,把自己当成初学者踏踏实实地学,你就能学会,还能发现它设计的精妙之处,而不是只看到缺点。

ysicing 11
ysicing 15 小时 8 分钟前
直接上手
johnsona 12
johnsona 15 小时 0 分钟前 via iPhone
vue
ericgui 13
ericgui 13 小时 10 分钟前
写 react 吧,概念简单,语法就是一个类似 html 或者 xml 的结构,你如果熟悉 xml 和 html,应该很快的,尤其是 xml
SingeeKing 14
SingeeKing 12 小时 40 分钟前 via iPhone
我的解决方案是 Web Assembly,但是坑也一堆,今天看阿里好像出了个只用写 JSON 的前端低代码平台可以试试
hddcpu 15
hddcpu 12 小时 18 分钟前 via Android
等 blazor wasm 中
g079708 16
g079708 8 小时 39 分钟前 via iPhone
@SingeeKing 阿里这个叫啥名字
dayeye2006199 17
dayeye2006199 8 小时 11 分钟前
简单的需求,用后端框架+模板引擎 也差不多基本搞定了。
稍微再复杂点,上点原生 JS 也差不多能搞定了。
别想着天天写 SPA 上前端框架了。

实在不想写 JS,激进点 – scala.js, clojurescript, …
beginor 18
beginor 7 小时 43 分钟前 via Android
angular,全家桶就是香。
musi 19
musi 7 小时 36 分钟前
上 Vue,按照 Vue 的模板写,不会有太大的心智负担。
一些冷门语法只能去 mdn 上查了
奇葩封装没有文档的话无解,只能去看源码
kensoz 20
kensoz 6 小时 9 分钟前
wordpress,各种模板不香嘛
Eyon 21
Eyon 6 小时 2 分钟前
我的答案是:

直接用 Vue 做一个项目,整个项目的那种
darknoll 22
darknoll 6 小时 1 分钟前 via Android
后端都会了,前端还不是分分钟的事
murmur 23
murmur 5 小时 53 分钟前
es6 可以不用,有些开发就是每个函数之前都 var self = this 。然后各种 self,也挺好

不要拘泥于语法糖,能用库就库,比如闭包这些东西,不是有 bind 了么
silencil 24
silencil 5 小时 49 分钟前 via iPhone
我是看了 js 红宝书,然后根据需求直接搜解决方法,跟着写,现在基本用 vue 写前端大部分时候不需要搜索了,除了样式。
silencil 25
silencil 5 小时 48 分钟前 via iPhone
如果不想学前端,推荐一个谷歌出品的框架,vaddin 。哈哈,谁用谁知道
maobukui 26
maobukui 5 小时 38 分钟前
和楼主类似,花了些时间学了下 ios,做了个天气 app,学了下 react,做了个小图床

图床: https://img.mengma021.com
iamv2er 27
iamv2er 5 小时 10 分钟前 via iPhone
vue 找个视频直接写 很快
xd199153 28
xd199153 4 小时 43 分钟前
@letking 比较同意。
我觉得后端们学习一个新的领域要摆正心态,

“前端这么简单,我应该看两眼就学会了嘛。这个写的这么 low,肯定是前端全都这么写” 这种心态不要有。

你觉得是奇葩的写法那就去找更优的写法,又不是没有。
xd199153 29
xd199153 4 小时 42 分钟前
@darknoll 忘记加狗头了
Maboroshii 30
Maboroshii 4 小时 40 分钟前
js 感觉和后端差不多 ,if else for 循环就能搞定大部分需求了吧… 麻烦的是布局
wellsc 31
wellsc 4 小时 39 分钟前
@harde 求数据出处
Yrobot 32
Yrobot 4 小时 29 分钟前 via Android
前端又不仅仅是 js,还有 css 。想要快的实现,还是上框架得了,antd pro 啥的,自己往里加点简单业务逻辑就能用了。
oppoic 33
oppoic 4 小时 26 分钟前
5 年以上的码农,谁还不会点 jQuery 啊
exploreexe 34
exploreexe 4 小时 24 分钟前
难道只有我一个人觉得学前端*难的是 CSS 吗
janxin 35
janxin 4 小时 14 分钟前 via iPhone
jquery 一把梭
bsulike 36
bsulike 4 小时 12 分钟前
低代码的话,也可以看下百度开源的 amis
PHPJit 37
PHPJit 3 小时 57 分钟前
@exploreexe #34 +1
x66 38
x66 3 小时 27 分钟前
上低代码框架,推荐 amis
murmur 39
murmur 3 小时 25 分钟前
@exploreexe css 不会是模块和布局拆解不熟练,flex 布局+不需要 ie 可以解决以前老前端 80%的工作量

*早的前端圆角都得自己贴图,现在 css 全搞定
samin 40
samin 3 小时 24 分钟前
@harde 我愿称之为组件化、模块化 (目的,让这位后端小伙伴打消念头)
sudoy 41
sudoy 3 小时 15 分钟前
我一直觉得 vue 好奇怪,明明是一个 js 框架,并且官方文档也写了 “官方指南假设你已了解关于 HTML 、CSS 和 JavaScript 的中级知识…”,可是学完 js 去学 vue 各种不习惯
luozejian 42
luozejian 3 小时 13 分钟前
从 Angular 入手?
murmur 43
murmur 3 小时 11 分钟前
@sudoy vue 只是把 html css js 分三段放在一个文件里,css 单独拿出来 include 也可以,有什么不习惯

都是模板引擎过来的人,还是太嫩
simo 44
simo 3 小时 9 分钟前
看大家推荐吧,我只是来吐槽前端的。
搞过各种语言项目,在我学过的这些语言范围内,前端*对是自己卷自己*猛的。虽然浏览器说不要你了,轰死一片,但杀伤力完全不如自己玩自己来得狠。
在前端这片松散、自由、是个人都能生存的土壤上,刷 kpi 出来的东西就像比蟑螂还要多。
piping 45
piping 3 小时 3 分钟前
quasar 框架(基于 vue js), 强力推荐!!你想做的基本官网文档都能找到,大部分功能写一些 html 就能实现了,无论是做 SPA,Mobile Web, PWA, SSR 都很方便
wangyzj 46
wangyzj 2 小时 20 分钟前
vue
Frytea 47
Frytea 2 小时 5 分钟前
框架三千,只取一瓢饮
inhal 48
inhal 2 小时 3 分钟前
学 Svelte
zhaol 49
zhaol 1 小时 58 分钟前
接触过模版引擎的后端直接来 vue,上手应该很快,ui 框架 antd for vue 或者 elementUI
micean 50
micean 1 小时 16 分钟前
当然是直接上 jquery 啦,写起来快,改起来快,查起来也快
charexcalibur 51
charexcalibur 53 分钟前
搞 vue admin,antd pro,把后端接口可视化配置,基本上就差不多了
shintendo 52
shintendo 43 分钟前
楼上全是推荐这框架那框架的,楼主是要接触一些前端代码,当然代码用的什么框架就学什么框架
zxCoder 53
zxCoder 17 分钟前
写 vue 吧,概念简单,语法就是一个类似 html 或者 xml 的结构,你如果熟悉 xml 和 html,应该很快的,尤其是 xml
thtznet 54
thtznet 14 分钟前
后端要写前端?太好了,C#一把梭适合你。

一次下载多个文件的解决思路-JS

真实经历

*近开发项目需要做文件下载,想想挺简单的,之前也做过,后台提供下载接口,前端使用window.location.href就行了呗。不过开发的时候发现,有些文件有附属文件,点击 下载按钮 需要下载两个文件,而且不能使用压缩包的形式。想想不是也挺简单,点击 下载 发送两个下载请求不就搞定了么。

说干就干,三下五除二就写好了,当点击 下载 的那一刻懵逼了, *个请求竟然自动Cancelled了,顿时一万个草泥马崩腾而过(因为是国外服务器,下载比较慢导致*个请求被Cancelled),这就意味着快速点击不同的 下载 按钮也会有同样的问题,这不行啊,然后开始了自己的下载探索之旅。


a标签 & location.href

我们知道a标签及href指向的如果是一个下载链接,那么相当于下载文件,对于单文件下载还是ok的,不过快速点击几个下载按钮,有的下载会被Cancelled,这可不行,继续百度。

上一段代码:

  1. const download = (url)=>{
  2. window.location.href = url;
  3. }

window.open

我们知道window.open可以打开一个新窗口,那么是不是可以实现下载呢,激动的我赶紧试了试,下载的确可以,不过会快速打开一个新窗口并且关闭,体验非常不好,果断放弃了。


iframe

突然想到iframe也可以向服务器发请求的,激动的我又赶紧试了试,哇塞,果然可以下载,而且没有违和感,代码贴出来。

  1. export const downloadFile = (url) => {
  2. const iframe = document.createElement(“iframe”);
  3. iframe.style.display = “none”; // 防止影响页面
  4. iframe.style.height = 0; // 防止影响页面
  5. iframe.src = url;
  6. document.body.appendChild(iframe); // 这一行必须,iframe挂在到dom树上才会发请求
  7. // 5分钟之后删除(onload方法对于下载链接不起作用,就先抠脚一下吧)
  8. setTimeout(()=>{
  9. iframe.remove();
  10. }, 5 * 60 * 1000);
  11. }

ps: iframe不会相互影响,可以连续下载哦!


其他方案

当然还有一些其他方式,Form下载、二进制流下载等,有空的小伙伴自行研究吧!

前端是不是应该更注重性能优化,有什么大型前端项目学习?

目前在学前端,以为一直以为前端就是前端,现在深入了解之后发现其实前端也是部属在后端,就是前端所需的资源(代码 /样式 /资源)等都存储在后端的。只不过浏览器在打开的时候,从后端去获取信息再加载到浏览器中运行。

所以从这点来说,前端更加要注重性能:
1. 资源和数据要尽量小,方便快速传输加载。
2. 因为浏览器要开很多页面,所以前端资源应该尽早释放,要注重内存优化。
3. 前端已经不是单个静态网页,而是复杂的容器(可以做复杂的事情,比如 canvas,webgl )。

不知道大型前端项目的代码量有多少(应该也大不到哪里去,跟后端比就是小虾米)?
前端对构建大型应用的可能性有多大?
前端 后端 浏览器 资源21 条回复 • 2021-07-16 13:56:53 +08:00
murmur 1
murmur 1 天前 ❤️ 1
前端优化只能砍需求,而这个几乎没法实现,懒加载你的首页还是一堆乱七八糟的,懒也懒不到哪里去

一个清爽的首页无论怎么做都很优化,堆旧淘宝那对乱七八糟的东西在首页,怎么优化首屏都下不来
66beta 2
66beta 1 天前
(应该也大不到哪里去,跟后端比就是小虾米)
KisekiRemi 3
KisekiRemi 1 天前 ❤️ 1
原本以为是面向用户体验进行开发,现在才明白是面向领导和公司开发
rioshikelong121 4
rioshikelong121 1 天前
现在一个 tab 随随便便占几百 MB 内存。吓人。
CodeCodeStudy 5
CodeCodeStudy 1 天前 ❤️ 1
第 2 点不成立,浏览器开很多页面跟前端的工作没有什么关系,只要当前页面不卡顿就行,过度优化没有用
3dwelcome 6
3dwelcome 1 天前
“3. 前端已经不是单个静态网页,而是复杂的容器(可以做复杂的事情,比如 canvas,webgl )。”

老外有句话:选*合适的语言,做*合适的事情。

JS *好就是快速开发单页面应用,也别太在乎性能。你说搭建大型 webgl 应用,不是不可以,但对于 JS 来说,巨型项目代码管理压力真的还挺大。
maplerecall 7
maplerecall 1 天前 via Android
大型也得有个参照,举个例子,Bing 的前端部分代码 clone 下来大概 100 多 GB 。虽然包含了一些资源和测试文件,但其中无论整体框架还是业务代码的复杂度远超业界*大部分后端项目了。

另外随着 node 应用越来越广泛,现在前端工作其实已经混合了不少之前属于后端的内容。不同项目的偏重性也都不一样,并不能武断的说前端代码量就一定小。例如工具、编辑器以及*近流行的 lowcode 类项目的前端代码量很多都远超后端部分的。
James369 8
James369 1 天前
@maplerecall bing 前端是什么项目
SergeGao 9
SergeGao 23 小时 42 分钟前
@maplerecall 好奇 Bing 前端都包括了什么? 100GB 的前端项目还没见过。。
murmur 10
murmur 23 小时 38 分钟前
@maplerecall 因为 node 做后端就把后端强行算前端就没意思了,虽然大家都是全干,但是讨论的时候还是按浏览器和服务器划分

ericgui 23 小时 35 分钟前
能做的事越复杂, 性能就越差

所以你只能做平衡,在满足公司业务的需求的同时,别太慢了,就行了。
toesbieya 12
toesbieya 22 小时 40 分钟前
之前有看过有人说腾讯文档前端有上百万行代码
godblessumilk 13
godblessumilk 22 小时 28 分钟前 ❤️ 1
可以了解下 OHIF viewer 这个前端项目,一个在线的 DICOM 协议医疗图像查看器,涉及到了大量的 webGL 和 canvas 对二进制流的渲染以及图像处理,工程复杂度和代码量都远超常规小体积图像文本处理的后端,https://viewer.ohif.org/ 是个典型的 PWA 离线 web 应用,server worker 让 js 开了多线程提高性能
a4854857 14
a4854857 21 小时 59 分钟前
@godblessumilk 简单扫了一眼你的描述顺手打开还蛮吓人
CraxClive 15
CraxClive 19 小时 38 分钟前 via iPhone
@a4854857 的确吓人…
banricho 16
banricho 19 小时 34 分钟前 via Android
看方向,数据可视化、地图这种,或者石墨文档、Notion 这类都是比较复杂的前端业务。不要光看代码量,很多电商或管理后台只是页面多,但实际上难度并不大。
DiamondYuan 17
DiamondYuan 17 小时 12 分钟前 via iPhone ❤️ 3
推荐读 vscode 源码

1. 代码量大,有 50 万行
2. 用了大量设计模式,vscode 的开发者是 《设计模式》 这本书的作者。
3. 附带了 monaco,优秀的前端编辑器。(几乎所有 cloud ide 用的都是 monaco
4. 跨平台( mac windows linux,跨端 ( node electron web,可以了解到如何通过依赖注入屏蔽环境差异,如何组织代码
5. 自带插件系统,可以学习如何设计一套优秀的插件 api,学习如何进行进程隔离。
6. 主题:学习如何实现动态换肤
7. 语言服务(lap): 这个不做编辑器可以不看
8. src/vs/base 包含一系列基础库,可以拷贝到自己心目里直接用
blessyou 18
blessyou 17 小时 1 分钟前 via Android ❤️ 1
等一等,优化的前提是有监控或者数据对比。没有就只能瞎吹。
DiamondYuan 19
DiamondYuan 16 小时 57 分钟前 via iPhone
除了 vscode,还可以看 chrome 的 devtool (没错,这个是前端项目)。
yunyuyuan 20
yunyuyuan 4 小时 51 分钟前
优化是用来面试的

前端大佬们,移动端布局不用 REM 用什么?

刚才看到这个文章 https://zhuanlan.zhihu.com/p/378619948

其中说到 rem 布局,有点疑惑。如果不用 rem 应该如何做自适应?
rem 布局 疑惑 大佬27 条回复 • 2021-06-25 13:02:52 +08:00
murmur 1
murmur 2 小时 28 分钟前 ❤️ 1
没有自适应,不适应,用一些相对布局,能拉开就行

强制做自适应的结果,就是小米主站的横屏手机显示,直接 chrome 选调试工具转一下屏就可以看到效果了
emonc 2
emonc 2 小时 27 分钟前
可以用 vw/vh
关于这个文章,考虑到 V 站不能说脏话我就不予置评了
kop1989 3
kop1989 2 小时 25 分钟前
实用层面上的自适应无非就是宽度匹配。

真正需要横屏、pad 使用的时候,考虑到内容密度的问题,你靠宽度匹配也不合适了。
需要重新规划布局,重新渲染。
wenzichel 4
wenzichel 2 小时 23 分钟前 ❤️ 1
我们现在用的是 vw 和 /vh,配合着 webpack 的插件 postcss-px-to-viewport,可以将源码中的 px 转为 vw 单位。

require(‘postcss-px-to-viewport’)({
viewportWidth: viewportWidth || 750, // 设计稿的宽度
unitPrecision: 3, // 单位精度,即保留几位小数
viewportUnit: ‘vw’ // 转换后的单位
}),
mxT52CRuqR6o5 5
mxT52CRuqR6o5 2 小时 15 分钟前 ❤️ 2
@emonc 把别人带坑里去,自己水平就变相提高了
dagouziwangwang 6
dagouziwangwang 2 小时 8 分钟前
emmm 文章里说 “FaceBook 使用 Tailwind CSS 重构后,节省了接近 70%的 css 代码,威力惊人”,好奇 className 多了多少
Vegetable 7
Vegetable 2 小时 8 分钟前
移动端我的体会是,如果不考虑横屏,vw/vh 很好用。引入横屏会麻烦一点。

这个文章早就看过了,一言难尽…
qaqLjj 8
qaqLjj 2 小时 3 分钟前 via Android
vw 啊
murmur 9
murmur 1 小时 51 分钟前
无论 vw,vh 都有个单位,*忌讳的是设计一个全局变量,妄图通过修改这个变量适配各种屏幕尺寸,而且国产手机的 rom 各种魔改,你不知道在 ui 设定缩放的时候会出现什么奇葩问题

你看各家,有几个适配的,都是选一个*小尺寸,比如横排*小只能 4 个按钮,那更宽就加大间距,竖排因为可以滚动所以几乎必须要考虑,真遇到横屏,两边留白

遇到需要大字体的时候,基本没几个管的,微信是有内置字体调整,其余的你只能祈祷有老年人模式

除非你是对横屏非常依赖的东西,比如视频、游戏、文档编辑预览等

想做自适应,除非你页面简单到一行字一张图,稍微复杂一点需要排版就容易崩

至于折叠屏,你看有几家适配,当然折叠屏也不需要适配,这么大屏幕都可以显示电脑版了
murmur 10
murmur 1 小时 51 分钟前
更正:必须要=》没有必要

Dukewill 11
Dukewill 1 小时 48 分钟前
小白请教下,vw/vh 跟直接用 % 有啥区别
learnshare 12
learnshare 1 小时 47 分钟前
em/rem 仅推荐应用在文本相关的属性中,如:
font-size/line-height/text-indent/word-spacing/letter-spacing/text-shadow 等

禁止在布局相关的属性中使用,如:
width/height/margin/padding 等

根据 root.font-size(rem) 调整布局或整体缩放是错误的做法
px2rem 更是纯粹的自讨苦吃

(小程序 750rpx 也是这种方式,开发 /设计省事了,pixel perfect 没了,更大的屏幕没法适配)
ericls 13
ericls 1 小时 45 分钟前 via iPhone
@Dukewill percent 都是爸爸的宽度
yl20181003 14
yl20181003 1 小时 44 分钟前
@Dukewill #11 百分比是相对父元素的吧,vw/vh 相对视窗大小
KuroNekoFan 15
KuroNekoFan 1 小时 42 分钟前
自适应和相对长度单位是两个问题,自适应应该理解为针对不同特性的设备有不同的 layout
另外,相对长度单位也没必要用 rem,直接上 vw 即可,配合蓝湖的自定义屏幕宽度很方便
learnshare 16
learnshare 1 小时 41 分钟前
总结来说,**缩放** 是 **适配(响应式)** 手段中*不该选择的方式之一
kensoz 17
kensoz 1 小时 39 分钟前
似乎现在 vw/vh 是主流?我这现在还在用 rem
kuxuan 18
kuxuan 1 小时 37 分钟前 via iPhone
各位大佬,有用 vw/vh 做的示例吗,给个看看。
wunonglin 19
wunonglin 1 小时 31 分钟前 ❤️ 1
自适应 !== 缩放
CodingNaux 20
CodingNaux 1 小时 21 分钟前
设计师偷懒只设计移动端界面,然后说适配 ipad,单纯放大,所谓的适应是这种吗?
这种没啥意思。

可以看看 bootstrap 怎么用 rem 的。响应式设计老生常谈了,但国内一般就是放大就所谓的适配,设计师也接受
tinkerer 21
tinkerer 1 小时 4 分钟前
@mxT52CRuqR6o5 哈哈哈哈哈哈,你这个观点的角度很不错
3dwelcome 22
3dwelcome 46 分钟前
这文章本身就是矛盾的。

作者推荐用 Tailwind CSS,可里面 REM 满天飞,我还在 V2 发过贴,专门吐槽过这点。
3dwelcome 23
3dwelcome 42 分钟前
@murmur “想做自适应,除非你页面简单到一行字一张图,稍微复杂一点需要排版就容易崩”

只要不是随心所欲手写 span 外套 div,严格按照布局规范来做(FLEX/GRID/BOOTSTRAP),感觉要崩也难。

我现在复杂布局,都是用代码根据设计稿自动生成,*少保证自适应在视觉上的一致性。

至于美不美观另说。
molvqingtai 24
molvqingtai 29 分钟前 via Android
手写的时候 vw/vm rem 配合着用,现在嘛,当然是 taiwindcss 啦
IvanLi127 25
IvanLi127 27 分钟前 via Android
目前看 大部分用 rem 搞自适应的,都是叫缩放,惨不忍睹。
otakustay 26
otakustay 18 分钟前
这问题你研究再深也无解的,它的根源是设计给的是什么,是响应式还是所有设备长一个样。设计要所有设备一个样,那实现上 rem 就是*佳的,归根到底设计水平太差
lrabbit 27
lrabbit 4 分钟前
@kuxuan https://www.lrabbit.life,基本只有 vw/vh

前端如何获取当前用户名和其他用户信息 需要一个 单独的 api 吗

1
chaleaoch 3 小时 18 分钟前
登录成功之后会返回当前用户信息.

但是切到别的 component 或者关掉浏览器之后在打开. 前端如何处理呢?

session 是有效的,但是前端不知道当前用户是谁了.

local storage?
wotemelon 2
wotemelon 3 小时 16 分钟前 ❤️ 1
需要一个获取用户信息的接口。如果是 ssr 更好,直接写到 store
Vegetable 3
Vegetable 3 小时 11 分钟前 ❤️ 1
常见的系统设计中,一般是以下 3 个情况

– 登录返回信息
– 登录不返回+独立获取信息接口
– 登录返回+独立获取信息接口

前端通常会将用户的信息持久化到本地,方案如 cookie 或者 local storage,至少也是使用 redux 之类的工具在内存里留一份,避免需要的时候只能再次请求接口
keepeye 4
keepeye 3 小时 8 分钟前 ❤️ 1
GET /profile
keepeye 5
keepeye 3 小时 8 分钟前 ❤️ 1
一般是需要一个单独的接口的,登录返回的不靠谱,万一数据变了呢?
chenluo0429 6
chenluo0429 3 小时 4 分钟前 ❤️ 1
用户信息肯定需要提供查询接口的,如果用户信息是静态不变的情况下,可以合并给登录接口来返回,但是只要用户信息可变动,那就一定需要独立的查询接口。
chaleaoch 7
chaleaoch 3 小时 2 分钟前
@chenluo0429
@keepeye
@keepeye
@Vegetable
@wotemelon

谢谢大佬们的热心解答.
Rocketer 8
Rocketer 2 小时 44 分钟前 via iPhone
jwt 里直接读就好啊
liyang5945 9
liyang5945 2 小时 37 分钟前
前端存储 token 到 cookie 或 local storage 里,用这个 cookie 调一个接口获取用户信息,保存到 store 里,这样切到别的 component 或者关掉浏览器之后再打开也没问题了
leven87 10
leven87 2 小时 20 分钟前
以上大佬说的都对

samin 11
samin 2 小时 15 分钟前
JWT 了解一下
skypyb 12
skypyb 2 小时 5 分钟前
按照楼上几位的说法, 要是用户的权限在关闭浏览器时变动了。再次打开浏览器直接拿 localStore 里的信息就有问题了吧。

我还是倾向于每次打开都要去请求一下
lybcyd 13
lybcyd 1 小时 7 分钟前
我习惯用单独接口,每次打开页面请求一下。单独的接口合理一点,因为不一定能保证当前用户和登录时返回的信息一致。
IvanLi127 14
IvanLi127 41 分钟前 via Android
倾向于从接口拿 。除了是小玩具或者登录不登录区别的大的网页。毕竟这个接口还承担着踢用户下线的功能呐
walpurgis 15
walpurgis 17 分钟前 via Android
功能独立较好,方便复用,登录只返回 token

选择Ubuntu服务器版操作系统的六大理由

今天分别从成本、系统集成、虚拟化、云计算、安全性、系统管理上来阐述,为什么要选择Ubuntu服务器版操作系统。

减少成本

(1) 减少数据中心成本

Ubuntu服务器版是真正能为企业减少IT基础设施成本的机会。Ubuntu服务器提供了企业功能定制化服务。精简的结构让*少的能耗和*省资源提供更多的服务。这种为特定功能定制的缩减版Ubuntu服务器也意味着更小的出错率。

(2)服务器维护简单

Ubuntu服务器只有部分组件需要维护,对于技术娴熟的系统管理员来说,维护Ubuntu服务器是一项清闲的工作。一般的服务只需要15-30分钟就可以配置完成。

(3)自动更新

经过一些初始配置工作后,剩下的系统可以自动进行安全配置。这样就不需要管理员再进行配置,服务器就可以提供一些重要服务。Ubuntu有两个版本更新周期,长短周期的无缝配合,让系统在5年内实现新技术的更新换代,版本更新过程中用户不需要担心系统安全和稳定问题。

(4)应用包

应用程序在Ubuntu中通常被称为包,因为在Ubuntu系统中,应用程序和其所依赖的库都必须打包在一起。这点与其他Linux系统不太一样。这就意味着系统管理员可以使用启动、停止、关机等简单的命令来控制Ubuntu系统中应用程序。这样简单的操作方式更加容易扩展服务器的功能,使用包方式不仅可以节省系统管理员的时间,还可以*大限度的提高数据中心的正常运行时间。

(5)减少能量消耗

通过Ubuntu企业云、Power Capping技术和PowerNap技术可以减少Ubuntu服务器系统的能耗。当数据中心的能耗减少了,系统可提供的服务也更好。Ubuntu具有*佳的服务环境,其低耗稳定的特性,可以*大限度的提高上网本和笔记本电池的寿命,同时让Ubuntu内核发挥*高效率。

(6)免费许可证

Ubuntu服务器提供免费的许可证和订阅。Ubuntu技术团队免费提供重要的维护和安全升级。所有订阅和许可证费用是通过提供有重要价值的服务获得,比如,给企业搭建环境、商业咨询和技术支持等。

系统集成

(1)集成现有的系统

Ubuntu服务器版本用常用的身份认证方式和服务入口工具简单地集成企业现有的客户/服务器结构。我们都知道系统集成技术的重要性,这也是Ubuntu团队花费大量时间研究如何实现服务器与基础设施简单融合的原因。

(2)简单的验证方式

验证功能对于网络信息识别与分享是非常重要的。所有Ubuntu服务器版都用Open LDAP来确保在必要时建立一个共享服务目录。通过简单的配置后,新版Ubuntu服务器就可以成为LDAP上网本中集成的一部分

(3)结合微软活跃目录

所有融合微软活动目录(ActiveDirectory)的Ubuntu服务器版本都有一个Likewise-Open工具。Likewise-Open可以帮助Ubuntu机器在不同机器中通过活跃目录实现资源的辨别、分享认证和访问。所以Ubuntu服务器可以通过简单的指令在无安全风险下为客户机提供资源服务。

(4)共享打印服务

共享打印服务是通过SAMBA协议(一种开源的SMB/CIFS的实现)或者CUPS协议(苹果常用的Unix打印系统,也用于苹果Mac OSX系统中)实现的。所有基于CUPS协议下的大部分平台都支持自动发现打印资源功能,在苹果电脑上可瞬间配置成功。在Windows机上安装打印机需要增加一些额外配置工作,但是在Ubuntu服务器版本上就可以提供石头般稳定的服务。

(5)使用SAMBA协议共享文件

文件共享和打印共享一样使用SANBA协议,可以合并微软的活动目录(Active Directory)。兼容Ubuntu客户端复杂的运行环境。通过NFS、Kerberos、SHH等协议实现UNIX和Linux系统的集成。

 三虚拟技术

(1)更容易实现虚拟化

Ubuntu服务器版是非常流行的虚拟化数据中心平台。Ubuntu服务器为主机和客户机提供KVM虚拟化技术。同时Ubuntu服务器还结合了大量的开源和专有技术。

(2)开源虚拟化

每一款发行版Ubuntu服务器都提供了很多方式来创建和管理虚拟化环境。开源技术是虚拟化环境搭建技术的前端,而且Ubuntu免费许可证的运行模式,非常适合动态的扩大和减少虚拟化环境中实际和虚拟的机器。

(3)低空间占用的操作系统

Ubuntu服务器可以通过虚拟机配置出空间占用低的理想环境。Ubuntu有一个虚拟机生成器,允许多个欲安装的机器通过简单的程序复制实现立刻安装。通过常用的环境配置工具,用户可以在简单的环境中管理虚拟机。而且虚拟机和物理机的管理方式没有不同,这两种机器用相同的界面和方式进行管理。

(4)Ubuntu服务器:已经准备好虚拟化

用Ubuntu系统内置的KVM,libvirt,和虚拟主机简表可以在X86中建立虚拟环境。为了简化硬件维修和维持效率平衡,在用户和服务器之间的迁移时要求它们共用一个存储系统。当相同服务器上的所有主机都使用相同的操作系统和应用程序时,内存集成可以*大程度的增加虚拟机的数量。

(5)通过VirtlO设备增加性能

VirtlO设备提供虚拟机访问硬件设备的直接通道,加快了运行速度和简化维护。你可以给虚拟机扩展特定硬件实现更高的吞吐量。Libvirt接口将要成为一项开源标准,通过第三方通用接口成为Linux内核的一部分。

(6)*好的客户端操作系统

通过现在主流的虚拟技术,比如,亚马逊EC2,VMware,Xen,Parallels,LXC,VirtualBox,以及KVM ,Ubuntu服务器可当做客户端来用。你可以基于虚拟机上在Ubuntu服务器上勾选你需要的功能,配置一个空间占用率*低的精小系统。我们还为你提供一个安装工具,只要几分钟就可以在你的系统上安装、卸载虚拟机。

云计算

Ubuntu服务器版可以为你提供一切资源,将你的基础设施建立在公共云前端(亚马逊 CE2)或者是你私有云的建设。你可以用相同的镜像和工具来控制这两种云。Ubuntu企业云可以通过防火墙的安全检查提供实时灵活的云计算,并且实现私有云与共有云之间简单迁移。

(1)私有云:Ubuntu企业云

如果你想在你的IT基础设施上创建私有云,Ubuntu企业云(UEC)可以为你提供所需要的工具。这样你就可以在安全环境下享受云计算带来的好处。

部署工作负载随时运行。提高或者降低应用程序的计算能力。作为Ubuntu服务器的重要组成部分,Ubuntu企业云很容易安装。UEC整合了一系列的开源项目,包括KVM、Libvirt和Eucalyptus。

(2)公共云:基于亚马逊 EC2

亚马逊灵活的EC2(ElasticCompute Cloud)允许你在*少的硬件条件下创建所需的虚拟系统。亚马逊EC2与Ubuntu服务器版本中的模块性、虚拟技术、一系列的应用软件和高效的执行度完美的配合。两者结合起来可以让企业在几分钟内建立灵活、符合企业需求的虚拟系统。

安全性

(1)建立安全性

Ubuntu服务器版本内核很安全,因为它是基于安全性很好的Debian操作系统。Ubuntu安全设计团队、Debian和一些Linux同行一起合作,来确保设计的系统能够及时发现并修复漏洞。Ubuntu免费公平的使用方式也意味着补丁包对于用户都是公开的,而不仅仅只是企业客户和订阅者。

(2)防火墙不复杂

Ubuntu服务器也引入简单易用的安全功能——这是一项*有用的安全技术,因为它可以减少安全管理中的“用户错误”因素。比如,防火墙会提示你为网络的数据通道指定你想要的(SMTP,HTTP,etc)协议。Ubuntu服务器没有默认的网络协议,所以即使首次安装管理员不熟悉的服务,也不会有安全隐患。

(3)通过AppArmor实现访问控制

AppArmor迅速的成为开源服务默认的强制访问控制工具。AppArmor允许系统管理员为每一个程序加入一个安全描述,限制非“安全”程序的访问和控制权力。AppArmor在传统的UNIX的任意访问控制的基础上额外增加了一些规则来控制程序的访问权限。这完全是 “学习”传统的设立规则方式,使其成为一种强制的标准而被广泛应用。

另一项功能是帮助你在服务器主目录下建立一个加密的私有目录,存储那些重要的秘密数据,用户名和登录信息。这是系统管理员为系统管理员设计的,那些有数据访问控制需求的管理员可以考虑花点时间来创建它。这种方式使用起来很方便。

管理员

(1)方便的管理方式

Ubuntu服务器让系统管理员工作起来更简单高效。Ubuntu的核心是Debian,而Debian是一款由系统管理员专门为系统管理员设计的Linux发行版,以高的安全性和易管理性闻名。所以有很多耗时的管理任务都被设计成简单、自动的。

(2)自动化部署更省时间

自动化部署是Ubuntu结构中的一项关键技术。原来为服务器增加一些相同或者简单的任务时,共同的一点就是配置过程需要消耗好几个小时。但是现在通过Ubuntu服务器,你可以建立可复制且独立于硬件的部署方案,加入你需要的应用程序中。只需几分钟就可以部署完成。Ubuntu服务器支持为主机提供部署方案。

(3)轻松获取应用包

Ubuntu用户通过Debian的包体系可以节省时间。每次的版本更新,Ubuntu服务器都会自动加入更多的服务部署标准,从原来的LAMP(Linux,Apache,MySQL,PHP/Python)栈到后来的java到现在的云计算。增加应用包可以从开源“体系”仓库中获得,随着不断扩展的Ubuntu体系,可以从Launchpad(PPA)中获得个人增加的应用包,或者一个公司也可以用自己打包应用程序来部署。

(4)通过启动板轻松管理

管理、监管、维护你的IT环境,启动板简洁的管理让用户管理多台机器就像管理一台般轻松。用户可以通过一个简单的Web终端来管理网络上的虚拟机和物理机,比如订阅服务或者是防火墙部署。

前端上传文件到服务器端

上传文件到服务器有很多插件,而且各种UI组件库,像iview,eleUI也都替我们封装好了,根本不用我们操心。
下面是原生的form 上传
原生form表单上传文件
直接上代码

<form enctype=’multipart/form-data’ action=”http://192.168。xxx.xxx:3000/upload” method=”post”>
<input type=”file” name=’pic’>
<input type=”submit”>
</form >

首先我们看form的enctype 属性
enctype 属性规定在发送到服务器之前应该如何对表单数据进行编码。默认地,表单数据会编码为 “application/x-www-form-urlencoded”。就是说,在发送到服务器之前,所有字符都会进行编码,但是在这里上传文件,我们用multipart/form-data,通过二进制方式提交。

action是你上传文件的地址路径,method是以什么方式进行处理,post为上传,get为获取。
前端很简单,重要的是后端,博主用node起了一个服务器,废话不说,上代码

var multiparty = require(‘multiparty’)

router.post(‘/upload’,function (req,res) {
//创建处理form表单的对象
var form = new multiparty.Form({
uploadDir: ‘./images’
})//文件上传的路径
//通过form.parse生成服务器文件,注意这里生成的文件名字不是原来的名字,而是编码后的名字,里面的回调包含错误信息,字段信息,文件信息
form.parse(req,function (err,fields,files) {
if(err) {throw err ;
console.log(err)}
else{
res.send(JSON.stringify(files.pic[0]))
}
})
})

这里需要安装插件multiparty
执行命令npm i multiparty
作用:使用内容类型解析http请求multipart/form-data,也称为文件上载。

构建负载均衡服务器之一 负载均衡与集群详解

一、什么是负载均衡

首先我们先介绍一下什么是负载均衡: 负载平衡(Load balancing)是一种计算机网络技术,用来在多个计算机(计算机集群)、网络连接、CPU、磁盘驱动器或其他资源中分配负载,以达到*佳化资源使用、*大化吞吐率、*小化响应时间、同时避免过载的目的。这是来自维基百科的介绍。负载均衡的目的,就在于平衡负载,给用户提供优质,可靠,稳定的服务。

*简单的负载均衡实例, 应用服务器并不直接与用户相连, 用户连接负载均衡服务器,然后由负载均衡服务器把消息转发给实际应用服务器。负载均衡器内部会根据应用服务器的负载情况,决定把消息转发给哪台服务器处理。同时负载均衡器还可以对用户屏蔽应用服务器失效,只要把用户的消息转发到非失效服务器即可。

提到负载均衡,就不能不介绍另外一个概念: 集群。集群就是一组部署有相同应用的服务器。例如web 服务器。用户的请求无论连接到哪台服务器上,都能得到相同的处理。这样我们实现一种服务器,可以将用户的请求根据特定规则转发到应用服务器上进行处理。就实现了完整的集群处理系统。这个服务器如果实现了后台服务器感知和配置功能,能够了解后台服务器的可用情况。就可以被称作为负载均衡器。

负载均衡在目前网络服务规模越来越庞大的情况下,成为一个大型服务器系统必须要面对的问题。随着用户和业务的增多,来自用户的访问量和数据流量不断增大,对服务器的计算能力和储存要求也在不断增加,单台服务器根本无法承担这么庞大的数据处理请求。这个时候,我们必须利用集群技术,采用一组服务器对来自用户的请求进行处理,服务器的数量要能够不断的扩充。在集群的前端,我们采用负载均衡技术,平均分散用户的请求到不同的处理服务器,并且能够在集群中某个服务失效时,即时感知,屏蔽,将消息转发到其他可用服务器上。

负载均衡分为硬件和软件:

(1).硬件LB(比较出名的)

F5 公司的 BIG-IP系列、Citrix 公司的 NetScaler系列、A10 公司的 AX系列

(2).软件LB

四层:LVS(Linux VirtualServer)注:国人开发的、七层:Nginx,HAProxy

二、集群的类型

1.scale on:向上扩展  

将服务器的内存容量调大和cpu数量增加些(简单说升级服务器硬件)

缺点:在一定的范围之内它的性能是上升的趋势,但是超出范围之后就是下降的趋势。因为随着它的cpu的个数增加我们需要给我们的cpu仲裁,而且随着cpu个数的增加资源竞争性越大。

2.scale out:向外扩展  

一台服务器应付不过来,我们就再增加一台服务器。  

优点:增减服务器很方便,而且没有向上扩展随着增加性能下降。

向外扩张的工作模式:当客户端向服务器端发送请求,服务器端只拿出来一台服务器来相应我们的客户端的请求。

(1).LB:Load Balancing:负载均衡集群

负载均衡集群中有一个分发器或者叫调度器,我们将其称之为Director,它处在多台服务器的上面,分发器根据内部锁定义的规则或调度方式从下面的服务器群中选择一个以此来响应客户端发送的请求。

(2).HA:High Availability 高可用集群  

高可用集群是服务的可用性比较高,当我们某台服务器死机后不会造成我们的服务不可用。其工作模式则是将一个具有故障的服务转交给一个正常工作的服务器,从而达到服务不会中断。一般来说我们集群中工作在前端(分发器)的服务器都会对我们的后端服务器做一个健康检查,如果发现我们服务器当机就不会对其在做转发。

衡量标准:可用性=在线时间/(在线时间+故障处理时间) 99%、99.9%、99.99%、99.999%

(3).HP:Hight Performance 高性能  

高性能的集群是当某一个任务量非常大的时候,我们做一个集群共同来完成这一个任务。这种处理方式我们称为并行处理集群,并行处理集群是将大任务划分为小任务,分别进行处理的机制。一般这样的集群用来科学研究与大数据运算等方面的工作。现在比较火的Hadoop就是使用的并行处理集群。

说明:三种集群之间的区别  

负载均衡着重在于提供服务并发处理能力的集群,高可用以提升服务在线的能力的集群。高性能着重用于处理一个海量任务。

三、主要负载均衡方案介绍

1:HTTP 重定向负载均衡

这种负载均衡方式仅适合WEB 服务器。用户发出请求时,负载均衡服务器会根据HTTP请求,重新计算出实际的WEB服务器地址,通过302重定向相应发送给用户浏览器。用户浏览器再根据302响应信息,对实际的WEB服务器发出请求。HTTP重定向方案有点是比较简单,缺点是性能比较差,需要2次请求才能返回实际结果,还有就是仅适合HTTP服务器使用。

2: DNS 域名解析负载均衡

在DNS中存储了一个域名的多个主机地址,每次域名解析请求,都可以根据负载均衡算法返回一个不同的IP地址。这样多个WEB服务器就构成了一个集群,并由DNS服务器提供了负载均衡服务。DNS域名解析负载均衡的优点是由DNS来完成负载均衡工作,服务本身不用维护负载均衡服务器的工作。缺点也是,由于负载均衡服务器不是自己维护,没法做精细控制,而且DNS在客户端往往带有缓存,服务器的变更很难及时反映到客户端上。

3:反向代理负载均衡

反向代理服务器位于实际的服务器之前,他能够缓存服务器响应,加速访问,同时也启到了负载均衡服务器的效果。反向代理服务器解析客户端请求,根据负载均衡算法转发到不同的后台服务器上。用户和后台服务器之间不再有直接的链接。请求,响应都由反向代理服务器进行转发。优点是和负载均衡服务集成在一起,部署简单。缺点是所有的请求回应都需要经过反向代理服务器。其本身可能会成为性能的瓶颈。著名的 Nginx服务器就可以部署为反向代理服务器,实现WEB 应用的负载均衡。上面的三种都是工作在OSI网络模型中的应用层,我们可以统称为应用层负载均衡(七层负载均衡)。下面介绍的几种工作在OSI网络模型中的4层以及4层以下(四层负载均衡),解决方案也具有更大的通用性。

4:IP负载均衡

用户请求包到达负载均衡服务器114.100.20.200后,负载均衡服务器在操作系统内核层获取网络数据包,根据负载均衡算法获取真实后台服务器地址192.168.1.1, 然后将数据包的目标地址改为192.168.1.1, 转发给内部服务器。整个过程都在内核层进行处理。收到192.168.1.1的响应包之后,会更改响应包的SRC IP, 转发给客户端用户。采用IP层负载均衡算法,全部处理过程都在内核层(Ring 0)进行。和七层负载均衡相比,具有更好的性能。但是由于所有的响应包都要经过负载均衡服务器,负载均衡服务器的网卡带宽,很容易成为系统的瓶颈,如果能够让响应包不经过负载均衡服务器,就可以*大的提升整个负载均衡服务器的服务能力。我们下面介绍的数据链路层负载均衡,就具有这个能力。

5:数据链路层负载均衡

数据链路层负载均衡,顾名思义,就是工作在TCP/IP协议*底层的数据链路层,进行负载均衡。我们常用的以太网中,在这一层主要采用数据帧进行通信,每个网卡都具有唯一的MAC地址,数据帧用MAC地址来标识数据的来源与目的地。数据链路层负载均衡通过修改数据包的MAC地址,实现负载均衡。

这种数据传输方式又称为三角传输,负载均衡数据分发过程中不修改IP地址,只修改目的MAC地址,通过配置真实物理服务器集群所有机器虚拟IP和负载均衡服务器IP一致,从而达到不修改数据包的源地址和目的地址就可以进行数据分发的目的,由于实际处理请求的真实物理服务器IP和数据请求目的IP一致,不需要通过负载均衡服务器进行地址交换,可将响应数据包直接返回给用户,避免负载均衡服务器网卡带宽成为瓶颈。这种负载均衡方式又称之为直接路由方式(DR).

如上图所示,用户请求到达负载均衡服务器114.100.20.200后,负载均衡服务器将数据包的目的MAC地址更改为00:1e:ec:bc:5e:03,并不修改数据包目的IP,由于服务器集群所有服务器的虚拟IP地址和负载均衡服务器IP地址一致,因此数据可以正常传输到达MAC地址为00:1e:ec:bc:5e:03的机器上,该服务器处理完之后,将响应数据包发送到网关服务器,网关服务器直接将数据包发送给用户,响应数据不需要通过负载均衡服务器,这样就避免了负载均衡服务器成为传输瓶颈的可能。

数据链路层负载均衡是目前使用*广泛的一种负载均衡方式。著名的负载均衡开源产品LVS(Linux Virtual Server),同时支持上面的IP负载均衡和数据链路层负载均衡。是学习负载均衡技术必须了解的产品。基于数据链路层的负载均衡虽然有非常好的性能,但是对网络拓扑也有比较大的限制,负载均衡服务器和后台服务器必须处于同一网络环境中才可以。

四、负载均衡算法介绍

前面介绍的内容,解决了从用户到实际后台服务器之间的数据包发送和响应的问题。下面我们介绍选择实际后台运行服务器的具体负载均衡算法。考虑到服务请求的不同类型服务器的不同处理能力以及随机选择造成的负载分配不均匀等问题,为了更加合理的把负载分配给内部的多个服务器,就需要应用相应的能够正确反映各个服务器处理能力及网络状态的负载均衡算法。我们以LVS为参考,介绍比较经典的8种负载均衡算法。

1.轮叫调度(Round Robin)

调度器通过“轮叫”调度算法将外部请求按顺序轮流分配到集群中的真实服务器上,它均等地对待每一台服务器,而不管服务器上实际的连接数和系统负载

2.加权轮叫(Weighted Round Robin)

调度器通过“加权轮叫”调度算法根据真实服务器的不同处理能力来调度访问请求这样可以保证处理能力强的服务器能处理更多的访问流量调度器可以自动问询真实服务器的负载情况,并动态地调整其权值

3.*少链接(Least Connections)

调度器通过“*少连接”调度算法动态地将网络请求调度到已建立的链接数*少的服务器上如果集群系统的真实服务器具有相近的系统性能,采用“*小连接”调度算法可以较好地均衡负载

4.加权*少链接(Weighted Least Connections)

在集群系统中的服务器性能差异较大的情况下,调度器采用“加权*少链接”调度算法优化负载均衡性能,具有较高权值的服务器将承受较大比例的活动连接负载调度器可以自动问询真实服务器的负载情况,并动态地调整其权值

5.基于局部性的*少链接(Locality-Based Least Connections)

“基于局部性的*少链接”调度算法是针对目标IP地址的负载均衡,目前主要用于Cache集群系统该算法根据请求的目标IP地址找出该目标IP地址*近使用的服务器,若该服务器是可用的且没有超载,将请求发送到该服务器;若服务器不存在,或者该服务器超载且有服务器处于一半的工作负载,则用“*少链接”的原则选出一个可用的服务器,将请求发送到该服务器

6.带复制的基于局部性*少链接(Locality-Based Least Connections with Replication)

“带复制的基于局部性*少链接”调度算法也是针对目标IP地址的负载均衡,目前主要用于Cache集群系统它与LBLC算法的不同之处是它要维护从一个目标IP地址到一组服务器的映射,而LBLC算法维护从一个目标IP地址到一台服务器的映射该算法根据请求的目标IP地址找出该目标IP地址对应的服务器组,按“*小连接”原则从服务器组中选出一台服务器,若服务器没有超载,将请求发送到该服务器;若服务器超载,则按“*小连接”原则从这个集群中选出一台服务器,将该服务器加入到服务器组中,将请求发送到该服务器同时,当该服务器组有一段时间没有被修改,将*忙的服务器从服务器组中删除,以降低复制的程度

7.目标地址散列(Destination Hashing)

“目标地址散列”调度算法根据请求的目标IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空

8.源地址散列(Source Hashing)

“源地址散列”调度算法根据请求的源IP地址,作为散列键(Hash Key)从静态分配的散列表找出对应的服务器,若该服务器是可用的且未超载,将请求发送到该服务器,否则返回空

前端 css+js实现网页中的【返回顶部】功能

描述:

本文主要是讲,通过css+js实现网页中的【返回顶部】功能。

 

实现代码:

HTML:

1 <div>
2     <button onclick="returnTop()" id="btnTop" title="返回顶部">返回顶部</button>
3 </div>

 

CSS:

 

 1 /* return top */
 2 #btnTop {
 3   display: none;
 4   position: fixed;
 5   bottom: 20px;
 6   right: 30px;
 7   z-index: 99;
 8   border: none;
 9   outline: none;
10   background-color: #89cff0;
11   color: white;
12   cursor: pointer;
13   padding: 15px;
14   border-radius: 10px;
15 }
16 #btnTop:hover {
17   background-color: #1E90FF;
18 }

 

 

JS:

 1 // 当网页向下滑动 20px 出现"返回顶部" 按钮
 2 window.onscroll = function() {
 3     scrollFunction()
 4 };
 5  
 6 function scrollFunction() {
 7     console.log(121);
 8     if (document.body.scrollTop > 20 || document.documentElement.scrollTop > 20) {
 9         document.getElementById("btnTop").style.display = "block";
10     } else {
11         document.getElementById("btnTop").style.display = "none";
12     }
13 }
14  
15 // 点击按钮,返回顶部
16 function returnTop() {
17     document.body.scrollTop = 0;
18     document.documentElement.scrollTop = 0;
19 }