对于生活中的计算机系统进行分析 --- 1. 卡拉OK系统

系统表现：

通过扫描一个二维码进行点歌，通过微信进行登录，进行搜索点歌。

结构猜测：

通过扫描二维码打开一个http链接 https://www.999inandon.com/ktv/weixinpl/common_shop/jiushop/forward.php?type=soundKingIndex&customer_id=41&batch=090910322635_1632223383&mark=1&version=1&connCode=c0a8008f 该链接要求必须通过微信打开，打开后进行点歌。

通过搜索可知，微信打开的判断方法来自微信内置UserAgent字段的设置。

通过分析HTTP请求可知1632223383是当前时间戳，所以这个信息是一个有时效性的信息.

第二次扫描其内容为: https://www.999inandon.com/ktv/weixinpl/common_shop/jiushop/forward.php?type=soundKingIndex&customer_id=41&batch=090910322635_1632223383&mark=1&version=1&connCode=c0a8008f 发现内容并没有发生改变, 考虑到该系统在该段时间并没有进行关机(只是关闭了显示), 所以该二维码可能是每次开机时进行刷新

分析其可能的结构:

1. 以中央服务器的方式搜集用户的点歌信息，将其下发到各个点歌客户端，对于用户端的配对方式应该通过客户端的主动通知。由于已知url中的batch字段中有一个内容是用户点歌端开机的时间戳。所以可以认为这个是主要的客户端定位信息。由于想到如果客户端使用静态batch地址可以导致用户在不在场的情况之下连入选歌客户端，导致选歌功能错误。所以这里有几种方式进行动态定位
   1. 通过用户端发送联网请求给中央服务器，服务器返回注册成功消息，并返回一个对应id
   2. 通过预定义的随机生成算法，根据实际的时间生成对应的batch id。进行服务器通信的时候只进行通知以及告知当前地址。 -- 仔细思考这个相关设计有问题。因为如果通知了中心服务器则服务器就开始服务虽然可以减少服务器进行授权的消耗，但是如果有人冒充客户端发送对应的请求授权信息，会导致服务器为无权限对象进行服务。导致服务被冒用的风险
   3. 关于这里的设计逻辑,应该是需要结合上面的两个技术 -- 需要能够通过batchid获取终端id因为需要通过终端id才能知道对应id节点使用的曲库是否为最新曲库 -- 关于这一点可以通过曲目库的更新版本号进行同步. 同步当前系统中运行的曲库的最后更新版本. 客户端通过自动将后续增量更新进行推送进行终端曲目的更新.
   4. 这里的两个服务请求(服务端注册和曲库推送)有没有可能是分开的 -- 可能,因为这样可以较为方便的进行失败重试 -- 例如接受曲目更新失效的时候不需要进行重新登记

通过以上的通信方案使得在中心服务器端可以生成一个batch id和客户端地址的对应表，每个使用某个batch_id访问的http请求都被处理为对应客户端的点歌请求。

2. 关于点歌服务的方案：

   1. 在客户端开机的时候进行全局歌曲列表的同步（可以通过增量同步而不是全量同步来减少需要传输的信息量）--- 歌曲列表的形象是歌曲网络资源链接和歌曲名的对应关系，需要兼顾通过终端不通过在线的方式进行点歌(所以对于热门歌曲等内容有硬盘存储架构)，每次有人点歌之后都通过中央服务器下传一个点歌id和用户id的对应关系。
   2. 本来我有想法是关于使用局域网的形式进行通讯 -- 但是这会导致一个问题：虽然在大多数环境下都是通过wifi进行连接的，但是在很多时候尤其是在公开场合更多的使用流量进行通信。这种情况下进行局域网的通信会导致服务端无法连接。 所以在更加一般的场景中使用局域网的服务器的应用是受到了限制的

3. 推测的服务端的接口功能:

   1. 进行终端回调登记的接口 -- 将batch_id与用户选歌信息的回调接口进行绑定
   2. 根据终端上传的最终曲库版本号进行曲库更新推送的接口 -- 进行增量更新减少对于网络的依赖.
   3. 歌曲文件下载服务接口 -- 可能通过某种形式进行加密,然后进行歌曲的下载. 将加载服务器和授权服务器分离, 减少授权服务的性能消耗