Service agent (SA) 这个项目与service manager (SM) 集成经历过两种方案，一种是直接与SM的数据库进行集成交互；另外一种就是面向服务的集成，通过SM提供的SMRWS API服务进行交互集成。我概括地称之为直接面向基准数据源的集成设计(SA->SMDB) 和面向服务的集成设计(SA->SMRWS->SMDB)。

问题

今天遇到一个面向服务的集成设计的问题，SMRWS的主从web servers的cache数据出现同步了问题，导致SA连接SMRWS获取的信息不准确，有一个场景就是我们通过SMRWS来验证用户权限，因为获取的信息不准确导致我们误判用户不再存在于SM源系统，进而删除了用户在SA系统的权限。

结果

作为下游系统的SA这种情况下显得格外尴尬，用户抱怨SA系统的可用性和稳定性。

反思

作为面向服务的下游系统，必须考虑外接服务的不稳定性，提前做好准备，进行一些异常应对， 比如当对方服务无法连接，要让本系统通过本地缓存保持”off-line” 继续工作。 当然对于上述的那个因上游系统的问题，导致本系统逻辑上的误判 (到底是用户真的不存在于上游系统背后的数据库了，还是因为上游系统出现了同步问题，这个需要和上游系统就关键逻辑场景进行标志，比如当上游系统的cache出现同步问题时候，需要在API返回结果里进行标识)。

随时过期的技术文章

在网络上搜索最流行的三大web服务器的对比，看到一些2014年的博客(比如http://yanguz123.iteye.com/blog/2055589），言之凿凿地做了一些表格化的对比整理。其中就有一项说nginx 不支持 sticky session. 还算比较有怀疑精神的我，当即表示怀疑最新的版本里nginx 是不是像这篇文章里所述仍然不支持sticky session.

于是去google搜到一些nginx官网的文章链接1 and 链接2 证实nginx 已然支持 sticky session.

My Point

写这篇的目的不是为了责难一些过往的博客，毕竟人家把自己当年学习的经验进行了总结和分享，特别值得肯定。 我想说的是技术本身一直在发展，一些技术文章和知识会过期。当你第一次学习某个主题的技术时，除了要了解他的历史，更重要的是知道他最新的样子。

My Suggestion

当你学习某个主题时( 比如nginx)：

1. 经常光顾官网的document, wiki
2. 买最新的出版的这个主题的书籍
3. 网络blog里的过往的文章当成历史去读，一定要自己加以验证。
4. 不要转载别人的文章的内容，建议只引用原始文章标题和链接。（理由： a. 转载后的拷贝版本是死的，不能获取到原作者对老文章进行的最新的修订。b.减少网络资源重复，创造绿色环保的网络）

图片类

台北故宫博物院免费图像

Why I write blog

The bottom line of morality

1. Don’t write advertorial. 拒绝软文，浪费时间
2. Don’t cheat readers. 不欺骗读者

The intention

1. Share experience in life. 分享生活经历或体会
2. Share experience of work. 分享工作中的经验

时间没有被工具节约

1. 时间没有被节约，工具调整了我们对时间的支配，但是又吸引我们到其他地方花了时间。并且把玩工具的过程也会浪费时间。

无所事事的快乐

1. 不要让时间工具把你是时间填的满满的，我们需要一点空间和时间，去无所事事地享受快乐。

计划还是要的

1. 每天醒来一天中有几件重要的事情要干，用纸写出来，一项项去实现。
2. 长期的目标，就在你每天的空闲里花点慢慢练习着去实践并接近目标。

举例说明

1. 早上起来，看下邮件，了解下项目上要做的事情，可能常规来讲4-5个小时能干完。剩下的几个小时，可以网上冲浪，也可以办公室里找人谈谈，当然也可以去研究下长期来讲个人比较感兴趣的东西。