屡试不爽的架构三架马车
希望在这里把这个事情说清楚了,怎么来划分服务怎么划分三个层次的服务是一个很有意思很有必要的事情,在服务划分之后最好有一个明确的文档来描述每一个服务的职责,这样我们在无需阅读API的情况下可以大概定位到业务所在的服务,整个复杂的系统就变得很直白了。 每一个服务对接的底层数据表是独立的没有交叉关联的,也就是数据结构是不直接对外的,需要使用其他服务的数据一定通过访问接口进行。好处也就是面向对象设计中封装的好处:
说白了就是我的数据我做主,我想怎么搞外面管不着,在重构或是做一些高层次技术架构(比如异地多活)的时候,没有底层数据被依赖,这太重要了。当然,坏处或是麻烦的地方就是跨服务的调用使得数据操作无法在一个数据库事务中完成,这并不是什么大问题,一是因为我们这种拆分方式并不会让粒度太细,大部分的业务逻辑是在一个业务服务里完成的,二是后面会提到跨服务的调用不管是通过MQ进行的还是直接调用进行的,都会有补偿来实现最终一致性。 考虑到跨机器跨进程调用服务稳定性方面的显著差异。在方法内部进行方法调用,我们需要考虑调用出现异常的情况,但是几乎不需要考虑超时的情况,几乎不需要考虑请求丢失的情况,几乎不需要考虑重复调用的情况,对于远程服务调用,这些点都需要去重点考虑,否则系统整体就是基本可用,测试环境不出问题,但是到了线上问题百出的状态。这就要求对于每一个服务的提供和调用多问几个上面的问题,细细考虑到因为网络问题方法没有执行多次执行或部分执行的情况:
如果你说,这么多服务,我在实现的时候很难考虑到这些点,我完全不去考虑分布式事务、幂等性、补偿(毫不夸张地说,有的时候我们花了20%的时间实现了业务逻辑,然后花80%的时间在实现这些可靠性方面的外围逻辑),行不行?也不是不可以,那么业务在线上跑的时候一定会是千疮百孔的,如果整个业务的处理对可靠性方面的要求不高或是业务不面向用户不会受到投诉的话,这部分业务的是可以暂时不考虑这些点,但是诸如订单业务这种核心的不允许有不一致性的业务还是需要全面考虑这些点的。 考虑到跨机器跨进程调用服务数据传输方面的显著差异。对于本地的方法调用,如果参数和返回值传的是对象,那么对于大部分的语言来说,传的是指针(或指针的拷贝),指针指向的是堆中分配的对象,对象在数据传输上的成本几乎忽略不计,也没有序列化和反序列化的开销。对于跨进程的服务调用,这个成本往往不能忽略不计。如果我们需要返回很多数据,往往接口的定义需要进行特殊的改造:
这里还引申出方法粒度的问题,比如我们可以定义GetUserInfo通过传入不用的参数来返回不同的数据组合,也可以分别定义GetUserBasicInfo、GetUserVIPInfo、GetUserInvestData等等细粒度的接口,接口的粒度定义取决于使用者会怎么来使用数据,更趋向于一次使用单种类型数据还是复合类型的数据等等。 然后我们需要考虑接口升级的问题,接口的改动最好是兼容之前的接口,如果接口需要淘汰下线,需要先确保调用方改造到了新接口,确保调用方流量为0观察一段时间后方能从代码下线老接口。一旦服务公开出去,要进行接口定义调整甚至下线往往就没有这么容易了,不是自己说了算了。所以对外API的设计需要慎重点。 (编辑:东莞站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |