这是一个创建于 3588 天前的主题，其中的信息可能已经有所发展或是发生改变。
遇到了服务化的一些问题，望有这方面的经验的大大不吝啬指教。
1. 在以前公司，因为有已经有200多个游戏，因为排行榜经常用，于是我们服务化了一个排行榜服务给游戏服务逻辑端调用，因为公会和社交关系，我们服务化了用户人际服务，因为经常需要集成第三方用户和平台，于是造了个看门狗服务。 这些都是非常通用的服务。
2. 现在在一家小互联网公司，今天在做签到模块，大主程说要做成soa服务化，最后的效果是直接面向客户的服务端在用户认证后，调用soa服务后拿到结果搞了个json转换直接扔给了客户端。其实这类web端和移动端公用的api做个简单的restful api已经足够了，后端用个orm或者data-mapping绝对能轻易解决。另外的一个情况是按照大主程的意愿和想法，对一遍文章做隐藏功能api，面向客户端的服务在调用soa服务 rpc blog.set(blog_id, status) soa service 只做一个一个简单的数据库字段修改就完事，然后抛了ok，在扔给客户端。
很郁闷，soa的粒度和什么业务逻辑才需要做服务化， 另外情景2到底有必要吗，对于非常简单的业务，需要服务化？
1. 在以前公司，因为有已经有200多个游戏，因为排行榜经常用，于是我们服务化了一个排行榜服务给游戏服务逻辑端调用，因为公会和社交关系，我们服务化了用户人际服务，因为经常需要集成第三方用户和平台，于是造了个看门狗服务。 这些都是非常通用的服务。
2. 现在在一家小互联网公司，今天在做签到模块，大主程说要做成soa服务化，最后的效果是直接面向客户的服务端在用户认证后，调用soa服务后拿到结果搞了个json转换直接扔给了客户端。其实这类web端和移动端公用的api做个简单的restful api已经足够了，后端用个orm或者data-mapping绝对能轻易解决。另外的一个情况是按照大主程的意愿和想法，对一遍文章做隐藏功能api，面向客户端的服务在调用soa服务 rpc blog.set(blog_id, status) soa service 只做一个一个简单的数据库字段修改就完事，然后抛了ok，在扔给客户端。
很郁闷，soa的粒度和什么业务逻辑才需要做服务化， 另外情景2到底有必要吗，对于非常简单的业务，需要服务化？
 |
1
justfly 2015-02-03 21:10:53 +08:00
我觉得看以后有没有多个业务复用这个逻辑，如果有的话就搞成服务，以后各种不同形态的业务对下层服务做各种聚合，最终提供api给客户端
|
Select Language