技术日志2023-5-18

1、Java远程调试

可参考：https://kefeng.wang/2018/03/06/idea-remote-debug/

2、用户中心这样的基础项目有什么用，感觉非常鸡肋。

今天开发讨论中涉及到了用户中心，感觉在项目中使用用户中心只是给业务系统发一个token，业务系统还需要自己做权限校验。
而且用户中心作为一个通用组件，还不能和业务系统强关联，在用户中心增加一个用户，还不能同步到业务系统。
用户中心能做的，业务系统也都可以做，而且也没有很多的工作量。

所以请教了一下ChatGPT，回答如下：

问：系统设计中为什么会有用户中心这种基础项目

答：用户中心是系统设计的一个基础项目，因为它涉及到用户信息、安全性、权限管理等核心问题。
首先，用户中心是系统中存储用户信息的重要组件，包括用户账户、密码、个人资料等。这些信息需要得到妥善的处理，防止被恶意攻击者盗取或篡改，以保证用户账户的安全性。
其次，用户中心还需要实现用户权限管理，在系统中进行访问控制，以确保用户访问系统时只能看到和操作它们被授权的部分。这也对系统的安全性和完整性至关重要。
最后，用户中心在交互设计和用户体验方面也非常重要。用户中心应该被设计成一个易于使用且符合用户期望的界面，充分考虑到用户习惯和心理需求，以提高用户对系统的依赖性和使用率。
总之，用户中心在系统设计中的重要性不言而喻，是保证系统的完整性和安全性的基础组件之一。

问：使用用户中心后项目还需要自己做权限校验吗

答：使用用户中心后，项目仍需要进行权限校验。尽管用户中心负责管理和维护用户的登录和基本信息，它并不负责应用程序级别的权限管理。
应用程序级别的权限管理是指控制用户可以访问和执行哪些功能、数据等等的授权。这通常需要在系统代码中实现，并在应用程序的操作中进行权限校验。只有在用户经过了应用程序级别的权限校验后，才可以执行所请求的操作。
用户中心通常只负责提供基本的安全机制，如认证、授权和会话管理。它并不负责应用程序的业务逻辑和权限细节，这些都需要应用程序自行处理。因此，即使使用了用户中心，应用程序仍然需要进行权限管理和校验，来确保系统的安全性和可靠性。

问：用户登录后每次请求还需要过一下用户中心吗

答：用户中心和业务系统都是独立的服务。当用户访问业务系统时，业务系统需要进行身份认证，并从用户中心获取身份信息的验证结果，以确保用户已经通过了有效的身份验证，并具有执行相应操作的授权。
具体来说，当用户进行身份验证并登录之后，在用户中心生成一个与该用户相关的会话标识（如令牌或会话 ID），该会话标识与用户的身份信息相关联，然后将该会话标识返回给用户。
当用户访问业务系统时，业务系统需要获取该会话标识，并将其发送到用户中心进行身份验证。如果会话标识有效并且与已登录用户的身份信息匹配，用户中心会返回验证通过的信息给业务系统。业务系统将使用该信息进行权限校验，并执行用户请求的操作。如果会话标识无效或过期，用户中心将返回未通过验证的信息，并要求用户重新进行身份验证。
因此，每次用户请求业务系统时，都需要先将会话标识发送到用户中心进行身份验证，以确保用户的请求得到有效认证和授权，从而保证系统的安全性和可靠性

问：那这样不会有性能问题吗

答：对于用户中心和业务系统之间的身份验证和授权，确实会增加一定的网络延迟和系统开销，但这种开销通常是可以管理和优化的。
以下是一些可能的优化措施：
使用跨域认证标准 (如 OAuth)：这可以使用户中心和业务系统之间的认证更加简单和高效，从而降低身份验证的网络延迟和处理时间。
使用缓存：将用户会话信息缓存在应用程序的内存中或使用分布式缓存（如 Redis) 可以减少每个请求中对用户中心的调用次数和网络延迟。
使用身份验证代理：这是一种专门用于集成和管理多个可信身份验证系统的软件。它可以实现在业务系统中自动选择和调用可用的身份验证源，从而简化和加速身份验证的处理过程。身份验证代理还可以提供额外的安全功能，如 IP 地址过滤、防火墙以及访问速率限制等。
优化硬件和网络：加强硬件设备和网络等基础设施的处理能力，增加机器的数量，配备更强劲的服务器设备，从而提高系统的性能和并发处理能力。
总之，虽然每次请求都需要进行身份验证和授权，但是通过上述方式，可以最大限度地降低身份验证和授权之间的延迟和处理时间，并提高系统的性能、稳定性和安全性。

问：那用户中心会返回给业务系统那些数据呢

答：当用户中心完成身份认证并对业务系统进行授权后，会将授权信息返回给业务系统。这些返回信息一般包括以下几个方面：
用户身份信息，包括用户id、用户名、用户角色等。
认证令牌或会话 ID 等信息，用于在后续请求中标识该用户的身份。
授权信息，比如用户所拥有的角色，用户可以访问的业务系统资源等。
认证/授权过程中所使用的密钥、证书等，以保证身份认证和授权的安全性。
其他有关用户身份验证和授权的相关信息和元数据，比如过期时间、访问时间、访问次数等。
这些信息将帮助业务系统判断用户身份，验证用户是否有权限请求相关资源或执行相应的操作，从而确保业务系统的数据和功能的安全性和可靠性。

问：如果用户属于多个部门，用户可以切换登录部门，是用户中心做还是业务系统做

答：多部门切换登录的功能可以由用户中心来实现。当用户在多个部门中有权限时，用户中心可以获取用户的部门信息，从而展示不同部门的资源，或者提供切换部门的选项，让用户选择要登录的部门。
用户中心将负责将用户信息和部门信息保存在会话中，并将用户的请求路由到相应的业务系统中。当用户选择切换部门时，用户中心会更新当前用户的会话信息，以反映用户所选择的新部门。这个过程几乎是透明的，用户无需在业务系统之间重新登录或输入身份信息。只需单击一下页面上的“切换部门”按钮，就可以切换到不同的部门，或者在不同部门的业务系统之间切换。
为了实现这个功能，业务系统也需要修改其用户认证和授权逻辑，以支持用户中心传递过来的部门信息，并根据部门信息过滤相关的业务数据或操作。但是这些业务逻辑的实现，是业务系统应该考虑的问题。用户中心可以提供一些 API 或 SDK，以方便业务系统集成多部门切换登录的功能。

问：用户中心支持用户拥有多个角色，用户属于多个部门，这样的表关系如何设计

答：对于这样的场景，我们通常采用以下两个表进行设计：

• 用户表（User Table）：用来存储用户的基本信息，比如用户ID，用户姓名，登录名，密码等等。

• id：用户唯一标识符。

• name：用户姓名。

• login_name：用户登录名。

• password：用户密码。

• …

• 用户-部门-角色 关联表（User-Department-Role Association Table）：用来存储用户所属部门和角色的关系，一个用户可以属于多个部门，可以拥有多个角色。

• id：关联表唯一标识符。

• user_id：用户表中的id，表示该关联信息属于哪个用户。

• department_id：部门表中的id，表示该关联信息属于哪个部门。

• role_id：角色表中的id，表示该关联信息属于哪个角色。

关联表中的 user_id, department_id 和 role_id 通常都是外键，它们与各自对应的表中的主键相对应。

这样设计的好处是可以灵活的解决多角色和多部门的问题，用户可以通过关联表来建立和多个角色和多个部门之间的关联关系。同时，如有需要也可以建立用户表和角色表、部门表之间的关联关系，实现高效的权限分配和管理。

问：在用户中心增加一个用户，是否需要同步到业务系统

答：增加一个新的用户后，业务系统需要获取这个新用户的身份信息和授权信息，才能对其完成业务操作。因此，用户中心需要将这个新用户的身份信息以及相应的授权信息同步给业务系统。
注意，这里所提到的同步不是简单的将数据复制到业务系统中，而是实现一种基于统一身份和授权的身份验证和授权机制。用户中心和业务系统之间需要建立一定的身份认证和授权模型，用户中心将负责在用户认证授权过程中与业务系统通信，以实现身份验证和授权的安全性和可靠性。
在具体操作过程中，当用户中心增加一个新的用户时，它会将该用户的身份信息和授权信息保存在自己的数据库中，并通知业务系统进行同步。业务系统在接收到通知后，将获取新用户的身份信息和授权信息，以便决定该用户是否有访问系统资源的权限。
当然，具体的同步策略和方法，需要根据业务系统的需求和特点而定。但是总的来说，用户中心和业务系统建立一种基于统一身份和授权的身份验证和授权机制是非常必要的，这将有利于提高系统的安全性和可靠性，同时也能满足更多的商业需求。

问：这个同步操作时通过消息队列吗

答：可以使用消息队列来实现用户中心和业务系统之间的同步操作。
消息队列是一种异步通信模式，有利于解耦和异步处理，可以帮助解决不同系统之间的纵向和横向扩展问题。在这里，消息队列可以用来协调用户中心和业务系统之间的通信，以确保信息的可靠传递和处理。
当用户中心增加一个新的用户时，可以将该用户的相关信息写入消息队列，然后业务系统在接收到消息后，从消息队列中读取该信息以便进行后续的同步操作。另外，在完成同步操作后，业务系统也可以将执行结果写入消息队列，以便用户中心重新获取处理结果，这将确保整个同步过程的可靠性和可控性。
使用消息队列的好处是，可以支持异步处理，从而减轻系统负担，提高系统的稳定性和弹性。同时，还可以提高系统的并发性和可扩展性，从而支持更大的业务流量。但是，也需要注意消息队列的安全和性能问题，避免出现性能瓶颈和安全漏洞。

问：还有什么同步方式呢

答：除了使用消息队列，还有一些其他的同步方式可以用来实现用户中心和业务系统之间的同步操作。比如直接使用REST API、定时任务同步和基于SDK的同步等等。根据不同的业务场景和需求，可以选择不同的同步方式，进行灵活的部署和使用。

3、新增司机所想到的问题

业务场景是这样的：

每一个司机都有自己唯一的档案信息（手机号、身份证号、驾驶证照片等），然后司机可以绑定到多个部门下。
新增司机的时候，如果司机档案信息不存在，则新增档案信息并且绑定到当前部门下，如果司机档案信息存在，则司机的档案信息回写到前端界面，然后保存操作只是将司机和当前部门进行关联。

问题是：

这样回写就容易暴露司机的信息，司机误输了手机号有可能刚好拿到别人的信息回写过来。

思考：
1、不影响，因为增加司机到当前部门本来就是管理员的操作，管理员本来就可以看到所有司机信息。
2、回写过来的信息如果不清除，那么用户很有可能会偷懒，只改部分信息提交。
3、如果用户已经填了一部分数据了，然后回写会将用户填的数据都覆盖，这样用户白写了。

4、写代码的思考

代码尽可能只写一份，不要因为别的地方要用而copy一下，通用的代码尽量抽出来写成方法。不然后面发生修改的时候非常容易漏改一些代码。

5、关于系统的想法

系统的设计应该是尽可能让上游操作保证一些规范，例如某某数据正常操作是一定会有的，那下游操作就可以减少很多处理了。不然代码越写越难，什么都不确定了，可能性就变多了，代码也更难了。