V2EX 首页   注册   登录

lecher

  •   V2EX 第 27664 号会员,加入于 2012-10-05 21:04:36 +08:00,今日活跃度排名 2459
    6 G 68 S 55 B
    lecher 最近回复了
    内部系统的话别管那么多规范了,先跑起来服务就可以。

    检测恶意参数是优先级最高的,不要相信任何客户端传过来的数据,所有参数都必须校验。是否考虑异步要看提供的服务是不是延时很高的,如果一个正常请求可能要几秒才能把处理好的数据返回,就需要考虑用异步框架在前面把请求都接住。后端开多台服务器提高负载能力,如果只是普通的业务,什么开发快用什么就好。

    测试的时候,有时间做边缘数据测试最好,要不至少也得在开发的时候考虑用户有没有可能传负数之类的数据,如果没有那么多时间,可以在编写代码的时候就采取防御式编程作为 RESTful 接口的策略。

    如果请求参数已经可能超过 GET 的限制,要放到 POST 里面做,那就不太符合 RESTful 的接口语义,等于应该分在 GET 和 POST 的资源操作都被合并到 POST 里面了,会导致你可能需要在 URL 上面做区分。
    比如 /source 是资源的 URL ,按 RESTful 的语义, GET 是获取 /source 的数据, POST 是新增 /source 的数据,你都合并到 POST 接口,可能就要在 URL 上面做区分,/getsource /newsource 这样才能实现资源的区分度。

    如果存在这种可能,或许不使用 RESTful 比较好,就在 URL 上面做语义区分。毕竟先提供服务才是主要的任务。能保证某些接口的幂等性就能少掉很多网络延迟导致的异常。
    @call43848
    这样的机制太伤用户体验。非常影响用户口碑。现在连用户滥用批量注册账号都不会管,还费精力去做回收账号这种吃力不讨好影响自己口碑的事情?

    腾讯以前倒是做过回收账号这事情,直接在用户申请协议上面要求,注册之后必须在限期内登录激活,并且超过多长时间不登录就会回收账号,那会儿估计是赶上账号系统资源不足没升级,服务器资源不够做了限流,实际上根本没有执行。现在有钱了更不会做这档傻事。

    网易也做过回收账号的事情,声称 180 天不登录会冻结,然后回收。实际也不执行。

    Gmail 也做在用户协议上面写过,超长时间不登录会被锁定注销,但是账号资源不会放出来。

    个人感觉,账号系统的维护成本是比较低的,真到系统资源紧张要回收账号的程度,要么很快可以调度资源扩容,要么这个服务也许很快就要整个关闭了。
    Google N 个服务说关就关。
    雅虎邮箱整个关掉。
    百度空间也是说关就关。
    商业的东西谁能说个准,缺钱了就关掉了。

    实在想要好的邮箱还可以自己花钱买域名做自己的域名邮箱。
    QQ 可以花钱买靓号。
    Google 财大气粗, Gmail 是没有靓号买了。
    我觉得还是看官方文档+stackoverflow 的效果直接。
    最好是有个动手的项目来实践,做 Web 应用似乎不太好想复杂业务来练习, MongoDB 用来做清洗数据可以有效提高对它的了解程度。
    一个是录入数据的压力比较容易在代码层面调整。
    另一个是做数据报表会刺激自己寻找各种奇怪结构的数据如何抽取。
    配合几个数据清洗和做报表的实践,应该就能对 MongoDB 有哪些性能的坑有初步了解了。
    先做功能,再丑也不要紧,只要功能可以解决需求,有用户才有优化的动力。
    第一版尽可能用原生的框架 UI 的组件,不要怕丑,因为框架自带的组件再简陋也是风格一致的设计,在没有审美的情况下,自己选各种组件去拼接出来界面的会更丑。
    也不要想着用业界比较酷炫的 UI 库,你会发现虽然官方 UI 丑,但是文档齐全出错好找解决方案,各种 UI 库哪怕是大厂出的,在对 APP 系统接口不够了解的情况下使用等于在同时学两套接口,出错查起来会有无从下手的感觉。

    交互是个大坑,尽可能按官方的交互手册来,而且要保持一致性,不要出现一个操作模式在不同地方有不一致的响应,不要拍脑门想快捷操作,因为程序员的思路和普通用户真的不一样,比如用户习惯了左右滑动代表拖动列表数据的话,就不要在某些地方出现左右滑动操作前进后退的事情了,反之亦然。
    iOS 的用户被系统教育了长按的操作习惯, Android 用户习惯这个操作的很少很少,如果是 Android 藏在长按触发的功能可能不会被用户发现。
    类似的还有双击触发、多点触摸拖动这类看起来便捷的技巧,不写清楚引导的话,有可能用户完全发现不了,虽然写了用户也不一定会记得住,所以是不是要用这种高级技巧看有没有时间写代码吧。

    "标签列表"->"详细介绍"->"另一个标签列表"->"另一个详细介绍" ->"又一个标签列表"。这里有个坑,如果没有复用组件的机制,反复点下去,会出现一个很长的调用栈,用户可能会返回到吐血。如果复用了又可能不符合用户的预期,比如超长的列表被重载了丢失操作历史。这个最好先想好用户可能更习惯那种交互。

    APP 的缓存和存储是个巨坑, iOS 有系统约束的清除规则, Android 有神奇的 SD 卡读写权限约束。
    iOS 还好只要读一个发行版的规范就好,读完手册不要犯该持久化的文件存在缓存被系统删掉的错误。
    Android 各家修改的 rom 权限略有微调,还没有文档,只能靠猜,如果是 Android 的话最好找个有经验的帮忙,至少碰到问题可以问个方向。

    iOS 虽然官方框架限制很多,但是真心对独立开发者友好,用户升级积极性高,几乎都是新版本系统,只要按着官方文档用官方的原生框架就能做出来一个还过得去的 APP 出来。 Android 有些机型真的很坑,不要想着兼容大多数主流版本,个人开发的话,能做到 4.0 正常, 5.0 、 6.0 不因为神奇的权限问题闪退就不错了。
    决定自己开发很有趣,我踩过的坑就这些印象比较深刻的,希望能对楼主有帮助。
    我用 admin LTE 做过管理后台模板。 admin LTE 要想用好光靠后端渲染是不够的,好多 admin LTE 集成的插件是要写 JavaScript 的代码的,获取后端的数据之后通过 JS 来做数据渲染。
    如果是想快速在 admin LTE 上面做开发,建议不要用 Django 集成的模板,拆成 restful 的形式, Django 、 flask 、 tornado 什么框架都好,只提供 API 接口。交互效果全部交给 admin LTE 的各种插件完成。这样开发起来会轻松一些。

    其实 admin LTE 这种形式的交互效果,如果要做的业务比较复杂的话,写起来 JavaScript 的代码量还是挺多的,因为要写很多网络请求的接口去拿数据。尤其你的任务系统可能会用到报表,还可能要集成不同的报表插件,所以不要对 admin LTE 抱太大的改造希望。这是一个庞大的管理后台模板,很多效果都是靠不同的插件完成的,实际开发的时候可能要去好几个不同的插件官网查看文档,做好这个心理准备。

    如果有时间和精力学习 JavaScript ,我觉得可以考虑用用 vuejs 方面的模板,我是个主后端的开发,做个人项目的时候最头疼的就是前端交互的逻辑,因为做出来的又丑又繁琐,接触 vuejs 之后,仅仅就是用 vue 替代 jQuery 就省去了我很多写前端渲染的精力,所以在这里推荐一下 vuejs ,考虑一下用它替换 jQuery 试试看?
    话说楼主一直提 native 在抓取各种数据聚合上面多么多么方便,恐怕不知道马化腾已经在人大提交过打击聚合类 app 的提案,并且很多手握版权的公司都在合力起诉那些聚合类 app 的持有者,以侵权为起诉理由,颇有抓住一个就往死里揍的阵势吧。
    任何一个做原创内容的公司,都非常讨厌侵权这种事情,转载过去就算了,直接构造请求一点成本不出就占用服务器资源,这种做法等于在抢钱吧。

    类似愿意开放资源访问的,通常都在 get 接口上面开放,哪怕是 POST 或者 PUT 的业务,只要按照其文档提交的请求,都能拿到相关的资源。根本不存在楼主说的有意愿开放访问但是受限于浏览器限制没有办法开放的情况。浏览器不能构造任何请求不是行业的业务痛点,反而是浏览器这个领域保护用户的重要优点。
    楼主发的这个话题,更像是一种泄愤,为什么浏览器不能让我想盗取什么就盗取资源。我在 native 上面盗用起来何其方便,在浏览器上面怎么就这么难,这浏览器是不是要死要死了。
    如果是 3 年以下的 php ,我个人感觉分几个级别:
    1. 计算机基础不扎实的,比如操作系统原理、网络通信、数据库原理、算法与数据结构没有办法自学的
    2. 项目经验少, CURD 方面的代码写的比较多,没有机会重构业务或者编写高并发业务代码的
    3. 异常处理经验少,对于突发的系统故障,没有机会调试,或者没有掌握调试技巧,不能有效分析 log 和系统参数找性能瓶颈的。
    4. 没有机会参与一个完整业务的框架搭建,不能理解框架在工程规范和业务增长兼容上面如何取舍的。

    这份大纲似乎没有在根源上面找准做 web 开发应该提升的技能,用工具可以有效提升工作效率,但是仅仅靠工具似乎更像是换了一把锋利的剑,没有找准对手的死穴,不能一击毙命,不算一部好的武林秘籍。
    看这份大纲有种有趣的感觉。就像买了一本武林秘籍,推销的老人各种吹嘘学完这部就能功力大增行走江湖不再被人欺压。翻开书一看,竟然是:
    如何购买一把锋利的宝剑
    选择一件优质防尘披风的几个要点
    组队战站位的几种方式
    执剑的几个起手式样本
    选择一匹良驹的关注点
    如何在酒馆与店小二讲价
    论几种夜行衣的穿着体验

    问题是学完这些,该被人吊打的时候还是得乖乖跪下认打啊。

    其实这份教学大纲也有不少有用的东西,比如 linux 的安装配置之类的, git 的协作技巧,翻墙的方法。但是这并不够,对特别初级的太杂乱没有主线,对有一定基础的又不够深入,花式技巧太多没有抓住重点。
    认真的说,作为一个入门的 web 开发人员,不管任何语言,要说有一份晋级初级开发的技巧想让我付费。我希望除了说服我要打好基础,认真学完什么算法与数据结构、网络通信原理、操作系统原理、数据库原理之类的说教之外。有这么一些内容。
    1. 如何搭建测试环境以及组件选型的几个测试要点。如果能以此为实例讲面对两三个可选组件的时候,怎么去测试并选择一个合适的组件。要是能用上 docker 做实例讲解更好。
    2. 高并发状态下,几种 sql 语句的性能对比。如果以此为实例,讲讲怎么用测试工具构造请求施加压力给服务器,数据库如何做 explain ,以及对于相关情景下面优化的 sql 语句之所以高效率的原理。
    3. 实战演示高负载状态下的服务器性能瓶颈分析。以此为实例,讲讲 linux 服务器的运行参数如何查看,对于 cpu 负载、内存消耗负载、磁盘读写负载、网络 io 负载如何查看以及对应资源不够用的时候会出现的现象。如果可以深入相关的业务分析是什么业务导致的性能瓶颈,以及在遇到瓶颈之后在考虑加硬件还是改代码的决策要点。
    4. xx 设计模式在搭建框架的应用。以此讲讲业务增长的不同阶段业务代码应该如何抽象,应该遵循什么工程规范避免低级的开发错误。能用实际参数讲讲在请求量达到什么阶段会崩掉,怎么不会过度设计之类的更好。
    5. 分布式系统搭建过程中要避免的几种代码。讲讲如果遇到了需要横向扩展的系统,在数据库设计的时候如何拆分,在分布式系统中应该牺牲哪些性能用于加强系统健壮性,缓存颗粒度以及在应该在哪些级别的业务考虑缓存。


    这些都是有能力编写初级代码,但是进一步提升可能会遇到的门槛,并且这些没办法完全靠文档和资料去学习,非常需要有经验的人引导才能迈过去。并且这种经验不是正常的业务代码开发有机会遇到的,不幸的是如果没有在校招的时候进入合适的公司,可能没机会去接触类似的业务场景。而如果没有解决类似业务场景的经验,有可能永远没办法通过具有这种业务场景的公司的面试。

    如果是进阶初级工程师的教程是这些,我相信愿意为此付费的人会挺多。毕竟讲讲入门的培训机构学费都得 1w 起,进阶初级的课程 1w 起一点也不过分吧。
    你想写 native 抓各种 api ,那是因为 native 你可以任意构造请求数据,所以没有同源安全这个限制。但是浏览器不可能放开这个限制,因为浏览器托管了 cookie 这类的敏感数据是可以做用户标识的,所以发出去的请求格式有限制,不能任意构造请求。
    即便是 native 的开发,也还有存储域的限制,一个 app 如果在框架指定的私有存储域写入文件,那么别的 app 也不可以访问到这个私有存储域的文件。而且最重要的一点, native 不可以调用用户浏览器数据或者其它 app 的资源,只能靠 native 自己构造请求数据。

    而浏览器对于 web 请求,是不验证发起域的,只要发出去的请求,默认就带上该域的 cookie 作为用户标识。所以 web 目前的请求方式决定了,限制跨域是保证浏览器用户数据安全的底线,不管任何浏览器都必须支持同源安全限制。只有符合 cors 白名单的网站才可以发跨域请求。

    如果浏览器在目前的业务下可以在任意界面构造任何请求发出去,这个浏览器不可能有人会使用。如果所有浏览器都没有同源安全限制,那互联网不超过一周就崩盘了,你随便访问一个不知名的网站,它就在后台给一票网银系统构造转账请求,在你不知情的情况下,钱就消失了。对网站来说,自己站点提供的服务,图片、 api 这类的,别的网站可以不告而取,任意调用。

    你想这么做,我猜测的原因可能是,你希望在自己的网页调用别人的资源,并且是别的网站没有在 cors 开放权限的资源。这种情况下你依然想调用这个资源,那就只剩你想盗用别人的资源这个情况了。
    碰到这种不能调用的资源,要么你找对方网站在 cors 上面加上你的网站域名,允许你直接调用。要么你自己开服务器做反代,转成同域请求。


    以后浏览器如果可以任意构造请求,那就要改变浏览器的请求模式,对于非同源的域发起的请求,比如 A.com 网页中构造了一个向 B.com 的请求,那这个请求拿不到任何 B.com 存储在浏览器的数据,相当于一个独立的用户发起的请求。比如 A.com 网页向 B.com 发出的请求永远不能携带 cookie 和敏感的 header 数据。

    这种情况下,才可能出现任意网页调用任意域的 api 数据。否则只会出现更多欺诈用户的现象。对行业生态和用户都是伤害。
    对于小型项目被 DDOS 。
    第一,找机房,机房能不能帮忙清洗流量。如果不能,可不可以通过增加带宽的方式把流量吃下来,吃得下来就有机会找办法清洗。
    第二,此机房已被打跨或者机房不愿意清洗流量,考虑临时上 CDN ,先把服务降级,先保证服务器的非交互可以正常展现,比如首页之类的。
    第三,实在不行就请求机房关闭外网,先走内网连接登录服务器改改安全配置,只要不是带宽被 D 光的攻击,比如 CPU 或者内容消耗型的,找找性能瓶颈或者降级业务,先保证服务器能提供基本业务。

    如果又用不起可以清洗流量的机房,又没钱买 CDN ,那就等死。

    此外网站安全靠代码, windows 上面的安全狗之类的都是 cpu 大户,所有请求全拦截进行分析,装上去,没等别人 DDOS ,用户流量大一点,就先把服务器 CPU 爆掉了,最好不要浪费资源在这种软件上面。

    临时迁移域名解析有个坑,用户的 DNS 解析记录更新是很慢的,如果就服务器没有做好反代新服务器的配置。
    直接切换并且旧服务器关闭,大概率面临某些地区用户丢失一周无法访问。
    如果迁移没有关闭旧服务器,又不做反代或者数据同步方案,大概率出现某些地区用户依然访问旧服务器数据分裂不一致。
    DigitalOcean
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   鸣谢   ·   655 人在线   最高记录 2466   ·  
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.7.5 · 46ms · UTC 23:31 · PVG 07:31 · LAX 16:31 · JFK 19:31
    ♥ Do have faith in what you're doing.
    沪ICP备16043287号-1