当前位置：文江博客话题详情

SaaS 成熟度级别 2，我如何构建可配置的 SaaS？（技术和模式）

发布于 2024-09-28 18:39:09 字数 74 浏览 1 评论 0原文

根据 SaaS 成熟度模型，如果可配置，SaaS 就是 2 级，但是我如何开始这个概念？我可以使用什么模式和技术来启用我的 SaaS？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

对风讲故事 2024-10-05 18:39:09

主要模式是将配置数据与应用程序代码分离。查找应用程序的属性，这些属性可能因安装而异，并将这些属性提取到配置系统中。

首先找出一些可能因安装而异的基本属性。一些示例：您的服务使用哪些端口号？什么网址？您正在使用什么证书/CA？客户可以对您的软件进行品牌重塑/重新设计吗？他们的品牌形象或皮肤资源位于哪里？您将部署到哪些操作系统，以及当操作系统发生变化时哪些内容可能会发生变化？甚至配置您的配置所在的位置也可能是一个需要改变的重要属性。然后扩展到特定站点可能独有的功能：如何启用它们？是否需要针对不同的客户进行不同的设置？当您完成此练习时，请记住，您正在向系统添加变化点，从而增加额外的复杂性，以及需要验证、测试和潜在安全的额外点。仔细考虑哪些变化点对您的客户真正重要，并重点关注这些变化点。

然后考虑实现：

通常，配置系统非常简单，就像与应用程序一起安装的纯文本文件一样，key = value 样式。配置可以位于多个文件中，或包含多个部分的一个文件（ini 样式），或两者兼而有之。
允许在配置中添加注释是很常见的，并且对于记录配置键的含义或允许客户自己记录为什么他们以特定方式设置某些内容非常有帮助。
根据您构建应用程序所使用的技术，应用程序堆栈可能有自然的配置机制。
有些人喜欢 XML 或 JSON 或 YAML，尽管在我看来，处理这些格式所花费的额外精力可能不值得，特别是如果人类正在编辑配置的话。
有时，复杂的配置文件可能是用成熟的特定于域的语言编写的。（从技术上讲，大多数配置文件格式都是某种类型的 DSL，但我在这里讨论的是那些真正为配置格式注入了大量表达能力的格式——条件、模式匹配、结构化类型等）但是，这个对于您和必须学习 DSL 的客户来说，都会带来额外的开销，而且你们可能都不想将读/写这些配置作为您的核心能力，所以我建议不要这样做，除非您有迫切的需要。
有些人喜欢用他们编写应用程序的脚本语言来编写配置，因为加载很简单，并且在指定配置时可以为您提供编程语言的全部功能。如果客户已经熟悉脚本语言，那么实际上他们可能很容易掌握，并且基本结构的脚本语言语法通常很简单。然而，我的经验是，客户很容易搞砸这些，而且语法错误对于客户来说诊断和修复并不是特别有趣。
通常，服务允许以多种方式指定配置：例如，配置文件、环境变量和命令行参数。这些对于临时调整默认配置以进行测试或让非系统管理员用户能够运行非常有用。

对于复杂的多层设置，您可能需要提供一些附加工具来帮助在必要时跨计算机同步配置。许多服务还提供生成默认配置文件的工具。这些文件通常会加载注释来解释每个可配置值，这将帮助客户开始使用它们。

有大量关于人们如何配置其服务的示例。研究您最喜欢的服务及其配置方式。自己思考或询问您的朋友，您认为哪些服务最容易设置。请记住，配置是您与客户的界面的一部分，因此您希望它尽可能干净、易于理解且易于使用。

The primary pattern is separation of configuration data from application code. Find the properties of your application that may vary from installation to installation, and pull those properties out into a configuration system.

Start by figuring out some basic properties that are likely to vary from installation to installation. Some examples: What port numbers are your services on? What URLs? What certs/CAs that you are using? Can the customer rebrand/reskin your software, and where are their brand images or skin resources located? What OSes will you deploy to, and what is liable to change when the OS changes? Even configuring where your configuration lives can be an important property to vary. Then extend to features that may be unique to particular sites: how do you enable them? do they need to be set up differently for different customers? As you go through this exercise, keep in mind that you are adding points of variation to your system, thus additional points of complication, and additional points that need to be validated, tested, and potentially secured. Think carefully about which points of variation really matter to your customers, and focus on those.

Then think about implementation:

Usually, a configuration system is as dirt-simple as plain text files that get installed with the application, key = value style. The configuration could be in multiple files, or one file with sections (ini-style), or both.
Allowing for comments in the configuration is common, and extremely helpful in documenting what the config keys mean, or for allowing the customers to document themselves why they set something up a particular way.
Depending on the technology you're building your applications with, there may be natural configuration mechanisms that go with the application stack.
Some folks like XML or JSON or YAML, though IMO the extra effort spent dealing with that format may not be worth it, especially if humans are editing the config.
Sometimes a complicated configuration file may be written in a full-blown domain-specific language. (Technically, most configuration file formats are DSLs of one sort or another, but I'm talking here about the ones who really pour a lot of expressivity into the configuration format – conditionals, pattern matching, structured types, etc.) However, this comes with additional overhead for both you and the customer who has to learn the DSL, and neither of you probably wants to make reading/writing these configs your core competency, so I'd advise against it unless you have a pressing need for it.
Some folks like to write their configs in the scripting language they're writing the applications in, since it's trivial to load and gives you the full power of a programming language when specifying the config. It may actually be pretty easy for customers to pick up if they're already familiar with the scripting language, and the scripting language syntax for basic structures is usually simple. However, my experience is that it can be surprisingly easy for customers to mess these up, and syntax errors are not particularly amusing for customers to diagnose and fix.
Often, a service will allow configuration to be specified in multiple ways: config files, environment variables, and command-line arguments, for example. Those can be useful for temporarily tweaking the default config for testing, or for a non-sysadmin user to be able to run.

For complicated multi-tier setups, you may want to provide some additional tools to help synchronize configuration across the machines where it's necessary. Many services also provide tools to generate default configuration files. These files are often loaded with comments to explain each configurable value, which will help the customer get started with using them.

There are a ton of examples out there about how people have gone about configuring their services. Study your favorite services and how they're configured. Think for yourself, or ask your friends, about which services you felt were the easiest to set up. Remember that the configuration is part of your interface to your customer, so you want it to be as clean, understandable, and easy-to-use as possible.

回复收藏 0 原文

~没有更多了~