COM+编程实战：从COM到企业级组件服务

简介：COM+编程资料包是一套面向企业级开发者的组件服务学习资源，聚焦COM+在事务、安全、事件、并发及分布式场景下的实际应用，适合已掌握COM基础并希望进阶的读者。包体共1339个文件，以cpp、h源代码文件为核心，辅以idl接口定义、def模块定义、rc资源脚本、rgs注册脚本及工程文件dsp/dsw，完整呈现COM+组件从编写、注册到部署的工程结构，整体仅836KB。已有187人学习下载。资源内含多个可编译示例项目，涉及客户端调用、监听器、事件探索、员工工资计算等业务场景，通过阅读源码与工程配置，可直观理解组件注册流程、MTS与COM+的演进关系、对象激活策略以及DCOM分布式交互机制。同时，附带的vbs脚本与makefile提供了自动化构建与配置思路，能帮助读者快速搭建实验环境，掌握ATL/MFC框架下的COM+开发技巧。 我早些年做Windows桌面开发的时候，接手过一套老系统，底层全是COM组件，业务逻辑跑在ASP页面里，数据库操作封装在VB6写的ActiveX DLL中。那时候我刚从C/S架构转过来，第一次面对“COM+”这个概念，翻了一堆文档，看了一堆名词——组件服务、对象池、事务、JIT激活——头都是大的。后来在实际项目里反复折腾，才慢慢把这些概念和真实场景对应起来。

这篇文章就围绕COM+编程展开，把我踩过的坑、理清楚的原理、以及实际项目中用得上的配置方法写出来。内容会涉及COM+的底层机制、事务处理、对象池、安全配置、以及与.NET互操作等几个关键方向，适合正在做Windows平台服务端开发、或者维护老旧COM+系统的朋友参考。

1. COM+到底是什么：从COM到COM+的演进逻辑

1.1 COM解决的是“组件复用”，COM+解决的是“企业级服务”

要理解COM+，得先从COM说起。COM（Component Object Model）解决的核心问题是：让不同语言、不同模块之间能够以二进制标准进行组件复用。你用一个C++写的COM组件，VB可以调用，ASP也可以调用，只要遵循COM接口规范就行。这套规范定义了IUnknown接口、引用计数、GUID标识、注册表登记等一套规则。

但COM本身只是一套组件通信协议，它不关心你部署在哪里、怎么管理并发、怎么保证事务一致性、怎么控制对象的生命周期。这些是企业级应用必须面对的问题。COM+正是为了解决这些问题而生的——它是一组运行在Windows上的服务，这些服务被集成在“组件服务”管理单元中，为COM组件提供进程管理、事务支持、对象池、即时激活、队列组件、安全角色等能力。

1.2 我理解的COM+最核心的几个服务

拿实际使用频率来说，我认为COM+最值得关注的是这几个：

• JIT激活（Just-In-Time Activation）：客户端调用对象方法时，组件服务才创建对象实例；方法调用结束后，对象可能被立即释放。这样做的目的是节省服务器资源，避免大量客户端各自持有长期存活的对象。
• 对象池（Object Pooling）：对象创建代价高时，把对象放进池里反复复用，减少创建和销毁的开销。但有个硬性要求——对象必须是无状态的，或者说能把状态重置为初始状态。
• 分布式事务（Distributed Transaction）：COM+可以自动将多个资源操作（如数据库、消息队列）纳入同一个事务，通过MSDTC（Microsoft Distributed Transaction Coordinator）协调两阶段提交，保证数据一致性。
• 基于角色的安全（Role-Based Security）：可以在组件服务中定义角色，将用户或用户组映射到角色，然后在组件代码里通过安全检查控制方法的访问权限。

1.3 一个直观的类比

如果把COM+比作一个酒店，那COM组件就是入住酒店的客人。COM只负责客人从哪里来、长什么样（接口定义）；而COM+负责的则是：客人什么时候能入住、住多久（JIT激活）、房间怎么周转复用（对象池）、客人之间的账怎么统一结算（事务）、哪些人能进哪些楼层（角色安全）。这套类比虽然不精确，但对初学者的理解非常有帮助。

2. 写一个COM组件并通过COM+注册：从VB6到C++的实操路径

2.1 用VB6创建一个COM+组件：最直观的入门方式

虽然VB6已经很老了，但用它来理解COM+的运作流程仍然是最快的。打开VB6，新建一个ActiveX DLL工程，添加一个类模块，代码如下：

Public Function Add(ByVal a As Long, ByVal b As Long) As Long Add = a + b End Function

编译成DLL后，打开“组件服务”——“组件”——“新建应用程序”，创建一个空的COM+应用程序，然后把DLL里的组件导入进来。导入后在组件上右键选择“属性”，能看到“事务”、“激活”、“并发”等选项卡，这里就是配置COM+服务的入口。

看起来很简单对吧？但这里有一个关键点：VB6的类模块默认支持对象池吗？不支持。VB6组件如果要用对象池，必须在属性里做额外设置，而且类模块不能持有客户端状态。我早期在这里栽过跟头——想当然地把数据库连接放在组件成员变量里，开启对象池后，第二个客户端拿到的对象状态是乱的。

2.2 用C++/ATL实现COM+组件：理解底层机制

用VB6写组件虽然快，但对理解机制无益。后来我用ATL重写组件，才真正看到COM+服务是怎么介入的。

在C++中创建一个支持COM+的组件，核心步骤包括：

• 定义一个继承自IDispatch或IUnknown的接口；
• 实现IClassFactory，并在GetClassObject中调用CoRegisterClassObject注册类工厂；
• 在DLL入口函数DllGetClassObject中导出类工厂；
• 通过组件服务管理单元将该DLL配置为COM+应用程序。

关键代码大致长这样：

class CMyComponent : public IDispatch { public: // IUnknown methods STDMETHODIMP QueryInterface(REFIID riid, void** ppv) { ... } STDMETHODIMP_(ULONG) AddRef() { return ++m_refCount; } STDMETHODIMP_(ULONG) Release() { if (--m_refCount == 0) { delete this; return 0; } return m_refCount; } // IDispatch methods STDMETHODIMP GetTypeInfoCount(UINT* pctinfo) { ... } STDMETHODIMP GetTypeInfo(UINT iTInfo, LCID lcid, ITypeInfo** ppTInfo) { ... } STDMETHODIMP GetIDsOfNames(...) { ... } STDMETHODIMP Invoke(...) { ... } // 自定义方法 STDMETHODIMP Add(long a, long b, long* result) { *result = a + b; return S_OK; } };

用ATL的话，这些都被封装好了，但我想强调的是：只有理解了手动实现COM接口时的那些细节——比如QueryInterface的规则、引用计数的生命周期、IDispatch的Invoke分发机制——你才能真正理解为什么COM+能对组件做那些“魔法”操作。COM+能拦截对象调用，靠的正是接口层面的代理与存根机制。它插入在你和组件之间，你调用方法时，先经过COM+的拦截器，再由拦截器转发给真实对象。

2.3 注册与配置的完整步骤

无论用哪种语言编写组件，最终都要经过下面这几步：

1. 编译生成DLL；
2. 使用regsvr32注册组件，或者直接通过组件服务导入DLL（组件服务会自动注册）；
3. 在组件服务中创建COM+应用程序，指定激活类型（库应用程序还是服务器应用程序）;
4. 将DLL中的组件添加到应用程序中；
5. 配置事务、安全、对象池等属性。

这里有个容易混淆的概念：库应用程序（Library Application）和服务器应用程序（Server Application）。库应用程序运行在客户端进程内，性能好，但没有独立的进程隔离；服务器应用程序运行在独立的DLLHOST.EXE进程中，崩溃不拖累客户端，但跨进程调用有性能损耗。我一般建议：如果组件要被多个客户端共用、且必须保证隔离性，用服务器应用程序；如果是在同一个进程内高频调用，追求性能，用库应用程序。

3. 事务集成：COM+分布式事务的工作机制与实操配置

3.1 为什么需要COM+事务，而不用数据库事务

单库单表操作，数据库自己的事务完全够用。但当业务跨多个数据库、多个消息队列，甚至涉及多个异构资源时，数据库事务就管不了了。COM+事务的价值在于：它横跨多个资源管理器，统一协调提交或回滚。

我做过一个典型的例子：订单系统创建订单后，需要写订单库、扣减库存库、向消息队列发送一条通知。这三个操作分布在两个数据库和一个消息队列中，任何一个失败，其他操作就必须回滚。这种情况下，我在COM+组件上设置事务属性为“需要事务”（Required），组件方法内部对三个资源管理器进行操作，任何一步抛出异常，调用ContextUtil.SetAbort()，整个分布式事务就回滚了。

3.2 代码层面的事务控制

在Vb6或C++组件中，事务控制主要靠两个方法：

• ContextUtil.SetComplete()：表示组件工作完成，事务可以提交；
• ContextUtil.SetAbort()：表示组件工作失败，事务需要回滚。

C++中通过IGetContextProperties或IContextState接口访问COM+上下文。典型代码：

IContextState* pContextState = NULL; HRESULT hr = CoGetObjectContext(IID_IContextState, (void**)&pContextState); // 如果数据库操作失败 pContextState->SetDeactivateOnReturn(TRUE); pContextState->SetMyTransactionVote(TxAbort); // 如果全部成功 pContextState->SetDeactivateOnReturn(TRUE); pContextState->SetMyTransactionVote(TxCommit);

这里有个关键细节：SetDeactivateOnReturn(TRUE)表示方法返回后对象应被停用，配合对象池使用时，对象会被归还到池中并重置。而事务投票（Transaction Vote）必须显式设置，否则COM+默认认为组件没有明确表态，会按失败处理。这是我踩过的一个坑——组件方法明明执行成功，但事务还是回滚了，查了半天，发现是忘了设置Transaction Vote。

3.3 事务超时与性能开销

COM+默认事务超时时间是60秒，可以在组件服务中修改。实际项目里，我一般把事务超时设置成30秒，因为一个事务涉及多个资源管理器，等待时间过长会拖累系统吞吐量。但也不能太短，否则网络抖动会让大量事务被误判为超时。调优思路是：先根据业务高峰期事务平均耗时设定一个基础值，再乘以2~3倍作为超时阈值。

分布式事务的性能开销主要在两阶段提交：第一阶段，事务管理器询问所有资源管理器“能提交吗？”；第二阶段，如果所有资源管理器都回答“能”，事务管理器才发送“提交”指令。这个过程中，除了网络往返，还有日志写入和锁竞争。所以，能用单库事务解决的场景，不要用COM+事务；只有跨资源、跨库、跨队列的场景才值得。

4. 对象池与JIT激活：性能调优的核心

4.1 JIT激活的工作机制

COM+的JIT激活机制经常会让人困惑：客户端持有的对象，实际上可能已经被COM+释放了。客户端以为自己在调用一个持久对象，实际上每次调用都可能是新对象。

机制是这样的：客户端调用方法A，COM+创建一个组件实例，执行完毕，如果组件设置了JIT激活，COM+立即停用对象。客户端再次调用方法B时，COM+重新创建实例。对客户端来说，整个过程是透明的，它始终持有一个指向代理的接口指针。这种设计带来的最大好处是：服务器端不会因为大量客户端持有对象而耗尽资源。

代价是：组件不能依赖成员变量在多次调用之间保存状态。如果你需要状态保持，要么通过参数传递，要么使用带状态的共享资源（如数据库、内存缓存）。这一点在组件设计中一定要提前规划，否则代码写了一半再改架构，很痛苦。

4.2 对象池配置策略

对象池让创建成本高的对象可以复用。配置项包括：

• 创建对象数上限：池中最多容纳多少个对象；
• 创建对象数下限：池启动时预创建多少个对象；
• 对象超时时间：从池索取对象的等待时间上限；
• 构造函数参数：部分语言/场景下用来初始化对象。

我建议下限不要设太大，因为预创建对象需要耗资源，如果业务高峰来得晚，这些对象在池里闲着也是浪费。上限要根据并发峰值来估算：假设每个客户端请求平均占用对象时间50毫秒，每秒有100个请求，那么同时需要的对象数大约是5个，考虑波动，上限设在10~20个比较稳妥。

需要注意的是，放入池中的对象必须实现IObjectControl接口。这个接口有三个方法：Activate（对象被从池中取出时调用）、Deactivate（对象被归还池中时调用）、CanBePooled（对象是否可以放入池中）。只有CanBePooled返回True的对象才会进入池中。

class CMyPooledObject : public IObjectControl { public: STDMETHODIMP Activate() { // 从池中取出时，重置状态 return S_OK; } STDMETHODIMP_(BOOL) CanBePooled() { return TRUE; } STDMETHODIMP_(void) Deactivate() { // 归还池中时，清空资源 m_pConnection = NULL; } };

4.3 一个实际调优案例

我之前维护的一套系统中，有个组件每次创建都要建立数据库连接，创建成本很高。最初没开对象池，压测时TPS只有200，CPU占用居高不下，大部分时间花在连接建立和销毁上。后来把这个组件配置成对象池，下限设5、上限设20，同时把数据库连接放在Deactivate时清空、Activate时重新绑定，TPS提升到了1500左右，CPU占用降了40%。当然，这个数字和业务复杂度、数据库响应速度都有关，但方向是对的：把高成本对象放进池里，能立竿见影地降低系统开销。

JIT和对象池是搭配使用的：JIT负责及时释放对象，对象池负责让释放的对象不要真正销毁，而是回到池中复用。两者配合，服务器资源利用率能明显提升。

5. 安全模型与角色配置：别把权限写在代码里

5.1 基于角色的安全

COM+的安全模型基于角色（Role）。角色是一个逻辑分组，可以映射到Windows用户或用户组。在组件服务管理单元中，可以为应用程序添加角色，然后为组件的方法分配角色权限。

比如订单系统里，你可以定义“订单查询员”和“订单管理员”两个角色。订单查询员只有查询方法的权限，订单管理员可以修改订单状态。这个权限分配发生在组件服务管理工具中，代码层面只需要检查当前调用者是否具有某个角色。

5.2 代码中检查角色身份

C++中通过ISecurityCallContext接口获取安全信息：

ISecurityCallContext* pSecCtx = NULL; hr = CoGetCallContext(IID_ISecurityCallContext, (void**)&pSecCtx); VARIANT_BOOL bIsInRole = FALSE; BSTR bstrRole = SysAllocString(L"OrderAdmin"); pSecCtx->IsCallerInRole(bstrRole, &bIsInRole); SysFreeString(bstrRole); if (bIsInRole == VARIANT_TRUE) { // 允许执行管理操作 } else { // 拒绝访问 }

这里要注意一个概念：CoGetCallContext获取的是调用上下文，不是对象上下文。它在COM+服务器应用程序中可以用，但在库应用程序中，调用上下文的行为可能不同。如果组件要同时支持两种激活模式，我建议在组件属性里启用“组件级别安全”或“应用程序级别安全”配置，让安全配置尽量在管理工具层面解决，代码层面只做兜底。

5.3 安全配置中的常见坑

常见的坑有三个：

1. 开发机器上调试一切正常，部署到服务器后组件方法全部报权限错误。原因是组件服务中的应用程序身份（Identity）没有配置正确，默认可能是“交互式用户”，在服务环境下无法正常创建窗口或访问资源。
2. 角色配置了，但请求还是被拒绝。需要检查组件的“安全”选项卡，看是否误开了“禁用安全检查”，或者是IIS进程的匿名用户没有映射到任何角色。
3. 在库应用程序中，角色检查不生效。库应用程序运行在客户端进程内，安全上下文继承自客户端，COM+自身的角色检查效果很弱。所以，严格的安全控制，应该放在服务器应用程序中。

5.4 身份与进程账号的设置

在“组件服务”中右键应用程序选择“属性”，切换到“标识”选项卡，可以设置该应用程序运行的身份。默认是“交互式用户”，当你在远程服务器上部署时，这个选项几乎一定出问题。正确做法是设置一个专用的服务账号，授予“作为批处理作业登录”的权限，这样组件服务才能用该账号启动进程、访问数据库、读写文件。

如果数据库账号也用了Windows身份验证，还要给这个服务账号授予数据库的登录权限。我在项目里通常会建一个叫“COMPlusService”的专用账号，独立于系统管理员账号，这样即便组件代码被攻破，影响范围也有限。

6. 与.NET互操作：现代技术栈如何接入COM+

6.1 .NET程序集作为COM+组件注册

.NET发展了这么多年，很多老系统的COM+组件正在逐步被替换或封装。但不少企业的核心业务仍然跑在COM+上，新系统需要和这些老组件交互。这时候，互操作能力就很关键。

如果你用C#编写类库，并希望它作为COM+组件使用，需要做这几件事：

1. 给类添加[ComVisible(true)]属性；
2. 使用[Guid]显式指定GUID，避免每次编译都生成新GUID；
3. 在项目属性中勾选“为COM互操作注册”；
4. 在类上添加[Transaction(TransactionOption.Required)]以配置事务行为；
5. 通过组件服务管理单元将程序集添加到COM+应用程序中。

using System.EnterpriseServices; [assembly: ApplicationName("MyComPlusComponent")] [assembly: ApplicationActivation(ActivationOption.Server)] [Transaction(TransactionOption.Required)] [ComVisible(true)] [Guid("A1B2C3D4-...")] public class OrderService : ServicedComponent { public void CreateOrder(OrderRequest request) { try { // 数据库操作 ContextUtil.SetComplete(); } catch { ContextUtil.SetAbort(); throw; } } }

6.2 在.NET中调用老COM+组件

反过来，如果你要在.NET中调用已有的COM+组件，方法更简单：在Visual Studio中添加对COM组件的引用，IDE会自动生成Interop程序集，你就能像调用普通.NET类一样调用COM+组件了。

这里有个性能细节：跨进程调用COM+组件会有明显的性能损耗，因为需要走RPC（远程过程调用）。如果调用非常频繁，建议把组件作为库应用程序部署在调用方进程中，或者考虑用本地消息中间件做异步化改造。不要盲目地把所有老组件的调用方式从同步改为异步，异步会引入消息丢失、重复消费、顺序问题，调起来很费劲。

6.3 迁移与替换的实践建议

老系统的COM+组件迁移到.NET Core/.NET 5+，最麻烦的地方在于：System.EnterpriseServices命名空间在.NET Core及后续版本中已经没有了。ServicedComponent、ContextUtil这些类都不再可用。如果必须保留COM+功能，我的建议是：保留一个单独的.NET Framework服务或进程来承载这些类，通过WCF或gRPC对外提供服务，让新系统不再直接依赖COM+。

如果新系统只是需要读取老COM+的数据，更稳妥的方案是先让老系统把数据导出到共享数据库或消息队列，新系统消费这些数据。这样解耦，比直接对老组件做远程调用更可控。

7. 排错经验与性能监控：那些让我熬到凌晨的问题

7.1 组件服务日志：先看事件查看器

COM+运行出问题时，第一反应不应该是去翻代码，而是打开事件查看器，查看“Windows日志——应用程序”。COM+服务的大量错误信息都会记录在这里，包括：

• 组件无法加载：通常是DLL缺失或依赖项未注册；
• 权限不足：可能是身份配置问题；
• DTC事务失败：需要检查MSDTC服务是否启动、网络是否允许RPC通信；
• 对象池创建失败：可能是构造函数抛出异常。

我见过的很多问题，其实事件查看器里都写得很清楚，只是没人去看。排查COM+问题，日志永远是最直接的线索。

7.2 常见错误码与处理

7.3 性能监控的两个工具

我实际用下来最有用的两个监控手段：

1. 系统监视器（Perfmon）：添加“COM+ Performance”计数器，能看“对象池命中率”“活动对象数量”“组件实例创建速率”等指标。池命中率如果长期低于60%，说明池的配置不合理，要么是池容量太小，要么是对象状态没控制好导致不能复用。
2. 组件服务管理单元的“正在运行的对象”视图：能看到当前进程内所有COM+对象的数量。如果数量居高不下，且不是正常的并发高峰，很可能是有组件没有正确归还或释放，导致对象泄漏。

7.4 一次真实的COM+事故复盘

有一次线上系统突然卡死，请求全部超时。排查过程让我印象很深。第一反应查数据库，数据库CPU正常、连接数正常。然后查IIS，也没发现异常进程。最后打开组件服务，看到DLLHOST.EXE进程CPU占满。

进一步排查发现，某组件开启了对象池且上限设为1000，而每个对象的Activate方法里都要执行一次数据库连接池初始化。理论上这些操作应该很快，但因为业务高峰期所有请求同时涌进来，池中对象被并发索取，Activate不断执行，数据库连接池被打满，后续请求全部等待数据库连接释放，形成连锁阻塞。

当时的解决方案是：把对象池上限调低到100，增加Activate中数据库连接操作的等待时间限制，同时优化数据库连接池配置。处理完系统恢复正常。这次事故给我的教训是：对象池并不是越大越好，要结合下游资源的承载能力综合考虑。池容量大但下游资源跟不上，等于把瓶颈从对象创建转移到了下游，问题的本质没有解决。

8. 什么场景真正值得用COM+，什么场景应该远离

8.1 值得用的场景

• 老系统维护：既有系统已经运行多年、稳定可靠，业务逻辑大量依赖COM+事务，这时候没必要为了“技术老旧”而强行重构。老技术能稳定创造价值，那就是好技术。
• 严格的事务边界需求：多个异构资源（数据库、消息队列、文件系统）之间的强一致性要求，COM+的分布式事务是现成方案。
• Windows环境内网系统：整个部署环境都是Windows，客户端和服务器都在同一域内，COM+的集成度和部署便利性很高。

8.2 应该远离的场景

• 跨平台需求：COM+是Windows专属技术，Linux、macOS都跑不了。如果系统可能需要跨平台部署，COM+一定是错误的选型。
• 高并发互联网应用：COM+的进程模型和分布式事务在大规模互联网场景下扩展性有限。互联网高并发系统普遍采用最终一致性、消息队列、事件溯源等方案，要求的是随时横向扩展，COM+不合适。
• 微服务架构：微服务讲究独立部署、独立扩展，每个服务可以有自己的数据库和事务边界。COM+强调的是组件共享容器和统一事务，这种理念与微服务完全相反。

8.3 我的选型心法

做技术选型时，我一般会问三个问题：

1. 这套系统会运行多久？如果预期运行5年以上，老技术的长期维护成本要算清楚。
2. 事务一致性是硬需求还是软需求？如果业务上允许短暂不一致，消息队列加重试机制比分布式事务更简单。
3. 团队对这个技术栈的熟悉程度如何？团队完全没有COM+经验，贸然上这个技术，学习成本会消耗掉很多项目时间。

COM+这个技术虽然越来越冷门，但它的设计思想——容器托管、声明式事务、对象池、角色安全——在现代框架中依然有迹可循。理解COM+，其实也是在理解企业级组件运行时的基本问题域。

最后分享一个个人习惯：每接到一个和COM+相关的任务，我都会先在本地把“组件服务控制台——事件日志——Perfmon”这三件套准备好。遇到问题，先看日志，再看监控，最后才动代码。顺序反了，往往会在错误的方向上浪费很多时间。这套排查逻辑，其实也适用于今天的大多数服务端系统。

本文还有配套的精品资源，点击获取