服务碎碎念

先分享三个有点滑稽的事情。

    有一天我去饭馆吃饭。点单后我就在座位上等着上菜了。等着等着，忽然服务员跑过来讲：“对不起，咱们的西红柿刚刚卖光了。麻烦你去一趟西门菜市场，买俩西红柿回来，咱们才能给你作菜。”

    有一天我去饭馆吃饭。点单后我就在座位上等着上菜了。等着等着，忽然服务员跑过来讲：“对不起，咱们厨师想请你试吃一下他创新的新菜。不过他本身还没尝试过，万一吃出事儿来你得本身兜着哦。”

    有一天我去饭馆吃饭。头一天去吃的时候，一切如常。次日我又去，点了和第一次同样的菜。没想到，服务员忽然向我扔来一个盘子，把我头都砸破了。

    现实中固然没有这样的饭馆。哪家饭馆敢推出这样的“服务”，分分钟被掀桌子砸场子。然而咱们的系统中，却真真切切的存在有这样的“服务”。

    咱们系统对接过一个服务。有一次，这个服务的内部数据要作迁移，从一套文件存储系统迁移到另外一套文件系统中。这个服务的负责人向服务调用方提出的方案是：他们提供一个新的查询接口。服务调用方若是先调用老的接口查一次？若是查不到数据，再调用新的接口重查一次。这跟厨房没有西红柿了、要顾客本身去买回来，不是同样的么？

    使用这种“顾客本身去买西红柿”的方案，直接后果就是本来只须要在服务接口内修改一次代码就能够解决问题，最后却须要调用方作了个全面的筛查、修改了八九处代码才完成。若是后续还要再有进一步的修改（例如将文件所有迁移到新的文件系统上、从而让老的文件系统完全下线），还须要调用方再作一次全面筛查、再修改若干处代码才能完成。

    把服务内部的实现细节“扩散”到服务外部，这就是所谓的“低内聚”。不少服务——不只是跨系统服务，还有系统内部经过interface来提供的服务——都有这样的问题。有的Excel解析服务要求调用方传入JXL组件中声明的类。这样一来，它就把内部的实现细节扩散到了调用方，从而使得调用方和解析服务本身都被绑定在了JXL组件上。结果，这个Excel解析服务就没法“顺滑”地切换到POI，也很难升级到Office 2007及之后的版本了。

    另一个系统提供的“服务”更使人哭笑不得。有一天那个服务的负责人忽然找到我，说大家调咱们的接口时加几个参数吧！我有点奇怪的反问他，没有接到新需求上线的通知，为何要加参数？他回答说，他们作了一些优化和改进，可是测试测不过来，因此想让咱们直接在线上帮他们测一下。我当时差点没背过气去：这厨师一口都没吃过的新菜，就敢端上来给顾客吃？咸了淡了仍是小事，万一食物中毒把顾客吃死了，这责任谁担？

    

    上面那俩“服务”好歹最后还没出错。还有一个服务提供的查询接口直接引起了线上问题：这个服务接口竟然不幂等。第一次查询时，接口还能正常返回数据；一样的数据再次调用时，接口竟然给返回了一个异常。这不就是那个第二次点一样的菜就拿盘子扔个人服务员吗？

    在没有其它操做的状况下，用一样的数据调用一样的接口，返回一样的结果，这就是幂等性。默认操做下，查询接口都应该是幂等的。我是真想不通这个查询操做是如何作到不幂等的——要让它不幂等，比让它保持幂等还更费精力。

    为何会有这样的服务呢？由于这些系统提供的“服务”并非面向它的用户、而是面向他们本身的：本身省心省力就万事大吉了，用户？管他呢！由于没有人去掀桌子砸场子，因此这样的劣币能够继续流通、甚至驱逐良币。

    咱们要作怎样的服务呢？具体的要求——幂等，健壮，稳定，隔离，高内聚低耦合，最大努力，高性能，等等——就不一一说了。至少在态度上，要把本身当开饭馆儿的，把用户当作顾客：别让顾客来吃个饭还满肚子牢骚。能力差、态度好还能培养；能力好、态度差真是难以引导，在IT这个技术突飞猛进的行业里，很容易就滑入能力差态度差的垃圾堆里去了。