已经到了这一步,进度还算比较快。只是悲剧的是,当我整理完项目调用关系后才“恍然大悟”,妈蛋,年前某个时间我已经做过一次这样的工作了。而且更夸张的是,那一次做的比现在还彻底,哇哈哈哈哈,我这种记性,也是醉了。值得庆幸的是,两次流程的大致方向还是一致的(不然就麻烦了,精神分裂~)。

言归正传,本来计划接着上一篇,直接开始写服务的详细设计呢,但是感觉还是缺少什么,应该就是对平台的整体设计规划吧。先上一张图:

图解:

  • 客户端和运营平台之间的通信统一基于Http的REST API,这类API尽可能保证完整业务逻辑,以粗颗粒度提供(意味着复用性较差)
  • Rest API内部会负责业务编排,以dubbo提供的高性能协议与运营平台中的数据应用服务进行通信
  • 数据应用服务之间允许相互依赖,同样基于dubbo
  • 数据应用服务之间的依赖应该尽可能的少,应该尽可能放在Rest API层来做处理这种依赖
  • 后方的各个数据系统之间不存在直接依赖,所有依赖都需要通过运营平台的数据应用服务来提供,通信同样基于dubbo
  • 计费和权限认证等逻辑尽可能的异步化或并行(后面详细讨论)

这是年前设计出的一张图,现在来看依然是很满意的,唯一值得考虑的就是“微服务”概念,我一直比较赞同这个概念,尤其是在做SOA筹备的时候更是如此。上图中,数据应用服务是比较适合以微服务方式设计的,不过还需要结合dubbo更仔细的琢磨琢磨。

接下来再来说一下关于上图中一些特殊的服务:计费,认证授权等。我提到了异步和并行,如图:

图解:

  • 虚线表示异步调用,实线表示并行调用
  • 计费和余额查询分离,会产生一个不一致的时间窗口,这需要结合业务来衡量可行性
  • 余额查询,权限认证和获取数据并行调用,最终会在API层合并后给予最终裁决
  • 图中省略了SLB的相关部分

最后,我们讨论一下系统中另外一种场景的通信:消息通知。稍微复杂一些的系统,都会对消息队列有强的需求。这是因为,系统之间的通信在排除了人类参与的情况下,并不需要非常之高的即时响应指标,相反,对消息的最终可达性要求确实100%的。这也是消息中间件的战场,各种各样的开源产品可供我们选择。

我们跳出具体的消息中间件,从业务层面来梳理一下我们目前的平台中要如何设计这部分场景,如下图:

图解:

  • 没什么要解释的啦

目前为止,我们已经从整体上描述了一下要做的事情,不管你们看完后有啥感受,我自己是清晰了不少,哇哈哈。这一篇谈的有点虚,都是围绕着实际业务来谈概念的,应该就是所谓的概念架构设计了吧~~

下一篇开始,就要深入到代码微观视角了,尽请期待!