微服务调用事项

微服务=配置+流程+组件
微服务调用:
1、不要用api去调用api,比如report的实体类去继承collect实体类,容易导致有些接口情况出现report—>collect,collect—>report,从而耦合性不好。
用server去调用api
总结起来是collect-server---->report-api √
report-server—>collect-api √
report-api—>collect-api ×
collect-server—>merchant-api √ 推荐
2、底层如merchant是用来被别人调用的,merchant商户服务相当于用户概念,所以用report—>merchant、collect---->merchant, 但是merchant不要去调用其他服务
3、并且调用之间修改版本要同步修改,如collect-api修改了,那么调用他的report-server也要同步修改过来。
4、集群打通问题
admin、merchat两个服务是同一个集群,它们显然是可以互相打通互相调用的。而merchant和collect、report服务手动去打通,使得collect、report可以调用merchant,但不意味着admin可以调用collect、report,这个要手动去打通。因为collect、report是另一个集群。除非集群和集群互相打通,不然还是要一个一个去打通,collect、report分开来去打通。

分析Java微服务优点

微服务最直接解决什么问题?
高可用,高并发(是问题),高性能 “三高”
主要网络可能会不可靠的,所有业务都依赖一个服务压力太大了,所以有微服务

服务与服务之间通过api网关去访问

同步通信与异步通信

微服务调用事项;分析Java微服务优点_微服务

SpringCloud和dubbo是微服务的两套不同方案,核心目标还是微服务架构解决问题

微服务调用事项;分析Java微服务优点_实体类_02

微服务最明显优点的就是模块化

lego处理前端要调用的路径

同时它自己可以有api调用,可以用来处理一些用户token,登录角色,日志等

同时lego调用每个模块的服务(Controller)请求的实体类命名可以为XXXReq,XXXRequest

private final IJoinBrandHotRemoteService joinBrandHotRemoteService;

而每个服务暴露出接口api给lego去调用

而每个服务下面专心去写业务
包括常用的各个层controller—>service—>mapper或dao---->注解查询sql或用xml文件 也就是增删改查 这里的实体类一般和数据库保持一致