SaaS 架构设计的参考指南( 二 ) _SaaS

文章插图
通过路由服务路由的产品 Web 应用
在后台，这可以是单个或一组带有 Web 前端的微服务。这些 Web 应用彼此独立，有自己独立的代码库、支持服务、部署管道，并且理想情况下是由不同的团队所有。在 SaaS 平台中，它们的分组方式与其所有团队的结构保持一致。
这样以来我们就能将大型 Web 项目分解为许多可管理的单元。可以将这种模式想象成是将大块牛排切成许多小块。一个产品 Web 应用包含一组不应与其他 Web 应用重叠的相关功能。
实现技巧：产品 Web 应用可以是任何 Web 应用程序，例如常见的 Express、Node.js 和 React 堆栈。将设计系统与可复用的微前端（例如 Mosaic 或 Open Components）搭配使用，可以让你的产品拥有一致的外观和体验。
Web 应用存储库这个服务负责保存多个团队拥有的 Web 应用程序的记录。路由服务调用 Web 应用存储库，以获取与所请求路径对应的 Web 应用 URL（匹配某个条目）。

文章插图
路由服务检索 Web 应用 URL 及其关联的路径
下面是一个 Web 应用存储库表示例，用来说明它的功能。

文章插图

基于角色的访问控制（RBAC）服务将提供权限信息，以帮助我们检查登录用户是否有权访问产品 Web 应用。
如果要维护的产品 Web 应用条目数量很少，这里就可以用一个简单的路由和硬编码哈希映射的代理。
实现技巧：这既可以是具有自己的 Web 管理 UI 的 RESTful 服务，也可以是简单的基础架构，比如说是位于路由服务中，或者来自对象存储（如 AWSS3）的代码配置文件。具体的实现方式将取决于所需的规模和可配置性。如果你要继续考虑服务实现，则可以将 JAVA、Go 或 C#与 RDBMS 或 NoSQL 数据存储搭配使用。
对于这个服务来说，验证过程是非常重要的，如果路径或 Web 应用 URL 的配置不正确，则可能会影响你服务的可用性。如果无法确定要支持的产品数量，请使用进化原型方法。你不必在开发周期的早期就构建这个服务，因为一开始只用一个简单的配置文件就够了。
身份验证应该有一个跨服务共享的专用身份验证服务。这里 JSON Web 令牌就可以派上用场，因为我们能轻松地通过标头跨多个服务传递令牌和其他有用的用户信息。
可以从路由服务或产品 Web 应用中调用身份验证服务。如果从产品 Web 应用调用身份验证服务，就能让产品 Web 应用所有者灵活地对他们想要保护的任何页面实施身份验证。这种灵活性让服务所有者可以管理公共页面，例如用户注册页。这种方法还减少了在路由服务中执行的逻辑。