在《BladeX开发手册》文档中有关于BladeX-Biz的描述如下：
1：核心主工程bladex单独起来，不做改动，只跟随官方主分支更新；每个子系统单独新建工程，将业务代码写入bladex-biz中（当然这是要重命名成各个子系统的）。最后多个子系统汇总到git的一个组织内，这样点进去就能看到这个综合平台内有多少个子系统了。分工明确，代码管理也方便
2：至于每个bladex-biz工程配置一个gateway，是非常必须的。这样gateway可以选择是调用注册在公共nacos的服务还是本机nacos的服务，非常灵活，方便进行调试。
一、该问题的重现步骤是什么？
N/A
二、你期待的结果是什么？实际看到的又是什么？
针对第1点的个人理解：针对多个子系统而言，bladex单独起来不做改动；但是，可以将多个子系统“公共部分”的功能增加到blaedx系统中，但是要注意与bladex之间的耦合，以便于能够跟随官方主分支的更新；而针对各个子系统不同的业务，多团队开发的时候，将“个性化”的与具体业务相关的功能分别在各自的“bladex-biz”中进行开发，最终进行整合。————此理解是否符合框架的设计意图？
每个bladex-biz中配置一个gateway，个人理解是为了开发过程中方便进行调试，既可以连接到本地Nacos亦可以连接到公共Nacos；而在真正的生产环境进行部署的时候，bladex-biz中的gateway是否不用启动的，统一经由bladex上的gateway进行转发即可？
基于第2点的理解，当多个开发团队分布在不同的城市开发，每个团队需要部署一个Bladex服务器（局域网开发为例）将所需要的auth，desk等基础微服启动起来以便于专注开发bladex-biz？而bladex-biz中的gateway的作用便起到，既可以连接到本机上的Nacos亦可以连接到公共（服务器）上的Nacos？
另外，Boot版本对接至Cloud的问题，关于用户等基础信息的处理机制是什么？
因为，Boot版本有一套属于自身的用户管理等基础功能，那么当Boot版本对接到Cloud版本后，那么当用户同一经由Cloud进行登陆的时候，那么Boot版本相关用户的管理是否不再起到作用？还是说，经由Cloud版本进行登陆后，去访问Boot版本时单独跳转成一个“新系统”，从而”独立“的访问Boot版本?
三、你正在使用的是什么产品，什么版本？在什么操作系统上？
《联合版》——cloud版本，Linux系统
四、请提供详细的错误堆栈信息，这很重要。
N/A
五、若有更多详细信息，请在下面提供。
N/A
扫一扫访问 Blade技术社区 移动端
加载中...
苏公网安备 32041102000998号