第四部分 — 建造工厂：架构与案例

案例研究：一个可组合的审评平台

第一个案例是参考架构的"体验与运维"脊梁，按其实际运行的样子呈 现：一家小型、完全外包的生物科技公司的临床数据审评平台，见于 PHUSE 论文 Beyond a Single Shiny Server(除匿名化的厂商细节外， 这套系统正是本书作者在生产中运行的那一套)。它的教益在于：一个 两人的团队能扛住什么——以及自建的诚实边界在哪里。

处境

审评应用早已超出厂商托管的单台 Shiny 服务器的承载：工作负载包含 这台只支持 R 的服务器根本无法托管的 Python 微服务，需要按应用控 制资源，并需要一套自己的部署纪律。岔路口：购买商业托管产品，或 者用开源部件组合一个平台并自行承担后果。团队选了第二条路——论 文明确指出，这是一个决定，而不是一种美德。

建成了什么

一台虚拟机上的一个 Docker Compose 技术栈，生产中二十一个服务： 十四个 Shiny 审评应用(八个跨研究、六个研究专属)、一个 R API、 五个 Python 服务(包括一个安全性监测服务和一个文档问答服务), 以及一个反向代理。这套架构几乎严丝合缝地对应参考模型的第 2–5 层，而且每一个承重的设计抉择都是一条值得借用的规则：

• 一扇门。 代理是唯一对外可达的服务，TLS 在边缘终结；其余 一切都绑定在 localhost。暴露是一项记录在一份经评审的文件里的 决定，绝不是某个容器默认值的意外。
• 身份认证只写一次。 CRO 合作伙伴的 SSO 签发签名的 JWT；一 个共享模块在每个应用内本地核验令牌，并配以分层的数据集级权限。 新应用通过引入继承安全，而非通过重新实现。
• 数据经一个 API。 没有应用挂载共享盘或自行打开数据库连接； 授权恰好存在于服务端的一个位置。应用保持无状态；存储的叙事保 持可迁移。
• 只经流水线部署。 没有任何东西靠手工变更：自动备份、受保 护的环境配置、重建，以及一项必须全部通过、否则部署即宣告失败 的十三点健康检查；回滚是一条命令。十份一页篇幅的决策记录 (ADR)记录了系统为何是今天这个形状。
• 跳板。 迁移通过在遗留平台上的一个 38 行转发应用保住了用户 一次登录的体验——整个迁移面一次坐下来即可审完。

诚实的边界

这篇论文最有价值的贡献是它的范围声明：这个平台是内部探索性审 评基础设施，不是经验证的系统，而经验证的商业平台仍是面向 GxP 交付的答案。它的决策规则正是从这份诚实中推导出来的。当工作负载 是多语言的、用途是内部探索、且有人愿意拥有流水线时，选择组合。 当交付物面向 GxP、或没有人愿意拥有流程时，购买经验证的平台。还 有两点澄清让这些规则保持真实：健康检查不是验证，而这些层是互补 品，不是竞争者。

这个案例为本书增添了什么

两点。第一，证明参考架构的第 2–5 层能在小团队规模下在生产中运 行，以纪律替代人头数。第二，边界本身：平台恰好停在证据层缺失的 地方——正是第 7 章的那个空格。下一个案例，讲的是当同样的本能 直指那个空格时会发生什么。

检验。 对任何自建平台，问："你上一次拒绝在没有一页记录 的情况下做出的决定是哪一个——而你明确不声称的能力是哪一个？" 两个问题都能答上的团队在组合；答不上的，是拿着一张图在即兴发 挥。