这是一种极为简单的微服务架构，只是为了从业务上拆分，避免项目演进过程中，难以拆分。每个微服务都是一个单独的项目，不对外暴露接口，仅可被入口项目调用，每个微服务对应自己的数据库，redis db，相关配置文件，redis key 必须使用前缀，未来有大key产生容易分析问题，两个微服务之间可以互相调用接口，不可操作对方数据库，redis等，业务互相独立。队列，日志和监控服务统一到第三方基础服务上，方便管理。
其中所有的调用由网关，也是入口处发起，请求进来之后，需要网关层面解密现有签名，然后加上新的对应微服务的签名，在请求上加上 trace id，调用远程服务，获得结果后返回给请求发起方。
微服务拆解之后，如果请求量不大，使用 http 协议调用完全足够，如果使用 tcp 等协议，会提升互相调用的响应速度，但是需要额外的注册中心来维护这些开放的地址，会需要额外的维护成本，http 协议的调用的基于路由组件就可以的，而每个微服务保留基础的路由组件，未来方便扩展成为其他形式调用。
备注： Rpc 是一种技术，远程调用技术，封装 http 请求就是这种技术的实现方式。 我们调用函数的本质是寻址函数地址，那么RPC的目标就是函数不在本地（本进程地址空间），但是从调用形式上又和调用地址空间内的函数一致。
风险点： 服务直接的互相调用可以用事件触发，用 http 请求来实现，在遇到 A 服务抖动的时候，B 服务持续调用，不经过限流或者降级等，容易引发服务间的雪崩，这个在项目发展中需要处理好，微服务架构的前期要点是细化拆解，后期要点是服务治理。
参考链接：
最后恰饭 阿里云全系列产品/短信包特惠购买 中小企业上云最佳选择 阿里云内部优惠券
