Salesforce 受管软件包：架构、策略与最佳实践

背景与应用场景

作为一名 Salesforce 架构师，我们经常需要在复杂的企业环境中，评估和设计解决方案，确保其可扩展性、安全性、可维护性与长期的可持续性。在 Salesforce 生态系统中，受管软件包 (Managed Packages) 是实现这些目标的关键机制之一。它们不仅仅是一种部署工具，更是一种战略性的资产，定义了应用程序的生命周期、知识产权保护和分发模式。

受管软件包是 Salesforce 平台上一种用于分发和管理应用程序、组件或定制功能的容器。与非受管软件包 (Unmanaged Packages) 不同，受管软件包在安装到客户的 Salesforce 组织 (Org) 后，其组件（如 Apex 类、Visualforce 页面、自定义对象等）会受到保护，不能直接编辑。这种保护机制使得软件包的发布者，通常是独立软件供应商 (ISV - Independent Software Vendor)，能够对其产品进行版本控制、升级和维护，同时保护其知识产权 (Intellectual Property)。

应用场景

受管软件包主要应用于以下场景：

• AppExchange 产品发布：这是最常见的用途。ISV 通过 Salesforce 的官方应用商店 AppExchange (应用商店) 发布其商业应用程序。受管软件包提供了必要的机制，包括版本控制、升级路径、许可证管理（通过 许可证管理应用程序 - LMA (License Management App)）和安全审查框架，确保应用程序能够安全、稳定地被数百万客户使用。
• 企业内部应用程序分发：大型企业可能拥有多个 Salesforce 组织，需要将标准化的应用程序、功能模块或集成框架部署到这些组织中。受管软件包可以作为一种有效的内部发布机制，确保所有组织使用的都是同一个版本，便于集中管理和升级。
• 可重用组件库：为实现代码和配置的重用，企业或 ISV 可以将通用的功能（如日志记录框架、身份验证模块、与外部系统集成的连接器）打包成受管软件包。这有助于降低开发成本，提高开发效率，并确保这些共享组件的一致性。

作为架构师，理解受管软件包的战略意义在于，它使得解决方案的模块化、可重用性和长期演进成为可能。它促使我们从一开始就考虑应用程序的生命周期、未来的扩展性以及如何最小化对现有客户的破坏。

---

原理说明

受管软件包的核心在于其独特的运行机制和生命周期管理。以下是作为架构师需要深入理解的关键原理：

命名空间 (Namespace)

每个受管软件包都必须注册一个唯一的命名空间前缀 (Namespace Prefix)。这个前缀会作为所有软件包组件（如自定义对象、字段、Apex 类、Visualforce 页面等）的标识符。例如，如果命名空间前缀是 myprefix，那么软件包中的一个自定义对象 API 名称将是 myprefix__MyCustomObject__c，一个 Apex 类的名称将是 myprefix.MyApexClass。命名空间前缀的作用包括：

• 避免冲突：确保软件包组件在安装到客户组织时，不会与客户自定义的或由其他软件包安装的组件发生命名冲突。
• 隔离性：为软件包的组件提供了一定的隔离性，使得软件包内部的逻辑和数据结构更加独立。
• 知识产权保护：命名空间是区分软件包所有者的关键标识。

元数据 (Metadata) 与组件保护

受管软件包的核心是打包和分发 元数据 (Metadata)。这包括了 Salesforce 平台上的几乎所有配置和代码元素：

• 自定义对象与字段 (Custom Objects and Fields)
• Apex 类与触发器 (Apex Classes and Triggers)
• Visualforce 页面与组件 (Visualforce Pages and Components)
• Lightning Web 组件 (LWC - Lightning Web Components) 与 Aura 组件 (Aura Components)
• 流 (Flows) 与进程构建器 (Process Builders)
• 自定义设置 (Custom Settings) 与自定义元数据类型 (Custom Metadata Types)
• 权限集 (Permission Sets) 与配置文件 (Profiles)
• 等等。

一旦受管软件包安装到客户组织，其中的大部分组件会被“锁定”或“受保护”。这意味着客户无法直接修改这些组件的定义（例如，不能修改 Apex 类的代码，不能删除自定义字段）。这种保护机制保证了软件包的完整性，并允许 ISV 进行可控的升级。

升级与版本控制

受管软件包支持复杂的版本控制和升级机制。ISV 可以发布软件包的新版本，客户可以选择升级到新版本。Salesforce 平台会处理升级过程中元数据的合并和更新。这要求 ISV 在设计软件包时，必须考虑向后兼容性 (Backward Compatibility)，确保新版本不会破坏客户基于旧版本的定制或数据。

架构师在设计软件包时，必须规划好版本发布策略，包括：

• 主版本 (Major Versions)：引入重大新功能或不兼容的变更。
• 次版本 (Minor Versions)：添加新功能，但保持向后兼容性。
• 补丁版本 (Patch Versions)：仅包含 Bug 修复，通常不改变功能。

可扩展性设计

尽管受管软件包的组件受到保护，但 ISV 仍需提供机制让客户能够定制和扩展其应用程序。这通常通过以下方式实现：

• 全局 (Global) Apex 方法：允许客户的 Apex 代码调用软件包内部的特定功能。
• 全局 Apex 接口 (Global Apex Interfaces)：定义客户可以实现的接口，从而提供自定义行为。
• 自定义设置或自定义元数据类型：作为配置参数，允许客户配置软件包的行为。
• 扩展点 (Extension Points)：如使用 Visualforce 组件的属性、Lightning 组件的属性或事件来暴露定制选项。

调控器限制 (Governor Limits)

Salesforce 平台对每次事务的资源使用有严格的调控器限制 (Governor Limits)。对于受管软件包，一个重要的架构考量是其代码如何消耗这些限制。通常，在一个事务中，由受管软件包代码消耗的限制与客户组织中的非受管代码是分开计算的。这意味着，一个软件包即使执行了大量 SOQL 查询或 DML 操作，只要在自己的“限制桶”内，就不会直接导致客户的非受管代码超出限制。然而，对于某些全局性限制（如堆大小、CPU 时间），它们是累积计算的。架构师必须确保软件包的代码是高效的，并遵循最佳实践，避免不必要的资源消耗，以确保客户组织的整体性能。

---

示例代码

虽然受管软件包本身不是通过 Apex 代码来“创建”的，但其核心功能在于如何包装和分发 Apex 代码及其他元数据。作为一名架构师，我将关注如何设计软件包内的 Apex 代码，使其能够被软件包的订阅者（即安装软件包的客户）安全且可控地访问和扩展。这通常涉及使用 global 关键字来暴露 Apex 类或方法。

以下是一个来自 Salesforce 官方文档的 Apex 全局类 (Global Class) 示例，它展示了如何在受管软件包中设计一个可供外部访问的类。当软件包中的一个类被声明为 global，并且其中包含 global 方法时，其他非软件包（即订阅者）的 Apex 代码就可以调用这些方法。这对于实现可扩展性至关重要。

Apex 全局类示例：公开软件包功能

这个示例展示了一个名为 PackageUtilities 的 Apex 全局类，它提供了一个公共方法 getCurrentDate。在受管软件包中，此类及其方法可以使用软件包的命名空间前缀进行标识（例如，如果命名空间前缀是 myprefix，则类名为 myprefix.PackageUtilities）。

// From developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_classes_global.htm
/**
 * @description This global class is part of a managed package.
 * It provides a utility method that can be called by subscriber organizations.
 * By declaring it as 'global', we expose its functionality outside the package namespace.
 */
global class PackageUtilities {

    /**
     * @description Returns the current date as a Date object.
     * This method is declared 'global' so that subscriber orgs can call it.
     * @return Date The current system date.
     */
    global static Date getCurrentDate() {
        // In a real-world scenario, this method might perform more complex logic,
        // such as retrieving a formatted date based on package-specific settings,
        // or performing a calculation using package-defined custom metadata.
        return Date.today();
    }

    /**
     * @description An example of an internal method that is not exposed outside the package.
     * Declared as 'private', it can only be accessed within this class.
     */
    private static String getInternalMessage() {
        return 'This is an internal message from the managed package.';
    }

    /**
     * @description Another example of a global method that could take parameters.
     * @param String userName The name of the user to greet.
     * @return String A greeting message.
     */
    global static String greetUser(String userName) {
        return 'Hello, ' + userName + '! From Managed Package.';
    }
}

代码注释详解：

• global class PackageUtilities：声明一个 Apex 类为 global。这意味着该类不仅可以在软件包内部访问，也可以由安装了此软件包的任何其他 Salesforce 组织中的 Apex 代码访问。这是受管软件包向外暴露功能的主要方式。
• global static Date getCurrentDate()：声明一个静态方法为 global。静态方法可以直接通过类名调用，无需实例化对象。global 关键字使其可以在订阅者的组织中被调用。
• return Date.today();：这是一个简单的实现，返回当前的日期。在实际的受管软件包中，这里可能会包含更复杂的业务逻辑，例如从自定义设置或自定义元数据中读取配置，然后进行计算。
• private static String getInternalMessage()：声明一个 private 方法。private 方法只能在其声明的类内部访问，即使类是 global 的，此方法也无法从软件包外部调用。这体现了封装和知识产权保护的原则。
• global static String greetUser(String userName)：另一个 global 静态方法的例子，演示了如何接受参数并返回结果。

架构师的视角：

设计这样的全局类时，架构师需要考虑：

• API 稳定性：一旦一个 global 方法发布，就很难在不破坏现有订阅者定制的情况下修改其签名（方法名、参数类型、返回类型）。因此，API 设计需要经过深思熟虑，并尽量保持稳定。
• 输入验证和错误处理：所有 global 方法都应该包含严格的输入验证和健壮的错误处理机制，因为它们会被外部代码调用，外部代码的行为可能无法完全预测。
• 权限与安全性：调用 global 方法时，会以执行用户的权限运行。架构师必须确保这些方法不会暴露敏感数据或允许未经授权的操作。
• 资源消耗：global 方法中的逻辑会消耗调控器限制。需要确保其高效性，并考虑批量操作的场景。

通过这种方式，ISV 能够提供一个稳定的 API 接口，允许客户在不修改软件包核心逻辑的前提下，与软件包的功能进行交互或扩展。

---

注意事项

作为 Salesforce 架构师，在处理受管软件包时，无论是设计、开发还是评估，都需要关注以下关键注意事项：

1. 安全性审查 (Security Review)

对于计划发布到 AppExchange 的受管软件包，安全审查 (Security Review) 是强制性的。这是一个严格的过程，Salesforce 会对软件包的代码和配置进行深度分析，以确保其遵循最佳的安全实践，不会引入漏洞或风险。作为架构师，从设计阶段就必须将安全性嵌入到软件包的每一个层面：

• 防范 SOQL 注入和跨站脚本 (XSS - Cross-Site Scripting) 攻击。
• 正确使用权限集 (Permission Sets) 和配置文件 (Profiles) 来控制访问。
• 避免硬编码敏感信息。
• 遵循最小权限原则 (Principle of Least Privilege)。
• 使用 Salesforce 的安全 API，如 stripInaccessible 来处理字段级安全性。

2. 调控器限制 (Governor Limits) 的影响

前面提到，受管软件包代码消耗的调控器限制有其特殊性。虽然某些限制是独立计算的，但另一些是共享或累积的。架构师必须：

• 优化代码：确保所有 Apex 代码都高效、批量化，并最小化 SOQL 查询和 DML 操作的数量。
• 避免无限循环或递归：这些可能导致 CPU 时间超限。
• 考虑异步处理：对于长时间运行或资源密集型操作，应使用 异步 Apex (Asynchronous Apex)，如 Queueable、Batch Apex 或 Future Methods，以避免超出同步事务限制。
• 提供监控：设计机制来监控软件包在客户组织中的性能和资源消耗，以便及时发现和解决问题。

3. 可扩展性与向后兼容性 (Backward Compatibility)

受管软件包的成功在于其能够被客户广泛采用和定制。架构师需要精心设计可扩展性模型：

• 谨慎使用 global 关键字：一旦方法或类被定义为 global 并发布，更改其签名将是破坏性的。因此，API 接口设计必须稳定且深思熟虑。
• 使用接口 (Interfaces) 和抽象类 (Abstract Classes)：鼓励客户实现接口或继承抽象类来扩展功能，而不是直接修改软件包的代码。
• 自定义设置 (Custom Settings) 和自定义元数据类型 (Custom Metadata Types)：提供配置选项，允许客户无需代码修改即可调整软件包行为。
• 避免删除关键组件：在升级过程中删除已发布的组件可能会导致客户组织的错误。如果必须弃用，应遵循明确的弃用策略。

4. 错误处理与日志记录 (Error Handling and Logging)

健壮的错误处理和日志记录机制对于受管软件包至关重要：

• 统一的错误处理：在软件包内部建立标准化的错误处理流程，捕获异常并提供有意义的错误消息。
• 日志记录：为软件包提供内部日志记录功能，以便在生产环境中调试问题。可以考虑使用 自定义对象 (Custom Objects) 或外部日志服务来存储日志，避免过度使用 System.debug，因为它们会消耗调控器限制。
• 用户友好的错误信息：当发生错误时，向最终用户提供清晰、可操作的错误信息，并指导他们如何寻求支持。

5. 权限模型设计

软件包必须定义其组件所需的最小权限集。架构师需要：

• 提供权限集：而不是修改客户的配置文件。权限集是向特定用户授予软件包组件访问权限的首选方式。
• 字段级安全性 (FLS - Field-Level Security)：确保所有自定义字段都配置了适当的 FLS，以保护敏感数据。
• 对象级安全性 (OLS - Object-Level Security)：同样，自定义对象也需要适当的 OLS。

6. 外部集成 (External Integrations)

如果软件包需要与外部系统集成，架构师需要考虑：

• 认证机制：安全地管理 API 密钥、OAuth 令牌等凭据。
• API 限制：外部系统的 API 限制以及 Salesforce 的标注调用 (Callout) 限制。
• 幂等性 (Idempotency) 和重试机制：确保在网络故障或外部系统问题时，集成能够健壮运行。
• 使用命名凭证 (Named Credentials)：这是一种更安全的连接外部系统的方式，可以管理认证并在指定呼叫端点进行呼叫，同时避免在代码中暴露凭证。

7. 性能优化

软件包的性能会直接影响客户的用户体验。架构师应关注：

• 高效的 SOQL 查询：使用选择性查询，避免在循环中进行 SOQL 或 DML。
• 索引：为自定义对象和字段设计合适的索引。
• 异步处理：如前所述，利用异步 Apex 避免阻塞用户界面。
• UI 性能：优化 Visualforce 页面和 Lightning 组件的加载时间。

---

总结与最佳实践

作为一名 Salesforce 架构师，受管软件包是构建可持续、可扩展且安全的 Salesforce 解决方案的基石。它们提供了一种强大的分发和管理模型，尤其对于 AppExchange ISV 和大型企业内部应用分发至关重要。成功使用受管软件包需要全面的规划和严格的执行。

对 ISV (独立软件供应商) 的最佳实践：

1. 早期架构设计：从一开始就将软件包的生命周期、可扩展性、安全性、升级路径和调控器限制纳入设计考量。这将避免后期大量重构。
2. 命名空间策略：选择一个有意义且简洁的命名空间前缀，一旦确定就不能更改。
3. 模块化设计：将应用程序划分为逻辑模块，每个模块尽可能独立，减少相互依赖，便于维护和未来扩展。
4. API 优先原则：将软件包暴露给订阅者的功能视为公共 API。精心设计这些 API，确保其稳定、清晰且向后兼容。所有 global 方法应具有良好的文档。
5. 安全性根植于设计：遵循 Salesforce 的安全指南，确保通过安全审查。这不仅仅是合规性要求，更是建立客户信任的关键。
6. 全面的测试策略：在每次发布新版本前，进行彻底的单元测试、集成测试和用户验收测试 (UAT)。在不同的 Salesforce 版本和各种配置下测试软件包。
7. 周密的升级路径：规划好如何处理数据迁移、旧组件的弃用以及新功能的引入，确保升级对客户的影响最小。
8. 详细的文档：为管理员、开发人员和最终用户提供清晰、准确的安装指南、配置步骤、使用手册和开发人员指南。
9. 性能优化：持续监控和优化软件包的性能，确保它不会对客户组织造成不必要的资源消耗。
10. 灵活的配置：利用自定义设置和自定义元数据类型提供灵活的配置选项，减少对代码修改的需求。

对客户（软件包订阅者）的最佳实践：

1. 仔细评估：在安装任何受管软件包之前，仔细审查其功能、安全评级、AppExchange 评论、支持承诺和定价模型。
2. 始终在沙盒 (Sandbox) 中测试：在将软件包部署到生产环境之前，务必在沙盒中进行全面的测试，了解其对现有定制和数据的影响。
3. 理解权限模型：确保只授予用户所需的最小权限，而不是过度授权。
4. 监控调控器限制：了解软件包如何消耗组织的调控器限制，并监控其性能，以确保不会影响整体系统稳定性。
5. 规划升级：与 ISV 保持沟通，了解新版本的功能和潜在影响，并在升级前进行充分测试。

通过遵循这些最佳实践，无论是作为构建受管软件包的 ISV，还是作为利用受管软件包的客户，都能够充分发挥 Salesforce 平台的强大能力，实现高效、可靠且具有前瞻性的解决方案。受管软件包是 Salesforce 生态系统互联互通和创新的核心驱动力。