微服务系列(三):微服务的分解和组合模式
如何更好的应对多个服务数据拼装问题?
写在春节：
这个需要数据拼接的中间层，有时我们也称之为服务聚合层，一般是与前端,APP之类直接相关的，
可能是分别返回不相关数据：
比如：空间的首页，需要返回不同模块（比如25个模块的数据），这些数据之间是彼此无关的。
也可能是：
比如：登录人员要显示的菜单，需要检查此人员的身份，角色，可以看到的菜单，还需要与CRM做校验，去掉未购买的模块数据。
这样，此层是有很多业务的，采用所谓的成熟框架是不能解决问题的，目前理解只能是编码实现之。我们在微服务层中之上构建了一个服务聚合层，或者称之为中前台接口层？？
其实，很多时候，最容易变化的就是这一层，而微服务中的基础层+业务层是比较稳定的，一般服务聚合层变更较大。以前的云平台中没有这一层，受到了很大的困扰，前端人员不断的抱怨后端人员不给一次性提供可用接口，需要反复调用多次HTTP，速度太慢；部分后端人员受不了前端人员的要求，在自己的成熟代码上增加逻辑，扩展复杂度，并不断扩展，导致接口越来越长，代码都快看不懂了。思来想去，是和自己的整体架构视野相关，坑是一点点踩的啊。同时，也明白了一个道理，不是现成有用的框架就是最好的解决方案，而是理解精髓，然后反复思考最佳实践方法，为我所用，才是王道。