如何为你的SaaS应用规划具备前瞻性的子域名结构

你终于为你的新SaaS应用想好了名字并购买了域名，令人兴奋的时刻！

你需要做的第一个技术决策之一，就是为各个Web属性选择合适的子域名。

你当然不想过早优化，但如果此时为不同的Web属性选择一组合理的子域名，将有助于你避免后续出现以下这些头疼的问题：

• 市场人员误操作导致应用路由出错
• 开发者修改导致营销站点样式混乱
• 管理复杂的重定向配置
• 应用架构中不得不引入反向代理
• SEO受损

让Web应用与营销站点分离

如果你是一个人既开发Web应用又负责撰写营销内容，可能会倾向于将两者放在同一个子域下。毕竟，这样可以共享CSS、Logo等资源，还能节省单独托管的费用。

但将来你可能会雇佣非技术的市场人员来添加或修改内容。为了让他们能独立高效地工作，你可能希望使用CMS（如Wordpress）。这通常需要独立的服务器，并且很可能与你开发Web应用所用的服务端技术（如Ruby/Rails、Nodejs/Express、Python/Django）不同。你也不希望在维护应用时影响到营销站点的可用性，或者因为修改应用的CSS规则而破坏营销站点的样式。

同一个子域还会让你无法选择用CDN托管静态营销网站，从而提升加载速度并降低托管成本。

为你的应用选择子域名

最简单的选择就是用 app，它不会过于限定用途，即使Web应用未来扩展也不会受限。B2B和B2C用户对此都很熟悉，许多知名服务如YNAB、Sendgrid和Optimizely都采用了这种方式。它还很简短，用户浏览器中的URL会更易读。

其他常见选项包括：

• dashboard —— Stripe采用
• manage —— GoCardless采用
• portal —— Autochart采用
• my —— Xero采用
• account —— Postmark采用
• secure —— HelpScout采用（我个人不推荐，太技术化了）

营销站点优先使用裸域名而非`www`

这一点比前面的建议更主观，两种方式各有优劣，无论是从用户体验还是技术配置角度。我的理由是，裸域名（又称apex或bare domain）对大多数用户来说“www”已经多余，而且在AWS Route 53和CloudFront上配置裸域名也很简单（我常用的DNS和静态网站托管服务）。

无论你选择哪种方式，都要确保配置好站点的重定向，让两者互通。

让营销站点和博客共用同一子域

我建议将博客作为营销站点的一部分，放在如mydomain.com/blog/这样的子目录下。市场人员通常会同时维护营销站点和博客。通过同一个CMS托管在同一站点，他们的工作会更高效。单一站点还能让品牌和站点布局（如统一的头部、导航和底部）集中管理。此外，分析配置会更简单，只需在Google Analytics和Google Search Console中配置一个Web属性。最后，SEO领域现在也推荐“优先使用子目录而非子域”。

API暂时与应用共用子域

只有当你打算将API公开时，这个决策才真正重要。我认为在应用v1阶段，API不应对外开放，因为外部集成通常不是用户的核心需求。此时，API应为私有，仅供Web应用的AJAX调用。因此，除非API是应用的绝对核心（而仅仅是集成手段），建议首发时将其放在主应用的同一子域下。

如果将来需要对外开放API，可以考虑用独立的api子域。关于应用代码的架构（如单体应用中的模块，或微服务架构下的独立仓库），这超出了本文讨论范围。但如果Web应用和API是分开的微服务，就需要引入反向代理（如Nginx）来实现基于路径的请求路由。而采用不同子域时，路由直接由DNS层处理，更加简单。