山大智云体系结构总结
经过了一学期的学习以及全员总结，整个项目的架构和最初猜测的组织结构相似：
并且组员们对其中的各个部件有了更详细的认识。
子部件
底层库
libsearpc
seafile系列部件中的内部通讯协议。仅服务端到服务端。（如seahub）
libevhtp
seafile系列部件中的外部通讯协议。服务端到客户端。（如seafdav）
接口
seaserv
一个python库，用于调用RPC服务。采用C-Binding的方式绑定了seafile-server中定义的RPC服务。
seafobj
一个python库，用于直接访问seafile-server管理的键值对象。
SeafileServer
后端核心服务，包括RPC服务和Http服务。
pro-set
后端核心服务的升级版，支持更多高级操作。
Seahub
Web服务。
seaf-frontend
seahub的前端。
seahub-extra
seahub的扩展包。
seafevents
Web服务的日常事件。
seafdav
提供seafile的WebDav服务，使用的是Http协议。
seafile-client
客户端。通过Http协议与seafile-server通讯，并可通过seafdav同步。
部署
集群架构
以下译自《Seafile管理手册》
Seafile 集群解决方案采用三层架构：
- 负载均衡器层：将传入流量分配到 Seafile 服务器。 HA 可以通过部署多个负载均衡器实例来实现。
- Seafile 服务器集群：由 Seafile 服务器实例组成的集群。 如果一个实例失败，负载均衡器将停止将流量交给它。 这样就实现了HA。
- 后端存储：分布式存储集群，例如 S3、Openstack Swift 或 Ceph。
这种架构水平扩展。这意味着，我们可以通过添加更多机器来处理更多流量。该架构如下图所示。
Seafile 服务器节点上有两个主要组件：Web 服务器（Nginx/Apache）和 Seafile 应用程序服务器。 Web 服务器将来自客户端的请求传递到 Seafile 应用程序服务器。 Seafile 应用服务器独立工作。他们不知道彼此的状态。这意味着每个应用服务器都可以独立失败，而不会影响其他应用服务器实例。负载均衡器负责检测故障和重新路由请求。
即使 Seafile 应用服务器独立工作，它们仍然需要共享一些会话信息。所有共享会话信息都存储在 memcached 中。因此，所有 Seafile 应用服务器都必须连接到同一个 memcached 服务器（集群）。稍后将提供有关 memcached 配置的更多详细信息。
后台服务器是各种后台任务的主力，包括全文索引、Office 文件预览、病毒扫描、LDAP 同步。它通常应该在专用服务器上运行以获得更好的性能。目前整个集群中只能运行一个后台任务服务器。如果有多个后台服务器在运行，它们在执行某些任务时可能会相互冲突。如果后台任务服务器需要HA，可以考虑使用Keepalived为其搭建热备份。更多细节可以在后台服务器设置中找到。
所有 Seafile 应用服务器访问同一组用户数据。用户数据有两部分：一份在MySQL数据库中，一份在后端存储集群（S3、Ceph等）中。所有应用程序服务器均等地为客户端提供数据。
所有应用服务器都必须连接到同一个数据库或数据库集群。如果您需要数据库集群，我们建议使用 MariaDB Galera Cluster。
三节点部署
三个节点，分别充当Web服务器、Seafile服务器、存储服务器。这样的划分分工明确，属于成本最低的方案，但性能上显然不是很好。尤其是在seafile server服务器上将承载大量计算型任务，对其性能要求很苛刻。
四节点部署
将office渲染以及pro-set（主要是ElasticSearch）这两个资源消耗高的服务独立到另外的辅助服务器中。此时Seafile服务器仅兼任对象键值和SQL服务器，并运行seafile-server服务；同时clamAV只对块存储服务器进行扫描。优化了Seafile服务器上的性能，但是降低了安全性。同时仍未解决负载均衡问题。
五节点部署
前端引入主从节点，进行负载均衡。因为Seafile服务器尚且不支持分布式，所以只能从前端上负载均衡。杀毒程序回到Seafile服务器中，仅让块存储服务进行I/O密集型任务。但是这样的方案仍没有备份措施。
更多节点
能够引入更多冗余服务器进行备份或者热备份，也可以引入独立的SQL服务器以及缓存服务器，但成本也相应提高。此处不再进一步探讨。
