基于VTK的Web PACS实现

云PACS架构选择

云PACS实现有两种思路：基于服务器端渲染，前端只负责交互和最终结果显示。另外一种是在HTML+js实现所有渲染和图像处理，后端和传统PACS一样只负责数据管理和传输存储。

两种实现方式都没有什么难以克服的障碍。前端渲染有很多已经可以使用的开源库和商业库，比如vtk.js、leadtools。后端渲染主要是解决操作映射以及负载均衡，也有很多成熟案例和应用。目前的主要区别是对于高端影像设备生成的图像，经常超过1G，网络带宽和浏览器的内存往往不能很好支持，这样就需要做比较复杂的分层压缩和传输设计。后端渲染服务器和数据位于同一个数据中心，对于网络和处理能力设计要求相对较低，再运算能力不足的时候，可以通过简单的负载均衡方案扩容。

对于两种方案的选择，建议大公司、技术能力强的团队选择前端渲染，相信5-10年后网络带宽和终端处理能力会远超过医学影像设备的数据量增长，可以现在就做一个面向未来技术的方案。对于小公司、希望快速上线的团队，建议选用后端渲染方案，增加服务器的成本远远低于多招聘几个研发工程师的成本，前端渲染方案需要的技术能力也远比后端渲染高。

服务器端渲染云PACS设计和实现

服务器端渲染架构设计

只考虑一个用户，服务器端渲染需要解决的问题是：收到用户请求，Web服务器启动一个后端渲染库，把影像数据装载进来，根据模板或者用户再服务器的窗口中进行渲染。把渲染的结果编程图片返回给前端。如果GUI客户端的人对此都不陌生，显示的双缓存机制也是同样思路。当用户有新的操作，把操作转换成相应图像参数调整，再次把结果图返回给前端浏览器。

怎么样把这个工作扩展到多用户，需要两个步骤。
1. 怎么样在一台服务器上支持多个并发用户。需要Web服务器支持绑定客户端session和后台线程或进程。理想的状态，是每个用户session，服务器都能自动启动一个进程，把相应的请求转发给这个请求。同时，这个进程内可以实现单线程访问。这是和普通Web服务器有区别的点，普通Web服务器默认是无状态的。一个用户请求包含了所有信息。云PACS需要session保持机制，主要是因为DICOM数据量很大，如果每个请求都重新装载数据、设置参数进行渲染，性能肯定不满足要求。同时，一个进程如果同时装载几套数据，很快就会达到内存瓶颈，所以，不同用户最好使用独立进程。另外，Opengl的很多访问是不能跨线程的，所以，session还要能绑定到线程。
2. 更高层次是如何实现多服务器见的负载均衡。因为这个方案中服务器和客户端是标准的Http通讯。所以，各种流行的七层负载均衡软件都可以提供这种功能。唯一需要注意同样是需要session-sticky的机制，保持一个用户请求固定转发到一台服务器上。具体配置可以参考负载均衡软件的手册。

建议大家仔细阅读Paraview Web架构的相关文档。架构和思路讲解的非常清楚。

实现参考

如果对VTK有比较好的了解，有兴趣实现基于VTK的云PACS的人，可以参考这个项目。https://github.com/xikuibin/WebVtk

这个项目目的式给出服务器端实现的样例。由于一些原因，暂时不打算把这个做成真正的云PACS。如果有人愿意参考此方案，做真正开源的云PACS，可以邮件联系。

对于想做商业方案的公司，请尊重VTK和Wt的相应许可限制。

实际部署建议用Ubuntu Linux，主要原因是支持VTK最好的平台是ubuntu。使用CentOS/RedHad系列支持VTK有太多坑就不要尝试了。