RT 最近打算在一个项目上启用Thrift，有过实战经验的给介绍一下？：）

没咋用，有段时间稍微研究了下， 服务暴露的方式方面不慎满意，其他地方应该还好。

反正用thrift的唯一强有力理由就是你需要IDL的支持。其它情况下，不一定非得用它。（个人觉得）

觉得“服务暴露方式”怎么不满意法？

我并不是为了IDL的支持，而是要为一个内部的开放平台项目找个技术方案。几天看下来，感觉还不错。

另外， 如果是开放平台， 最好是不要对公网开放的那种， 我估计thrift没有各种throttle啦， 安全啦之类的支持，毕竟服务实现都是generated的， 可定制的点太少。

从我的角度，除非你要跨语言，让多语言都可以访问你的服务，否则thrift没太大意思。 

在java平台上，一大把的替代方案。 protobuf为啥只提供数据的序列化而deprecate service generation， 估计也是因为service如果是自动生成的话， 许多地方太死了，优化和扩展都不好搞。（纯粹自己猜的， 没细研究）

理解，目前的定位主要是内部使用。将来可能会开放出去。

达伦兄在类似“封装服务”的解决方案上有什么好的建议？

这个文章写的不错：

http://highscalability.com/amazon-architecture

协议中立， 服务独立， 框架或者平台给力，呵呵

---------         -----------       ------------

|  svr   |        |   svr    |       |  svr     |

---------         -----------        -----------

   \/                  \/                   \/

---------------------------------------------

|      framework / platform                |    (LB, provisioning, failover, etc)

---------------------------------------------

                       | neutral protocol 

                      \/

---------------------------------------------

|                misc. clients                   |

---------------------------------------------

http://fujohnwang.blogspot.com/2011/09/darrens-casual-thoughts-on-distributed.html

这是之前有一阵子我胡思乱想的东西，大徐要是感兴趣可以看看，呵呵，阿里巴巴开源了个dubbo框架， 其实就是做基于RPC的服务框架， 实现了我上面提到的大部分功能，但哪个产品不是我规划的，所以，我提到的些东西他们也有没有实现的。 

dubbo是java写的，原则上可以用，经过实战检验过的，呵呵，就是不知道开源的彻底不彻底 ；-）

淘宝内部在用dubbo搭建平台？

淘宝是用他们自己的HSF， 跟b2b的dubbo类似，他们做的比较早，但绑定到了OSGi， 呵呵，dubbo设计的时候，吸取了HSF设计和实现上的一些经验和教训，呵呵

thrift还是蛮好用的，特别是系统中有多种不同语言混合时，比如前台web，比用消息简单清晰多了。如果追求性能，必须使用异步调用，对于C++异步调用还未具体去实践，但感觉支持不是很好。除了，一个service需要占用一个端口外，还不能指定IP，感觉这点很不爽。

why can not set ip for thrift? I want to bind the ip specified.

TNonblockingServer.cpp：

  for (res = res0; res; res = res->ai_next) {

    if (res->ai_family == AF_INET6 || res->ai_next == NULL)

      break;

  }

// bind的IP是无法设置的

  if (::bind(s, res->ai_addr, res->ai_addrlen) == -1) {