先分享三个有点滑稽的事情。
有一天我去饭馆吃饭。点单后我就在座位上等着上菜了。等着等着，突然服务员跑过来说：“对不起，我们的西红柿刚刚卖光了。麻烦你去一趟西门菜市场，买俩西红柿回来，我们才能给你做菜。”
有一天我去饭馆吃饭。点单后我就在座位上等着上菜了。等着等着，突然服务员跑过来说：“对不起，我们厨师想请你试吃一下他创新的新菜。不过他自己还没尝试过，万一吃出事儿来你得自己兜着哦。”
有一天我去饭馆吃饭。头一天去吃的时候，一切如常。第二天我又去，点了和第一次一样的菜。没想到，服务员突然向我扔来一个盘子，把我头都砸破了。
现实中当然没有这样的饭馆。哪家饭馆敢推出这样的“服务”，分分钟被掀桌子砸场子。然而我们的系统中，却真真切切的存在有这样的“服务”。
我们系统对接过一个服务。有一次，这个服务的内部数据要做迁移，从一套文件存储系统迁移到另一套文件系统中。这个服务的负责人向服务调用方提出的方案是：他们提供一个新的查询接口。服务调用方如果先调用老的接口查一次？如果查不到数据，再调用新的接口重查一次。这跟厨房没有西红柿了、要顾客自己去买回来，不是一样的么？
使用这种“顾客自己去买西红柿”的方案，直接后果就是原本只需要在服务接口内修改一次代码就可以解决问题，最后却需要调用方做了个全面的筛查、修改了八九处代码才完成。如果后续还要再有进一步的修改（例如将文件全部迁移到新的文件系统上、从而让老的文件系统彻底下线），还需要调用方再做一次全面筛查、再修改若干处代码才能完成。
把服务内部的实现细节“扩散”到服务外部，这就是所谓的“低内聚”。很多服务——不仅是跨系统服务，还有系统内部通过interface来提供的服务——都有这样的问题。有的Excel解析服务要求调用方传入JXL组件中声明的类。这样一来，它就把内部的实现细节扩散到了调用方，从而使得调用方和解析服务自己都被绑定在了JXL组件上。结果，这个Excel解析服务就无法“顺滑”地切换到POI，也很难升级到Office 2007及以后的版本了。
另外一个系统提供的“服务”更令人啼笑皆非。有一天那个服务的负责人突然找到我，说你们调我们的接口时加几个参数吧！我有点奇怪的反问他，没有接到新需求上线的通知，为什么要加参数？他回答说，他们做了一些优化和改进，但是测试测不过来，所以想让我们直接在线上帮他们测一下。我当时差点没背过气去：这厨师一口都没吃过的新菜，就敢端上来给顾客吃？咸了淡了还是小事，万一食物中毒把顾客吃死了，这责任谁担？
上面那俩“服务”好歹最后还没出错。还有一个服务提供的查询接口直接引发了线上问题：这个服务接口居然不幂等。第一次查询时，接口还能正常返回数据；同样的数据再次调用时，接口居然给返回了一个异常。这不就是那个第二次点同样的菜就拿盘子扔我的服务员吗？
在没有其它操作的情况下，用同样的数据调用同样的接口，返回同样的结果，这就是幂等性。默认操作下，查询接口都应该是幂等的。我是真想不通这个查询操作是如何做到不幂等的——要让它不幂等，比让它保持幂等还更费精力。
为什么会有这样的服务呢？因为这些系统提供的“服务”并不是面向它的用户、而是面向他们自己的：自己省心省力就万事大吉了，用户？管他呢！因为没有人去掀桌子砸场子，所以这样的劣币可以继续流通、甚至驱逐良币。
我们要做怎样的服务呢？具体的要求——幂等，健壮，稳定，隔离，高内聚低耦合，最大努力，高性能，等等——就不一一说了。至少在态度上，要把自己当开饭馆儿的，把用户当做顾客：别让顾客来吃个饭还满肚子牢骚。能力差、态度好还能培养；能力好、态度差真是难以引导，在IT这个技术日新月异的行业里，很容易就滑入能力差态度差的垃圾堆里去了。