来个对微服务有理解的解答下疑惑,或者叫讨论

• 先来一张图!

• 阐述下个人观点

1. 我认为此图的业务层在代码里表现就是前端代码，因为微服务领域模型按领域划分职责。
2. 服务中心为单个微服务，微服务之间是直接采用fegin通信，不需要再包装任何中间代码层，jar层，不然无法体现微服务的独立性。
   ###疑问：

1.业务层是否需要再包装，即对各个服务中心包装一对一的范围业务接口
业务层是直接调用服务中心，还是应该在把中心服务聚合包装一次更合理
简而言之就是*服务中心能不能被前端直接调用，
2.服务中心之间的调用，是否需要进行再包装，比如 服务中心有fegin层、restApi层，
中心之间的访问 是否对fegin进行包装，其他只能引用fegin包装层
3. 如果一个 会员中心，需要填写表单并上传文件，是会员中心直接包装一个完整的接口（内部调用文件中心），
还是业务端自己独立调用文件中心，收到返回，再调用会员中心更合理

不能说错，也不能说全对！
要了解一些事情，得从历史出发！
你要理解微服务，那么你得了解微服务的发展历史！

展示那层才是前端吧, 业务层是后端逻辑处理代码;
微服务的每个服务都是通用的 也是相互独立的, 比如你做两个app, 都有对应的用户积分, 那么他们都可以调用微服务里面的积分服务, 然后在各自对应的业务层进行业务自己的处理并返回结果, 这块是有点中台的那个概念的; 独立性在于积分服务挂了, 但是其他所有的模块都不受影响, 包括上线部署等等都只会跟积分这个最小单元有影响
这块还有个网关的概念, 可以指定服务专门做转发用rpc通信做网关, 也可以直接业务端rest返回

展示层才是前端，业务层是业务的后端处理接口，服务中心可以是提供基础数据的地方，比如数据中台。

服务中心一般是间接被调用的，尽量保持前后端分离，让前端的处理逻辑更加简单

展示层才是前端 业务层是后端service那层

微服务的好处是：告别强耦合、混沌、笼统的大系统，化解为一个个“微小的服务”，能够有针对性的对某一模块进行扩展和维护