接口服务化问题

目前相对项目的缓存进行优化，然后网上找了资料，有几个问题想问下，
一般情况下我们的缓存都是在业务逻辑上面处理的，如下图：

上面缓存架构有一个缺点：业务方需要同时关注缓存与DB，
那么我们进一步优化，加入一个服务层：

这个方案应该是主流方案了，它向上游提供帅气的数据访问接口，向上游屏蔽底层数据存储的细节，这样业务线不需要关注数据是来自于cache还是DB。
那么问题：这个service该怎么实现呢？或者说用什么好的实现方案呢？

rpc，数据序列化与反序列化。

大型系统通常会混合多重编程语言，例如前端可能用的是php，而复杂的后端计算和业务逻辑又用了java，某些特殊的服务可能用了erlang或者c++。
那么rpc采用跨平台语言的，apache thrift，或者zeroc ICE就比较方便了。

service使用易于长期进程存活的，健壮的语言编写。 java比较适合。 application不论是php还是什么其他语言，都可以方便的调用。

当然也可以使用json之类的约定数据结构，在各端进行“序列化”与“反序列化”。
考虑好service层的高可用性方案，后端调用的问题，用个注册/发现，心跳健康检查等保障就可以了。 自行开发或者使用zookeeper之类的都行。