我觉得，光要做好 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 感觉就讲不完了，量一直冲上去挑战就会一直来，颈瓶有可能出现在你系统任何地
方，你能承受越高的挑战你的价值自然也越高。
学无止尽，回头是岸。
不对，是加油，共勉之 ^^