在 Amazon 的时候，公司内有大量的组来维护不计其数的 service，而 service 之间的通用通讯方式是公司内部的一个框架，协议是自定的，客户端也是内部的；现在到了 Oracle，我看到这个变成了 RESTful，也就是说，协议本身变成了最常见和适用的一种。我看到有太多论述 RESTful 优点的文章了，而实际工作中也确实有所体会，比如接口和报文的可读性好，不需要特制的客户端，上手和调试都比较容易等等。但是，如果看到某个东西被冠以过多正面的评价，就要当心了。我也慢慢地体会到了一些问题。不过，在谈谈我的思考之前，我想先明确一下我对 REST 的认识，而这点，鉴于历史原因，也是我不太愿意花时间争辩的内容。我 [……]阅读全文
Tag: Service
分布式系统中唯一 ID 的生成
其实老早就像写一点这个话题。几乎我见过的所有大型系统中，都需要一个唯一 ID 的生成逻辑。别看小小的 ID，需求和场景还挺多：
- 这个 ID 多数为数字，但有时候是数字字母的组合；
- 可能随机，也可能要求随时间严格递增；
- 有时 ID 的长度和组成并不重要，有时候却要求它严格遵循规则，或者考虑可读性而要求长度越短越好；
- 某些系统要求 ID 可以预期，某些系统却要求 ID 随机性强，无法猜测（例如避免爬虫等等原因）。
独立的生成服务
比如数据库。最常见的一种，也是应用最多的一种，就是利用数据库的自增长序列。比如 Oracle 中的 sequence 的 nextVal。有多台 application 的 h[……]阅读全文
三次性能优化经历
最近在做一些性能优化工作，回想起工作这些年来，参与过的三次集中性能优化，每次都得折腾少则一个月，多则半年。这些内容既是不同视角、不同思路的比较，也是挺有趣的工作经历。
Portal 的性能优化
这已经是大概五年前了，搞了接近半年的 Portal 性能优化，后来某些内容总结在这篇文章里面。既然是 Portal，性能优化上就有它的特点。比如说：
Portal 的性能优化需要从前端和后端两个角度去思考问题，先考虑客户端和服务端之间的交互模型，然后再在客户端和服务端单独考虑分而治之。这个其实和设计的思路是一样的，交互问题需要首先考虑，定义好交互的报文形式（比如某 JSON 的具体形式）以后，包括用户触发什么行为引
[……]阅读全文
