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

集群和微服务、分布式

（对系统分而治之，解决因为并发访问过大带来的系统复杂性（例如：业务，开发，测试，升级，可靠性） 微服务设计的特点（单一职责，独立进程，开发测试效率高，可靠性高，升级难度小，但是会带来一定的维护成本）
Maven清理clean 编译complite 安装install 部署deploy
集群：多个服务器对一个服务，rocketmq消费的时候默认使用集群模式，而不是广播模式；redis用了集群，每个服务器分担一些，还有master节点、从节点。
微服务：一个服务对一个功能类别业务，一个服务器对一个任务、服务，一个服务可以有多个实例
分布式：分布式系统是若干独立计算机的集合，单体架构向多体架构演变的过程。分布式属于微服务的一种。
主从复制，读写分离。

开发步骤

Req---->一系列复杂的关系-------->resp 跨服务
查询数据库---->nosql:redis缓存，存储es目的搜索查询
---->mysql
主服务controller---->业务服务
接口层面加了feign
熔断 – 打断调用链提早结束不正常的调用
降级 – 使某一个节点暂时退出系统减少接收请求量，等它恢复
容错机制
同一个意思
Server—>api 业务调用req
业务服务调用
Network、saas-admin–>业务服务----->商户服务---->底层服务common framework

微服务调用事项

微服务=配置+流程+组件
微服务调用:
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网关去访问

同步通信与异步通信

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

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

lego处理前端要调用的路径

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

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

private final IJoinBrandHotRemoteService joinBrandHotRemoteService;

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

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