跨负载均衡器的 ItextSharp 实现



我们正在评估ITextSharp(现在称为IText(用于生成pdf文档。这将用于我们的网站,这些网站将通过多个服务器的负载平衡解决方案发布。

根据Itext的说法,这将需要在我们的负载平衡配置中每台服务器(我们不是开源的(的生产许可证,以及uat和开发人员许可证。这显然是一项相当大的投资。

谁能推荐任何替代方案来降低成本?

另外,如果我们要使用其他产品,我们是否可以采用一种模式来最大限度地减少现有网站原型的迁移工作?

您可以稍微更改一下体系结构,并拥有一个专用的PDF生成服务器。 然后,您需要将请求归结为可以在服务器之间发送的内容。 根据您的目标,这可能是相对简单的内容,例如用户 ID 和报表名称,也可能是复杂的(文本布局,那里的图像(。

就与商业iText保持距离而言,有两种选择。

1(使用较旧的MPL iTextSharp。 它不会拥有所有最新的功能和错误修复,但很难击败价格。

2("包装器"设计模式。 构建一个相对通用的接口,并将该接口的当前实现放在 iText 之上。 如果以后需要将其换出,则重新生成粘附代码,而不是整个应用。

最新更新