[email protected]:~$

  • 如何用微服务制造问题

    如何使用微服务制造问题 微服务成本 理想的微服务平台 声称使用微服务架构的公司越来越多,一方面是云服务商的炒作,另一方面也的确是微服务带来好处的影响。 无论如何理解,在 twitter 上可以看到越来越多的程序员在吐槽微服务.. 一方面,理论上微服务通过大事化小分而治之,可以解决开发周期长,旧项目难以维护等一系列问题,看起来非常万能。 另一方面很多人忽略了微服务的隐含成本,在实际实施后反而感觉处处不便。 实行微服务所需要的额外工作大致如下几类: 部署困难:需要搭建如 K8s, CloudFoundry 等应用平台来解决 测试困难:需要搭建 Jenkins 等 CI 工具来完成单元测试/集成测试 运维困难:需要在应用平台上搭建监控和告警服务 Debug 困难:需要搭建日志服务接入平台,需要接入调用链分析工具 代码维护:微服务化后可能有些服务长期无人修改,对每个服务都需要建立良好的文档 可以看到,实行微服务需要优秀的运维团队支撑起应用平台(k8s)、监控告警工具、CI 服务、日志/调用链服务。需要开发团队做好文档化、自动化测试。 这些工作在单一应用架构时经常会被忽略掉,但是微服务中如果没有这些工具 debug、运维 等工作会非常痛苦,会浪费掉团队大量时间。 所以微服务的先决条件是团队需要拿出精力来维护以上基础服务。 很多小团队选择使用微服务架构,但后果往往是花费大量额外精力去支撑平台,或在基础服务不完善的情况下浪费大量时间 debug,实在不是一个好的选择。而大公司实行微服务带来的好处则相当明显,因为人数众多,维护平台的消耗几乎可以忽略不计。 有野心的公有云服务商应该将自身作为所有中小企业的微服务平台,提供微服务架构的所有基础服务,大量降低使用微服务的成本。这样微服务才会成为真正通用的架构模式。 从功能上来说 AWS(国外的那个..) 最接近理想形态。已经真正的可以让中小企业完全基于 AWS 基础服务来设计自己的后台架构。而其他服务商还多以 VPS + 数据库的形态出现。 如果以支撑微服务架构为目标的话,AWS 为首的公有云还都有一定的距离。 不知未来哪一家有野心的厂商可以提供真正实用的微服务公有平台。

  • 算法惨不忍睹-背包

    看了道 leetcode 题目 https://leetcode.com/problems/ones-and-zeroes/description/ 这其实是一道背包问题,使用背包的状态转移方程可以简单解决 轻轻松松试了下手,果断翻车了… 我发现并不是题目难,而是我一直没能真正理解背包算法为何会这样来设计? 每次看到解答都会感觉反直觉,无法将直觉思路联系到这种解法,而网上的解题过程也大多由结果出发,没有掌握到 why 看题目时我的直觉是对每一个字符串判断需不需要,然后利用递归计算,算法如下。 def find_max_form(strs, m, n) str = strs.first # 当前字符串 strs = strs[1..-1] # 剩余部分 m1 = str&.count('0') n1 = str&.count('1') if str.nil? 0 elsif m1 > m || n1 > n # 放弃不满足条件的当前字符串 find_max_form(strs, m, n) else # 选择构成当前的字符串时的数量 find_max_form(strs,...

  • CSRF 矛与盾

    CSRF(跨站请求伪造:Cross-site request forgery) 可谓老生长谈的话题,有无数的博客和文章都在讲 CSRF 攻击与防范。 近日感觉自己知识点之间存在着裂缝,无法做到了如指掌。于是弥补了下知识裂缝,并写成文章,贡献了 yet another CSRF 博文.. 摘要 CSRF 实践 POST 比 GET 安全? 为什么还要 CSRF protect token? 前后端分离和 CORS CSRF 实践 顾名思义,一句话概括跨站请求伪造(CSRF)就是:在用户浏览 A 站(恶意网站)时,伪造用户向 B 站(正常网站)发起请求。 我们用 ruby sinatra 简单的模拟下这个过程,从而更好的理解这种攻击手段。 用 a.rb, b.rb 两个脚本来模拟 A, B 站点,并修改 /etc/hosts 为两个站点提供不同的域名。 如果不明白可以先略过这两个脚本,之后回来再看。 # a.rb # testa:4000 #...