屡试不爽的架构三架马车

希望在这里把这个事情说清楚了，怎么来划分服务怎么划分三个层次的服务是一个很有意思很有必要的事情，在服务划分之后最好有一个明确的文档来描述每一个服务的职责，这样我们在无需阅读API的情况下可以大概定位到业务所在的服务，整个复杂的系统就变得很直白了。

每一个服务对接的底层数据表是独立的没有交叉关联的，也就是数据结构是不直接对外的，需要使用其他服务的数据一定通过访问接口进行。好处也就是面向对象设计中封装的好处：

• 可以很方便地重构底层的数据结构甚至是数据源，只要接口不变，外部不会感知到。
• 性能有问题的情况下需要加缓存、分表、拆库、归档是比较方便的事情，毕竟数据源没有外部依赖。

说白了就是我的数据我做主，我想怎么搞外面管不着，在重构或是做一些高层次技术架构(比如异地多活)的时候，没有底层数据被依赖，这太重要了。当然，坏处或是麻烦的地方就是跨服务的调用使得数据操作无法在一个数据库事务中完成，这并不是什么大问题，一是因为我们这种拆分方式并不会让粒度太细，大部分的业务逻辑是在一个业务服务里完成的，二是后面会提到跨服务的调用不管是通过MQ进行的还是直接调用进行的，都会有补偿来实现最终一致性。

考虑到跨机器跨进程调用服务稳定性方面的显著差异。在方法内部进行方法调用，我们需要考虑调用出现异常的情况，但是几乎不需要考虑超时的情况，几乎不需要考虑请求丢失的情况，几乎不需要考虑重复调用的情况，对于远程服务调用，这些点都需要去重点考虑，否则系统整体就是基本可用，测试环境不出问题，但是到了线上问题百出的状态。这就要求对于每一个服务的提供和调用多问几个上面的问题，细细考虑到因为网络问题方法没有执行多次执行或部分执行的情况：

• 我们在对外提供服务的时候，不但要告知用户服务提供的业务能力，还要告知用户服务的特性，比如是否是幂等的(对于订单类型的操作服务，相同的订单相同的操作强烈建议是幂等的，这样调用方可以放心进行重试或补偿);是否需要外部进行补偿(在这里你可能说为什么需要外部进行补偿，服务就不能自己补偿吗，对于内部的子逻辑服务当然可以自己补偿，但是有的时候因为网络原因请求就没有到服务端，服务端一无所知这个调用当然无从去补偿);是否有频控的限制;是否有权限的限制;降级后的处理方式等等。
• 反过来，我们调用其它服务也需要多问几句目标服务的特性，针对性进行设计相应的补偿逻辑、一致性处理逻辑和降级逻辑。我们必须考虑到有些时候并不是服务端的问题，而是请求根本没有到达服务端。
• 服务本身往往也会有复杂的逻辑，作为客户端的身份调用大量外部的服务，所以服务端和客户端的角色不是固定不变的，当我们的服务内部有许多客户端来调用服务端的时候，对于每一个子逻辑我们都需要仔细考虑每一个环节。否正会出现的情况就是，这个服务是部分逻辑幂等的或是部分逻辑是具备最终一致性的。

（编辑：宿州站长网）

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