对服务化的一些疑问和思考

服务化是今年的重点，在听了其它部门的服务化进程汇报后心中疑问丛生，正好有机会找前辈友群聊了下服务化相关的问题，随手记录于此。

前言：首先应该掌握服务化的思想，大多数人一听到服务化马上开始考虑代码层面要做怎样的改动，一头钻进了具体的实现中。类似于，即使使用了java这样OOP的语言，仍可能会写出面向过程风格的代码，从而无法体现OOP的优势。

1、对服务化的理解

1.1 发生发展的背景及定义

服务化与远程方法调用有密切的关系，远程方法调用试图解决跨JVM/跨平台的应用交互，随着这些远程调用（服务）规模和复杂度的不断扩大，必然涉及到以下问题：

• 核心服务被大量调用，如何保证其可用性？
• 不同服务间如何充分利用系统资源？
• 服务调用纵横交错，如何理清其依赖关系？
• 当前有哪些服务可用？
• 根据受众，需要提供不同的服务？

等等这些都是服务化要解决的。并非对外暴露了几个服务就能宣称完成了服务化，服务化有一系列基础建设作为保障。

1.2 类比

服务化是业务规模膨胀、复杂后的一种解决方案，可以拿小饭馆和大饭店做类比。小饭馆里可能只有一两名服务员，从迎宾到点菜再到上菜，每个服务员要能胜任所有任务。客户每次发起请求，服务员集群中随机一位服务员主机响应并完成服务，其情形类似于目前的web应用集群。当饭店规模上了一定的程度，招聘服务员的时候就会说明其功能性特征：招洗菜工、跑堂、迎宾各几名。每个服务员面向其服务内容各司其职，往往迎宾所需数量相对固定，可以少招点，负责点菜上菜的可以多招些（解决扩展性只要动态调整服务集群内主机的数量）；洗菜的和洗碗的可以分时由同一拨人完成、用餐高峰可以临时加派钟点工（流动计算，充分利用服务器资源）；包厢由专职服务员把守（根据受众提供不同的响应速度、下行带宽等）；

1.3 服务化的目的

并非所有的对外接口都要做服务化改造，服务化只是手段，最终目的仍然是快速响应业务方变化的需求。

2、对服务化的误读

2.1 不断有人提到“原来我们在二方库里开放了DAO，现在正逐渐演化为开放seavice。”

易误导为开放seavice就是完成了服务化。从开放DAO到开放BIZ层，虽然封装的层次提高了，但封装的效果仍取决于对开闭原则的把握。若BIZ层封装得不到位，对于服务调用方和提供方仍然是悲剧。另外，暴露DAO提供服务的方式本身就不太好，应用与应用间因此紧密耦合在了一起。

2.2 有人提到“在枚举类中添加了一项，导致序列化失败，因此考虑放弃使用枚举"

易误导为用了服务化就不能使用枚举了。服务化涉及到远程方法调用，数据交换可以走二进制流或纯文本两种形式的协议，前者自然涉及序列化的问题。

为此有几种解决思路：

• 数据交换改为纯文本如xml/json等形式
• 自定义序列化协议，保证枚举类型的兼容性
• 提供不同版本号，升级后不影响老版本继续对外服务

3、几种服务化架构

3.1 基于hession的远程方法调用

适合企业内部的服务化（没有跨平台的需求），优点：二进制序列化效率高，含客户端能完成数据验证等功能。

3.2 web seavice with SOAP

适合内部向外部提供服务，优点：跨平台(xml)、能够自描述；缺点：xml性能相对较低。

3.3 Atom

针对web2.0背景下数据交互、聚合优化，优点：跨平台(json)，twitter、google等大佬支持。