最新版本的 ownCloud，ownCloud Infinite Scale (OCIS)，是对这款历史悠久的开源企业文件共享和同步软件栈的完全重写。它具有用 Go 编写的新后端、用 Vue.js 编写的前端以及许多更改，包括无需数据库。这种可扩展的模块化方法取代了 ownCloud 的 PHP、数据库和 POSIX 文件系统，并承诺性能提高 10 倍。
传统上，ownCloud 围绕着拥有一个 POSIX 兼容的文件系统来存储用户上传的数据——数据的不同版本和垃圾文件，以及配置文件和日志。默认情况下，ownCloud 用户的文件位于其 ownCloud 实例上的路径中，例如 /var/www 或 /srv/www（Web 服务器的文档根目录）。
每个维护过 ownCloud 实例的管理员都知道它们会变得非常庞大；如今，它们的规模通常比 ownCloud 最初设计的要大得多。最大的 ownCloud 实例之一是澳大利亚学术和研究网络 (AARNet)，该公司存储了超过 100,000 名用户的数据。
让我们用“Go”来实现微服务
ownCloud 的开发人员确定，用 Go 重写代码库可以带来比 PHP 更多的优势。即使计算机程序看起来像是一整块代码，但大多数程序在内部都分为不同的组件。通常与 ownCloud 一起部署的 Web 服务器（例如 Apache）就是一个很好的例子。在内部，一个函数处理 TCP/IP 连接，另一个函数可能处理 SSL，还有另一段代码执行请求的 PHP 文件并将结果传递给最终用户。所有这些事件都必须以一定的顺序发生。
ownCloud 的开发人员希望新版本能够同时服务多个步骤，以便事件可以同时发生。能够并行处理请求的软件不必等待一个进程完成后才能开始下一个进程，因此它们可以更快地交付结果。并发性是 Go 在容器化微架构应用程序中如此受欢迎的原因之一。
通过 OCIS，ownCloud 正在适应以微服务原则为中心的架构。 OCIS 分为三个层：存储、核心和前端。我将研究这些层中的每一层，但对人们来说真正重要的是整体性能。用户不会考虑分层的软件；他们只希望软件能够运行良好且运行速度快。
第一层：存储
系统可用的存储是 ownCloud 的最低层。性能也带来了可扩展性；大型 ownCloud 实例必须能够应对数千个客户端的负载，并在现有存储空间已满时添加额外的磁盘空间。
与当今的许多其他概念一样，对象存储和可扩展存储在 ownCloud 设计时还不可用。现在管理员已经习惯了有更多的选择，因此 ownCloud 允许将物理存储设备处理外包给外部解决方案。虽然 OCIS 仍然支持基于 S3 的对象存储、基于 Samba 的存储和 POSIX 兼容的文件系统选项，但首选的部署方式是使用 EOS - 开放存储 (EOS) 存储。
EOS 来拯救
EOS 针对访问文件时的极低延迟进行了优化。它通过 XRootD 框架向客户端提供基于磁盘的存储，但也允许其他协议访问文件。 ownCloud 使用 EOS 的 HTTP 协议扩展与存储解决方案通信（使用 HTTPS 协议）。 EOS 还允许几乎“无限”的可扩展性。例如，CERN 的 EOS 设置包括超过 200PB 的磁盘存储空间，并且还在不断增长。
通过选择 EOS，ownCloud 消除了传统存储解决方案的几个缺点
- EOS 没有典型的单点故障。
- 所有相关服务都冗余运行，包括横向扩展和添加所有现有服务的实例的能力。
- EOS 承诺永远不会耗尽实际磁盘空间，并且内置了存储数据的冗余。
对于大型环境，ownCloud 希望管理员使用 OCIS 部署 EOS 实例。为了换取维护单独的存储系统的负担，管理员可以不必担心 OCIS 实例的可扩展性和性能。
小型设置怎么样？
这暗示了 ownCloud 针对 OCIS 的假定用例：它不再是小型企业一体化服务器，也不是小型家庭服务器。 ownCloud 使用 OCIS 的策略针对大型数据中心。对于小型或家庭办公室设置，EOS 可能过于庞大，并且对于单个管理员来说管理起来过于苛刻。 OCIS 通过 Reva 框架为小型设置提供服务，该框架支持 S3、Samba 甚至 POSIX 兼容的文件系统。这是可能的，因为 EOS 没有硬编码到 OCIS 中。 Reva 无法提供与 EOS 相同的功能集，但它可以满足最终用户和小规模安装的大部分需求。
第二层：核心
OCIS 的第二层（由于 Go 的存在）更像是微服务的集合，而不是一个单一的核心。每一个都负责在后台处理一项单独的任务（例如，扫描病毒）。基本上，OCIS 的所有功能都来自特定微服务的工作，例如使用 OpenID Connect 对身份提供者验证请求。最终，这使得连接现有用户目录（例如 Active Directory Federation Services (ADFS)、Azure AD 或 Lightweight Directory Access Protocol (LDAP)）到 ownCloud 变得简单。对于那些没有现有身份提供者的人，ownCloud 会附带自己的实例，从而有效地使 ownCloud 维护自己的用户数据库。
第三层：前端
OCIS 的第三层，前端，是供应商所称的 ownCloud Web。它是用户界面的完全重写，并且基于 Vue.js JavaScript 框架。与 OCIS 核心一样，Web 前端也是基于微服务原则编写的，因此可以实现更好的性能和可扩展性。开发人员还利用这个机会对 Web 界面进行了改造；与以前的 ownCloud 版本相比，OCIS Web 界面看起来更小巧、更简洁。
OCIS 的开发人员在遵守现代软件设计原则方面做得非常出色。根据微服务方法构建应用程序的根本问题是使环境的各个组件相互通信。 API 可以提供帮助，但这意味着每个微组件都必须有自己明确定义的 API 接口。
幸运的是，有一些现有的工具可以减轻开发人员的负担，最值得注意的是 gRPC。 gRPC 背后的想法是拥有一组预定义的 API，这些 API 可以在一个组件中触发另一个组件中的操作。
其他值得注意的设计变更
使用 Traefik 处理网络流量
这种新的应用程序设计给底层网络带来了一些挑战。 OCIS 的开发人员选择了 Traefik 框架来解决这些问题。 Traefik 会自动负载均衡微服务的不同实例，管理自动 SSL 加密，并允许额外部署防火墙规则。
后端和前端之间的分离为 OCIS 增加了优势。 事实上，用户通过 ownCloud Web 触发的操作与在后端执行任务的 ownCloud 引擎完全分离。 如果用户手动启动对存储在 ownCloud 中的文件的病毒检查，他们不必等待检查完成。 相反，检查在后台进行，用户会在检查完成后看到结果。 这就是并发性的工作原理。
作为微服务的扩展
与其他 Web 服务一样，ownCloud 支持通过扩展来扩展其功能。 OCIS 并没有改变这一点，但它承诺解决一个众所周知的问题，尤其是在社区应用方面。 来源不明的应用可能会导致服务器出现问题、阻碍更新并对服务器的整体性能产生负面影响。
OCIS 基于 gRPC 的新架构使得在现有微服务旁边创建扩展变得更加容易。 由于 API 由 gRPC 预定义，因此开发人员只需创建一个具有所需功能的微服务，该微服务可以由 gRPC 控制。 Traefik 确保在具体情况下，新部署的附加组件会自动添加到现有的通信网格中。
再见，MySQL！
ownCloud 切换到 gRPC 和微服务消除了对关系数据库的需求。 相反，需要存储元数据的组件自行执行此操作。 由于 Reva 和缺少 MySQL 依赖项，在小型环境中运行 ownCloud 的复杂性大大降低——这对于大型数据中心的维护人员来说尤其受欢迎，但对于任何规模安装的管理员来说都很好。
启动并运行 OCIS
ownCloud 在 2020 年 12 月发布了 OCIS 1.0 的技术预览版，将其作为 Docker 容器和二进制文件发布。 其 GitHub 存储库的部署部分中链接了更多有关使其运行的示例。
使用 Docker 安装
使用 Docker 容器启动并运行 OCIS 很容易，但如果您不熟悉 EOS，事情可能会变得复杂。 OCIS 的 Docker 镜像可在 Docker Hub 上找到。 查找当前 master 分支的 Latest 标签。
任何来自大型云提供商的标准虚拟机或数据中心中使用的任何入门级服务器（使用标准 Linux 发行版）都应该足够，前提是系统已安装容器运行时。
假设您已经安装了 Docker 或 Podman，启动 OCIS 的命令非常简单
$ docker run --rm -ti -p 9200:9200 owncloud/ocis就这样！ OCIS 现在在 localhost 的 9200 端口等待您的服务。打开一个 Web 浏览器并导航到 http://localhost:9200 进行查看。
演示帐户和密码为 einstein:relativity、marie:radioactivity 和 richard:superfluidity。管理员帐户为 moss:vista 和 admin:admin。如果 OCIS 在具有可解析主机名的服务器上运行，它可以从 Let's Encrypt 使用 Traefik 请求 SSL 证书。
(Martin Loschwitz, CC BY-SA 4.0)
(Martin Loschwitz, CC BY-SA 4.0)
使用二进制文件安装
作为 Docker 的替代方案，还有预编译的二进制文件可用。 感谢 Go，用户可以从 Master 分支下载最新的二进制文件。
OCIS 的二进制版本默认使用 /var/tmp/ocis 作为默认存储位置，但您可以在其配置中更改该位置。您可以使用以下命令启动 OCIS 服务器
$ ./ocis server以下是通过 ocis 二进制文件提供的一些子命令
ocis health运行健康检查。 大于 0 的结果表示错误。ocis list打印所有正在运行的 OCIS 扩展。ocis run foo启动一个特定的扩展（在本例中为foo）。ocis kill foo停止一个特定的扩展（在本例中为foo）。ocis --help打印帮助消息。
该项目的 GitHub 存储库包含完整的文档。
设置 EOS（很复杂）
按照 ownCloud 的建议，在大型环境中部署带有 EOS 的 OCIS 需要一些额外的步骤。 EOS 不仅增加了所需的硬件，并增加了整个环境的复杂性，而且设置起来也是一项稍微较大的任务。 CERN 提供了简洁的 EOS 文档（链接自其 GitHub 存储库），并且 ownCloud 提供了一个 分步指南。
简而言之，用户必须获取并启动 EOS 和 OCIS 容器；配置 LDAP 支持；并在启动它们时使用 EOS 配置杀死 home、users' 和 metadata 存储。最后但同样重要的是，需要设置帐户服务以与 EOS 配合使用。所有这些步骤都是 GitHub 存储库中记录的“docker-compose”命令。EOS 上的 Storage Backends 页面还提供了有关验证、故障排除和内置 EOS shell 的命令参考的信息。
权衡风险和回报
ownCloud Infinite Scale 易于安装，比以往任何时候都快，并且为可扩展性做好了更好的准备。模块化设计，带有微服务和 API（甚至对于其扩展），看起来很有希望。 ownCloud 正在拥抱新技术并为未来发展。如果您运行 ownCloud，或者如果您一直在考虑尝试它，那么现在是最好的时机。请记住，这仍然是一个技术预览，并且每三周发布一次滚动版本，因此请报告您发现的任何错误。
1 条评论