我觉得，光要做好 CRUD 就很不容易了耶，我想简单谈谈 R 就好。 我们假设一下。 当你的 API response time 越来越高时，怎麽办呢？ 第一步可以先看看演算法和 db 有没有调效的空间，演算法和 db 的调效就可以研究好一 段时间了。 如果调完了，还是不够快呢？ 那可以考虑分析一下你的资料，分出常变动和不常变动的，常变动的放在 db 没问题，不 常变动可以考虑用 cache 来解决。 cache 可以考虑自已处理，或者找找适合的工具，然後要 cache 在本机还是弄个 memory 的 nosql db 呢？db 的话要 redis 或 memcached呢？ cahce 也是个可以好好研究的东西，比方说 cache 要设多长呢？设短了查询频率还是很 高，设长了花较多的空间，然後资料有更新是要主动去更新 cache ，还是等 cache 时间 到了下次被 hit 再更新就好？ 接着我们假设一下，你已经处理好你的 cache，也榨乾你那台 server 的效能了。 接下来要嘛升级要嘛加机器，升级总会到个物理极限就不谈了，谈谈加机器吧。 加机器那问题就又来啦。（来不完乾） 如果你是三台、五台还好，一百台你总不可能要 client 接你 100 台机器吧，那就要了 解一下 load balancing 啦，lb 怎麽做和怎麽做好也是一门学问。 然後 100 台机器时，你总不会还要一台一台手动去更新程式吧，那怎麽自动部署呢，比 如用用 ansible 之类啊，也是可以研究的。 然後通常也不用到 100 台机器啦，瓶颈就又会变到你的 db 那了，那这时候要怎麽解呢 ？可能可以做个读写分流啊，怎麽做跟怎麽做好也是可以好好研究。 光 R 感觉就讲不完了，量一直冲上去挑战就会一直来，颈瓶有可能出现在你系统任何地 方，你能承受越高的挑战你的价值自然也越高。 学无止尽，回头是岸。 不对，是加油，共勉之 ^^ --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 118.150.53.122 ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Soft_Job/M.1527938538.A.85D.html