针对萌娘百科iOS应用的中继服务器公开的技术文档，相关详细设置由于安全问题不便透露，将在Github repository内部的wiki进行描述。希望本篇的语言不会过于复杂，让非技术人士也能看的懂，同时带有一定信息含量（用作科普）。本文内容部分属于设想，并未完工，另外一部分可能不一定是最新的，内容仅作参考。
需求分析
主要还是希望能够获得100%的自由操作权限，如果在mediawiki方面做出改动，需要征求各方意见，影响范围是全局性的，可能威胁mediawiki的稳定性。另外一方面，目前后端十分混乱，不希望再添加混乱。一旦牵涉到网页，很多东西就要为浏览器浏览考虑，而不是App。例如部署方面，后端由于众所周知的原因访问困难，使用一些临时措施来改善访问。网页不可以改变域名，而手机可以轻松通过各种方法自动切换线路。
此外，还有如下需求：
- 一个专门针对手机、平板设计的首页
- App的后台统计、数据分析功能
- 提供App定制的排版数据
将后端频繁崩溃的影响减到最小
本服务器还实验了独立的头像和评论系统。
解决方案
概论
首先，从设计方面，手机客户端应该是可以在所有服务器下线的情况下，依然可以依靠缓存运行的（在缓存存在的前提下）。
总体布局采用两台由不同ISP提供的服务器（以下称为服务器C和服务器L）。服务器L 是主服务器，所有的程序都会在服务器L运行。服务器C是从服务器，仅架设一个nginx的代理。两台服务器之间的延时非常小，希望访问服务器C的时候，不会感觉到这是一台缓存服务器。两台服务器的独立线率只有95%左右，但是经过如此部署，互为补充，整体可用性可达99.7%以上。部署上可以全部使用https，保护客户隐私，另外在一定程度上，隐藏了API的接口方案。
代码方面，整个中间件使用slim架构封装，github自动部署。页面缓存采用多重缓存的机制。nginx上，设置了刷新限制，防止高频率从hhvn获取内容，如果获取失败，则使用cache。而hhvm的各种耗时操作使用了hhvm特有的函数（register_postsend_function）进行后置，极大地缩短了页面返回的时间。另外对页面的压缩方法也进行了调整，存储采用最大级别的压缩，如果是从后端读取则使用中等级别的压缩，确保用户在速度和文件大小两方面，取得一个最好的平衡。
客户端所提供的用户名 + UUID是这个平台的核心，承担了对客户端的权限核实。用户头像、评论及各种属性都是基于这个唯一的身份特征及验证的上面的。敏感操作全部基于https以保障用户的隐私。考虑到当前网页版的安全设计，这个设计不能说很安全，但应该是恰当的。
定制首页
首页的很多数据需要mw各种模板引用的支持，因此，在萌娘百科创建了一个页面，并不单独在中转服务器上设置。页面走的是与一般页面一致的缓存渠道，但是，页面内容是针对手机客户端的读取需要进行设计的。采用成对的html tag对内容进行标记，提升稳定性，避免mediawiki自动添加不必要的html属性。
条目的代表图片
工作流程：服务器得到客户端请求检查数据库，如果有数据则返回，如果没有则向后端服务器获取条目中含有的所有图片；对条目中的图片名称截取整合后向服务器获取图片的属性；更新数据库的内容。
因此，第一个人的第一次请求是不能得到图片的连接。另外，此功能对于重定向的页面是无效的。图片内容并不经常改动，为了减轻后端服务器的压力，成功抓取一次以后，服务器并不会再次进行抓取，再次抓取需要删除数据库中该条目所在的行。数据库内预留有指定条目图片和禁用特定图片两个值，可以分配数据表权限给有经验的百科编辑者直接管理条目的图片。
用户头像与评论
基于客户端提供的用户名 + UUID进行识别，授予更改头像和发布评论的权限。用户头像采用重定向指向头像存放的位置。用户评论则采用与本套博客相近的评论系统。服务器后端预留有评论管理的必要功能，可以分配数据表权限给有经验的百科编辑者直接对特定用户进行禁封。
用户统计功能
按照苹果的设计规范，不能够对用户进行过度地跟踪。iTunes Connect 也提供了非常便捷的统计工具，因此此项功能正在逐步移出中继服务器。目前对条目的热度和设备的类别进行了跟踪以便对更新进行规划，不排除以后推出条目热点分析。统计的定时脚本并没有上传到Github repository中。
部署及调试方法
个人推荐将Repo Fork到本地进行调试。使用一款API测试工具将会极大地提升你的调试效率和代码的稳定性。部署的时候，先关闭DNS到服务器L的解析，让服务器C进入缓存运作模式，部署文件，通过改host的方法在线调试，成功后再恢复服务器C的正常模式，并恢复服务器L的解析。如果希望得到更好的稳定性以及在编程上获得更大的自主权，建议自行搭建有自己主机和服务器的子系统，本人可以直接开放数据库接口，并将力所能及地提供帮助。
