对面向服务架构的一些体会

上一个项目中参照了SOA的思想，web前端使用java，后端服务使用C++，通信使用thrift。

在使用过程中一些总结：

1. thrift 风格的接口其实本质是rpc，和以前的corba，java的rmi，zero的ice，淘宝的HSF、阿里巴巴的dubbo的思想一致。使用这类接口的难点在于接口的设计，接口和前端展示结合太紧密了，接口粒度太大，不容易重用服务，粒度太小，要多次调用服务，增加网络开销，难啊，特别是接口数据结构的有包含关系时。
2. 这类rpc的通信框架应该要有timeout机制，一个服务调用得有timeout，这样才不会阻塞，而这个timeout并不是tcp传输的timeout，应该是应用层的timeout。
3. 这类rpc的通信框架应该有异步机制，这样能发起多个服务调用，节省总的调用时间。
4. 内部服务需要rpc框架呢还是rest服务？个人觉得跟信息结构有关，evernote的内部和外部api都是thrift，淘宝等内部是rpc型，外部api是rest型。很多时候内部也用rest是很牵强的。
5. 有同事这样使用thrift，定义一个很通用的request和response结构来通过thrift来传输，在代码的两端再转换成相应的业务数据结构，美其名曰接口简单，稳定。个人认为这样是不对的。其实一旦涉及约定变化，就算这类接口不变，但是两端的数据结构的转换都的变。这其实是消息通信的模式。rpc和消息有各自的场景。
6. rpc服务对网络部分失效不支持，如一个rpc接口，addcase，如果写数据库成功了，但是网络返回响应失败了，这时客户端得到网络异常。代码里的异常捕捉处理是重新发起呢，还是不处理。其实对这类问题，技术能处理，调整服务接口，使之冥等性，但是这样又污染服务接口，妥协之，对重要的数据采用冥等方法处理。
7. 当然这只是服务使用的初步阶段，以后的服务容错，注册、治理是后期项目大了的问题。
8. 也又有人说服务的架构太重了，web前端可以直接访问数据库。其实前端还有一个open server同样调用后端的c++服务，openserver为提供通道方便桌面程序做些和系统的交互。