结对编程作业服务器端系统设计、玩法和接口简要

Notice

写得乱得一比，将在脑子清醒的时候重构

文档

API文档

文档可以看这里，正常情况的文档已基本稳定，异常情况的文档还没写
如有问题，可以留言或CC我

整体设计

客户端服务端采用HTTP请求的方式进行交互，客户端可以通过开局接口开局或加入并抽牌，并通过出牌提交接口出牌，然后本局等待结算。客户端可以立即开下一局。

设计考虑

原考虑和存在的问题

原本我是考虑设计一个实时进行牌局的对战平台，凑够四个人开局，发牌，2秒(或其他考虑RTT的合理时间)内出牌，然后服务端判牌，结算，整个过程实时进行，大家同步。

但是这样存在一些问题。首先就是凑够四个人开局，由于结对，我们的用户基数只有六十几个，让大家在同一时间一起运行客户端，是不太现实的。其次，实时传输和结算会给服务器带来很大压力。而且这样也不方便测试和Debug。其中最主要的还是大家的上线时间的问题。

当前考虑

考虑到福建十三水一局游戏中每个人出牌只依赖于他所拿到的牌，且他看不到别人拿到的牌，直到结算。这样，当一个客户请求开局时，服务端可以先寻找他可以加入的战局，找不到则创建，发牌，拿到出牌，保存。直到这局凑够人数进行结算。客户也可以一直开局，一直出牌，符合AI的能力。

这样，将两个过程解耦合，不但可以解决实时性的问题，还能在一定程度上解决性能问题。判牌和结算逻辑可以抽离出去，可以设计成在本局最后一个玩家出牌时运行，也可以设计成周期性运行，还可以通过消息队列或其他"Fire and Forget"连接。由于我们的服务端不可避免的需要经常重启，这样的设计也可以解决脏数据（半完成的宏观事务）的处理问题。妙啊

玩法

玩家客户端登录后，可以不断请求开局接口，然后提交出牌，这些出牌会被记录并在合适的时候结算。客户端可以获取战局历史和历史详情，并通过这些数据在图形界面上回放牌局。详见API文档。
(这里会补一些图)

FAQ(Maybe)

认证问题

认证使用session机制和Header域的方式，API文档里带有Authorization这一节的接口均需要认证。认证的方法是在请求的HTTP头部添加一个名为X-Auth-Token的字段，值为登录接口返回的对象中的token字段的值，或者响应头中X-Auth-Token字段的值。

开局数量问题

为避免未完成的牌局过多，同时考虑服务器的并发压力，限制每个玩家未完成牌局数量。如未完成牌局过多，会被拒绝开新的局，但仍然能加入战局。也就是说，当你未完成牌局已达上限，且没有其他你可以加入的牌局的时候，开局接口失败。

PSP

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	40	40
Estimate	估计这个任务需要多少时间	40	40
Development	开发	405	1070
Analysis	需求分析(包括学习新技术)	75	60
Design Spec	生成设计文档	60	120
Design Review	设计复审	60	200
Coding Standard	代码规范(为开发制定合适的规范)	60	120
Design	具体设计	120	210
Coding	具体编码	0	180
Code Review	代码复审	0	60
Test	测试(自我测试,修改,提交修改)	30	120
Reporting	报告	70	80
Test Report	测试报告	20	20
Size Measurement	计算工作量	10	10
Postmortem & Process Improvement Plan	事后总结并提出过程改进计划	40	50
	合计	515	1190

转载于:https://www.cnblogs.com/rtxux/p/11578507.html