请教大家一些关于微服务的问题

[JSP_killmylife]

1.在微服务当中，我们应当怎么处理实体类对象？比如订单服务需要用到用户服务的user对象，是否可用一个jar把实体类封装起来放到各自服务中调用？假如如此那mybatis的XML映射文件怎么写resultType？
2.使用feign调用其他微服务功能，我是用了oauth2.0专门弄了个授权服务器，其他资源服务使用基于注解（@EnableOAuth2Sso）的单点登陆，那么我要怎么解决调用方无权访问（未登录）的问题。
3.使用mycat管理各个数据库，使其统一起来，对开发者而言就像是同一个数据库而不用配置多数据源（个人理解哈，错了请指出，目前只是用到读写分离，数据库方面只做了主从复制，不知道在集群的环境下能否实现）。对于一个微服务架构的应用而言这种方法是否可行？能解决分布式事务的一致性问题吗？
4.在实际开发中，日志需要入库吗？还是用ELK管理起来？
5.使用支付宝沙箱功能中，支付宝方直接返回一个页面给你，我要怎么弄才能实现只返回那个扫描支付模块。没啥头绪，想听听大家的想法。
题外话：怎么写一个基于JS的脚本实现TX游戏网页的整点抢购功能？小弟对JS的理解只是入门级别。

[shuos_yan]

1. 是不是可以单独抽出来一个工程专门负责实体类，然后用到之后引用
4. 感觉看情况，需求要不要进行日志管理，可以入库一些简单明了的日志比如说登陆，登出

其他的没用过

[fxxkingBeast]

单独一个COMMON项目，装实体类。权限的话 通过GATEWAY来控制,,

[Forevermark993]

1.微服务的每个项目中会分多个模块，用dubbo来说，声明模块（dubbo接口与相关实体类），service模块（业务逻辑），dubbo接口类实现（提供者），web模块（含有），调用的时候肯定得引用声明模块咯~~maven坐标~~，既然是微服务，每个服务只负责自己相关的业务，订单业务用到用户，就要通过rpc调用，而不是通过表去查~~，dubbo是禁止这种做法的 2.既然你做了授权中心，没有权限的肯定跳转到授权中心的登录页面，具体可以参考sso逻辑，如果是内部系统的api接口，就不应该做这种权限校验，外部系统返回错误码~~json串你懂的 3.mycat不太了解不过多做评价，如果存在多个库，肯定存在cap问题，用mycat不是解决数据不一致的好方案，还是得从base与业务之间寻求平衡平衡点 4.日志分为两种，一种是系统日志，一种是业务日志（包括操作日志），看公司业务，如果业务日志需要做审计的话，那就必须入库，否则不需要，elk看需求，elk挺重量级的，而且绝大部分功能都用不上，可以换轻量级的，其实设计到微服务肯定会用跟踪链~~需要整合sky之类的框架，dubbo的话，可以扩展dubbo用logback的MDC来实现轻量级调用链跟踪 5.没做过，不做评价 如果是跨域js脚本的话，根本不起作用~~，要实现抢购功能，只能通过爬虫模拟，或者可编程浏览器去实现，实现都比较麻烦，验证码那关就不好过

[JSP_killmylife]

引用 1 楼 外面雨好大 的回复:

1. 是不是可以单独抽出来一个工程专门负责实体类，然后用到之后引用 4. 感觉看情况，需求要不要进行日志管理，可以入库一些简单明了的日志比如说登陆，登出 其他的没用过

目前来讲我们是这么用的，通过git管理也方便

[JSP_killmylife]

引用 2 楼 fxxkingBeast 的回复:

单独一个COMMON项目，装实体类。权限的话 通过GATEWAY来控制,,

我记得GATEWAY与zuul是两种可选方案吧，听说GATEWAY对oauth2支持不太好

[JSP_killmylife]

引用 3 楼 Farmermark993 的回复:

1.微服务的每个项目中会分多个模块，用dubbo来说，声明模块（dubbo接口与相关实体类），service模块（业务逻辑），dubbo接口类实现（提供者），web模块（含有），调用的时候肯定得引用声明模块咯~~maven坐标~~，既然是微服务，每个服务只负责自己相关的业务，订单业务用到用户，就要通过rpc调用，而不是通过表去查~~，dubbo是禁止这种做法的 2.既然你做了授权中心，没有权限的肯定跳转到授权中心的登录页面，具体可以参考sso逻辑，如果是内部系统的api接口，就不应该做这种权限校验，外部系统返回错误码~~json串你懂的 3.mycat不太了解不过多做评价，如果存在多个库，肯定存在cap问题，用mycat不是解决数据不一致的好方案，还是得从base与业务之间寻求平衡平衡点 4.日志分为两种，一种是系统日志，一种是业务日志（包括操作日志），看公司业务，如果业务日志需要做审计的话，那就必须入库，否则不需要，elk看需求，elk挺重量级的，而且绝大部分功能都用不上，可以换轻量级的，其实设计到微服务肯定会用跟踪链~~需要整合sky之类的框架，dubbo的话，可以扩展dubbo用logback的MDC来实现轻量级调用链跟踪 5.没做过，不做评价 如果是跨域js脚本的话，根本不起作用~~，要实现抢购功能，只能通过爬虫模拟，或者可编程浏览器去实现，实现都比较麻烦，验证码那关就不好过

1.既然用到了微服务肯定是各自服务对应各自的库的，我不可能用订单服务查询用户的数据库，顶多发送请求给用户服务。 2.假如该应用是甲方公司内部用的，你的意思是我不该弄这种鉴权模式吗？可是公司部门业务繁多，各个部门又有各自的系统，不应该使用单点登陆实现吗？ 3.我只记得mycat是有个什么XA协议在，也支持事务。分布式事务解决方案网上很多，但都没有提到mycat，都是提到seata二阶段提交以及TCC补偿机制、mq实现最终一致性。 4.ELK只用做日志及搜索还可以吧

[Forevermark993]

引用 6 楼 JSP_killmylife 的回复:

1.既然用到了微服务肯定是各自服务对应各自的库的，我不可能用订单服务查询用户的数据库，顶多发送请求给用户服务。 2.假如该应用是甲方公司内部用的，你的意思是我不该弄这种鉴权模式吗？可是公司部门业务繁多，各个部门又有各自的系统，不应该使用单点登陆实现吗？ 3.我只记得mycat是有个什么XA协议在，也支持事务。分布式事务解决方案网上很多，但都没有提到mycat，都是提到seata二阶段提交以及TCC补偿机制、mq实现最终一致性。 4.ELK只用做日志及搜索还可以吧

2.内部多系统api交互不应该做类似鉴权，除开涉及内网外网，或者部门定位~~，比如定位你们部门为服务商，我们部门为商家，这样才需要鉴权，看场景吧，如果涉及多个系统登录，确实需要开发一套sso 3.mycat个人认为不合适微服务的场景，它的出现只是为了解决读写分离、水平切分、垂直切分等，mycat的xa事务缺陷具体参考http://www.iocoder.cn/MyCAT/xa-distributed-transaction/确实不能保证最终的一致性 4.elk做收集没说不可以，只是说比较重量级,而且海量日志需要专门做优化，如果不需要那么多复杂功能的话，建议选轻量级的日志