屡试不爽的架构三架马车

如果你说，这么多服务，我在实现的时候很难考虑到这些点，我完全不去考虑分布式事务、幂等性、补偿(毫不夸张地说，有的时候我们花了20%的时间实现了业务逻辑，然后花80%的时间在实现这些可靠性方面的外围逻辑)，行不行?也不是不可以，那么业务在线上跑的时候一定会是千疮百孔的，如果整个业务的处理对可靠性方面的要求不高或是业务不面向用户不会受到投诉的话，这部分业务的是可以暂时不考虑这些点，但是诸如订单业务这种核心的不允许有不一致性的业务还是需要全面考虑这些点的。

考虑到跨机器跨进程调用服务数据传输方面的显著差异。对于本地的方法调用，如果参数和返回值传的是对象，那么对于大部分的语言来说，传的是指针(或指针的拷贝)，指针指向的是堆中分配的对象，对象在数据传输上的成本几乎忽略不计，也没有序列化和反序列化的开销。对于跨进程的服务调用，这个成本往往不能忽略不计。如果我们需要返回很多数据，往往接口的定义需要进行特殊的改造：

• 通过使用分页的形式，一次返回固定的少量数据，客户端按需拉取更多数据。
• 可以在参数中传类似于EnumSet的数据结构，让客户端告知服务端我需要什么层次的数据，比如GetUserInfo接口可以提供给客户端BasicInfo、VIPInfo、InvestData、RechargeData、WithdrawData，客户端可以按需从服务端拿BasicInfo|VipInfo。

这里还引申出方法粒度的问题，比如我们可以定义GetUserInfo通过传入不用的参数来返回不同的数据组合，也可以分别定义GetUserBasicInfo、GetUserVIPInfo、GetUserInvestData等等细粒度的接口，接口的粒度定义取决于使用者会怎么来使用数据，更趋向于一次使用单种类型数据还是复合类型的数据等等。

然后我们需要考虑接口升级的问题，接口的改动最好是兼容之前的接口，如果接口需要淘汰下线，需要先确保调用方改造到了新接口，确保调用方流量为0观察一段时间后方能从代码下线老接口。一旦服务公开出去，要进行接口定义调整甚至下线往往就没有这么容易了，不是自己说了算了。所以对外API的设计需要慎重点。

（编辑：宿州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!